Как стать автором
Обновить

Комментарии 26

Дополнение следует вынести в предисловие.
По всему остальному — как-то, выкатыванию кода с изменениями в последние пять минут и тестированием полночи этих изменений — извините, конечно, но это проблема не программиста, а что "так можно сделать". А если так можно — оно периодически будет сделано, вне зависимости от того, о какой профессии идёт речь.
Заканчивайте спринт днём, морозьте код, тестируйте оставшиеся полдня и вечером отправляя последний отчёт в 18:00 спокойно идите домой. Исправьте свои процессы и перестаньте винить исполнителей.
Не писать тесты — тоже, очевидно, "так можно".

У нас код морозится за два-три дня до конца спринта, и это на одном из самых бардаковых проектов. Фичи подождать могут пару недель, ни у кого ничего не отвалится. Беда если не так.

Баттхерта псто.

Get a life!
Гарантирую вам, что имея активный и счастливый образ жизни вам не понадобится сидеть и в соцсетях доказывать или отстаивать.
В том проекте один разработчик умудрился забыть выложить обновлённый код в общий репозиторий и два его коллеги полдня в экстремальном режиме пытались определить — почему же функция не работает так, как заявлено?

Чтобы такого не было, разработчик должен сообщать номер коммита с исправлением в комментариях к задаче. Тогда "пол дня экстрима" превратится в минуты, необходимые на сверку номеров.

Проще писать номер задачи в сообщении коммита.

При нормальной интеграции СКВ и багтрекера — в сообщении коммита будет указан ID задачи, а в багтрекере автоматически проставлена связь между задачей и коммитами, с ней связанными и/или закрывающими её (см. Github/Gitlab, etc)

Да уж. Статья шибко злая получилась. Прям наболело у автора. Заминусуют… А жалко, потому что, некоторые вопросы подмечены довольно верно, хоть и довольно грубо. Как минимум статья заставляет задуматься.


И на самом деле не важно как именно устроен процесс разработки в команде: некомпетентность помноженная на завышенную самооценку всегда себя проявит в виде проблемы.
Людьми нужно оставаться независимо от того, тестировщик ты или ПМ или кодер. При благоприятном эмоциональном климате в команде многие проблемы решаются в разы быстрее.


И тут фокус вопроса смещается на проблему подбора персонала. Девочки из отдела кадров тебе понабрали МУД-ов, или ты их тоже собеседовал, брал на испытательный срок и решал: вписывается новый человек в команду или нет? А руководитель должен быть психологом и уметь мотивировать, указывать на ошибки и при этом способствовать созданию позитивного эмоционального климата в команде.

Я правильно понимаю, что автор сравнивает программистов со скотом, всячески их поносит, а также их обвиняет в косяках, которые должны контролироваться и управляться как раз управленцами, которые в примерах автора, не компетентны и не выполняют свои профессиональные обязанности, а вместо этого ненавидят программистов? Очень удобная позиция.

Автор, судя по тональности текста, сам является носителем критикуемых им недостатков в софт-скиллах. А что касается остального, большинство перечисленных проблем просто не может возникнуть в коллективе с нормально налаженными процессами и скорее характеризует общий бардак в компании. Мой совет молодому специалисту будет такой — держаться от подобных компаний подальше.

Совершенно поддерживаю. Все эти проблемы решаются вменяемым управлением персоналом. Четкий девопс, «батька-прораб-тимлид» и скрам-мастер при правильном применении снижают уровень беспредела на нет. А если надо то и пистонов могут вставить. Если в компании бардак, то не только кодеры могут распоясаться. Такова-с культура.
Я помню реакцию и лицо одного программиста, которому в качестве попытки уловить труднонаходимый «плавающий» дефект предложил воспользоваться профайлером встроенным в IDE: мне было указано, что это не собачье дело руководителя проекта советовать, какими средствами программист должен пользоваться в своей работе.
Профайлер, если что, предназначен для получения статистики по использованию программой памяти и процессорного времени. «Плавающий дефект» профайлером не вылечить. Или вы перепутали профайлер с отладчиком?

Ты можешь по запросу коллеги, тестировщицы, аналитика или заказчика за 3 минуты пропарсить пару сотен тысяч
Я очень сочувствую тем программистам, которые под вашим руководством превратились в мальчиков на побегушках, выполняющих «запросы» мимо таск-трекера, парсящих логи, фигачащих отчёты в Экселе. А с учётом того, что это для них −
рутинные операции, требующие многократного повторения в течение рабочего дня…
… то вы получаете ровно то, на что напрашиваетесь: наглость (потому что иначе с вами в одной команде не прожить) и некомпетентность (потому что хороший разработчик не будет терпеть такого к себе отношения).

