На днях я прочитал Что бы я хотел знать, когда начал свою карьеру в качестве разработчика программного обеспечения, статью в Lifehacker, адаптированную из ответа Quora от Майкла О. Черча. С тех пор я не переставал думать об этом. Думаю, я нахожу это таким заставляющим задуматься, потому что, хотя я согласен практически со всеми его советами, это так сильно отличается от того, что я мог бы извлечь из своего двадцатилетнего опыта профессионального разработчика программного обеспечения.

Совершенно очевидно, что Майкл призывает молодых программистов, решающих, сколько усилий приложить к своей работе, «уходить в сторону отставания». Он продолжает давать множество полезных советов о том, как ориентироваться в корпоративной политике и добиваться успеха. Я не настолько наивен, чтобы думать, что умение управлять и общая болтовня не важны для достижения профессионального успеха. Но нам повезло, что мы живем в эпоху Альфа-ботаников, когда разработчики программного обеспечения (по крайней мере, хорошие) являются дефицитным и хорошо продаваемым товаром. Если вы не чувствуете, что ваша текущая работа не позволяет вам продвигаться вперед за счет тяжелой работы и чистого мастерства программирования, не отвечайте на макиавеллиевские интриги. Просто поменяйте работу.

Однако более важно то, что только один из четырнадцати пунктов Майкла («Распознавайте основные технологические тенденции, кроме пустяков») вообще относится к разработке программного обеспечения. Остальное — хороший общий совет по карьере, какой бы ни была ваша работа. Смысл названия статьи («…как разработчик программного обеспечения») заключается в том, что она должна быть как-то специфична для нашей отрасли, и именно так я бы подошел к вопросу.

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

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

Только после окончания университета в моей самоудовлетворенности начали проявляться трещины. Я устроился в небольшую переводческую компанию в парижском пригороде единственным разработчиком довольно амбициозной системы управления терминологией. Хотя я создал довольно внушительный прототип, продукт так и не был запущен в производство. Оглядываясь назад, легко увидеть, что это был слишком сложный проект для моего 23-летнего стиля программирования. (Ужасная ошибка «Общая ошибка защиты» в Windows 3.1 появлялась так часто, что мой босс, генеральный директор компании, стал сардонически приветствовать меня «Салют, mon Général!», проходя мимо меня в коридор.)

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

Самый поразительный урок, который я усвоил, заключается в том, что временные рамки, которые заранее кажутся абсурдно раздутыми, обычно выглядят разумными и даже респектабельными в конце проекта. Большое количество раз на протяжении моей карьеры мы с коллегами соглашались, что проект не может длиться более, скажем, трех месяцев. Затем это занимает девять месяцев или двенадцать месяцев или больше (иногда намного больше). Но, оглядываясь назад, со всеми подробностями, подводными камнями и касаниями на виду, можно увидеть, что первоначальная оценка была безнадежно нереалистичной. Во всяком случае, гонка за ним только замедляла проект.

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

И все же подавляющее большинство разработчиков по-прежнему неохотно тратят время на модульные тесты, проектную документацию и обзоры кода (то, чем я особенно увлечен). Существует широко распространенное мнение, что наша работа заключается в написании кода, а все остальное — это отвлечение, убивающее производительность.

Это не означает, что мы должны разработать технические спецификации в мельчайших деталях, прежде чем напишем строку кода. Я большой сторонник agile, и создание чего-то, что работает так быстро, как вы можете, — отличный способ начать большинство проектов. Но мы должны быть готовы потратить время на частый и обширный рефакторинг, принимая во внимание уроки, извлеченные при первом проходе по коду. Нам нужно работать над тестами и документацией по мере продвижения, а не оставлять их на неуловимое будущее Shangri-La, когда утихнет стресс, связанный с запуском новых функций. Мы должны понимать, что наша работа заключается не в создании большего количества кода за меньшее время, а в создании программного обеспечения, которое будет стабильным, производительным, удобным в сопровождении и понятным (для вас или кого-то еще, несколько месяцев или лет). по дороге).

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

Первоначально опубликовано на сайте blog.salsitasoft.com 25 января 2015 г.