Комментарии 28
обычное дело в начинающих разрабов.
сам такой был - нахватаешся проектов думаешь что раз два а там раз дватри...
а по молодости и потусоватся хочется :)
Да, по факту - история ультра базовая. Корни часто разные: кто-то переоценил силы, кто-то залип в перфекционизм, кому-то просто тяжело сказать "я не успеваю". Но сталкиваются с этим почти все
Если бы только начинающих. Опытные не менее подвержены. Да и сам был, если честно.
Ситуация. Есть класс задач которые лучше решать другим способом, чем привыкли в команде. Показал на своем примере. Обсудили в команде. Все согласились. Пришли две подобные задачи. Молодые пытаются. Старые, опытные - больше по привычке. Поэтому что ответственность, привыкли - знают, что точно сделают и прочее, прочее, включая прокрастинацию.
Это в той или иной форме есть у всех.
Вижу АИ картинку в статье - скипаю.
Такую картинку, да ещё в целях КДПВ странно было бы рисовать руками.
А если мне применение какой-нибудь функции подсказала нейросеть, я честно написал об этом в комментах, и вам дали этот код на поддержку?
А это ещё и статья АИ. С форматированием скопированым сразу из АИ.
Ещё и заплюсованая.
Как же цветёт хабр при ChatGPT.
Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
Мне кажется, важно создать атмосферу, где можно честно сказать: «Я не успеваю» или «Я не понимаю», без страха осуждения.
Как-то раз давно я сказал начальнику, что люди не выполняют задачи не потому что не хотят, а потому что не могут. Он посмотрел на меня непонимающим взглядом. Начальство не хочет слышать о проблемах потому что это будет означать, что они наняли недостаточно квалифицированного сотрудника, а в этом они себе никак признаться не могут, их психика защищает их обходя такие острые углы.
Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
Все по делу, спасибо. На удаленке лет 10 уже. Как перешёл на неё, очень часто такое было. Помогли микроделайны которые сам просил, типа встречи в конце рабочего дня чтоб показать что сделано. ну и из дома работать не могу, семья ребёнок мешают сосредоточиться. снял себе мини офис, ухожу туда когда припекает
По мне так советы как дожечь, то что еще не догорело.
Это про меня:
Дао программирования 5.3:
Однажды ученику дали задание написать несложный финансовый пакет.
Ученик неистово работал много дней, но когда его Учитель просмотрел его программу, он обнаружил, что она содержит экранный редактор, множество универсальных графических подпрограмм, естественноязыковый интерфейс и ни малейшего намёка на что-нибудь финансовое.
Когда Учитель спросил об этом у ученика, тот возмутился. “Не будьте таким нетерпеливым”, — сказал он, — “когда-нибудь я добавлю в программу финансовую часть.”
Поэтому я и не работаю программистом.
у меня была ситуация - вел один продуктовый проект (полный рефакторинг морально устаревшего, т.е. понимали что делали и зачем) состоящий из нескольких приложений. Вначале нас было трое, двое разработчиков присоединились временно - каждый выполнил свою часть, хорошо поработали, запустили, парни вернулись в свой отдел. Единственная причина почему позволили переборку с нуля и изменение архитектуры - платил клиент. Иначе бы опять на сопли и изоленту делали заплатки.
Первое, заложили везде точки расширения, обработчики запросов, ответов, исполнение команд - можно делать врезки если нужно в любом месте pipeline.
Spring boot приложения были добавили им стандартно поддержку плагинов - в оригинале валили все зависимости в общую кучу... Как помойку - что поверх ляжет, то и будет работать. Как мавен разрулит, так и запустим (до него руками так как ант был). Попутно разобрался с одним опен сорсным проектом класслоадера и поправил его. Плагины мне понравились, разделяй - властвуй принцип. Сейчас мог цеплять разные версии одной и той же библиотеки в монолит. А так клади в папку plugins или в ext ( если основной класслоадер) плагин для клиента, и расслабляйся. Можно в zip формате.
Как то от скуки, плагины в war web приложение засунул для пробы, хоть это и не по фен-шую - тем не менее, работало, а почему нет.
Самое основное - покрыл все тестами. Вначале старался, конечно, но потом стал не успевать. Процентов 60 кода было покрыто минимум.
Интеграционные тесты на докере (базы и тд) хотя официально докер был запрещен.
В общем, хоть мерить строками кода устаревший подход, примерно 60 тыс строчек было, около 90 модулей maven ( часть ресурсные).
Это был один из трех проектов что вел, основной.
Что было замечено сразу - тестеры были опечалены. Реально не могли схватить ошибки.
Если ошибки хватались, то как правило, это было приложение для интеграции, похожего размера но с командой от 8 до 12 человек, с высокой текучкой и без рефакторинга. В приложении царил ад, содом и гоморра - даже опытные люди с ходу кубок размотать не могли. Лид флегматично тянул время, зарплату платят и ок. Улыбался руководству. Был на хорошем счету.
Со временем я стал терять интерес и начал забивать на качество. Смысл стараться, если рядом бардак. Просил хотя бы одного разработчика к себе в пару - а зачем, у тебя и так все работает а мы не успеваем! Как в анекдоте - админ Вася ленивый, ничего не делает, а Петя админ трудолюбивый - каждые полчаса систему переустанавливает. Угадаем какой админ медаль получил?
Тоже пытался как-то все упорядочить. Потом с грустью осознал, что пока наводишь порядок в одной стороне, с другой стороны начинается хаос потому что коллегам то ли пофиг на системность и лишь бы закрыть задачу, то ли нет глубокого понимания и делают как могут. В итоге приходится признать поражение и поставить крест на мечтах о стройном будущем проекта.
более того, бардак необходим чтобы заменить тебя было труднее.
Если навязал Гордиев ушёл в котором кроме тебя никто не разберется, то и заменить тебя труднее.
Проблема в том, что разработчик может усложнять систему до степени своей некомпетентности
Т.е. и сам не факт что разберешься
Хотя это будет сильно легче, чем с нуля конечно
у меня в начале 2000х был пример одного товарища - сидел коптил небо в одной страховой конторе в Торонто.
Пересидел много кого на in house продукте - народ уходил быстро потому что legacy , зарплата так себе.
В общем, он в определенный момент тоже ушел, перед уходом еще больше костылей сделав.
Потом сделал условие по оплате 300 CAN в час за передачу опыта когда к нему обратились , уже как контрактнику. Пока сидел в конторе, получал 20 в час (по низам считай).
Больше полугода покормился, дембельский аккорд.
У меня похожая была тема, тоже в Торонто - ушел с 22 в час. Через полгода в той же конторе как контрактник проект по open tv (на С) доделывал по 70 в час, с оплатой еженедельно, отелем и билетом из России, ибо пригорело а замену не найти быстро.
Для этого должны быть кодовнеры на различные части проекта, без одобрения которых ни один коммит не попадает в мастер.
Это не работает. Предположим первый сотрудник code owner. Второй решал, релал какую-то задачу и наконец выдал решение, которое не устраивает первого. Первый блокирует pull request. Вот что происходит дальше. Менеджер спрашивает у второго статус по задаче, он говорит, что вот я сделал, а первый заблокировал. Менеджер идёт к первому и убеждает его принять решение как есть потому что работы много и нужно идти дальше вперёд. Время - деньги. Если же побеждает первый и pull request отправляется на доработку, то второй начинает очень лениво и очень долго править замечания. С управленческой точки зрения это все равно, что простой. Я уже не говорю об эмоциональной стороне, когда так называемые сеньоры очень болезненно воспринимают любые замечания к результатам своего труда.
Работает.
Менеджер идёт к первому и убеждает его принять решение как есть потому что работы много и нужно идти дальше вперёд.
Нет, не убеждает. Если кровь из носа фича нужна завтра в релизе, рефакторинг просто сразу планируется в следующий спринт.
Если же побеждает первый и pull request отправляется на доработку, то второй начинает очень лениво и очень долго править замечания.
Саботаж? Пойдёт искать новую работу. Кодовнером должен быть не упёртый пионер с синдромом вахтёра, а опытный специалист.
Я уже не говорю об эмоциональной стороне, когда так называемые сеньоры очень болезненно воспринимают любые замечания к результатам своего труда.
Синьоры всё нормально воспринимают, у них детство в жж отыграло.
В 100% случаев - когда у меня возникали проблемы с написанием кода - это означало - что формулировка задачи отсуствует в принципе. Отсутсвие понимания какой результат ждут - мгновенно выжигает мотивацию что-либо делать вообще.
По этому самое важное (имхо) - сфорумлировать в задаче ожидаемый результат, причем конечный. Например - вместо "рефакторинга легаси" задача должна содержать список классов или пакетов или мест - где нужно что-то сделать. А вместо "снизить потребление памяти" - "снизить потребление памяти на n%" - хотя-бы
Когда разработчик тебе врёт: прокрастинация, отмазки и что с этим делать