Но за достаточно долгую уже карьеру я встречал не так много программистов, использующих комбинации КБД на клавиатуре для вызова тех или иных стандартных действий — большинство для этого используют более медленный манипулятор «мышь».
Ну, а советы типа «выучить шоткаты» и «освоить слепой десятипальцевый метод» меня с некоторых пор даже умиляют. Просто вишенка на торте. Понятно же, что скорость написания программы ограничивается только скоростью нажимания кнопок!
Профайлер, если что, предназначен для получения статистики по использованию программой памяти и процессорного времени. «Плавающий дефект» профайлером не вылечить. Или вы перепутали профайлер с отладчиком?

Более того, отладчиком плавающие дефекты тоже не ловятся. Разве что удалённым, и то не всегда.

Как пасти (с)котов, или Советы юному программисту

Неправильный заголовок, судя по тексту нужно было написать «Как пасти (с)котов, или Советы юному скоту». Жаль программистов которые у вас работают, вы от них требуете быть машиной оркестром, не болтать, не есть, не срать. Ведь кто не жмёт на кнопки тот не работает (и не дай боже кодер не знает шотов и слепую печать). А ещё кодер должен тестировать до отупения свои правки, заменяя тестировщика, отрываться от задач чтобы поискать что-то в логах, хотя для этого ненужны сверх скилл, а достаточно запустит поиск, ну да ведь прерывание над задачей никак не повлияет на скорость её закрытия. А ещё программист конечно же должен быть админом, эникейщиком, и дэвопсом. Чтобы уметь разворачивать кластеры, и управлять зависимости, у него ведь 2 руки, а ещё и ноги есть, ничё не сдохнет. Пускай ещё «гениальный» пм поучит его как профайлером искать баги. А да пускай ещё диаграмму ганта составит, а то пму некогда, он ничего не делает видимо.

По вашему статье вырисовывается что программист должен быть программистом, админом, эникейщиком, дэвопсом, тестером, пмом, и при этом ни на что не отвлекаться, быть безгрешным, смиренно терпеть советы пм по коду и инструментам (учитывая что пм не знает разницу между конструктором и деструктором, и советует профайлер для дебага). Бедные ваши программисты. Это не они скоты, это вы ублюдки. В остальном описаны примеры не компетентных программистов которые не должны проходить испытательный срок.

Некоторые моменты улыбнули (например, про критику митингов и про обсуждение разницы в минорные версиях фреймворков — такое часто вижу, да и сам иногда люблю попрактиковать, что уж там). Но общий язык статьи слишком не нейтральный. Автор описывает проблемы завышенного Чсв и некомпетентности, которые могут быть у кого угодно, но почему-то все сводится именно к разработчикам. Как с таким негативом в голове можно руководить — не понимаю.

Завышенное ЧСВ это бич. И не только у программистов, бывает и у руководителец, а также у ПМов и т.д. Но как холодный душ для молодых программистов статья нормальная. Всегда можно задуматься о своец ограниченности, главное, чтобы это не переросло в комплекс, что тоже бывает часто!

Стиль написания напоминает мне стиль постов на одном сайте с доменом в Италии. Особенно «дружок» и т.д. Мудаки есть везде, а вот задача ПМ'а наладит работу на проекте так, чтобы работали все нормально и продуктивно.
применения практик постоянного интегрирования и автоматического развёртывания релизов, достигаемых к появлению седых волос 35 годам

Вот это сакральное знание, буду знать к чему стремиться!

По аналогии на основе предыдущих результатов? На основе количества экранных форм и запросов на ввод-вывод к БД?

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

кажется, я скоро буду готов к повышению!

Аналогичное ведро помоев можно вылить на любого участника процесса и на ПМа в первую очередь. Вот только зачем? Считаешь людей винтиками в своем процессе — придется столкнуться с крайне циничным отношением к себе любимому. Умеешь разруливать ситуации на позитиве и добиваться уважения технарей — работа приносит удовольствие и результаты радуют. Не нравится работать с программистами — меняй профессию.

Если вы думаете, что программисты не любят вас только за то, что вы не программист, у меня для вас плохие новости. Ну да выше уже все написали.
А вообще, я против, чтобы такие изначально оскорбительные по форме и сути статьи публиковались на хабре, для этого есть Пикабу и прочие свалки.

Я думаю ты отсидел очень много в очень низкосотрных конторах. Типа на проект один реальный программист, штуки 3 вчерашних выпускников и 10к студней по дешёвке. В них из за перманентного пи*деца и отсутствия времени на обучение формируется очень храктерный шаблон навыков у сотрудников.

Если компанию (в лице ПМ, например) не устраивают знания и навыки программиста,(как технические, так и коммуникационные), то она или увольняет программиста, или выделяет ресурсы на его обучение.


Хотите слепой метод? Остановите разработку на неделю и пускай программисты тренируются в каком-нибудь тренажёре. Слышал оценки, что 40 часов за неделю достаточно для одной раскладки, при условии, что в остальное время клавиатурой не пользуешься. Я, как программист, такой роскоши как 5 дней подряд по 8 часов обучаться слепому набору и не пользоваться клавиатурой остальное время, позволить себе не могу. По крайней мере пока такого требования нет на большинстве вакансий.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории