{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Как быть успешным разработчиком

Офис "Digital Skynet"

Статья для тех, кто только начинает карьеру и еще не представляет какой увлекательный путь впереди.

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

Правильно оценивайте проект

Неправильная оценка объема работы, необходимой для выполнения проекта, - постоянная ошибка среди новичков и даже опытных разработчиков.Около 50% проектов имеют завышенный бюджет или сдаются с опозданием. Это ужасно!

Когда я работал над первым коммерческим проектом, мне нужно было оценить его: сколько времени и сотрудников потребуется для работы, какая будет итоговая стоимость.

Я был молодым, энергичным и амбициозным, поэтому недооценил время на разработку. Это испортило отношения с некоторыми коллегами, заказчиками и подорвало уверенность в собственные силы. Позже менеджер проектов дал отличный совет: всегда добавлять 30% от общего количества часов. Лучше переоценить проект и передать его заказчику раньше назначенного срока, чем оправдываться, почему не успели вовремя.

Преимущества:

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

Думаете, что заказчики будут считать вас несерьезными и ленивыми, если вы оцениваете в 10 недель то, что можно сделать за 2? Я тоже так думал раньше, тем не менее, пока вы открыто общаетесь с заказчиками и бизнес-процессы прозрачны, всё будет в порядке.

На вас лежит ответственность за стоимость проекта, потому что именно разработчик может его правильно оценить. Поэтому объясните клиенту простыми словами, почему столько времени требуется на разработку.

Лучшее - враг хорошего

Во время работы вы столкнетесь с тем, что не всё можно учесть с первого раза. Нужно быть осторожным, если хотите учесть все мелочи, потому что вы можете потратить несколько часов, пытаясь во всём разобраться.

Это характерно для перфекционистов. С самого детства нам внушают, что всё надо делать идеально, однако идеально не бывает. Невозможно знать абсолютно всё. Развивайте гибкость ума и способность быстро находить нужную информацию. Мы принимаем решение из множества альтернатив.

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

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

Я определяю лучший и худший сценарии и исходя из них принимаю решения. Рекомендую прочитать книгу "Принципы" Рэя Далио. Советы из неё помогут правильно оценивать риски и находить пути их снижения.

Не бойтесь трудностей. Я кайфую от решения сложных задач и проблем. В некотором смысле радость жизни заключается в решении проблем различной сложности.

Не отклоняйтесь от намеченного пути

Feature creep первое, что приходит на ум. Вам хочется добавлять и добавлять новые фичи, потому что код выглядит так, будто он был написан в 90х. Вы уверены, что никто и никогда не будет использовать ваш продукт.

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

Определите конечную цель в начале проекта и стремитесь к ее достижению независимо от внешних обстоятельств.

Преимущества:

  • Это уменьшит Feature creep и вы сфокусируетесь на задаче. Об этом написано много книг, поэтому я не буду вдаваться в подробности.
  • Определите сроки выполнения проекта. Назначьте конкретную дату, к которой проект будет готов. Даже если проект будет выполнен не идеально, вы получите обратную связь.

Собирайте обратную связь

Я сторонник частых релизов. Релизы позволяют своевременно получать обратную связь. Это очень важно, поскольку вы учитываете все требования и пожелания заказчика и оперативно исправляете ошибки.

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

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

Протестируйте продукт на небольшом сегменте пользователей. Желательно, чтобы это были не друзья или семья, а люди, которые могут дать объективную оценку.

Ищите ответы перед тем как спросить

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

Нет ничего плохого в том, чтобы обращаться за помощью к более опытным ребятам, но полезнее искать ответы самому. И если уж совсем ничего непонятно, просить, чтобы объяснили.

Почему полезно самостоятельно искать ответы?

Во-первых, вы познакомитесь с новой информацией, которая пригодится в дальнейшем. Узнаете дополнительные фишки, которые улучшат код.

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

Разработчики шутят, что большую часть времени проводят на StackOverflow или что-то гуглят. В этом есть доля правды!

Способность быстро находить ответы - ценный навык. Благодаря развитию интернета, мы можем находить нужную информацию в любое время и в любом месте.

Не менее важно учиться правильно задавать вопросы. Правильно поставленный вопрос - это половина ответа.

Стремитесь к простоте в работе и жизни

Начинающие разработчики работают по принципу “всё лучшее сразу”. Они используют и абстракцию, и наследование, и сложные интерфейсы, и много чего ещё. Но всегда ли это необходимо? Нет. Это усложняет код. Помните, что с вашим кодом потом будут работать другие люди.

Оптимизируйте код. Думайте не только о производительности, но и о читаемости.

Стремитесь к простоте и в жизни. Вычеркните всё ненужное и сосредоточьтесь на важном.

Перевод статьи How to be a successful software engineer от Digital Skynet :)

0
2 комментария
Gutal1n

Новичку 30% времени сверху при оценке накидывать? Лол, там умножать на 3 надо

Ответить
Развернуть ветку
Вася Бездомный

1. Оценка должна быть командная - так сглаживаются "неровности" в производительности отдельных спецов. Если работаешь один, то разумнее следовать правилу "#NoEstimates".
2. Фичами и беклогом занимаются не разработчики, а другие, специально обученные люди.
3. Релизами занимаются не разработчики, а другие, специально обученные люди.

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда