Как быть успешным разработчиком
Статья для тех, кто только начинает карьеру и еще не представляет какой увлекательный путь впереди.
Я делюсь рекомендациями для разработчиков, но некоторые из них будут полезны для представителей разных профессий.
Правильно оценивайте проект
Неправильная оценка объема работы, необходимой для выполнения проекта, - постоянная ошибка среди новичков и даже опытных разработчиков.Около 50% проектов имеют завышенный бюджет или сдаются с опозданием. Это ужасно!
Когда я работал над первым коммерческим проектом, мне нужно было оценить его: сколько времени и сотрудников потребуется для работы, какая будет итоговая стоимость.
Я был молодым, энергичным и амбициозным, поэтому недооценил время на разработку. Это испортило отношения с некоторыми коллегами, заказчиками и подорвало уверенность в собственные силы. Позже менеджер проектов дал отличный совет: всегда добавлять 30% от общего количества часов. Лучше переоценить проект и передать его заказчику раньше назначенного срока, чем оправдываться, почему не успели вовремя.
Преимущества:
- Будет достаточно времени для разработки и рефакторинга.
- Позволяет сделать лучший дизайн, а не просто работающий.
- Могут произойти форс-мажорные ситуации: болезнь, отпуск, командировка и т.д. Да что угодно может пойти не так, поэтому запас времени жизненно необходим.
Думаете, что заказчики будут считать вас несерьезными и ленивыми, если вы оцениваете в 10 недель то, что можно сделать за 2? Я тоже так думал раньше, тем не менее, пока вы открыто общаетесь с заказчиками и бизнес-процессы прозрачны, всё будет в порядке.
На вас лежит ответственность за стоимость проекта, потому что именно разработчик может его правильно оценить. Поэтому объясните клиенту простыми словами, почему столько времени требуется на разработку.
Лучшее - враг хорошего
Во время работы вы столкнетесь с тем, что не всё можно учесть с первого раза. Нужно быть осторожным, если хотите учесть все мелочи, потому что вы можете потратить несколько часов, пытаясь во всём разобраться.
Это характерно для перфекционистов. С самого детства нам внушают, что всё надо делать идеально, однако идеально не бывает. Невозможно знать абсолютно всё. Развивайте гибкость ума и способность быстро находить нужную информацию. Мы принимаем решение из множества альтернатив.
Например, вы закончили институт, что будете делать дальше? Можно устроиться в крупную компанию или небольшой стартап, а можно быть фрилансером. Список вариантов безграничен и выбор зависит от ваших предпочтений.
Лучшее, что мы можем сделать - собрать как можно больше информации, оценить риски и ответственно подходить к делу.
Я определяю лучший и худший сценарии и исходя из них принимаю решения. Рекомендую прочитать книгу "Принципы" Рэя Далио. Советы из неё помогут правильно оценивать риски и находить пути их снижения.
Не бойтесь трудностей. Я кайфую от решения сложных задач и проблем. В некотором смысле радость жизни заключается в решении проблем различной сложности.
Не отклоняйтесь от намеченного пути
Feature creep первое, что приходит на ум. Вам хочется добавлять и добавлять новые фичи, потому что код выглядит так, будто он был написан в 90х. Вы уверены, что никто и никогда не будет использовать ваш продукт.
Поймите, что это всё в вашей голове. Не утверждайте, что люди не будут пользоваться вашим продуктом.
Определите конечную цель в начале проекта и стремитесь к ее достижению независимо от внешних обстоятельств.
Преимущества:
- Это уменьшит Feature creep и вы сфокусируетесь на задаче. Об этом написано много книг, поэтому я не буду вдаваться в подробности.
- Определите сроки выполнения проекта. Назначьте конкретную дату, к которой проект будет готов. Даже если проект будет выполнен не идеально, вы получите обратную связь.
Собирайте обратную связь
Я сторонник частых релизов. Релизы позволяют своевременно получать обратную связь. Это очень важно, поскольку вы учитываете все требования и пожелания заказчика и оперативно исправляете ошибки.
Однако ранние релизы не должны отражаться на качестве кода. Неработающий продукт никому не нужен и это просто неуважение к клиентам.
На каждом этапе предоставляйте продукт с небольшим количеством функций, но которые будут исправно работать.
Протестируйте продукт на небольшом сегменте пользователей. Желательно, чтобы это были не друзья или семья, а люди, которые могут дать объективную оценку.
Ищите ответы перед тем как спросить
Начинающие программисты часто задают вопросы, даже не пытаясь найти ответ самостоятельно. Когда они сталкиваются с чем-то незнакомым, их первое желание заключается в том, чтобы спросить у старшего программиста, что и как делать.
Нет ничего плохого в том, чтобы обращаться за помощью к более опытным ребятам, но полезнее искать ответы самому. И если уж совсем ничего непонятно, просить, чтобы объяснили.
Почему полезно самостоятельно искать ответы?
Во-первых, вы познакомитесь с новой информацией, которая пригодится в дальнейшем. Узнаете дополнительные фишки, которые улучшат код.
Во-вторых, невозможно из джуниора вырасти в сеньора, если не развивать свои навыки. Когда вы будете сеньором, к вам будут обращаться за помощью другие разработчики, поэтому не ленитесь учиться.
Разработчики шутят, что большую часть времени проводят на StackOverflow или что-то гуглят. В этом есть доля правды!
Способность быстро находить ответы - ценный навык. Благодаря развитию интернета, мы можем находить нужную информацию в любое время и в любом месте.
Не менее важно учиться правильно задавать вопросы. Правильно поставленный вопрос - это половина ответа.
Стремитесь к простоте в работе и жизни
Начинающие разработчики работают по принципу “всё лучшее сразу”. Они используют и абстракцию, и наследование, и сложные интерфейсы, и много чего ещё. Но всегда ли это необходимо? Нет. Это усложняет код. Помните, что с вашим кодом потом будут работать другие люди.
Оптимизируйте код. Думайте не только о производительности, но и о читаемости.
Стремитесь к простоте и в жизни. Вычеркните всё ненужное и сосредоточьтесь на важном.
Перевод статьи How to be a successful software engineer от Digital Skynet :)
Новичку 30% времени сверху при оценке накидывать? Лол, там умножать на 3 надо
1. Оценка должна быть командная - так сглаживаются "неровности" в производительности отдельных спецов. Если работаешь один, то разумнее следовать правилу "#NoEstimates".
2. Фичами и беклогом занимаются не разработчики, а другие, специально обученные люди.
3. Релизами занимаются не разработчики, а другие, специально обученные люди.