Как быть медлительному разработчику?

Question

[inavo]

Добрый! основной вопрос понятен из заголовка, суть такова: я джун уже больше полугода, и за это время зафейлил большую часть сроков по таскам. При этом стараюсь писать план, что буду делать, беру время с запасом, но часто и того не хватает. Могу зависнуть на какой-нибудь фигне. Всё это сильно удручает.

Подскажите, как вы ведете задачи, чтобы укладываться в сроки?

И не по теме, как относитесь к медлительным коллегам?

Comments

[Strannyk]

Задачи сами эстимируете?

Могу зависнуть на какой-нибудь фигне.

Частая ошибка. Определите время, которое можете потратить на пробуксовку (час, например) и по истечении его обращайтесь за помощью.

[Ярослав Александров]

Как быть медлительному разработчику?

- перестать быть тупым и ленивым
- работать над своей силой воли
- повышать самодисциплину
- постоянно повышать свои навыки и квалификацию, включая в свободное от работы время.

как относитесь к медлительным коллегам

а как бы вы отнеслись к адвокату, когда у вас заседание, прошёл месяц, но документы адвокат не сделал, потому что он "медлительный".
Медлительный = плохой специалист.

[Алекс Поз]

Стыдно признаться, но сам таким был. Наверное первые года три тупил и скрывал сроки (пошёл работать на 2.5 курсе из 5). Сложно было въезжать в проект, мало знаний, опыта 0, оценка была с расчётом на мидла. Было не просто, но я выжил))

[Игорь Воротнёв]

Ярослав Александров,

- перестать быть тупым и ленивым

Перестать быть мудаком который дает тупые демотивирующие советы начинающим

- работать над своей силой воли

Силы воли не существует, это дремучий миф 19-20 века. Существует сложная биохимия мозга, которую далеко не всегда можно изменить/контролировать.

- повышать самодисциплину

Это не решает причины медленной работы, зато повышает уровень стресса. И в итоге приводит к отрицательным результатами (см. про биохимию мозга).

- постоянно повышать свои навыки и квалификацию, включая в свободное от работы время

Необходимо так же меньше работать, больше отдыхать. Уставший мозг не только хуже работает, но и опять же страдает биохимия мозга.

В общем, все четыре "совета" - вредны. Все эти ваши силы воли, самодисциплины, мужики не жалуются и тд - одна из главных причин почему среднестатистический русский мужик бухает, рано умирает, а часто еще и от собственных рук. Прекратите жить в 19м веке.

Автору - не слушайте подобных советов, они вредны. С вами все в порядке, все через это проходили. Посмотрите мой ответ ниже.

[Ярослав Александров]

Игорь Воротнёв, мудака в зеркале увидишь

[nozd up]

Strannyk, плюсую: у нас убрали джуна с испытательного срока, потому что не смогли донести до него: начинаешь пробуксовывать - обращайся за помощью.

[freekir]

Strannyk, nozd up, Оно хорошо, когда есть к кому обратиться и когда даже вроде есть к кому они могут не отвечать. Не во всех компаниях сразу 1000 старших разрабов спешащих тебе на помощь имеется в наличие.

Answer 1

[Дмитрий]

Это же все относительно. Кто-то работает быстрее кто-то медленнее. Это ваш темп, если вы помимо решения задач еще и будете грузиться скоростью - на пользу не пойдет. Ну зафейлили значит зафейлили, кто сказал, что сроки были корректные.

Answer 2

[Robur]

уже больше полугода, и за это время зафейлил большую часть сроков по таскам

Я за последние 8-10 лет зафейлил большую часть сроков по таскам. Потом понял что проблема в сроках.

беру время с запасом, но часто и того не хватает.

Какой запас? Есть давно выведенный эмпирический закон - оценку опытного разработчика надо умножать на pi, если вы джун и сами время определяете, то 2*pi, если вы хотите работать хардкорно, и 3*pi если более близко к реальности.

Подскажите, как вы ведете задачи, чтобы укладываться в сроки?

Надо ставить реальные сроки. Но оценка - одна из самых сложных задач. Если только вы не клепаете конвеером одно и то же. Ну и анализ постфактум, то что реально можно улучшить-изменить, надо исправлять.

И не по теме, как относитесь к медлительным коллегам?

Если работают хорошо и ответственно - то хорошо отношусь, если работают плохо и через жопу то плохо.
Если медлительность объективна - то всегда есть причина и с ней можно поработать. Но не всегда даже и нужно.

