Дню программиста посвящается
«Я хотел бы это знать до того, как стать программистом», — фраза, которую иногда можно услышать даже от достаточно опытного разработчика. Ничего удивительного: представление о профессии и жизнь в профессии — совершенно разные вещи. Чем опытнее и взрослее становится специалист (в любой сфере), тем меньше у него иллюзий и романтизации своей деятельности. Мы собрали 7 фактов, которые должен знать каждый начинающий программист и о которые опасно спотыкаться на профессиональном пути. Кажется, День программиста — отличное время, чтобы об этом поговорить.
Мы собрали общий срез «открытий» для программистов разных уровней и специализаций. Не обязательно столкнуться сразу со всеми ситуациями — но часть из них всё равно хоть как-то но проявляется в жизни каждого из нас ????
Не все программисты одинаковы
Когда мы только думаем стать программистом, программирование для нас делится на специализации: игры, сайты, приложения для бизнеса, программирование ЧПУ (о нём кто-то думал, интересно?). Кажется, вот сейчас прочитаешь пару книг, попрактикуешься и утрёшь нос игроделам, Цукербергу и разработчикам электронного расписания. А потом оказывается, что программист — это лишь часть команды, причём не то чтобы часть наряду с дизайнерами или тестировщиками, а часть команды программистов, каждый из которых отвечает за узкие и порой скучные задачи. Серьёзный коммерческий проект пилится одним человеком в каких-то уникальных, исключительных случаях — и речь в них идёт об очень опытных разработчиках с глубоким бэкграундом.
Но и это не все открытия. Оказывается, что можно быть разработчиком, программистом, инженером-программистом, и это совершенно разные подходы работе над программным обеспечением. Чтобы не только кодить, но и проектировать, и развертывать, и внедрять, нужны новые знания. Нет, не так: нужно офигеть сколько новых знаний. Плюс ко всему, нужно желание и какие-никакие склонности, например, к аналитике, систематизации, умению предвидеть результат и работать с детальными требованиями. Много чего, в общем, нужно. Однако это не значит, что быть «просто программистом» плохо: специалист, владеющий всеми тонкостями языка программирования и способный использовать все фичи в реальной работе, до сих пор на вес золота. Да, кстати, истинная глубина языков программирования порой становится сюрпризом даже для уверенных мидлов.
Не весь смысл в коде
В какой-то момент на заре карьеры фанат своего дела прочитывает (и что важно, понимает) «Совершенный код» Стива Макконнелла и решает, что всю жизнь будет писать код ёлочкой, комментировать, оптимизировать, проводить непрерывный рефакторинг и делать код понятным, эффективным и производительным. Более того, некоторые строго следуют всем постулатам и выносят мозг своим коллегам и руководителям, не обнаруживая код достаточно совершенным. До первого горящего багфикса, пятничного релиза и «срочно-важного» клиента, у которого некоторые вещи приходится дописывать чуть ли не на проде. И тут-то выясняется, что исправление в одной строке требует переписывания десяти других, где-то есть щепотка легаси, а продуктовый менеджер никоим образом не готов ждать новых итераций рефакторинга. Фигак-фигак и в продакшен.
Однако как только вы начнете работать над проектами, в которых задействовано большое количество участников команды, вы быстро окажетесь под большой кучей кода, потому что, чтобы изменить одну строчку, необходимо изменить 5 других блоков кода. И получается, что код — это функциональность, а смысл — в управлении разработкой, взаимодействии внутри команды, способности решать нестандартные задачи на лету и гибко перестраиваться для достижения оптимального результата в сжатые сроки при наименьших затратах времени, труда и нервов.
Что касается совершенного кода, он приходит с опытом и становится стилем — но только если пройти все предыдущие этапы.
Код — это ещё не всё
«Код — это всё, что нужно», — третье ошибочное суждение, связанное с кодом. Кстати, очень похожее на ошибку будущих врачей: они тоже думают, что будут лечить, пока не столкнутся с бумагами, отчётами, нормативами и прочей бюрократией. К слову, такая бюрократия есть во всех специальностях (даже у художников и музыкантов), просто врачи и программисты почему-то наиболее болезненно к ней относятся. Думается, из-за завышенных ожиданий от своей деятельности.
Так вот, программирование — это не только реализация идеи в коде, это ещё и документация (без которой не смогут работать пользователи), спецификации, тесты и автотесты, комментарии коду, нудные описания в базах знаний и багтрекерах и многое другое. Кроме всего перечисленного, ещё есть сбор и анализ требований, составление технического задания, правки техническому заданию и ещё много всего того, что приходится делать, особенно если в команде нет хорошего продакта и аналитика. И это всё отнимает много времени, вызывает раздражение, но без такой «бюрократии» мало-мальски рабочий проект не выживет.
Я разработаю свой лучший проект
Нет. Для разработки лучшего (и особенно хорошо монетизируемого) проекта нужна хорошая, сильная команда профессионалов, которые точно знают, как сделать свою работу хорошо. Со временем становится понятной ещё одна мысль: свой лучший не равно лучший для пользователей. Практически каждый спринт вы будете натыкаться на неожиданные требования, которые реально удовлетворяют запросам пользователей, но при этом противоречат вашему вкусу, пониманию UX и представлениям о прекрасном. Лучший проект это тот, который нравится пользователям, решает их задачи и легко поддерживается. Остальное — высокое искусство программирования, не имеющего ничего общего с реальностью ????
Ещё одно открытие внутри этого: мыслить проектами не получится. Чтобы сделать в разработке что-то стоящее, нужно учиться декомпозировать проект на проблемы, проблемы на задачи, задачи на компоненты и, собирая снизу вверх, идти к целостной сущности. Только так. Если делать именно проект, в дальнейшем любая деталь реализации сможет его обрушить. Декомпозиция и разработка по частям страхуют от многих «монолитных» неприятностей.
Проекты ради проектов бессмысленны
Мы не раз говорили о важности сбора требований пользователей (отчасти потому что при разработке CRM-системы это актуально как нигде) и внимания к пользовательскому опыту. Всё просто: проекты без цели не способны взлететь, какая бы гениальная идея ни лежала в их основе. Пет-проекты, идеи программного ретрита на Багамах, тестирование скриптов управления сетью на Марсе и клавиатура для кота должны оставаться фан-проектами. Поймите правильно: не нужно от них отказываться, нужно не бросать работу и не вкладывать всё шуршащее, движимое и недвижимое в заведомо неподъёмный стартап. Каким бы красивым он вам ни казался!
Главный код-ревью — твой
Всегда нужно оставаться критичным к своему коду. Код-ревью от коллег бесценен: любые проблемы лучше увидеть незамыленным глазом. Но важно уметь работать с кодом самостоятельно: не делать его совершенным, не заморачиваться на мелочах, но иметь свой внутренний code style (который будет совмещаться с любым корпоративным), своего строгого ревьюера, который не только видит код, но и понимает, как он работает внутри всей системы, как его можно улучшить, ускорить. Это не врождённый талант, это серьёзная и вдумчивая работа, которая требует обучения и понимания технологий улучшения читабельности, производительности, устойчивости и универсальности. Если вы научитесь быть микрокомандой для самого себя, ваша ценность на рынке значительно возрастёт, а зависимость от типа команды и стиля управления разработкой снизится. Профессионал с высокой степенью свободы и независимости — это во многом даже круче, чем некоторые дутые тимлиды и СТО.
Учиться придётся непрерывно
Если хочется чего-то добиться в профессии, расти и иметь авторитет в сообществе, придётся очень много учиться. По факту — непрерывно. Хорошая новость: когда ты благодаря этому зарабатываешь, обучение идёт не в пример легче.
Стоит ли идти в программирование? Если появилась такая мысль, обязательно нужно хотя бы попробовать. Будет просто? Просто не будет, будет сложно. и чем выше ваши амбиции и потребность в развитии, тем будет тяжелее. Нужны ли склонности и задатки? Для по-настоящему хорошего разработчика — да, потому что там и алгоритмы, и математика, и сети. Этому за шесть месяцев не научиться. Будут ли разочарования? Будут. Главный профит? Вы — востребованный специалист, который точно знает, что делать и который твёрдо стоит на ногах. Всё остальное приложится: и деньги, и уважение, и карьерный рост.
???? Всех программистов, разработчиков, инженеров-программистов, стажёров, джунов, мидлов, сеньоров и тимлидов с днём программиста!
Комментарии (19)
GothicJS
13.09.2023 05:41Оказывается, что можно быть разработчиком, программистом, инженером-программистом
Все куда проще: пишешь программы - программист. Зарабатываешь на этом деньги - профессиональный программист. А все остальное это упражнения в лингвистике.
MiraclePtr
13.09.2023 05:41+1Ваша классификация не учитывает существование дилетантов.
А иначе можно договориться до того, что и бабка-знахарка, к которой пол-деревни ходит с проблемами и которая "лечит" отваром коры дуба и заговорами (и некоторым это даже помогает) - "врач".
Pshir
13.09.2023 05:41+1Если её отвары и заговоры стабильно помогают, то она - врач
MiraclePtr
13.09.2023 05:41+1А если они помогают только тем, кто в них верит, или в половине случаев их "работа" помогает только временно, а потом клиенту становится еще хуже, чем раньше было? С программистами-дилетантами нередко вот выходит именно так.
GothicJS
13.09.2023 05:41+1А если они помогают только тем, кто в них верит
Кстати, в этом случае я бы дал пациенту один совет - поверить. Задумайтесь)
Frevv
13.09.2023 05:41+1"А потом оказывается, что программист — это лишь часть команды" - просто не надо устраиваться на работу и все. Будешь делать что хочешь, свои проекты, только уже все придумано. А в офисе у разработчиков 99% проектов это интернет-магазины и crm компаний. Все, нуднотень, все по шаблону, одно и то же из года в год.
Многие в одиночку и начинали разработку, как хобби, потом уже перерождалось в крупные проекты. Но это начало 2000х, сейчас уже все есть что нужно людям.
KenobyM
13.09.2023 05:41+1Все просто, если проект хотя бы средний, то большую часть времени вы будете код ЧИТАТЬ, а не ПИСАТЬ.
da-nie
А есть наоборот, где вы один будете делать всё это: рисовать интерфейсы ПО, писать его логику, писать прошивку для МК, который будет подключаться к компьютеру, сопрягать всё это по разным протоколам обмена и линиям (ethernet+rs485+ ещё хрен знает что) со сторонним устройством (потребителем). Ах да, ещё и схему этой фигни на МК разработаете. Ладно хоть математику вам дадут. А на выходе получится некий прибор на базе ПК+МК. С одной стороны интересно, каждый раз разное, но с другой...
Ugli
для меня это хобби, так что я и общий дизайн поделки черчу, и плату развожу, и режу её и паяю и мк прогаю и корпус вырезаю)
да, фрезер чпу для плат и корпусов тоже сам сделал))
da-nie
Это пока поделка. А вот когда будет сложное промышленное изделие и начнут дрючить за план и доработки, это быстро начнёт вызывать раздражение.
Ugli
догадываюсь, но мог бы и не говорить))
как раз раздумываю о превращении хобби в профессию
Axelus
Подобную работу могут выполнять только продвинутые фулстеки. Зато, на мой взгляд, это самая интересная работа, в которую погружаешься полностью, от проектирования до реализации. А уж если заработает готовый результат, да так, как надо - это вообще восторг!
da-nie
Восторг будет пока не появится вопрос, а почему вон те люди, которые за этот проект формально отвечают (главный конструктор и прочие около него), живут и в ус не дуют, а вы изо дня в день один реализуете всё, что там эти чудесные люди навыдумывали себе.
MiraclePtr
В российском эмбеддеде, увы, это очень распространено - выполнять работу трех-четырех разных специалистов за зарплату одного (это ещё в лучшем случае)...
Leetc0deMonkey
Почему только эмбеддеде и почему только российском? Это такой способ скрытой девальвации зарплат, когда под те же вроде бы неплохие деньги накидывают всё больше и больше требований и обязанностей.
MiraclePtr
Потому что там это выражено ярче всего, другим отраслям и сферам в IT до такого как там еще очень далеко (по наблюдениям меня и коллег, благо есть очень много с чем сравнивать).