Есть ли место творчеству в разработке?
Многие романтизируют нашу профессию, но так ли это на самом деле, большой вопрос.
В некоторых рекламах показывают программистов, которые пьют чашку кофе, за окном льёт дождь, а яблочко на ноутбуке (прошли времена) светится и озаряет надеждой на светлое будущее. В реальности же всё немного иначе.
Чаще всего разработка — это совокупность многих ограничений: ТЗ, дизайн, жёсткая архитектура, процесс код-ревью и тестирование — повторить несколько раз. В зависимости от уровня компании между каждым этапом могут быть свои прослойки, в том числе согласования, многократные изменения и смещения приоритетов.
Когда-то давным-давно я запомнил важную истину: код, который вы пишете на работе, вам не принадлежит. Казалось бы, банальная фраза, но она сильно меняет мировоззрение. Наша задача — в первую очередь закрывать потребности бизнеса и получать за это справедливое вознаграждение.
В мифическом человеко-месяце Брукса есть глава, посвященная радостям ремесла. Я не помню детали, так как читал её в университете, но суть в том, что программисты радуются самому процессу разработки и решению сложных, запутанных вещей. Выброс дофамина, который мы получаем, когда сложные вещи наконец компилятся, бустит общее состояние, а возможность делать вещи, полезные остальным, выступает путеводной звездой.
На мой взгляд, выгорание человека как специалиста происходит в первую очередь от отсутствия понимания, что именно нужно сделать. И от монотонности одного и того же, что справедливо не только для программирования. Поэтому в сфере, когда вы решаете новые задачи, расширяя функциональность, гибкость мышления будет только развиваться.
Я общался со многими людьми, которые менторят людей (а ещё ведут блоги о разработке, но не программируют сами, что интересно), видел множество ребят, которые разочаровывались в программировании спустя два месяца после попадания в профессию, и видел выгоревших профессионалов с десятилетним опытом по причинам, озвученным в абзаце выше.
Несмотря на это, количество людей, которые стремятся попасть внутрь магического IT все также высоко. Приведу пример, за последние несколько месяцев я общался со своими коллегами из топовых компаний, и по нашим суммарным внутренним метрикам количество продолжает расти, в начале года на одну вакансию в среднем было 12 отзывов, сейчас около 40 (это уже после того, как HR делятся резюме кандидатов), об этом нужно помнить.
Творческая ли наша профессия?
Если вы умеете находить радость в условиях жёстких ограничений и кайфуете от того, что вашим продуктом будут пользоваться тысячи людей, безусловно.
Если вы готовы постоянно учиться, следить за новыми технологиями и у вас в компании можно юзать новые фреймворки, а не поддерживать 12 ось, то да.
Если вы не боитесь сложных вызовов, когда на Stackoverflow отсутствуют ответы, а ChatGPT ещё не обучился, конечно.
Но когда вы в очередной раз столкнётесь с багом, который не воспроизводится или ваше приложение зареджектят потому что луна опять не в той фазе, или же проект надо будет перевести на Swift 7 спустя несколько лет, а для этого надо будет обновить треть кодовой базы — перечитайте этот пост.
😃 iOS Dev
Многие романтизируют нашу профессию, но так ли это на самом деле, большой вопрос.
В некоторых рекламах показывают программистов, которые пьют чашку кофе, за окном льёт дождь, а яблочко на ноутбуке (прошли времена) светится и озаряет надеждой на светлое будущее. В реальности же всё немного иначе.
Чаще всего разработка — это совокупность многих ограничений: ТЗ, дизайн, жёсткая архитектура, процесс код-ревью и тестирование — повторить несколько раз. В зависимости от уровня компании между каждым этапом могут быть свои прослойки, в том числе согласования, многократные изменения и смещения приоритетов.
Когда-то давным-давно я запомнил важную истину: код, который вы пишете на работе, вам не принадлежит. Казалось бы, банальная фраза, но она сильно меняет мировоззрение. Наша задача — в первую очередь закрывать потребности бизнеса и получать за это справедливое вознаграждение.
В мифическом человеко-месяце Брукса есть глава, посвященная радостям ремесла. Я не помню детали, так как читал её в университете, но суть в том, что программисты радуются самому процессу разработки и решению сложных, запутанных вещей. Выброс дофамина, который мы получаем, когда сложные вещи наконец компилятся, бустит общее состояние, а возможность делать вещи, полезные остальным, выступает путеводной звездой.
На мой взгляд, выгорание человека как специалиста происходит в первую очередь от отсутствия понимания, что именно нужно сделать. И от монотонности одного и того же, что справедливо не только для программирования. Поэтому в сфере, когда вы решаете новые задачи, расширяя функциональность, гибкость мышления будет только развиваться.
Я общался со многими людьми, которые менторят людей (а ещё ведут блоги о разработке, но не программируют сами, что интересно), видел множество ребят, которые разочаровывались в программировании спустя два месяца после попадания в профессию, и видел выгоревших профессионалов с десятилетним опытом по причинам, озвученным в абзаце выше.
Несмотря на это, количество людей, которые стремятся попасть внутрь магического IT все также высоко. Приведу пример, за последние несколько месяцев я общался со своими коллегами из топовых компаний, и по нашим суммарным внутренним метрикам количество продолжает расти, в начале года на одну вакансию в среднем было 12 отзывов, сейчас около 40 (это уже после того, как HR делятся резюме кандидатов), об этом нужно помнить.
Творческая ли наша профессия?
Если вы умеете находить радость в условиях жёстких ограничений и кайфуете от того, что вашим продуктом будут пользоваться тысячи людей, безусловно.
Если вы готовы постоянно учиться, следить за новыми технологиями и у вас в компании можно юзать новые фреймворки, а не поддерживать 12 ось, то да.
Если вы не боитесь сложных вызовов, когда на Stackoverflow отсутствуют ответы, а ChatGPT ещё не обучился, конечно.
Но когда вы в очередной раз столкнётесь с багом, который не воспроизводится или ваше приложение зареджектят потому что луна опять не в той фазе, или же проект надо будет перевести на Swift 7 спустя несколько лет, а для этого надо будет обновить треть кодовой базы — перечитайте этот пост.