Я например могу сделать что-то супербыстро, пока мне объясняют задачу, в стиле "х**к, х**к и в продакшен", но предпочитаю делать дольше но лучше. Поэтому таски закрываю позже чем мог бы, но это такой код и результат, в котором я и окружающие уверены. Он и через полгода будет хорош, и багов в нем на порядок меньше.

Comments

[serega011]

Если у вас не супер интеллектуальные задачи, то оценка хоть и трудная задача, но вполне реальная даже джунам. Умножать на пи должен не программист, он должен более или менее корректно оценить. Умножить на e или пи или 2 может менеджер. А программисту надо учиться нормально оценивать и искать пути решения задач, а не сидеть и тупить.

Answer 3

[Иван Шумов]

1. Если ты джун то у тебя должен быть куратор или наставник. Если нет то ты пришел работать куда-то не туда.
   
2. Если тупишь и не можешь решить задачу то во-первых надо научиться задавать вопросы коллегам, а во-вторых научиться повышать квалификацию
   
3. Когда ты джун то стоит забыть что рабочий день 8 часов. Твой рабочий день - 24 часа минус небольшие перерывы на сон и еду. Если ты, конечно, не пришел просто "за деньгами" в IT
   
4. Если бы у меня джун за полгода не вырос и не стал бы нормально работать на проекте - я бы его уже уволил и взял другого. Я бы сказал что такой человек у меня испыталку не прошел
   

Comments

[inavo]

1. дергать куратора по каждому вопросу не есть гуд

2. задача в итоге всегда решается, но гораздо медленнее чем хотелось бы и могла бы.
Повышать квалификацию вы имеете ввиду домашние проекты?

3 .24/7 уже проходили, обычно это заканчивается моральным и/или физическим истощением, но всё равно 10 в день точно уходит

[Иван Шумов]

1. дергать куратора по каждому вопросу не есть гуд

Этот человек именно для этого и существует. Это заложено в его рабочее время и если он этим не занимается, а подопечный проваливает сроки это в первую очередь проблема куратора

Повышать квалификацию вы имеете ввиду домашние проекты?

Как один из вариантов

3 .24/7 уже проходили, обычно это заканчивается моральным и/или физическим истощением, но всё равно 10 в день точно уходит

Ну, могу только посочувствовать. Нового джуна найти на позицию проще всего. Выглянуть на улицу и поймать себе джуна вместо уволенного - дело минут 15-и, как бы. Тут либо надо пахать и держаться за позицию, показывая что ты можешь, либо же ждать увольнения

[Daria Motorina]

inavo, 24/7 это стопроцентное выгорание, зачем нужен куратор, который относится к джуну как к говну? Любой работодатель может найти себе классного спеца, как говорит Иван, но что-то не нашел и внезапно у него медленный джун, а мог бы быть миддл с тремя годами опыта и той же зарплатой (сарказм). Учиться нужно, но не ценой собственного здоровья и психики.

[Иван Шумов]

Daria Motorina, те кто приходил в IT по зову сердца и по тому что действительно нравится эта сфера - что в начале, что сейчас тратят львиную долю своей жизни на саморазвитие. рабочий день это не значит что ты работаешь над задачами все это время. Это и общение с коллегами и развитие в том числе. Поэтому когда я говорю про работу 24/7 это в первую очередь работа над собой

[Дмитрий]

inavo, У меня отец когда делал ремонт в своей огромной 150-метровой квартире, ему чтобы положить на пол плитку порекомендовали очень хорошего спеца, но предупредили что он делает все на совесть но очень медленно. Они согласились. Работал спец 8 месяцев, фактически как третий член семьи с отцом и его женой. Но положил все на совесть и абсолютно никуда не торопился.

[Daria Motorina]

Иван Шумов, приход в IT по зову сердца это идеализация образа и ломание неокрепшей психики, это не Спарта и не поле боя на жизнь и на смерть. Безусловно нужно развиваться и нести ответственность за свою работу, но обобщать на всех образ жизни матерых энтузиастов это неправильно. Энтузиасты и двигатели прогресса занимают свою нишу, а ремесленники свою и каждый из них найдет свое место в профессии, если захочет.
Ваша точка зрения верна, но не единственно правильная.

[Иван Шумов]

Daria Motorina, ремесленники в IT выживают только в одном месте - в аутсорсинге где их тысячи в одной компании и только в том случае если их поставили на поток как винтики. В остальных компаниях дауны, увы, долго не держатся если они не способны быстро адаптироваться и развиваться.

[Daria Motorina]

Иван Шумов, Ваше право считать как хотите

[Иван Шумов]

Daria Motorina, у меня был опыт со всех сторон баррикад просто

[Северное Сияние]

Когда ты джун то стоит забыть что рабочий день 8 часов. Твой рабочий день - 24 часа минус небольшие перерывы на сон и еду

От такого действия результат будет один - выгорание.
В РФ программистам платят не такие баснословные деньги, что бы убивать себя 24 часа за посредственные деньги.

те кто приходил в IT по зову сердца и по тому что действительно нравится эта сфера - что в начале, что сейчас тратят львиную долю своей жизни на саморазвитие

саморазвитие - это термин ТП-зд. Никакой львиной доли жизни не нужно тратить на работу, комментатор выше правильно написал, "это не Спарта и не поле боя на жизнь и на смерть", это всего лишь работа, с которой в случае необходимости, тебя выкинут на мороз без сожаления. Идеализировать так работу и возводить её во главу угла может как раз только новичок в этой сфере. Опытный разработчик относится к работе как к работе, выключает комп в 18 часов и идёт отдыхать.

[Иван Шумов]

Bavashi, этот случай в контексте данного вопроса не рассматривается как минимум по тому что я говорю про отклонение сотрудника на испытательном сроке работодателем. В данном вопросе человек уже проработал 6 месяцев, а значит что ИС уже снят. Кроме того джуны очень редко перерастают бывших наставников. Проблема банальная - разница во времени старта и разница в опыте на момент расставания. Сначала разрыв быстро сокращается, но потом разница в темпе практически нивелируется на дистанции лет 10 и более и догнать наставника становится почти невозможно.

[Иван Шумов]

Bavashi, я с этим полностью согласен, просто мы живем в мире капитализма и сегодня это банально не выгодно бизнесу. Я сам начинал заниматься IT когда еще ходил в среднюю школу и до сегодняшнего дня считаю что поддержка и помощь в коллективе и сообществе - максимальная ценность, которую можно иметь. Но. Бизнес против

[Иван Шумов]

Bavashi, ну, вообще-то именно так и происходит. Джунов берут в основном туда где их обучение поставлено на поток и где они заложены в бизнес-модель. Это аутсорсинг и крупные комании с IT отделами от нескольких десятков людей. В остальных случаях джунов берут от нищеты бюджета. В большинстве своем бизнес ориентируется на миддл+ уровень по тому что требуется продукт и нет бюджетов на размусоливание и не охота ни с кем нянчиться.

Тут такая история - джун это дешевая рабочая сила. Полгода одного джуна редко сильно заметно на фоне проекта, даже если он занимает время наставника. Если он занимает слишком много этого времени то его уже можно увольнять и искать следующего. Обычно это выясняется после 2 месяцев ИС

[Иван Шумов]

Bavashi, это понятно, но в контексте данного топика на этом ресурсе эту сторону вопроса рассматривать вообще бесполезно)

Answer 4

[xmoonlight]

Подскажите, как вы ведете задачи, чтобы укладываться в сроки?

никак.
1. Нужно делать то, за что платят. И делать это - на совесть.
2. Нет опыта/знаний - нужно получать самостоятельно в режиме самообучения, а не на реальных заказах.
3. Думать не только о своём успехе, но и об успешности проекта со стороны Заказчика.

UPD: Личные компоненты и сниппеты кода, текстовики с описанием действий, расписанных по шагам, сильно экономят время, если встанет перед вами похожая задача в очередном проекте.
Это - личная копилка знаний, которые не поместились в голове.

Если встаёт проблема с логикой при решении незнакомой задачи, разбейте её на части.
Пример: добавить столбец к существующей таблице на странице, который должен формироваться через модификацию существующего запроса к БД.
1. Найти код вывода таблицы.
2. Найти запрос к БД в коде подготовки данных для этой таблицы.
3. Составить новый запрос через интерфейс работы с запросами к БД.
4. Поменять в коде старый на новый запрос, закоментировав старый.
5. Проверить/отредактировать корректность вывода/рендеринга таблицы на странице.

Profit!

Comments

[Sanes]

Да когда им учиться, если они по 8-12 часов в день закрывают?

[xmoonlight]

Sanes, бросать закрывать и учиться.

