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

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

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

И не по теме, как относитесь к медлительным коллегам?
  • Вопрос задан
  • 2360 просмотров
Решения вопроса 6
@dimoff66
Кратко о себе: Я есть
Это же все относительно. Кто-то работает быстрее кто-то медленнее. Это ваш темп, если вы помимо решения задач еще и будете грузиться скоростью - на пользу не пойдет. Ну зафейлили значит зафейлили, кто сказал, что сроки были корректные.
Ответ написан
Robur
@Robur
Знаю больше чем это необходимо
уже больше полугода, и за это время зафейлил большую часть сроков по таскам

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

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

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

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

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

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

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

Я например могу сделать что-то супербыстро, пока мне объясняют задачу, в стиле "х**к, х**к и в продакшен", но предпочитаю делать дольше но лучше. Поэтому таски закрываю позже чем мог бы, но это такой код и результат, в котором я и окружающие уверены. Он и через полгода будет хорош, и багов в нем на порядок меньше.
Ответ написан
inoise
@inoise Куратор тега Веб-разработка
Solution Architect, AWS Certified, Serverless
  1. Если ты джун то у тебя должен быть куратор или наставник. Если нет то ты пришел работать куда-то не туда.
  2. Если тупишь и не можешь решить задачу то во-первых надо научиться задавать вопросы коллегам, а во-вторых научиться повышать квалификацию
  3. Когда ты джун то стоит забыть что рабочий день 8 часов. Твой рабочий день - 24 часа минус небольшие перерывы на сон и еду. Если ты, конечно, не пришел просто "за деньгами" в IT
  4. Если бы у меня джун за полгода не вырос и не стал бы нормально работать на проекте - я бы его уже уволил и взял другого. Я бы сказал что такой человек у меня испыталку не прошел
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Подскажите, как вы ведете задачи, чтобы укладываться в сроки?
никак.
1. Нужно делать то, за что платят. И делать это - на совесть.
2. Нет опыта/знаний - нужно получать самостоятельно в режиме самообучения, а не на реальных заказах.
3. Думать не только о своём успехе, но и об успешности проекта со стороны Заказчика.

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

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

Profit!
Ответ написан
@loonny
Как я вас понимаю, боролся с той же проблемой пока более опытный разработчик не посоветовал:
1) Засекать время за которое пишешь код и использовать эти знания для установки сроков для последующих похожих задач. Для замера не важно это заказ или собственная задумка. Главное работать в привычном темпе и не торопится сделать быстрее потому что идет таймер, задача не сделать быстрее и не показать красивые результаты, а замерить время работы.
2) Анализировать проект до установки точных сроков, хорошо представить объем работы и исходя из предыдущего пункта устанавливать сроки (лучше с запасом, как минимум первое время).
3) Если не успеваете обязательно связаться с заказчиком и уведомить его об этом (в большинстве своем заказчики достаточно понимающие. К тому же лучше подождать еще пару дней чем искать нового исполнителя). Возможно предложить скидку, если ситуация этого требует.
4) (из своего опыта) Ограничить отвлекающие факторы.
я джун уже больше полугода, и за это время зафейлил большую часть сроков по таскам. При этом стараюсь писать план, что буду делать, беру время с запасом, но часто и того не хватает. Могу зависнуть на какой-нибудь фигне. Всё это сильно удручает.
Ответ написан
HeadOnFire
@HeadOnFire
PHP, Laravel & WordPress Evangelist
1. Даже опытные разрабы часто ошибаются в оценках и делают дольше - именно поэтому опытные ПМы наши оценки всегда умножают на коэфициент. У хорошего ПМа даже есть матрица коэфициентов - благодаря магии статистики можно посчитать на сколько в среднем ошибается тот или иной разраб в команде. Jira вообще умеет это считать сама.
2. Чем детальнее задача прописана/поставлена, тем проще и быстрее ее делать. Если задачи не идеальны (а они всегда не идеальны), часто будет всплывать что-то непредусмотренное, что сдвинет сроки. Это нормально.
3. Очень полезный совет Strannyk - лимит на тупление. Именно это один из главных скилов джуна, который надо развивать. Максимум час времени на самостоятельный разбор, если гугл и документация не помогли за это время - идем к более опытным товарищам за советом. Лиды для этого и существуют, а не для получения более высоких зарплат (как некоторым из них кажется).
4. Определите ВСЕ нюансы, которые влияют на вашу скорость. Что именно вас тормозит. И устраните то, что можно, а с остальным учитесь жить, возможно даже использовать в свою пользу. Мне известны очень крутые разрабы, которые достаточно медленные в классическом понимании из-за их "задротства" - у них всегда вместе с кодом идут тесты, документация и тд, в том числе грамматика в документации в порядке. Какой-то команде такой стиль работы не подойдет и там такой разраб не продержится, а в какой-то наоброт, именно такие и нужны. Где-то нужно "*уяк-*уяк и в продакшн", а где-то важно качество/стабильность/надежность/безопасность, а сроки вторичны.
5. Набираться опыта. Больше опыта - точнее оценки и быстрее все делается.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
@vitaly_il1
DevOps Consulting
А какой feedback от куратора? Может быть это вам кажется что тупите а на самом деле все ОК, начальство довольно?
Я уже много лет как старый DevOps, но очень-очень часто бьюсь целый день над какой-нибудь ерундовой проблемой :-)
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
достигается упражнениями.

декомпозиция и реальная оценка своих возможностей.
Ответ написан
@tester12
Для начала - посмотреть на коллег. Они в сроки укладываются или нет? Если нет, то что-то не так в организации, это уже вопросы к руководству. Если да, то вопросы к медлительному джуну. Значит он либо ничего не знает и тратит кучу времени на гугление "как это сделать", либо он занят ещё чем-то не тем.
Ответ написан
@qwermus
Сроки - большая проблема у разработчиков. Сжатые сроки - страдает качество, и тут всё зависит от начальства или заказчика. Если им всегда надо на вчера - я предпочитаю от такой работы отказываться, на пользу это не пойдёт. Конечно, можно делать в спешке и как попало, но спустя время результат будет удручающий и поддерживать продукт будет сложнее и сложнее. Лучше постараться искать людей, которые с пониманием относятся ко времени разработки и готовы мириться с медленной разработкой при условии, что продукт получается качественный.
Ну и касательно самого вопроса - можно пытаться часть задач оптимизировать. Я, например, долгое время пользовался дримвивером и он казался мне удобен, но в какой-то момент открыл для себя ПХП-шторм, который делает часть работы за тебя - это позволило ускорить работу. Так можно постараться рутинные задачи по максимуму оптимизировать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы