«Любая система — это отстой, смиритесь с этим»: 20 мудрых советов от разработчика с 20-летним стажем

Сооснователь  компании Simple Thread Джастин Этередж прошел путь от специалиста по разработке программного обеспечения до CEO небольшой IT-компании c командой из 25 человек. По его словам, за это время у него сформировалось понимание и отношение к индустрии, а также некоторые убеждения. Выводами, которые Джастин сделал за 20 лет в профессии, он поделился в своем блоге. 

Вот что он написал. 

1. Моих знаний до сих пор недостаточно 

«Как ты можешь не знать, что такое BGP?», «ты никогда не слышал о Rust?» — возможно, многие слышали это в свой адрес. Причина, по которой многие любят программное обеспечение (ПО), заключается в том, что это одна из ниш, в которой можно учиться бесконечно. Это означает, что разработчик может потратить десятилетия в индустрии и все равно иметь огромный пробел в знаниях по определенной дисциплине. Чем раньше вы это поймете, тем быстрее сможете избавиться от синдрома самозванца и будете с удовольствием учиться у других и учить других. 

2. Труднее всего создавать полезные вещи 

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

3. Лучшие разработчики программного обеспечения думают как дизайнеры 

Хорошие разработчики не забывают о пользовательском опыте и учитывают его при создании продукта. Будь то внешний или программный API, или пользовательский интерфейс, хороший специалист думает о том, почему и как пользователь будет с ним взаимодействовать, а также что для него важно. Учет потребностей пользователя — это основа хорошего UX. 

4. Лучший код — это отсутствие кода или код, который не нужно поддерживать 

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

5. Программное обеспечение — это средство достижения цели 

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

6. Бесконечный анализ — это плохо 

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

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

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

8. Так или иначе, любая система — это отстой, смиритесь с этим 

Создатель языка программирования С++ Бьерн Страуструп как-то сказал: «Есть только два вида языков: те, на которые люди жалуются, и те, которыми никто не пользуется». Это можно распространить и на большие системы. Не существует «правильной» архитектуры: 

• Вы никогда не погасите весь свой технический долг;
• Вы никогда не разработаете идеальный интерфейс;
• А ваши тесты всегда будут слишком медленными.

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

9. Вопросов «почему?» много не бывает 

Используйте любую возможность, чтобы поставить под сомнение предположения и подходы, которые «всегда делались так, как надо». Пришел новый член команды? Обратите внимание на то, как он себя ведет и какие вопросы задает. Поступила заявка на новую функцию, которая не имеет смысла? Убедитесь в том, что вы понимаете цель и то, что движет желанием получить эту функциональность. Если вы не получаете четкого ответа, продолжайте спрашивать «почему?», пока не поймете. 

10. Суперпрограммист — миф

«Десятикратный» программист, который якобы в 10 раз более производителен, чем «обычный», — это миф. Идея о том, что кто-то может сделать за 1 день то, что другой компетентный, трудолюбивый, такой же опытный программист может сделать за две недели — глупа. Кто-то может быть «десятикратным» программистом только в том случае, если вы сравниваете его с «0,1-кратным» программистом — тем, кто тратит время впустую, не просит обратной связи, не тестирует свой код, не рассматривает риски и так далее. Нужно стараться не допустить появления «0,1-кратных» программистов в команде, а не заниматься поиском мифического «десятикратного» программиста. 

11. Разработчик без мнения — плохой разработчик

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

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

12. Людям не нужны инновации 

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

13. Самая важная часть системы — ваши данные

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

14. Переходите на новые технологии только в крайних случаях 

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

15. Не путайте скромность с невежеством 

Многие программисты предпочитают не высказывать своего мнения, пока их не спросят. Но это не значит, что такому человеку нечего сказать или добавить к вашим словам. Иногда самые шумные люди — это те, кого меньше всего хочется слушать. 

16. Письменные навыки — это очень важно 

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

17. Простые процессы — это хорошо

В наши дни все хотят быть гибкими, но гибкость заключается в том, чтобы создавать вещи небольшими частями, учиться, а затем проводить итерации. Если кто-то пытается впихнуть в это нечто большее, то, скорее всего, он что-то продает. Это не значит, что людям не нужна помощь, чтобы работать таким образом, но сколько раз вы слышали, как кто-то из вашей любимой технологической компании или крупного проекта с открытым исходным кодом хвастался тем, как прекрасен их процесс SCRUM? Опирайтесь на процесс до тех пор, пока не поймете, что вам нужно больше. Доверяйте своей команде, и она все сделает. 

18. Разработчики должны чувствовать и нести ответственность за свою работу 

Если вы отделите человека от результатов его работы, он будет меньше заботиться о своей работе. Это основная причина, почему кроссфункциональные команды работают так хорошо, и почему DevOps стал таким популярным. Речь идет не об неэффективности, а о владении всем процессом от начала до конца и прямой ответственности. Дайте группе людей нести полную ответственность за проектирование, создание и доставку программного обеспечения (или чего угодно), и вы будете приятно удивлены. 

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

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

Никто не скажет на собеседовании, что он будет ненадежным, грубым, напыщенным или никогда не будет приходить на собрания вовремя. Кто-то якобы умеет определять характер человека по некоторым «маячкам», например: «Если кандидат спрашивает об отгулах на первом собеседовании, значит, он будет часто их брать», но это ерунда. Если вы обращаете внимание на подобные «маячки», вы просто бьете наугад и отсеиваете потенциально хороших кандидатов. 

20. Всегда старайтесь создать небольшую систему 

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