Answer 5

[Игорь]

Как я вас понимаю, боролся с той же проблемой пока более опытный разработчик не посоветовал:
1) Засекать время за которое пишешь код и использовать эти знания для установки сроков для последующих похожих задач. Для замера не важно это заказ или собственная задумка. Главное работать в привычном темпе и не торопится сделать быстрее потому что идет таймер, задача не сделать быстрее и не показать красивые результаты, а замерить время работы.
2) Анализировать проект до установки точных сроков, хорошо представить объем работы и исходя из предыдущего пункта устанавливать сроки (лучше с запасом, как минимум первое время).
3) Если не успеваете обязательно связаться с заказчиком и уведомить его об этом (в большинстве своем заказчики достаточно понимающие. К тому же лучше подождать еще пару дней чем искать нового исполнителя). Возможно предложить скидку, если ситуация этого требует.
4) (из своего опыта) Ограничить отвлекающие факторы.

я джун уже больше полугода, и за это время зафейлил большую часть сроков по таскам. При этом стараюсь писать план, что буду делать, беру время с запасом, но часто и того не хватает. Могу зависнуть на какой-нибудь фигне. Всё это сильно удручает.

Answer 6

[Игорь Воротнёв]

1. Даже опытные разрабы часто ошибаются в оценках и делают дольше - именно поэтому опытные ПМы наши оценки всегда умножают на коэфициент. У хорошего ПМа даже есть матрица коэфициентов - благодаря магии статистики можно посчитать на сколько в среднем ошибается тот или иной разраб в команде. Jira вообще умеет это считать сама.
2. Чем детальнее задача прописана/поставлена, тем проще и быстрее ее делать. Если задачи не идеальны (а они всегда не идеальны), часто будет всплывать что-то непредусмотренное, что сдвинет сроки. Это нормально.
3. Очень полезный совет Strannyk - лимит на тупление. Именно это один из главных скилов джуна, который надо развивать. Максимум час времени на самостоятельный разбор, если гугл и документация не помогли за это время - идем к более опытным товарищам за советом. Лиды для этого и существуют, а не для получения более высоких зарплат (как некоторым из них кажется).
4. Определите ВСЕ нюансы, которые влияют на вашу скорость. Что именно вас тормозит. И устраните то, что можно, а с остальным учитесь жить, возможно даже использовать в свою пользу. Мне известны очень крутые разрабы, которые достаточно медленные в классическом понимании из-за их "задротства" - у них всегда вместе с кодом идут тесты, документация и тд, в том числе грамматика в документации в порядке. Какой-то команде такой стиль работы не подойдет и там такой разраб не продержится, а в какой-то наоброт, именно такие и нужны. Где-то нужно "*уяк-*уяк и в продакшн", а где-то важно качество/стабильность/надежность/безопасность, а сроки вторичны.
5. Набираться опыта. Больше опыта - точнее оценки и быстрее все делается.

Answer 7

[Vitaly Karasik]

А какой feedback от куратора? Может быть это вам кажется что тупите а на самом деле все ОК, начальство довольно?
Я уже много лет как старый DevOps, но очень-очень часто бьюсь целый день над какой-нибудь ерундовой проблемой :-)

Answer 8

[tester12]

Для начала - посмотреть на коллег. Они в сроки укладываются или нет? Если нет, то что-то не так в организации, это уже вопросы к руководству. Если да, то вопросы к медлительному джуну. Значит он либо ничего не знает и тратит кучу времени на гугление "как это сделать", либо он занят ещё чем-то не тем.

Answer 9

[qwermus]

Сроки - большая проблема у разработчиков. Сжатые сроки - страдает качество, и тут всё зависит от начальства или заказчика. Если им всегда надо на вчера - я предпочитаю от такой работы отказываться, на пользу это не пойдёт. Конечно, можно делать в спешке и как попало, но спустя время результат будет удручающий и поддерживать продукт будет сложнее и сложнее. Лучше постараться искать людей, которые с пониманием относятся ко времени разработки и готовы мириться с медленной разработкой при условии, что продукт получается качественный.
Ну и касательно самого вопроса - можно пытаться часть задач оптимизировать. Я, например, долгое время пользовался дримвивером и он казался мне удобен, но в какой-то момент открыл для себя ПХП-шторм, который делает часть работы за тебя - это позволило ускорить работу. Так можно постараться рутинные задачи по максимуму оптимизировать.