Комментарии 118
Он действительно гениальный инженер, который привык работать один
Уже противоречие
Как можно генерировать такой бред?)
Он не задал себе вопрос: «Как этот человек изменит работу остальных пятерых?»
У дефективных менеджеров часто всё происходит само-собой. Хотя наверное иногда следует сказать о целях, например по подтягиванию команды. Придумать отдельные мероприятия или хотя бы поставить встречу.
Вместо этого они готовы не только на джуна поставить сложную задачу, и на уборщицу тикет бы поставили, если бы могли. "Там в команде разберутся и вообще юниты в постоянной синхронизации сами по себе."
Сказки уровня б из 2003. Верните книжку, из которой вы этот шедевр классической литературы взяли, тому деду который вам ее одолжил.
А в должностных у "звезды" было "объяснять джунам фреймворк" или хотя бы "обучение коллег"?
Потому что его брали с ожиданием "напишет" - вот он и пишет! А все, что его отвлекает от письма, он с раздражением игнорит.
Вот я тоже не понял. Понабирают роковых, а потом спрашивают как с терпил.
Терпила в данном случае, я думаю, менеджмент. При чем от собственной глупости потерпевший.
Тут проблема не в найме «рок‑звезды», а в том, что руководитель сам не решил, кого нанимает. Рассказывать
Если нужен человек, который за три месяца перепишет сложный модуль, — это договорённость одного рода. Если нужен человек, который перепишет модуль, обучит команду, задокументирует архитектуру, снизит bus factor и будет вежливо и понятно объяснять джунам фреймворк, — это уже договорённость о другом, другой бюджет и другая постановка задачи.
А в статье выглядит так: наняли «чтобы написал», он написал, потом выяснили, что ещё хотелось наставника, архитектора, техписателя, тимлида и немного корпоративного психолога.
Тут не рок‑звезда разрушила команду. Тут менеджмент купил гитариста, а потом удивился, что он не дирижирует оркестром, не чинит сцену и не продаёт билеты.
И это уже не говоря, что по описанию первая цель была напилить и запустить, то есть даже если и были договоренности про «подтянуть команду» — не факт, что человек ожидал, что на фоне разработки ему ещё «классное руководство навесят, немедленно и сразу.»
P. S. Автор притом говорит как представитель компании или как тот самый тимлид/менеджерский голос, хотя формально это учебный вымышленный кейс. Тут уж либо крестик снимать, либо... легенду лучше придумывать. Потому что пока читается как жалоба вот этого самого руководителя, который пишет по «у нас», но дистанцируется от ситуации, чтобы не получить от читалей вопрос «а Вас‑то наказали за такое руководство?»
Это писал профессиональный препод в лучшем случае :-) компания какая то ? Преподавание или копирайтер. Вот и топит за то что преподование оказывается главным скилом, уже смешно :-( это не только в программировании встречалось, классика поднятия значимости. уборщица бы написала - главное, порядок на кухне...
Эмммм.... Я не очень в курсе, какой грейд у "рок-звезды", но обычно про сеньоров говорят:
"Вторая важная задача senior-программистов — это обучение и менторство. Они делятся опытом и формируют культуру знаний. Передача экспертизы делает команду и продукт значительно сильнее. При этом менторство снижает зависимость команды от отдельных сотрудников и помогает повысить эффективность новых людей." (с) https://blog.skillfactory.ru/senior-razrabotchik/
Чувствую боль этого рокера. Когда окружен людьми, на 2 головы слабее себя, причём, скорее всего, не только в знании фреймворка, а и в способности строить и валидировать длинные логические цепочки, держать достаточно токенов в контексте, и уметь мыслить абстрактно.
К слову, если, и, вправду, модуль трейдинга столь важен и критичен для компании и алгоритмически сложен, и там зарыто конкурентное преимущество, то, таки да, рок-звезда там нужна. Можно иметь хоть 6, хоть 60 посредственностей, но, если конкурент такой рок-звездой обладает, то это имеет немного смысла. Голлиаф, перекидывающий джейсоны между сотней микросервисов, не одолеет Давида, бьющего точно в темечко.
Вообще, подозреваю, что найм ещё одного разраба его уровня, возможно, смог бы решить вопрос. Топовые инженеры любят работать с равными себе. Да и, если один сбежит, то второму будет куда легче вникнуть, чем толпе растерянных детей
Вот да, если повезло с умом, то как будто только в кванты и идти. Больше нигде не возьмут без мимикрирования, видимо страшно брать тех, кто может оказаться умнее интервьювера, порой во всех отношениях, лучше или вежливо выпроводить, или завалить как-то
Главное не перепутать “умнее интервьюера” и высокомерие. Множество раз видел такое, разговаривает через губу, каждое предложение начинает с глубокого раздраденного вздоха, а потом “ой меня никуда не берут, никто со мной не разговаривает, это потому что я самый умный а все тупые”. Особенно обидно такое видеть когда человек действительно умный. Ну потрать ты капельку ума на то чтобы научиться с людьми нормально разговаривать.
На эту тему вспомнилось, как у кого-то из серьёзных бизнесменов в начале его пути была команда на 100% состоящая из странных, неформальных, и маргинально выглядящих людей. Условно, у него офисе сидел панк с ирокезом, девушка с татуировками на все лицо, ещё какие-то странные люди вроде мужиков с помадой в юбке. Он объяснял, что готовность с такими работать - было его единственным преимуществом при хантинге топ спецов, ибо ни денег ни узнаваемого бренда у него не было. Поэтому, ставя жёсткие рамки по хард скиллам, единственные, кто к нему шли, это те, кого больше никто не брал
Вообще, подозреваю, что найм ещё одного разраба его уровня, возможно, смог бы решить вопрос. Топовые инженеры любят работать с равными себе.
По тех.уровню напарника можно и чуть ниже, достаточно чтобы понимал его код, но с хорошими софт. скилами, чтобы он был "переводчиком" между звездой и командой.
Напарник, это вариант, но скорее проблема в организации работы - видимо отсутствуют “морковки” за время потраченное на подтягивание команды, написание избыточной (с точки зрения самого программиста) документации, и т.д. . Мне, наверное, повезло - ни один из встреченных мной рок-звёзд и близко не был похож на описанного в статье, а вот вчерашних студентов или школьников таких - да, встречал, но даже с ними руководители как-то отношения выстраивали обычно.
А зачем тогда команда? Звучит примерно, как "а давайте приделаем трактору дополнительную сверхнизкую передачу, чтобы за ним поспевали кони, тянущие вместе с ним одну упряжку"
Это придуманый кейс компании которая занимоется черт знает чем... В нашей реальности подобной дельты скилов среди программистов просто не бывает, в коммерческой разработке, по крайней мере... если упрощать объяснение, то это как требовать от олимпиадника - почему твой сосед по парте не выигрывает олимпиады вместе с тобой :-) Но коммерческое программирование это тупой алгоритм, а не олимпиады... Это выдуманный кейс...
Прикол в том, что это не рок-звезды, а скорее аутисты. Таким людям проще с компом общаться, чем с людьми.
У самого такие коллеги были и есть. Ну не может человек объяснить, что и как делать. Инфу из него по отдельным строкам вытягивать приходится. У меня от нынешнего уже целый цитатник всяких умных команд, и он продолжает расти. А физически просто времени нет в этом направлении расти, в том числе потому что тема не моя.
До этого был парень, его после увольнения никто вспомнить не мог, потому что он от людей тупо прятался. Уволился потому что попытались заставить работать иногда с людьми. На новом месте его держат именно как кодера. Я случайно узнал, что он о смене места начал думать, его новые коллеги узнали, и они там переполошились, начали думать, что ему еще улучшить.
И да, проблема ровно та же, что без него никак. Кто то бухтит по этому поводу, но на деле без него в принципе можно обойтись, возможно когда то его и получится заменить, но всегда всплывает какое нибудь говно, которое будет оттягивать этот момент. И то, что казалось парой месяцев может растянуться на годы.
Другой вопрос, что другие не хотят читать. Вот я на каждый чих делаю инструкции. Просто потому что некоторые фишки нужны раз в пару лет, и там о них никто не вспомнит. И вот буквально на той неделе ко мне подошёл коллега, который спросил у меня, как делать его работу. Он тупо с 2024 года этого не делал и забыл, а я задокументил на случай если мне это делать понадобится. Но один хрен он попросил в двух словах расписать, ибо там же на сетевой лезть надо и читать... В итоге я единственный на 4 направления, у кого пара гигов - это просто всякие инструкции, написанные лично. Где то криво, где-то не актуально, но зато есть.
В итоге я единственный на 4 направления...
Опять bus-фактор
Лет двадцать назад в IT в основном шли люди такого склада, который вы называете аутизмом. Потому что тогда не было командной работы в этой сфере. И эти люди никуда не делись, они по-прежнему в деле.
Сегодня ничего не поменялось. Болтливые экстраверты отвлекают от мыслительного процесса своим бесполезным трепом о том, как вчера попили белковый смузи на Лиговском.
Ох, как я вас понимаю! Я поступила на ИТ-специальность 23 года назад. Людей не то чтобы не люблю, но искренне не понимаю, зачем тратить ресурсы на всяческие small talks. Открывать рот надо по делу.
Я долгое время был эникеем, очень много работал с людьми и просто неистово вкачал себе софты. Иногда люблю поболтать с коллегами, например пока ждешь кофе, на обеде, или иногда бывает так: отвлекся от задачи, с коллегой взглядом пересекся - он тоже отвлекся от задачи, и тут вы начали чет обсуждать) Ну а вообще это такая интроверсия с периодическими всплесками экстраверсии, потому что хочется с кем-нибудь поделиться с тем, что ты только что раскопал)) Главное никому не мешать и никого не отвлекать этим. Всему есть мера, время и место.
Еще добавлю, по своему опыту - в таких рандомных болталках очень часто происходил обмен экспертизой и находилось решение какого-то повисшего вопроса
Ох, блин, я вот тоже лет 15 эникеил, терминалы в магазины ставил и вот это вот всё - и так наловчился включать в себе такого общительного коммивояжёра, который и расспросит, и ответит, и разговор поддержит, и договорится, и организует и т.д. и т.п. А потом приходил домой и тупо не хотелось вообще никого видеть и ни с кем разговаривать. Последние несколько лет работаю аналитиком, и самое первое, что я делаю с утра - надеваю хорошие наушники с шумодавом и весь день молчу, даже на созвонах. Не поверите, такой кайф 😊 (жаль, на удалёнку не отпускают - данные чувствительные, нельзя за контур выносить..)
Я терпеть не могу «экстровертов», потому как они
как девушка в этом скетче —
могут годами трындеть о проблеме вместо того, чтобы решить её за три минуты. И это люто, бешено выводит из себя.
Ну я сам такой. Не очень люблю общаться. Нет необходимости, могу весь день молчать. Но на той же работе я понимаю, что навык общения нужен. И лучше быть "своим в доску улыбчивым парнем", чем "каким то хреном, который даже не здоровается". Опять же, когда дойдёт дело до сокращения, руководство будет не только по хард скилу смотреть, но и по софт. И всегда найдется тот, кто скажет "пусть мне этот улыбчивый помогает, а не этот, который даже не поздоровается".
Опять пальцем на исключение показываем и бухтим. Неадекватная риторика
В конец истории он там с топором в офис пришёл и всех на мясо изрубил и ещё полгода продавал в элитные рестораны Москвы.
А если по теме, то у нас была прикольная история: CTO по своим связям где-то нашёл и нанял некого хмыря, который был преподнесён как новый блестящий тимлид для одной из свежесозданных команд. Человек с блеском говорил на любые наши технические темы, был звездой Highload++ (и до сих пор входит там в число каких-то организаторов), на кофепоинте увлечённо спорил и объяснял разные сложные штуки про распределённые системы, многофазные коммиты и репликации и прочую дичь с многопоточностью и внутренностями компилятора. Со временем выяснилось, что это его основной скил - блестяще излагать. Брался он за разные начинания, все были брошены на полпути. Команду эту свою к успеху не привёл, продукт не сделали ни в какой версии, один из старожилов даже психанул и уволился. Потом его конечно попёрли каким-то образом, сообщив нам что "объяснили друг другу, что ожидания не оправдались" ну и вроде как подписали даже какие-то формальные отказы от взаимных претензий. Чел был настолько блестяще излагал и умело вовлекал в любые увлекательные обсуждения всех вокруг, что даже когда на него прямо наехали со словами "а вот ты начинал и где результат", то всё кончилось сначала многослойными объяснениями почему так вышло и сверху очередным увлекательным спором о технологиях! Это было любопытное психологическое явление - всем вокруг было очевидно и ясно как день, что имеют дело с ловкачом-продавцом-пылесосов, а поскандалить и довести его агрессивно до ухода или заткнуть никто не решался!
Такие люди тоже могут приносить пользу, если их правильно применять. На тех же конференциях бренд компании продвигать, тоже дело.
Наняла меня как-то небольшая компания, чтобы я перевел их платформу с технологии X на Y, опыт такой у меня был, но вместо того чтобы писать новую архитектуру и код, меня сначала загрузили в попытках ускорить работу X (опыта какого у меня не было), а потом и еще и доработки по X (опыта какого у меня не было), в итоге очень плохо ушел со скандалом в с обеих сторон. Что они там теперь про меня рассказывают, я хз, возможно также как в вашем примере.
Взяли в группу фронт-меном рок-звезду, а теперь ноют, что он разнес гримерку и набил морду бас-гитаристу. То, что группа теперь собирает стадионы и ездит в мировые туры это, само собой, заслуга менеджмента. Главный вопрос на повестке - как сделать, чтобы фронт-мен стал зайкой, и при этом продолжал собирать стадионы. Я правильно изложил?
От этой истории у меня полное ощущение, что в команду полную бездельников наняли нормального инженера. Особенно - код в неявной логике - в которой не кто разобраться немог! Или не хотел? Или началось - вон Ваня больше получает и значит ему нужнее - мы тупо посидим покурим в сторонке - он все сделает. Проблема не в звезде - а в команде - которая отказалась тянуться за звездой. Учитываю ситуацию - что звезду взяли по причине того - что модуль ДОЛЖЕН быть написан - то разгонять нужно команду.
Ошибка найма «рок‑звезды» — это не история про плохого инженера. Это история про некомпетентного руководителя, который не задался вовремя вопросом: «Как мне потянуть еще одного сотрудника, когда я уже не вывожу шестерых?».
Уже на второй неделе наш гений отказался писать документацию. Это был первый звоночек, но тимлид не придал ему значения — «главное, чтобы код был».
Ну так повесить будничные задачи и рок звезда обычно превращается в чуть лучше средняка. Хотите рок звезду, нанимайте в пару подмастерье, технического писателя, обслуживающий персонал. Впрочем можете сэкономить и взять только обслуживающий персонал результат будет чем-то похожий...
Если кандидат говорит «мой код самодокументируем» или «не пишу комментарии, они устаревают» — красный флаг.
А что он не так говорит? Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название. И да, я видел команды, которые своё неумение в нейминг пытаются компенсировать комментариями. И да, комментарии потом забывают править, они устаревают. Всё правильно.
А остальные комментарии по правилу "всё должно быть документировано" являются просто мусором, забивающим контекстное окно. В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный. Приходится по каждому методу проходить и смотреть, что он там на самом деле делает.
Человек может умеет работать с наименованиями. А у вас сразу ред флаг. Не надо так.
Вот к чему такое чёрно-белое мышление? Представьте если бы в документации к стандартной библиотеке какого-нибудь языка (выберете на свой вкус) у функций не было никакого описание, только “удачно выбранное” название. Это был бы ад. Имел неудовольствие пользоваться библиотеками, где никакой документации на методах нет. Документация нужна, по крайней мере на внешнем API. И API какой-нибудь подсистемы внутри вашего продукта ничем не хуже API какой-нибудь библиотеки.
В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный
В итоге (если какой-нибудь новичок наслушается такого рода пафоса) будет код и без комментариев и с отвратным неймингом. Что хуже, чем с комментариями и отвратным неймингом.
потому что комментарии бесполезны
Потому что их надо уметь писать, big news. Вы так пишете как-будто комментарии вообще всегда бесполезны, что не соответствует истине. Например в каком нибудь Си, вы предложите называть функцию так? “ReadFileReturnsZeroOnSuccessAndNegativeOneOnError(…)”. А то как же, комментарии писать нельзя!
А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Вот к чему такое чёрно-белое мышление?
Вот расставление редфлагов по признаку "не пишу для каждой функции комментарий" и есть чёрно-белое мышление. Или кандидат думает как мы, или он плохой.
Потому что их надо уметь писать
Потому что вырываете слова из контекста. Если комментарий пишется по принципу "всё должно быть задокументировано", то в нём смысла нет. Когда комментарий пишется по принципу "тут надо бы пояснить читателю", то в нём смысла на порядок больше.
ReadFileReturnsZeroOnSuccessAndNegativeOneOnError
"readfile". Не силён в чистых сях, но существуют конвенции. 0, если выполнилось без ошибок, -1, если была ошибка. Конвенциальности в именование не вносятся. Это во-первых.
А во-вторых опять же, не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта.
Или кандидат думает как мы, или он плохой.
Я если что интервьюера не защищаю, спорю только с вашей позицией.
Когда комментарий пишется по принципу “тут надо бы пояснить читателю”, то в нём смысла на порядок больше.
Я тут с вами согласен, я бы может и не стал с вами спорить, если бы вы свой изначальный коммент более нюансным сделали)
Конвенциальности в именование не вносятся.
Да, очевидно, я специально привёл абсурдный пример. То что функция возвращает 0 или -1 надо писать в комментарии к ней, особенно если кроме -1 у нас есть другие коды ошибок.
не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта
Я и ничего не путаю, я написал чёрным по белому “API какой-нибудь подсистемы внутри вашего продукта ничем не хуже API какой-нибудь библиотеки”. Вы так пишете, как-будто если код внутри нашего проекта, то просто у всех программистов в команде идеальное знание кода и что какая часть делает. Что если у нас один человек пишет модуль, а другой человек этим модулем пользуется? На API этого модуля всё равно не писать комментарии? Но ведь API модуля по сути публичное для второго программиста. Могу предвидеть контраргументы:
Но если люди в одной команде, то им проще спросить друг у друга что метод делает. - Но если что-то записано в комментарии в коде, то оно будет хранится в гите и будет доступно если кто-то новый в команду прийдёт. А то придётся опять у автора кода спрашивать “а как оно работает/как им правильно пользоваться” (если он ещё не уволился).
Во время разработки код часто меняется, поэтому писать комментарии бесполезно, они будут устаревать. - Это уже вопрос дисциплины в команде, такое надо на код ревью отлавливать.
Вы так пишете, как-будто если код внутри нашего проекта, то просто у всех программистов в команде идеальное знание кода и что какая часть делает
Я пишу так, как будто у всех программистов в команде есть представление о предметной области и они хорошо знают язык программирования. И они хотя бы в курсе архитектурных решений того куска кода, на который смотрят.
Этого уровня вполне достаточно, чтобы не засорять код бессмысленными комментариями, и в то же время эта планка достаточно низка, чтобы можно было её считать квалификационным барьером.
Комментарии, рассчитанные на читателя, не обладающего соответствующей квалификацией не делают код понятнее для этого читателя. Но затрудняют работу над проектом тем, кто проходит квалификационный барьер.
то им проще спросить друг у друга что метод делает
напомнило)
А чо, Рафаэль — опытный разработчик: он знает, что у соседней команды данные самые свежие — а конфу последний раз правили пять лет назад. Да и о подводных граблях из серии «а вот у Васи с этим методом случай был...» у кулера потрындеть не вредно.
А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Да но нет. Требование "понимать должны без меня, а то из отпуска достанут" и там, и там в наличии. Требование "да и я сам должен после отпуска через год захочу вспомнить почему тут так а не эдак не перелопачивая всё" - тоже.
существуют конвенции. 0, если выполнилось без ошибок, -1, если была ошибка.
Насколько я помню, конвенция — «0: ошибок нет, -1 — что-то пошло не так, более точно см. код ошибки в errno(); старший бит установлен (то есть число отрицательное) — ошибка, код в остальных битах.»
ReadFileReturnsZeroOnSuccessAndNegativeOneOnError(…)
Даже в “каком-нибудь C” можно написать так, что суть будет понятна любому человеку, работающему с языком дольше месяца:
enum error_code read_file(...)some_result read_file(..., enum error_code* err)
Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название.
Комментарий должен пояснять не что делает метод, а зачем он это делает.
Точно у метода, вычисляющего длину строки, нужно писать зачем вычислять длину строки?
Точно. Как минимум, чтобы стало понятно зачем вместо вызова библиотечной функции свой самобытный метод написали.
А если метод и есть библиотечный?
Тогда комментарий просто обязателен. Просто в случае библиотек комментарий пишется не рядом с кодом, а в документации. Пример: https://cplusplus.com/reference/algorithm/sort/
зачем вместо вызова библиотечной функции свой самобытный метод написали.
Именно так. Не обязательно писать комментарии к каждой строке кода, но к каждому блоку - надо расписывать, нахрена этот блок вообще тут нужен.
Не "зачем это делает". А "почему именно так". Зачем это метод делает решает не метод, а вызывающая сторона. Ей виднее зачем.
Как только код соприкасается с реальным миром - никакой нейминг не поможет. Только комментарии. Расскажите, как неймингом указать, что "это мы делаем потому, что согласно ст. № .... ФЗ №... от .... надо выполнить следующие действия..."
Это прямо идеальный пример, когда комментарий рассказывает "почему именно так", а не "что делает метод". И это правильный комментарий.
Но тут есть один нюанс. Этот комментарий должен быть не перед методом, который делает что-то в соответствии с "№ .... ФЗ", а где-то посередине кода, прямо перед вызовом этого метода. Потому что сам метод не знает о том, зачем его вызывают и в соответствии с каким ФЗ. Он просто делает свою работу, когда от него требуют.
Хватает ситуаций, когда комментарии нужны, но не вида userId // идентификатор пользователя.
Но уметь писать полезные комментарии и не писать бесполезных - это отдельный сложный навык. А если в компании отсутствие комментариев приравнивается к "красному флагу", то могу представить, какой бардак там творится.
Дальше — хуже. Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код.
Дак это он специально что-бы его потом не уволили, когда проект доделают до конца. Блин умный мужик!
«Расскажи случай, когда ты помог младшему коллеге разобраться в сложной теме. Что именно сделал? Как часто это происходит?».
Ну знаете иду я как-то а кофейный автомат у одного джуна купюру зажевал. Ну я его ногой пнул и он кофе налил.
Я помню давно давно в прошлой конторе в соседнюю команду как то взяли рок звезду (на фоне остальных). Вроде даже интервьюер сказал ему, что резюме и ответы на собесе лучшие когда либо видели и очень хотел бы видеть его в нашей команде. Человек разумеется принял оффер. В командах были спринты, в конце каждого спринта был общий созвон (zoom) со всеми командами и все должны рассказать, что за спринт сделали важного + потом zoom ретро по спринту. Так этот новый чел просто отказался приходить на эти мероприятия, не знаю чем мотивировал, возможно что код в проде лучшее доказательство что сделал, а не эти спринт ревью, общем саботировал корпоративные практики работы в командах, но в кодинге был боженька. Испытательный срок не прошел конечно. Причем при найме говорили что работе в команде + аджайл.
В конце каждого спринта был общий созвон (zoom) со всеми командами и все должны рассказать, что за спринт сделали важного + потом zoom ретро по спринту
...
Причем при найме говорили что работе в команде + аджайл
Хоть я и не большой фанат аджайла, но такая встреча это же ужас. Это ещё одна неэффективная встреча, маскирующаяся под демо. Ретро, хотя-бы было не со всеми командами?
Ретро, хотя-бы было не со всеми командами?
Да, внутри команды конечно (прошу прощения забыл этот момент добавить). Да тут дело не в том, что аджайл это плохо или хорошо, ему сказали как происходит воркфлоу - дэйлики, ретро, демки, брейншторминги и прочее, ну то есть каждый день какой-то движ в зуме. Зачем тогда соглашаться на работу мне не ясно. Я сам этого не люблю, тоже больше интроверт, но это часть игры, просто нужно смириться, я понимал это когда принимал офер. Видимо думал раз рок-звезда то сделают исключение, но это так не работает.
Для меня тоже афигенная проблема в пятницу вспомнить, что я делал в понедельник. Поработаете с моё — осознаете, что всё оно сливается в сполшную монотонную полосу. (И нет, не джейсоны.)
Если честно в наше время, я не понимаю, как может быть ситуация, что кто-то что-то может не понять в коде. Сейчас ведь ии могут полную аналитику всего приложения за пару минут выдать. Речь о топовых думающих западных ии.
Хорошая история, генерируйте еще.
Но через пару месяцев начинаются проблемы. Наш вундеркинд категорически отказывается писать документацию («Код сам себя документирует для тех, кто умеет читать»). Code review от него выглядит одинаково: «Это не работает, перепиши с нуля» — без объяснений. Джуниор, попросивший помощи, услышал: «Читай документацию к фреймворку, я не репетитор».
Еще и пользователей консультировать отказался, гад такой.
Чел вообще топовый. Удивляет только одно - как он видя вокруг команду в подгузниках, вписался в их песочницу.
Трейдинг, хайлоад... и тут же обязанности "объяснять джуну..." ладно, хрен с ней документацией, может он прав, может он не прав, нужно видеть контекст.
Но человек на таком проекте, которого взяли, чтобы хайлоад реально был - это не про кураторство над джунами. В трейдинге хайлоад либо сразу приносит прибыль, либо его отсутствие сразу приносит убытки и большие.
Это же не тот же хайлоад, когда апишечка стала откликаться на 15% быстрее, чтобы аватарчик в соцсеточке загрузить быстрее. Это реальные бабки, и там битва идет за доли процентов в скорости.
И как чел с опытом таких проектов, сможет что-то объяснить джуну на его, джуна, языке?
Взяли рок-звезду, разрешили ему накодить кучу, разрешили ничего не документировать, и никому не передавать знания.
Организация и дисциплина в конторе так себе.
мне кажется эту чушь сгенерил вам ИИ для вашей рекламы
Выделяем сложный модуль в отдельный проект, назначаем на него рок-звезду, даём ему возможность подобрать себе коллегу, который “будет тебе помогать” и “закрывать тикеты, пока ты в отпуске”.
Выделяем этих двоих в отдельную команду, с отдельными code-review и митами. Тем самым снимается львиная доля проблем с токсичностью в команде.
Ещё желательно натравить в качестве reviewer-а этого проекта (ведь “он так важен”), вашего архитектора/staff, которого рок-звезда не может просто заткнуть, как недостаточно компетентного, чтобы ему что-то объяснять или доказывать. Его задача - добиться от рок-звезды внутренней архитектуры модуля, которая для понимания не требует ни быть её автором, ни даже просто выдающихся компетенций (хотя требуемые компетенции по прежнему могут значительно превышать компетенции вашей команды, но это отдельный вопрос).
Дальше получается вилка - если рок-звезда и правда неадекват (скорее всего с серьёзным выгоранием), то его можно уволить после того, как “помощник” в целом разберётся в модуле, а в новую команду добрать сильных специалистов. Откуда бюджет на расширение? Ну, если рок-звезде приходится работать по 10+ часов в день, значит либо количественная сложность проблемы недооценивается бизнесом, либо ваша рок-звезда не такая уж и звезда, а просто старый, усталый рокер, а качественная сложность проблемы ему не по зубам.
Ну а если вы просто наняли человека, технический уровень которого сильно превышает уровень остальной команды, то внезапно окажется, что новая команда продуктивна, в ней нормальная рабочая атмосфера и т.д. и т.п. Ну, отлично, получилась кузница кадров, а проблема в запрягании лебедя, рака и щуки куда-то не туда.
Альтернатива - внутренний перевод либо звезды, либо руководителя команды, так как текущий с ситуацией, очевидно, не справляется.
Есть такое понятие, "коллективное владение кодом". Оно в команде обязано быть в наличии!
НО если этот самый код (блок кода, модуль, имплементацию) - пишет один человек, а остальные молятся на него, то с какого перепуга этого работягу заставлять писать ещё и документацию?
Пусть тогда остальные тоже потрудятся: хотя бы попытаются этот код понять и задокументировать его.
Задокументировать, именно так, как они его поняли - а трудяга, прочитав этот документ, поймёт, поняли его, или не поняли, и что поняли не так.
Пара-тройка итераций - и вот и документация готова и понимание появилось. Без какого-либо взаимодействия и трат времени трудяги на разъяснения и тем более на разработку документов - пусть продолжает писать только код.
Сто раз так практиковал - неимоверная эффективность детектед.
Иначе несправедливо получается: работает один, а потом ещё и репетитором, да ещё в письменном виде - книги документов пишет. А остальные на расслабончике проехались, "не понятно им, разъясните, научите".
если этот самый код (блок кода, модуль, имплементацию) — пишет один человек, а остальные молятся на него, то с какого перепуга этого работягу заставлять писать ещё и документацию?
Пусть тогда остальные тоже потрудятся: хотя бы попытаются этот код понять и задокументировать его.
Задокументировать, именно так, как они его поняли — а трудяга, прочитав этот документ, поймёт, поняли его, или не поняли, и что поняли не так.
Кстати, восхитительная идея: одновременно и поднимает ЧСВ гуру («вот идиоты, даже не поняли, что я имел в виду!»), и поддомкрачивает команду до уровня.
Очередная история про менеджера, который вообще не понимает, чего он хочет. Тут вроде технический ресурс, а это значит, что размазанные на несколько экранов (или даже статей) советы можно взять и обобщить в одну концепцию. Для начала определи, чего ты хочешь, потом запиши это на бумажке (потому что память - штука очень гибкая), а потом уже действуй, постоянно сверяясь с этой бумажкой. Если в процессе ты заметил, что ты хочешь что-то за пределами этой бумажки, напиши новую, положи рядом и не пытайся делать вид, что именно этого ты хотел изначально.
Если изначально хотелось быстро переписать модуль силами нового сотрудника, потому что имеющиеся неспособны это сделать, то не надо делать вид, что задача была подтянуть команду. Если хотелось не только модуль, но ещё и чтобы команду научили разбираться в коде, в котором сама команда разобраться не способна, то, очевидно, это стоит не меньше, чем вся имеющаяся команда. То есть не меньше 6 средних зарплат по команде, а не 2 с половиной. Не обязательно в руки одного человека, но суммарные затраты будут такими, ничего не поделать - базовая арифметика должна соблюдаться.
Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код.
кто и как ревьювил архитектуру ? кто и как ревьил этот код ?
Ревью - это не только про поиск ошибок и проблем, это и передача знаний.
Складывается впечатление что корень проблем был в процессах, а новый сотрудник выступил лакмусовой бумажкой ...
Про суть статьи уже сказали, меня очень триггернуло вот это:
И еще один индикатор — это готовность к парному программированию. Предложите разработчику написать первую задачу в паре с кем‑то из команды. Если он отказывается («я быстрее один») — вы получили одиночку, и в командной разработке это минус.
Я никогда не соглашусь от балды писать что-то в паре с кем-то, особенно свою первую задачу, когда я вообще не обладаю контекстом разработки на новом месте. Парное программирование работает тогда, и только тогда, когда оба разработчика знают контекст задач и проекта в целом, знают, что другой это знает, и знают стиль, уровень и подход друг друга. Иначе это корабль с двумя капитанами, один из которых всегда Барбосса, а другой Джек Воробей. Я на текущем месте пришел на конкретный проект и работал в паре с текущим разработчиком проекта года полтора где-то, потом остался на проекте один, коллегу перекинули в другое место. Так вот, первые несколько месяцев я вливался в контекст, спрашивал, старался глубоко разбирать задачи, первый месяц вообще делал только типичные заявки техподдержки - потому что кодинг это не только написание кода строго по ТЗ, это еще и наполнение собственного контекста и понимания того, как работает бизнес с тем, над чем ты работаешь. Особенно когда над проектом ранее работало шесть разных разработчиков в течение десятка лет, которые писали кто во что горазд, в данных в БД местами авгиевы конюшни, 70% кода - это легаси, от которого надо избавляться, и которое наполовину просто де-факто не используется, а то как написано, и как этим пользуется конечный пользователь - две большие разницы. Сейчас я бы очень хотел кого-нибудь, кто исключит bus factor в отношении меня самого, потому что коллега покинул компанию, но пока что этого нет, а разработчиков с других проектов я знаю, знаю прекрасно их подход и стиль, но на моем проекте меня 95% этих людей просто не заменят. Отчасти потому, что проект имеет в подразделении негласную репутацию "вон той аццкой жести, в которую лучше не лезть". Оставшиеся 5% - те, кто имел какое-то отношение к проекту в последние несколько лет. Да, они конечно реализуют за меня точечные задачи, квалификация никуда не девается, но делать с проектом что-то масштабное - им понадобится минимум тот же месяц на вхождение в проект, с учетом того, что остальным контекстом они уже обладают по факту того, что работают в компании годами. И документация тут не сильно поможет, к слову.
Интересно. А вот в моей текущей команде комментарии в коде запрещены. Если только ты не докажешь ревьюверу, что без комментария вот этот кусок никто не поймет ("465 дней это не опечатка 365, а 15*31"). Я тоже вначале был слегка изумлен, но потом привык. Это правило когда-то ввел вот такой рок-стар, который потом ушел в другую компанию, а правило осталось. Да, пять сухих мартышек и подвешенный банан.
Встречал интересную практику “комментарии в коде пишем капсом”, призванную демотивировать людей писать слишком длинные или избыточные комменты. Ещё вспоминается один коллега, у которого в редакторе комментарии были настроены ярко красными: “Если уж я написал комментарий, лучше бы ему быть заметным”.
Подтягивать команду и писать идеальный код, два принципиально разных навыка, редко сочетаемые в одном человеке (хотя такое и бывает). Надо на этапе набора, прозрачно ставить для себя и окружающих цели найма. Для топовых специалистов, нужны соответствующие условия, прежде всего уровень окружающих их сотрудников и управленцев должен быть сопоставим, самый лучшие звездные специалисты чахнут попав в слабую команду к бестолковому управленцу. Часто такое встречаю, до абсурда просто доходит, когда один и тот же человек подрабатывая на сторону вне основного рабочего времени творит чудеса, а на основном месте в своем бигтехе и 10% не выдает от номинала. Потому, что любая система стремиться к уровню минимальной энергией и максимальной энтропией. Это наоборот может работать, если в команду к 5 топ экспертам посадить джуна, то он может очень быстро прокачаться.
Выглядит не то что он гений, а то что команда ну прямо совсем слабая. Не могли сами создать новую платформу, не могут разобрать в коде который решает их проблемы без комментариев. Не готовы отстаивать свой код. Звучит печально и приговор команде. Есть набор туповатых фриков которые явно не тянули и поэтому пришлось срочно нанимать спеца который конечно не захотел тянуть всю команду так как это бесполезно.
а то что команда ну прямо совсем слабая. Не могли сами создать новую платформу, не могут разобрать в коде который решает их проблемы без комментариев. Не готовы отстаивать свой код. Звучит печально и приговор команде
я вот за всю свою карьеру, далеко не часто встречал прям "команду" которая горой за код, результат и чтобы прям ващекруто мы тут пашем.
Всегда есть организующий людей человек, всегда есть кто работает тупо за зарплату и не вникает. на галерах и галероподобных проектах такое прям вообще массово, люди тупо делают задачки по ТЗ которые откудато материализируются и делают их по принципу "мне платят норм и ок, остальное не моё"
Обвинять в этом команду...ну такое, в этом виноват менеджмент который не нашел нормального тимлида чтобы он всё организовал и поменял людей которые вообще не тянут
в данном кейсе, тимлида нашли, но он явно не тимлид, а одиночка который вырос гдето в тепличных условиях, а когда дело дошло до жестоких реалий когда у тебя 10 человек из которых 5 это джуны, 4 миддла и 1 миддл+, а еще и аналитика нет который помогает не забыть бизнеспроцессы... тут реально начнет бесить что миддлы с джунами тупо бабки получают и жалуются что ТЗ плохо описано
Тупо обвинять тупого что он тупой. Это не обвинение, а констатация факта. Предыдущею команду они благополучно просрали. Причем всю ведущею группу раз не кто не может в архитектуру. Руководство собрало новую команду которая явно не тянула (брали что подешевле) и попробовала взяв одного который должен были тянуть проект и обучать команду. Сэкономили называется. Почти наверняка сроки уже горели и гению сказали вытяни проект. Гений в итоге работает 60 часов в неделю и ему явно не до обучения. И то что он сразу забил на обучение показывает как раз что он уже бывал в такой ситуации и не собирается на себя ещё и этот геморрой взваливать. Обучать людей которые не хотят и особо не тянут ну такое себе. Так что нет не был он до этого в тепличных условиях.
Как то мало минусов
А когда эту рок-звезду нанимали, ему было сказано, что в его обязанности будет входить помимо написания кода еще и менторинг, и обучение в виде "подтягивания всех остальных, и еще куча всего, что себе напридумывали тимлид и менеджер? Просто это далеко не всем нравится и подходит. Или понадеялись на "авось", как обычно?
Вообще, лучшем видом документирования программного кода являются юнит-тесты. И если система действительно "сложная", то они всё равно необходимы.
Если "рок-звезда" сам не пишет юнит-тесты, то его можно было бы об этом попросить, дать ему на это время. Программист понимает, что это не бессмысленное занятие, если делается это не ради метрик покрытия кода тестами.
Но если "рок-звезда" настоящая рок-звезда, то он сам пишет юнит-тесты. И тогда тем более понятно, почему он шлёт куда подальше всех этих "нипанятна, напиши документацию".
Да пофиг на звезд и не звезд. Айтишник, где твоя "база". Работает - не трогай.
Думать о том как развивать проект должен тот кто сам знает как развивать проект и способен поставить "задачу" (как минимум по SMART, простихоспади) на не абстрактную "цель". Теимлидам всяким на заметку: учите матчасть!
Человек из болота вас решил вытащить, а у вас среда обитания нарушилась. Вам и там было хорошо.
Ошибка найма «рок‑звезды» — как один супер‑инженер разрушил команду за полгода