Это перевод заметки Ника Харли There’s never been a better (or a worse) time, to be a software engineer.
Иногда престижность работы программиста ломается коллегой, который разбивает голову о клавиатуру. Инновации позволяют программистам быть более производительными, писать код быстрее и качественней. Но это не мешает существовать тем продуктам, которые усложняют нашу работу...
Начнем с плохого...
1. Работа никогда не заканчивается
Как разработчик, вы ежедневно возвращаетесь к набору тех проблем, которыми пропитан ваш софт. Он абсолютно всё делает неправильно. А того, что люди от него хотят, этот софт как раз не делает.
Все ваши взаимодействия с пользователями сводятся к тому, что они хотят чего-то, чего вы им не дали. Они не понимают, почему всё не так просто, как им кажется.
Мы мечтаем о том дне, когда кто-то поблагодарит нас за безупречную работу в проекте и не потребует каких-нибудь "добавок".
Спецификации и требования — заранее, пожалуйста!
2. Люди (до сих пор) не понимают, чем вы занимаетесь
Возможно, подруге вашей мамы нужна помощь с принтером — ей сказали, что вы работаете в ИТ. Или у вашего продакт-менеджера отсутствуют какие-либо технические знания, и он совершенно не разбирается в современных методах программирования.
Кажется, никто не понимает, в чём заключается ваша работа, и вам нужно отчитываться перед людьми, которые не в курсе требований или ограничений. Объяснять понятно всем, что вы делаете, бывает настолько сложно, что иногда пытаться не имеет смысла. Поэтому на встречах вы просто ограничиваетесь фразой «я работаю с компьютерами».
3. Как же много новых языков и фреймворков для изучения
На момент, когда вы будете читать эту статью, вероятно, будет существовать ещё один новый JavaScript-фреймворк, который стыдно не использовать. Кажется, никто больше не работает с HTML напрямую.
Похоже, вам нужно переучиваться на свою профессию каждые пять лет или рисковать отсталостью.
В мире языков и фреймворков случился настоящий взрыв. Все они требует поддержки. А разработчики не всегда успевают оставаться в курсе всего. Изучение любых дополнений к 400+ языкам программирования и уже существующим фреймворкам — это работа на полную ставку. Почему вы не проводите каждые выходные, играя с новейшими технологиями? Возможно, у вас есть жизнь за пределами рабочего пространства, вы не грезите, не едите и не дышите кодом.
Позор.
4. Работа с кодом других людей
«КТО НАПИСАЛ ЭТОТ КОД!?»
«Это полная каша! Тут нет никакого смысла!»
«Я проверяю историю коммитов... Хочу узнать, кто написал этот мусор...»
«Так, подожди...»
«Это был я, в прошлом году»
Если не считать изменения собственного устаревшего кода, попытки понять, как работает часть унаследованного кода — боль. Но от вас ожидается, что вы погрузитесь в него и просто продолжите писать, как ни в чём не бывало.
Пытаться разобрать намерения предыдущего разработчика еще сложнее, когда этого разработчика больше нет поблизости, а код плохо написан, плохо прокомментирован или плохо задокументирован.
Если бы только люди понимали...
Но, есть и множество положительных моментов...
Современная разработка софта на самом деле никогда не была проще.
И вот почему…
Приложения теперь сообщают вам, когда они нездоровы
Раньше разработчики полагались на своих пользователей. Именно они выявляли проблемы, сталкиваясь с ними когда приложение уже в production. Но времена меняются.
Инструменты мониторинга ошибок, которые могут сообщить вам, что не так с вашим приложением и почему, без необходимости просить пользователей сообщать об ошибках. Такие инструменты уже в арсенале самых продвинутых компаний в мире, и они становятся всё умнее. Они указывают, когда следует обратить внимание и где корень ошибки.
(Команда Хекслета предпочитает Rollbar, — прим. ред.)
Теперь, когда ошибки загружаются в баг-трекеры автоматически и ручной процесс становится историей, больше инженеров можно направить на создание новых возможностей, функциональности и целых продуктов, а не на поддержку этих продуктов.
Инструменты, вероятно, знают больше о вашем софте и клиентах, чем вы. Поэтому скоро не будет никакого оправдания дерьмовому софту.
Инструменты могут выполнять за вас тяжёлую работу
Раньше нам нужно было заморачиваться только о нескольких устройствах и размерах экранов. Теперь, когда появляется новый продукт от Apple, Samsung или Google, ситуация может измениться существенно.
Но современные кроссплатформенные фреймворки и инструменты позволяют разработчикам сокращать объем дублирования и усилий, необходимых для поддержки пользователей любых устройств, браузеров или операционных систем.
Прогрессивные веб-приложения набирают популярность, поскольку они подходят каждому пользователю, независимо от браузера — они построены по принципу прогрессивной оптимизации.
Xamarin, приобретенный Microsoft в 2016 году, позволил тысячам команд выпускать собственные приложения для Android, iOS и Windows, используя существующие навыки, команды и код, вместо того, чтобы создавать отдельные приложения для каждой платформы. А такие инструменты, как Foundation, Bootstrap и Semantic UI созданы, чтобы разработчикам интерфейсов больше не нужно было начинать с пустого файла CSS для получения безупречных пикселей.
Жизнь была бы намного сложнее без этих инструментов. Не делать все с нуля — роскошь.
Времена выхода финальных версий ушли в прошлое — ура!
Выход финальной версии когда-то приносил поток нервов и стресса, особенно когда приближалось время выхода релиза в production.
Непрерывная интеграция и доставка берут верх — команды постепенно отказываются от крупных, пугающих цикличных релизов, используя итеративные мелкие деплои. У них чаще добавляются новые опции, чаще происходит обновление конечной версии и исправление багов может происходить несколько раз в день. Оттого, что возможностей привнести новую ценность больше, вероятность в удовлетворении своих клиентов выше. А продукты таких команд часто более высокого качества.
Результат — ускоренный выход на рынок, выше степень удовлетворённости качеством обслуживания и быстрая реакция на изменения потребительского рынка.
Дни выхода сломанного релиза в production и тотального фейла у конечных пользователей (или страха попасть в такую ситуацию) ушли в прошлое, по крайней мере, для большинства команд.
А что думаете вы?
Разве у нас когда-нибудь было всё так хорошо?
И какие самые лучшие и худшие моменты в программировании для вас?
От редактора: Мы на Хекслете часто публикуем переводы статей. Важно помнить:
- Мнение автора статьи может отличаться от мнения администрации и сотрудников Хекслета.
- Цель перевода – показать мнение. Поэтому одна статья может визуально противоречить другой: это просто разные мнения. Мы оставляем на вашу ответственность возможность анализировать и делать выводы для себя.
