Pull to refresh
145.09
Rating
VDSina.ru
Серверы в Москве и Амстердаме

Культура разработки ПО слишком позитивна, это может нам вредить

VDSina.ru corporate blogProgrammingDevOps
Translation
Original author: Albert Kozłowski
image

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

Выгорание


Разве не странно, что множество молодых людей ощущает себя выгоревшим всего спустя несколько лет работы? Я часто встречаю людей, испытавших срыв всего спустя один-два года. Я и сам испытал выгорание (даже дважды). В первый раз мне пришлось взять перерыв на полгода. Во второй раз, который произошёл совсем недавно, мне потребовался целый год, прежде чем я смог вернуться к программированию.

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

Но как насчёт людей, которые не любят программирование, но всё же хорошо справляются со своей работой? Попробуйте сказать своим коллегам или в Twitter, что вы один из них, и вас сразу же заклеймят как плохого разработчика. Однако на самом ли деле это так? Люди, которые делают свою работу, а после работы занимаются чем-то другим, тоже могут быть потрясающими программистами. Не каждый обязан приходить домой и трудиться над хобби-проектами, писать посты в блог, записывать видео в YouTube о кодинге и читать книги о программировании.

Я был одним из тех людей, которые пытаются всё своё свободное время работать. Многие годы я чувствовал вину за то, что не трачу всё время на преследование какой-то воображаемой продуктивности. Догадайтесь, к чему это меня привело?


Новые блестящие игрушки


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

Не у всех работают тысячи микросервисов, как у Uber, и не каждой компании требуется K8S. Однако сложно удержаться от всеобщего энтузиазма, или хотя бы не делать вид, что ты его разделяешь. Скольким организациям не удалось мигрировать на React или Angular? В результате они получили кодовую базу, разделённую на старый «плохой» код, который работает, и новый код, который разработчики пытаются заставить работать.

Эта недавняя статья показывает реальность многих организаций: I Almost Got Fired for Choosing React in Our Enterprise App

Best Practices


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

Какие из этих «универсальных» best practices на самом деле не универсальны? DRY (Don’t Repeat Yourself) часто упоминается в одном предложении с KISS (Keep It Simple Stupid), хотя часто они являются взаимоисключающими практиками. «Simple» означает отсутствие необязательных абстракций, однако если начинать сразу с DRY-кода, то он и ведёт к преждевременным абстракциям.

Лично я пользуюсь правилом 3X:

«У нас есть одержимость многократным использованием. Но не корите себя за это, это эндемичное заболевание среди разработчиков ПО. Даже, пожалуй, профессиональная болезнь.



— Многократно используемые компоненты создавать в три раза сложнее, чем одноразовые

— Многократно используемый компонент должен быть проверен в трёх различных областях применения, прежде чем его можно будет считать достаточно обобщённым, чтобы добавить в многократно используемую библиотеку». — Coding Horror

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

Подведём итог


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

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

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

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

Я хочу пробовать что-то другое, и это совершенно нормально.



На правах рекламы


Наша компания предлагает аренду VPS для совершенно любых проектов. Создайте собственный тарифный план в пару кликов, максимальная конфигурация позволит разместить практически любой проект — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Подписывайтесь на наш чат в Telegram.

Tags:программированиеразработка
Hubs: VDSina.ru corporate blog Programming DevOps
Total votes 59: ↑46 and ↓13+33
Views16K
Comments Comments 162

Top of the last 24 hours

Information

Founded
Location
Россия
Website
vdsina.ru
Employees
11–30 employees
Registered
Representative
Mikhail