«Любая система — это отстой, смиритесь с этим»: 20 мудрых советов от разработчика с 20-летним стажем
Сооснователь компании Simple Thread Джастин Этередж прошел путь от специалиста по разработке программного обеспечения до CEO небольшой IT-компании c командой из 25 человек. По его словам, за это время у него сформировалось понимание и отношение к индустрии, а также некоторые убеждения. Выводами, которые Джастин сделал за 20 лет в профессии, он поделился в своем блоге.
Вот что он написал.
«Как ты можешь не знать, что такое BGP?», «ты никогда не слышал о Rust?» — возможно, многие слышали это в свой адрес. Причина, по которой многие любят программное обеспечение (ПО), заключается в том, что это одна из ниш, в которой можно учиться бесконечно. Это означает, что разработчик может потратить десятилетия в индустрии и все равно иметь огромный пробел в знаниях по определенной дисциплине. Чем раньше вы это поймете, тем быстрее сможете избавиться от синдрома самозванца и будете с удовольствием учиться у других и учить других.
Возможно, сейчас это клише, но причина, по которой большинство разработчиков не верят в эту формулировку, заключается в том, что они считают, что это обесценивает их работу. Лично я считаю это чушью. Наоборот, это подчеркивает сложность и иррациональность среды, в которой нам приходится работать. Вы можете разработать самую технически впечатляющую вещь в мире, а ее никто не захочет использовать. Такое случается постоянно.
Хорошие разработчики не забывают о пользовательском опыте и учитывают его при создании продукта. Будь то внешний или программный API, или пользовательский интерфейс, хороший специалист думает о том, почему и как пользователь будет с ним взаимодействовать, а также что для него важно. Учет потребностей пользователя — это основа хорошего UX.
Большинство инженеров-программистов всегда будут склоняться к написанию кода, особенно когда нетехническое решение неочевидно. То же самое относится и к коду, который не нужно поддерживать. Команды разработчиков склонны изобретать колесо, несмотря на то, что многие решения уже давно придуманы до них. Важно соблюдать баланс.
Основная задача любого программиста — это создание полезного продукта. Очень немногие разработчики программного обеспечения понимают это, и еще меньше тех, кто это осознает. По-настоящему осознание этого приводит к другому способу решения проблем и другому взгляду на инструменты. Если вы верите, что программное обеспечение подчинено результату, вы будете готовы найти «правильный инструмент для работы», который может и не быть программным обеспечением.
Некоторые люди сразу погружаются в задачу и пишут код. Другие хотят сначала все исследовать и уходят в состояние бесконечного анализа. В таких случаях установите для себя дедлайн, по истечении которого просто начинайте решать проблему. Такая схема быстрее приведет вас к созданию лучшего решения.
Поддерживать экосистему разработчиков — это тяжелая работа, и очень важно понимать ее потенциал. Если вы не осознаете, что возможно и что доступно в этой экосистеме, вы не сможете разработать разумное решение для всех, кроме самых простых проблем. Подводя итог, отмечу, что следует опасаться людей, проектирующих системы, которые давно не писали код.
Создатель языка программирования С++ Бьерн Страуструп как-то сказал: «Есть только два вида языков: те, на которые люди жалуются, и те, которыми никто не пользуется». Это можно распространить и на большие системы. Не существует «правильной» архитектуры:
Но это не оправдание для того, чтобы никогда не делать что-то лучше. Меньше беспокойтесь об элегантности и совершенстве; вместо этого стремитесь к постоянному улучшению и созданию пригодной для жизни системы, в которой вашей команде нравится работать, и которая стабильно будет приносить пользу.
Используйте любую возможность, чтобы поставить под сомнение предположения и подходы, которые «всегда делались так, как надо». Пришел новый член команды? Обратите внимание на то, как он себя ведет и какие вопросы задает. Поступила заявка на новую функцию, которая не имеет смысла? Убедитесь в том, что вы понимаете цель и то, что движет желанием получить эту функциональность. Если вы не получаете четкого ответа, продолжайте спрашивать «почему?», пока не поймете.
«Десятикратный» программист, который якобы в 10 раз более производителен, чем «обычный», — это миф. Идея о том, что кто-то может сделать за 1 день то, что другой компетентный, трудолюбивый, такой же опытный программист может сделать за две недели — глупа. Кто-то может быть «десятикратным» программистом только в том случае, если вы сравниваете его с «0,1-кратным» программистом — тем, кто тратит время впустую, не просит обратной связи, не тестирует свой код, не рассматривает риски и так далее. Нужно стараться не допустить появления «0,1-кратных» программистов в команде, а не заниматься поиском мифического «десятикратного» программиста.
Ничто не настораживает меня больше, чем Senior-разработчик, который не имеет собственного мнения о своих инструментах или о том, как подходить к созданию программного обеспечения. Я бы предпочел, чтобы кто-то высказал мнение, с которым я категорически не согласен, чем чтобы у него вообще не было никакого мнения.
Если вы пользуетесь своими инструментами и не любите или ненавидите их по каким-то причинам, вам не хватает опыта. Вам нужно изучить другие языки, библиотеки и парадигмы. Существует мало способов повысить уровень своих навыков быстрее, чем активный поиск того, как другие решают задачи с помощью инструментов и техник, отличных от ваших.
Люди много говорят об инновациях, но обычно ищут дешевых побед и новизны. Если вы внедряете инновации и меняете то, как люди должны делать вещи, ожидайте негатива. Если вы верите в то, что делаете, и знаете, что это улучшит повестку, приготовьтесь отстаивать свою позицию.
Помните, что ваши данные, скорее всего, переживут вашу кодовую базу. Потратьте силы на поддержание их в порядке, и это окупится в долгосрочной перспективе.
Старые технологии, которые остались на плаву, — это акулы, а не динозавры. Они решают проблемы настолько хорошо, что пережили быстрые изменения, которые постоянно происходят в мире технологий. Не делайте ставку против этих технологий и заменяйте их только в том случае, если у вас есть очень веская причина.
Многие программисты предпочитают не высказывать своего мнения, пока их не спросят. Но это не значит, что такому человеку нечего сказать или добавить к вашим словам. Иногда самые шумные люди — это те, кого меньше всего хочется слушать.
Разработчики программного обеспечения должны вести блоги, журналы, писать документацию и вообще делать все, что требует от них для развития навыков письменного общения. Письменная работа помогает обдумать проблемы и более эффективно донести их до команды. Хорошая письменная коммуникация — один из самых важных навыков, которым должен овладеть любой инженер-программист.
В наши дни все хотят быть гибкими, но гибкость заключается в том, чтобы создавать вещи небольшими частями, учиться, а затем проводить итерации. Если кто-то пытается впихнуть в это нечто большее, то, скорее всего, он что-то продает. Это не значит, что людям не нужна помощь, чтобы работать таким образом, но сколько раз вы слышали, как кто-то из вашей любимой технологической компании или крупного проекта с открытым исходным кодом хвастался тем, как прекрасен их процесс SCRUM? Опирайтесь на процесс до тех пор, пока не поймете, что вам нужно больше. Доверяйте своей команде, и она все сделает.
Если вы отделите человека от результатов его работы, он будет меньше заботиться о своей работе. Это основная причина, почему кроссфункциональные команды работают так хорошо, и почему DevOps стал таким популярным. Речь идет не об неэффективности, а о владении всем процессом от начала до конца и прямой ответственности. Дайте группе людей нести полную ответственность за проектирование, создание и доставку программного обеспечения (или чего угодно), и вы будете приятно удивлены.
Собеседования лучше проводить для того, чтобы понять, кто такой человек и насколько он заинтересован в той или иной области знаний. Пытаться выяснить, насколько хорошим членом команды он будет, — бесполезное занятие. Насколько человек умен также не является показателем того, что он будет отличным членом команды.
Никто не скажет на собеседовании, что он будет ненадежным, грубым, напыщенным или никогда не будет приходить на собрания вовремя. Кто-то якобы умеет определять характер человека по некоторым «маячкам», например: «Если кандидат спрашивает об отгулах на первом собеседовании, значит, он будет часто их брать», но это ерунда. Если вы обращаете внимание на подобные «маячки», вы просто бьете наугад и отсеиваете потенциально хороших кандидатов.
Нехватка бюджета, невозможность решить, какие функции следует сократить, желание создать «лучшую версию» системы — эти причины могут подталкивать к созданию крупной системы, но это того не стоит. В процессе создания системы вы узнаете так много нового, что в результате итераций сделаете еще более улучшенную систему. Это удивительно трудно доказать большинству людей.
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…