Как бы страшно не звучали технические сложности, алгоритмы, архитектура проекта - всегда остается львиная доля на бытовые процессы.
Соберу те, с которыми столкнулась сама и те, которые часто слышала от знакомых разработчиков.
"Бытовуха"
- Самая сильная боль всех разработчиков - это плохо описанная задача (ТЗ). Представьте, что задача у вас такая: добавить кнопку "Настройки уведомлений" на главную страницу сайта. И все. На первый взгляд, задачка простейшая, но когда мы начинаем задумываться, возникает миллион вопросов: могут ли на нее нажимать/видеть неавторизованные пользователи? а пользователи с неподтвержденным номером телефона? а пользователи, которые находятся в черном списке? а администратор приложения?
В итоге обычно выясняется, что кнопка нужна была только для администратора приложения, но не обычного пользователя.
Как вы понимаете - это самый простой пример. У больших приложений сложная архитектура и условия, нужно учитывать не только логику фронтенда (кнопочек), но и бэкенда (обработка и хранение данных), что иногда из пятиминутной на взгляд менеджера проекта задачи, она вырастает до нескольких дней разработки и еще столько же тестирования, потому что она могла все сломать. - Задача никому уже не нужна. Да, такое тоже бывает, ты месяц разрабатываешь большой кусок функционала, продумываешь архитектуру, меняешь старый код, создаешь новое, а когда все готово - выясняется, что заказчику разонравилась его же идея или он ожидал другой реализации или спрос на это уже прошел и твоя работа отправляется в помоечку. Казалось бы, что плохого? Ты работал, твою работу оплатили, но мы, разработчики - люди ранимые и чувствительные, хотим видеть результат своей работы и работать "в стол" не вдохновляет совсем.
- Митинги. Бесполезность присутствия, например, фронтенд разработчика на некоторых встречах, где обсуждаются задачи бэкенда - угнетает. Но еще больше угнетает, когда вся встреча превращается в обсуждение одной задачи менеджером проекта и аналитиком, и вы, и вся ваша команда, час слушаете в каком виде вам поступит задача.
Настоящие проблемы
Особенно остро переживаются, когда ты только начал. Ты уже умеешь писать немножко кода, знаешь как работает git и даже немного знаешь SQL, чтобы делать какие-то запросы, но как только дело касается смежных систем - ты переживаешь микроинсульт. Сейчас у меня уже нет паники, только принятие и поход в дебри документации.
- Работа с БД порой вставляла палки в колеса, которые непонятно как доставать, когда ты еще совсем юн. Накатывание и откатывание миграций, ручное редактирование таблиц, установка расширений (Postgis, например) - всегда мини-приключение, особенно в первый раз.
- Приходится учиться работать с тем, что казалось бы к программированию отношения не имеет (но так кажется только в начале) - работать с Linux, Powershell, администрирование серверов, открытие портов, настройка WinRM и многое многое другое. Недавно впервые столкнулась с Powershell и WinRM, нужно было написать приложение, которое удаленно вызывает скрипты, а для этого нужно было понять как это сделать без приложения. Так я познакомилась с групповыми политиками, ActiveDirectory, узнала, что бывают доменные пользователи, а не только локальные (да я вообще не разбиралась в винде, и что вы мне сделаете), настраивала удаленный доступ, разбиралась в синтаксисе Powershell, а также COM-объектов, с которыми он должен был работать.
На днях познакомилась с протоколом SCIM, еще в процессе разбирательства, но уже написала мини-приложение, чтобы понять как правильно реализовать методы и работать со схемами.
Еще иногда документацию нужно писать. Скучно, занудно, но во всех работах есть аналогичная нудятина. - Новые интеграции/технологии. Например, сложно первый раз придумать хорошую архитектуру для работы с Telegram или работать с leaflet на JS (это фронтендерская библиотека для работы с картами и точками на ней). Сначала хотелось быстро получить результат и сделать что-то по наитию или скопировав чье-то готовое решение. Или быстренько вмешаться в существующую логику, не вдаваясь в детали.
Сейчас я уже без паники иду в документацию, стараюсь изучить ее полностью, ну или почти полностью, и только потом перехожу к стадии поиска best practices. Недавно из интереса разворачивала RabbitMQ в докере (и то и другое трогала первый раз), чтобы потестить 2 мини-приложения на C# (publisher + consumer). С опытом приходит интерес и радость от нового вместо ступора, это не может не радовать)
"Ненастоящие" настоящие проблемы
Это ты сам.
- Переработки. Очень часто работа программиста не заканчивается на том, когда он выключил компьютер. Мы можем думать о задаче в спортзале, пока чистим зубы или пока пытаемся отдыхать. Нерешенная проблема зудит и не дает покоя, а озарение вызывает непреодолимое желание проверить свою теорию. А попытки ее проверить иногда затягиваются на несколько часов или бессонные ночи. Я не знаю, лечится ли это. Я вот не могу спокойно заканчивать рабочий день с нерешенной проблемой. Я буду о ней думать и я обязательно к ней вернусь)
- Усталость (
тупняки). Иногда просто замыливается глаз и маленькая опечатка может сломать твою жизнь на несколько часов. Ты видишь один путь и одно решение, но они ведут тебя не туда. Понимаешь это только на следующий день. - Выгорание. Тут влияют и переработки, и "бытовуха", и уровень зп и уровень удовлетворенности жизнью. Увы, идеального рецепта как это лечить нет. Кому-то нужно просто отдохнуть, кому-то в целом чуть меньше работать, а кому-то работать столько же, но за другие деньги или в другом коллективе.
- Здоровье. Глаза и спина просто тают на глазах. Кому-то чуть больше везет и зрение не уходит. А вот спиной нужно действительно заниматься, если есть озабоченность внешним видом и комфортным долголетием.
И это еще без сеньерских проблем с ответственностью за команду, проект и его жизнеспособность. Ну и проблемы совместимости начальников и членов команды - это уж везде можно найти, но мне пока дико везет со всеми.
Как-то так и живем. А вы как?
