5 главных привычек успешных разработчиков

Чтобы добиться успеха, надо сначала поверить, что мы сможем

Чтобы добиться успеха, надо сначала поверить, что мы сможем.

Мы становимся тем, что мы постоянно делаем.

Несколько полезных советов от Рави Шанкар Раджан

Рави Раджан (Ravi Rajan) – глобальный менеджер ИТ-программ из Мумбаи, Индия. Он также является заядлым блоггером, поэтом-хайку, энтузиастом археологии и историком-маньяком. Связаться с Рави на LinkedIn , Medium и Twitter .

6 минут чтения

Ларри Уолл, автор языка программирования Perl, однажды сказал, что у великих разработчиков есть три достоинства: лень, нетерпение и гордыня.

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

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

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

Успех, к которому вы стремитесь, зависит от того, как вы видите себя, мир и привычки, с которыми вам приходится сталкиваться в жизни. Фактически, согласно исследователям из Университета Дьюка, 40% нашего успеха (или неудачи) происходит автоматически в результате наших привычек.

И вот некоторые главные привычки, которые помогут укрепить ваш успех разработчика.


Будь профессионалом

Стив Мараболи попал точно в цель, когда сказал:

«Правильные и трудные вещи обычно одинаковы. И то, и другое требует профессионализма».

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

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

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

Всегда помните, что профессионализм – это ответственность. Вы не можете быть всегда правы. Но вы должны признавать свои ошибки.


Не повторяйте одну и ту же ошибку

Амит Калантри сказал:

«Если за извинением следует оправдание или причина, это означает, что они снова совершат ту же ошибку, за которую просто извинились».

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

Все работает нормально. Но программное обеспечение не идеально. Любое программное обеспечение содержит ошибки.

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

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


Ничего не оставляй на удачу. Это никогда не работает.

Джим Дженкинс правильно сказал:

«Горечь плохого качества сохраняется еще долго после того, как радость от соблюдения графика была забыта».

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

Вот почему тестирование так важно. Как вы можете знать, что ваш код работает? Это просто. Проверь это. Проверьте это снова. Проверьте это так. Проверьте это по-другому. Проверяйте это все семь дней, включая воскресенье!

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

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

Что делать, если код «не проверяется»? Код написан таким образом, что затрудняет тестирование.

Короткий ответ здесь – это сделать код доступным для тестирования. И лучший способ сделать это – сначала написать свои тесты, прежде чем писать код, который должен их пройти.

Всегда помните, что цель вашего кода – это решение бизнес-задачи. Если эта цель не достигнута, никакое улучшение кода не имеет смысла.

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


Всегда создавайте гибкий код

Сири Хустведт правильно сказала:

«Творчество всегда зависело от открытости и гибкости, поэтому будем надеяться на большее и того, и другого в будущем».

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

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

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

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

Всегда следуйте принципу «Безжалостный Рефакторинг». Оставьте очиститель кода, когда вы его закончите, и если это означает, что вы делаете что-то «лишнее» из того, что вам было сказано, сделайте это.


И, наконец, всегда учись.

Энтони Дж. Д’Анджело был сто раз прав, когда сказал:

Развивайте страсть к обучению. Если вы это делаете, вы никогда не перестанете расти.

«Я хочу пройти курс S4 HANA. Но работодатель не спонсирует»

«Я хотел изучить формы Webdynpro . Я не могу найти время из своего плотного графика»

«Я хочу посетить этот Codeathon. Но это в выходные».

Все это оправдания, чтобы не учиться. Ваша карьера – ваша ответственность. Ваш работодатель не обязан убедиться, что вы работаете на рынке. Ваш работодатель не обязан обучать вас, отправлять на конференции или покупать книги. Эти вещи – ваша ответственность.

Как правило, следуйте правилу 40–20 часов каждую неделю. 40 часов времени принадлежит работодателю. Оставшиеся 20 часов принадлежат вам для вашего собственного обучения. Сделайте свою неделю как минимум 60 часовой, чтобы впитать в себя непрерывную культуру обучения.

Выделить 20 часов в неделю не сложно. Если вы используете свое время с умом; время в пути, время обеда, выходные и т. д. В вашем распоряжении гораздо больше времени, которое можно использовать для себя.

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

Как правильно сказал Seema Openers.

«Самообразование открыто для всех, но оно принимается только теми, кто отказывается жить маленькой и бесцельной жизнью».


Поделиться...
Поделиться в facebook
Поделиться в twitter
Поделиться в vk