Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Миддлы и джуны, а как вам работается c сеньйорами над одним проектом?

Всем привет! Представьте себе такой расклад. Вы устроились на новое место работы в продуктовую компанию, где из всех специалистов — разработчик только один, он там работает 5-10 лет и заслуженно может называться сеньйором. Пускай это будет Senior PHP-developer. И приходите к нему вы — Middle PHP-developer, работать с ним над одним и тем же проектом. Я думаю, что у многих форумчан похожий расклад (не обязательно PHP-программеров). Теперь вопрос: нормально ли вам там работается? Нету ли такого, что что бы вы не написали, сеньйор это все равно считает говнокодом и или переписывает сам, если там мало, или заставляет переписывать вас так, как это видит он, диктуя свою архитектуру? Причем любой ваш вопрос по проекту его раздражает и мешает ему работать.

И еще вопрос: допустим сеньйор написал какой-то модуль и кинул вам на доработку, чтоб вы быстро разобрались в коде и дописали этот модуль. Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это «не его»?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Все зависит от того, как в первый день в опенспейс зайти.

Если, например, заходите в опенспейс, а синьйор полотенце под ноги кидает — ни в коем случае нельзя его поднимать. Просто переступить и всё.

Еще сеньйор может задавать вопрос — «Вилкой в глаз или пофиксишь баг один раз». Правильный ответ — «Что-то я в компании одноглазых не вижу».

Ну и классика. Если сеньйор начинает говорить что-то типа «Есть два бага — один минор точеный, другой блокер блоченый. Какой себе взять, какой джуну отдать?» — сразу загуглите правильный ответ. Иначе багфикс и унижения на код ревью до самого конца.

Если правильно на все вопросы ответили — будете в авторитете и возможно в один прекрасный день станете синьйором.

Миддлы и джуны, а как вам работается c сеньйорами мудаками над одним проектом?

Поправил вопрос.

Миддлы и джуны, а как вам работается c сеньйорами над одним проектом?

Нормально работается, меня не бьют даже.

Должен сказать этот, так званый сеньор, хороший пример «дутого сеньора».

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

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

Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это "не его"?

Это говорит то, что скорее всего перед тобой как раз таки говнокод, ну если вы конечно не для NASA какой-то рокет сайенс пишете или проект с каким то дата хай лоад, но я очень сильно сомневаюсь что на проекте с одним синьором, пишут что-то серьезное.

ЗЫ при возможности меняй работу, этот чел выдрочит тебе все мозги и даже не даст тебе развиваться, кроме как развиваться в такого же мудака. И ничему толоковому ты в этом бедламе не научишься, разве что набрать желанный год опыта работы и свалить на +500 на адекватную галеру.

Странные вы люди
1. Джуниорам и миддлам в нормальных местах поручают работу их уровня квалификации, где они не смогут напортить. Джун будет двигать кнопочки и менять конфиги, миддл формошлепить и крудить, синьор — делать работу требующую подумать.
2. Менее опытных нанимают не потому, что хотят их облагодетельствовать. Простую работу тоже надо делать и она должна стоить дешевле. Соответственно берут людей с меньшей квалификацией и именно на них делают большую часть денег оутсорсеры — синьоры дорогие.
3. Если Джун не справился с сложным заданием виноват тот, кто его поручил не подходящему сотруднику.
4. Нормальные люди все это понимают. Поэтому не третируют тех, кто знает меньше. Тех же, кто третирует называют токсичными и это правильно, при первой возможности от них избавляются

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я бы задался вопросом, а для чего вас наняли?

С ваших слов, это выглядит так: проект начал расти, и этот единственный разработчик перестал справляться из-за большого количества новых задач. Ему спустили разнарядку: надо нанять ещё разработчиков, чтобы разгрузить его. Ему это вполне возможно что не очень нравится: ещё бы, 5 лет сидел сам, никто его не трогал, всё было хорошо, и тут на тебе. Принять неизбежное он не хочет или не может. С большой долей вероятности масла в огонь подливает ещё что-то, что вы делаете, а ему не нравится, потому что он привык делать по-другому, а вы ему подсовываете своё решение (плохое или хорошее — другой вопрос, оба варианта возможны).

У вас есть варианты:
1. Свалить оттуда и устроиться в другую компанию, и пусть они сами решают свои проблемы. Самый простой вариант.
2. Попытаться выйти на честный диалог с этим разрабом, найти общий язык, выпить вместе пива, в общем, найти точки соприкосновения. Процентов 20 что сработает.
3. Разворотить осиное гнездо и пойти к начальству — в общем, пойти на конфликт.

В последнем варианте последствия могут быть любыми. Если всё так, как я описал, то скорее всего вас не уволят сразу, а начнут разбираться. Дальше всё зависит от вашей харизмы и харизмы этого разработчика. Либо он убедит начальство, что вы некомпетентны, и вас жёстко поставят на место или уволят (что весьма, весьма вероятно с учётом того, что он работает там много лет и имеет репутацию), либо вам удастся перевести огонь на него, но тогда вообще неизвестно что будет. Вы будете в контрах с ведущим разработчиком, проблему вы не решите, огонь конфликта будет медленно поддерживаться совместной работой и вылазить на поверхность тут и там, до тех пор пока компания не наймёт ещё 3-4 разработчиков (из них пару сеньёрных) и вы не задавите старожила количеством. Тогда он либо уволится, либо уйдёт в тень и будет попиливать какой-то фрагмент проекта, максимально дистанцируясь от вас.

Тогда он либо уволится

и тогда точно этому проекту придет п****ц)

Со стороны сеньора или лида, любой ново-прибывший человек — это нагрузка. Надо и свою работу делать, и за него «подумать». Потому как просто так за пару дней «войти в сложный проект» — нет, обычно не выходит. Да и «джун» обычно — это ведь студент. Он или еще на 3-5 курсе учится или вот только закончил. Ты ему будешь рассказывать как правильно класс называть, или как в деталях правильно решить задачу, вообще как более-менее правильно програмировать, т.к. обычно люди если и программировали для себя — то весьма «по-своему». Всегда ценю людей которые думают своей головой.

собирать вопросы в очередь и задавать их на следующий день с утречка

+1
Одне запитання на дві хвилини — вихід з потоку на 30 хв. Краще консолідувати пачку запитань в одну сесію.

Причем любой ваш вопрос по проекту его раздражает и мешает ему работать.

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

для этого и существуют тестовые задания, чтобы понять, как тебя оценивают
чел не может прийти в проект с одним сениором не прособеседовавшись с ним

чел не может прийти в проект с одним сениором не прособеседовавшись с ним

Запросто. Т.к. решает не синьор.

Что решает не сениор? Приходит или не приходить на собеседование?

Синьор ничего не решает. T.к. его дело реализовывать проект/кодить — а дело менеджмента заведовать ресурсами.

Потому, к примеру, если у менеджмента есть лишние ресурсы, которые некуда деть и которые невозможно уволить (актуально для Германии) — их запихнут на тот проект, где есть бюджет. И никаких синьоров при этом, ни о чём не спросят.

Или к примеру, если менеджмент решит, что пора на проект завести ещё пару чел (т.к. болъшой риск, при завязке проекта на 1 чела) — синьора никто не спросит тоже.

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

Так Бельгия же — родина мелкописечника и подкаблучника Олланда, и там все остальные — такие же ±.

4. Периодически проводишь код ревью и насилуешь особо упоротых.

А в чем заключается особая упоротость в твоём случае?

Любая програмерская хрень — это всегда море говнокода и если она монолит, то ее проще выкинуть. А если модульная, то по необходимости модули обновляются переписываются, рефакторятся и т.п.

и что удивительно, разработчикам приходится регулярно повторять

Инкапсуляция — это способ заметания мусора под ковер
а ты разбрасываешь мусор по всей квартире!
Инкапсулируй!!!

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

Инкапсуля́ция (лат. in capsula; от capsula «коробочка») — размещение в оболочке, изоляция, закрытие чего-либо инородного с целью исключения влияния на окружающее. Например, поместить радиоактивные отходы в капсулу, закрыть кожухом механизм, убрать мешающее в ящик или шкаф.

Криво ты написал. Не под ковер

правильно я написал

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

это скорей педагогический прием :)

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

поэтому придумываю свои. в расчете что если тоже самое рассказать другими словами — то может и результат будет. для проекта :)
у меня ж забота не подготовить разработчика к собеседованию, а повысить его эффективность

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

ну так как требовать если на проекте в принципе нет тестов и чувак бы просто проигнорил
ревью у нас были по 2-3 недели
ну в итоге то он вылетел на мороз, ну не так чтоб на мороз, работу то другую найти не проблема

я думаю там наняли кого-то «подешевле» но «толкового» и отдали чуваку вроде как на вырост, а по факту регулярно спрашивают с него, какие результаты приносит подопечный, не принимая ответ «пишет тесты к своему говнокоду», аргументируя тем что «ну оно же работает?», «давай в продакшен, потом своей фигнёй заниматься будете». Лечится тем чтобы показать, что таки «не работает» и вообще опасно.

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

Да, но если вы пойдёте на поводу у начальства в этой ситуации и выкатите плохой код в продакшен, и продакшен упадёт, то виноваты всё равно окажетесь вы.
Чувак эту проблему для себя купирует тем, что переписывает код за подопечного, что является пагубной политикой. Если подопечный написал плохой код, то начальству чётко надо донести, что это «не готово» и «не работает», а не «почти готово» или тем более «готово, но там код плохой». И когда эта ситуация будет повторяться второй, третий, четвёртый раз, то чётко поставить вопрос об увольнении подопечного.
Короче там по ходу тупо нехватка власти и отработанных процессов, человек лезет ему через голову, не слушается его как руководителя, а он не в состоянии это пресечь.

Да, извините, я совсем отвык от жёсткого кровавого аутсорса за последние годы. В продукте, или по крайней мере при отсутствии большой цепочки посредников, такое гораздо менее возможно. Все понимают, что из одного котла едят, навернётся котёл — плохо будет всем.

Как она может быть продуктовой, если французы (с ваших слов) посредники между вами и Intel / Toshiba?

ответ пм был крайне прост: «учи его, ты не сразу все знал»
а продакт спрашивал какого черта так долго, мы ж тебе даже помощника наняли
ото у меня пригорало

Ну так порекомендуй им почитать книгу «Мифический человеко-месяц».

Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован «закон Брукса»: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».

Добавление новых людей даёт плюс в средне-долгосрочной перспективе, а не мгновенно.

я им посоветовал определится, нужен ли я на проекте, оказалось нужен, в итоге джун пропал, пм убрали

Когда начинающие говорят
— Уже полгода ищу работу! Да я ж за еду готов работать!
в уме ответ:
— а почему это — за мою еду? ну вот и остальные не хотят делиться — своей едой.

Как это... Здравомыслящий? Не... А, да: токсичный душнила!

Миддлы и джуны, а как вам работается c сеньйорами над одним проектом?

Нормально работается, меня не бьют даже.

разработчик только один, он там работает 5-10 лет

Беги оттуда при первой же возможности в место получше, всё остальное — неважно).

Ну я уже работаю в с 2011-го, причем над одним и тем же проектом (уже на уровне архитектора), остальным нужно бежать?

Забавная переписка двух чуваков из одной компании)
Я кстати щас напишу то же что у вас, т.к. ваша либа для pdf’ок платная, а нам нужна открытая)

У нас там много чего, и мы оба не по PDF’ам при этом). Прикольно, что на первом этапе первого недавнего собеседования тоже заметили, что о, а мы же вашу PDF’ную либу использовали у себя).

Так вам открытую или чтоб работать с ней без мата можно было? Так как с большинством открытых проектов нужно постоянно танцевать с бубном.

Нет, на нормальных данных открытые будут работать нормально, но если генерация pdf не совсем по стандарту, то открытые тупо будут или не открывать pdf документ, или открывать с глюками. Вот только пользователи вашего продукта, претензии будут выставлять к вам.

Так у нас на баркодах сейчас обое два разработчика, остальные занимаются портированием кода на Java/Android/C++.

Они тоже считаются). Интеграции порождают процессы. А вот к одному разработчику я бы пошёл только в случае, если бы было относительно всё равно, чем заниматься, либо наоборот чем-то цепляла предметная область. Т.е., постановка вопроса «вот вам проект, его с нуля 5-10 лет разрабатывает один человек, теперь вас будет двое» — это достаточно стрёмно и намекает достать огромный микроскоп и задать миллион вопросов, прежде чем принимать оффер — доступы-то предварительно никто не даст посмотреть, а что там на самом деле.

а что за проект если не секрет? Имею ввиду область — гемблинг, банкинг и т.п....

Баркоды, в основном добавление новых типов и улучшение качества распознавания (большая часть времени). Уже порвали Google-овский Zxing и по количеству симбологий и по качеству распознавания, если что.

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

Мой совет — послушно делай все то, о чем он тебя просит, и тем образом которым он хочет. Даже если это неприятная работа. Твоя задача состоит в том, чтобы окружающие увидели, что ты тоже умеешь решать проблемы. Не забывай общаться с окружающими, и выполнять их просьбы.
Не забывай рассказывать окружающим между делом, что ты делаешь.

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

Удачи.

Это вот этот конкурент-то?

Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают

Не смешите наши синьорские тапки. :)

П.С. Необязательно видеть в любом джуне, кинутом началъством на твой проект, конкурента.
Как правило, джун — это просто джун. Что-то типа «5-го колеса» в телеге. :)

Зато синьер часто на самом деле не синьер

ну чувак пилил рабочий продукт который приносил деньги компании на протяжении 5-10 лет. Наверное, можно его считать сеньором?

На этом проекте — наверное, можно :) В целом же — хз.

ну чувак пилил рабочий продукт который приносил деньги компании на протяжении 5-10 лет. Наверное, можно его считать сеньором?

Мы даже не знаем, что там за проект.

Просто там вполне может оказаться какая-то внутрикорпоративная система с соответствующими рисками по качеству, учитывая аж 1 человека на проекте.

щас я включу машину времени...
вобщем в карьере джуна/миддла есть такие важные пункты:
— абстрагировать себя от результатов проф.деятельности. вот прямо вообще — «не мой это ребенок». это сильно поможет в следущем...
— не забывать дергать своего патрона на предмет «зацени плз — так норм?» (почему так надо — вижу уже ниже норм люди расписали, а если вкратце — «чтобы не выпнули неожиданно заборт»). Я знаю, что сеньоры чаще всего оч.заняты (иногда даже делом) — штож, надо виверить мементы. Потому что...
— ирл-ретроспектива жизнедеятельности «стремящегося пацана» может быть совсем не в regular code review. Она может быть поставлена так — «Василий, через полчаса маякни кого из 5х новичков одного мы оставим, до 16 надо решить. И да еще [большой-список-задач-начальнику]»
— вопрос «сколько у меня на это есть времени?» — хороший вопрос. прямо всегда. даже если его потом повторить 3 раза добавив вначале «...а все-таки,..» (если не говорят прямо — скорее всего, вам выдали очень большой кредит доверия, и попасть в ожидаемые/фантазируемые эстимейты для вас — вопрос выживания на позиции)

P.S. жизнь несправдлива, мир жесток, Бог умер.

может он просто мудак, да

а может и — посмотрите на ситуацию его глазами

итак, он

разработчик только один, он там работает 5-10 лет

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

сеньйор это все равно считает говнокодом и или переписывает сам, если там мало, или заставляет переписывать вас так, как это видит он, диктуя свою архитектуру?

и, поэтому он знает что будет в стиле этой кодовой базы, the Project way, а что будет «коллективным письмом из Простоквашино»
и, что важнее, он знает предметную область, и нутром чует — в какую сторону будет развиваться проект, хотя об этом могут не догадываться даже те кто ставит задачи!

Но, если вам претит «его архитектура», и вы уже поняли что она просто результат его самодурства, зашоренности, ретроградства которым он занимался 5-10 лет, вместо погружения в предметную область проекта, то да, — предложите свое обоснование — своей архитектуры :)

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

но если он не самодур, а все же обосновывает свою критику ваших предложений — то улучшайте их.

Причем любой ваш вопрос по проекту его раздражает и мешает ему работать.

ну, во-первых потому что вопросы — и правда мешают работать.
просто вас наверное не дергают еще каждый час с вопросами = не вышибают с потока
во-вторых — ангелов не существует. причин раздражения может быть тьма, и при этом среди них ни одной вызванной вашими вопросами и лично вами.
так что уж точно — не воспринимайте раздражение на свой счет.
считайте что у него просто зуб ноет, и он рычит на весь белый свет. ну и на вас попутно :)

Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это «не его»?

Если уверены что этот код написан хорошо, — то тогда проблема просто в пока в экспертизе того кто вскипает мозгами.
делать с этого вывод о работник не создан, не его — рано.

возможно и такое, что у этого работника уже формируется синдром самозванца ;)

Ниже уже хорошо перефразировали вопрос, на

а как вам работается c сеньйорами мудаками

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

А меня раз уволили после того как я за 4 дне не смог разобраться с high load игровым серваком. Там порождающие фабрики, отдельно контекст, отдельно логика, отдельно rules, а в команде только дизайнеры и тестировщика — было весело :)))

Должен сказать этот, так званый сеньор, хороший пример «дутого сеньора».

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

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

Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это "не его"?

Это говорит то, что скорее всего перед тобой как раз таки говнокод, ну если вы конечно не для NASA какой-то рокет сайенс пишете или проект с каким то дата хай лоад, но я очень сильно сомневаюсь что на проекте с одним синьором, пишут что-то серьезное.

ЗЫ при возможности меняй работу, этот чел выдрочит тебе все мозги и даже не даст тебе развиваться, кроме как развиваться в такого же мудака. И ничему толоковому ты в этом бедламе не научишься, разве что набрать желанный год опыта работы и свалить на +500 на адекватную галеру.

Должен сказать этот, так званый сеньор, хороший пример «дутого сеньора».

А хз кто он там есть, если он единственный разраб в той конторе. Куча вариантов.

Миддлы и джуны, а как вам работается c сеньйорами мудаками над одним проектом?

Поправил вопрос.

Странные вы люди
1. Джуниорам и миддлам в нормальных местах поручают работу их уровня квалификации, где они не смогут напортить. Джун будет двигать кнопочки и менять конфиги, миддл формошлепить и крудить, синьор — делать работу требующую подумать.
2. Менее опытных нанимают не потому, что хотят их облагодетельствовать. Простую работу тоже надо делать и она должна стоить дешевле. Соответственно берут людей с меньшей квалификацией и именно на них делают большую часть денег оутсорсеры — синьоры дорогие.
3. Если Джун не справился с сложным заданием виноват тот, кто его поручил не подходящему сотруднику.
4. Нормальные люди все это понимают. Поэтому не третируют тех, кто знает меньше. Тех же, кто третирует называют токсичными и это правильно, при первой возможности от них избавляются

3. Если Джун не справился с сложным заданием виноват тот, кто его поручил не подходящему сотруднику.

Это ты отстал от жизни. Нынче на проектах скрамы, спринты и демократии. Соответственно, джуны сами (сами!) ассайнят на себя таски какие хотят, а потом пытаются с ними справиться.

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

Подозреваю, отсюда и такие топики.

Джун будет двигать кнопочки и менять конфиги, миддл формошлепить и крудить, синьор — делать работу требующую подумать.

все как бы классно, только так оно не работает :)

в реальности на проектах нагрузки смешанные — то есть может быть спринт завален очень сложными задачами или очень простыми (ибо у клиента дедлайн), вот и выкручиваешься как можешь + есть понятие внезапного пожара — и туда обычно кидают синьора — НО может оказаться что фича над которой он работал заблочит всю команду, соотвественно кого-то туда надо поставить, а в этот момент к примеру какойто джун уже уперся в блокер, догадайся с 1 раза на кого упадет доделывание задачи?

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

Но там где бюджета на спецов нет то делают как получается.

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

вы рассматриваете разработку как коня в вакууме, но в реальности вакуума нет. можно помочь изолировать проблемы, но изоляция не равно решение

Вот так вот прям низзя? Сириесли? Низзя только там где руководство старается- срочные таски на вчера, режет бюджет, нанимает идиотов или безоптыных...В остальном, вполне себе можно наладить процесс разработки и не лажать за редким исключением.

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

предотвращать пожары, выстраивая рабочие процессы.

Так не бывает. Если команда тянет — её грузят. Если команда закроет, скажем, 100 стори-поинтов — ей насыпят на следующий спринт 150. Запланированный к концу года релиз — внезапно передвинется на пару-тройку месяцев «вперёд», к ближайшей выставке, итп...

Это делает пожары. Но пожар, это нормальный процесс разработки востребованного продукта.

После чего команда демонстративно будет закрывать 75-80 СП.

Мы же о взрослых и ответственных людях, на серьёзных проектах — а не о «галерном» детсаде, с киндергельдом в виде зарплаты...

Мы же о взрослых и ответственных людях, на серьёзных проектах

Прям как галерный передаст сказал, до сих пор веришь в эту куету?

Ну и закроют опять 100, чудес же не бывает чтобы откуда-то в полтора раза больше производительности подъехало

Пожары, о которых ты говоришь признак очень плохого менеджмента

Сидеть в вялотекущем проекте, отсиживать 35-40 часов в неделю, придумывать себе таски — это и неинтересно, и неприбыльно. Так что, отлично понимаю этого твоего мейта.

Но да, 90% современных разрабов, для которых работа это кофе и сошиалайзинг — такого не понять.

Сидеть в вялотекущем проекте, отсиживать 35-40 часов в неделю,

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

При пожаре тоже самое, только ещё добавляется гнетущая атмосфера

Сидеть в вялотекущем проекте, отсиживать 35-40 часов в неделю

А що в нас тільки два варіанти, або жопа або нічого робити?
Просто налаштувати норм процеси не варіант?

В мене он зараз на проекті взагалі от якраз повільний гавно проект з придумуванням завдань, але при цьому через гавно процеси із сторони клієнта кожний реліз умудряються зафакапити

Пожары, о которых ты говоришь признак очень плохого менеджмента

Пожары — норма у лидеров (мировых) рынка в своих областях.

Если у тебя на проектах пожаров не было, значит ты работал 1) на каком-то мало кому нужном ацтое 2) за киндергельд.

Были, плохой менеджмент это основа украинского айти, как же я мимо этого всего смогу?

пожар, это нормальный процесс разработки востребованного продукта.

Нет. Я таких пожарников посылаю нахер

это тоже часть нормального процесса разработки востребованного продукта ))

Нет. Я таких пожарников посылаю нахер

Если они платят 100/час, при до 250 часов/мес?

Чем не жизнь? 2 года так поработал — 10 лет можешь отдыхать. И не в африканской дыре, а где-нибудь в Испании...

Типа я не видел испаний. Не смешно. Аборигены там почти в такой же жопе, как в болгариях.

погугли картинки по «ceuta migrants» — поймёшь разницу между Испанией и африками

гугла запросить инфу по зарплатам аборигенов в испаниях

Зарплаты всяко в разы больше, чем у африканеров будут + всевозможные социальные плюшки.

Оттого африканеры массово бегут в Испанию, а не наоборот.

. Джун будет двигать кнопочки и менять конфиги, миддл формошлепить и крудить, синьор — делать работу требующую подумать.

что то как то сильно сомнительно, мне приходилось делать работу требующую «подумать» с самого начала.

Ну кому и кнопки двигать — «подумать» ;-)

Ну кому и кнопки двигать — «подумать» ;-)

да ну нет — классификатор эмейлов, разработка алгоритма процессинга фигни закодированной в бинарный протокол без спецификации, как то это не назовёшь двиганием кнопок.

Ого, так це я вже мідл виходить. Треба начальству повідомити :)

Значит код написан плохо. Качество кода определяется его понятностью. Потому что код пишут для людей, а не для машин.

Код крупного проекта — всегда сложен и непостижим для джуна. Так что, дело не в коде.

Ошибаешься, размер проекта не влияет на сложность напрямую, лишь косвенно через критическую массу говнокода, если на проекте в основном амебные разработчики

Значит код написан плохо. Качество кода определяется его понятностью. Потому что код пишут для людей, а не для машин.

это фантазия которая в 80% случаях не имеет место быть в реальности.

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

Все решается, если есть тот, кто порешает эти проблемы, если нет, то сложное и непонятное решение можно получить и на 200 строчках кода

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

Wrong.
Складність предметної області та рішень дуже легко компенсується зрозумілою реалізацією цих рішень, наявністю коментарів, тестів, документації.

Вы можете сколько угодно писать комменты, доку и тесты, только это не сделает решение простым. Да, будет труднее забокопорить если все покрыто тестами (только не теми где все замочено а нормальными). Да, если код сложный комменты остаются последней надеждой. Да, правильно написаная дока поможет (только кто ее писать умеет?). Но ничего из этого не сделает это простым. Если у вас сложный юкс и вы даёте мануал к нему — это не делает юкс простым. Если у вас сложная область и все покрыто правильными тестами — это поможет избежать случайных поломок, но добавление нового функционала — не-а, оно все равно внутри сложное.Комменты объяснять мотивацию и цель, но по прежнему не делает решение простым.

Ми, очевидно, говоримо про різні речі.
Будь-яка доменна область для не спеціаліста в цій області апріорі буде складною, тут нема про що сперечатися.
Мій посил був про те, що код який пишеться, якщо це що не супер low-level, має, грубо кажучи, відповідати SOLID принципам і хоча б мінімально відповідати порадам дядька Боба з «Чистого коду». Якщо це є, то такий код легко читається, фіксається і дописується незалежно від доменної області.

Якщо ж система це говнокод з функціями на 100500 строк, простині закоменченого коду, все працює через магічні флаги і т.д. то не треба прикриватися доменною областю, треба визнати, що це херовий проект з високим рівнем входу в нього і складність його підтримки росте з кожним комітом.

Якщо ж система це говнокод з функціями на 100500 строк, простині закоменченого коду, все працює через магічні флаги і т.д.

и я с этим на 100% согласен.

и где-то тут уже писал, что проблема в излишней сложности — ее не должно быть. но сделать из сложного простое (посыл в рут комменте), это фантазиях в 95% случаях (в остальных 5% это были излишняя сложность в бизнесе, которую программер каким то чудом заметил, и разложил на то, каким оно на самом деле есть), и именно об этом я написал

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

Складність предметної області та рішень дуже легко компенсується зрозумілою реалізацією цих рішень

дивно тільки чому тоді ті що розуміють — не пишуть такий код для тих хто не розуміє :)

ну щоб почитав код, і не треба було розуміти — domain

і взагалі, чому усяки книжкі про науки так важко написані
чому б комікси не написати?

чому усяки книжкі про науки так важко написані
чому б комікси не написати?

Ви будете сміятись, але я знаю принаймні одну країну де так роблять — Японія ))
* en.wikipedia.org/wiki/The_Manga_Guides

Тобто там немає ані коледжів, ані університетів — почитав мангу, та й все второпав!

Тобто там немає ані коледжів, ані університетів

Без поняття — ніколи там не був

если у вас сложная доменная область

ОК, допустим. И сколько при этом процентов кода занимают именно сложные низкоуровневые алгоритмы в общем решении?

Низкий уровень это не про доменную область как бы

Низкий уровень это не про доменную область как бы

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

Я писал про доменную область — она везде разная, а твой финтех — с его алгоритмами это только одно из многого. Кстати тут ещё вопрос точки зрения, для меня почти всегда это 100 процентов сложного, так как меня кидают на те задачи которые обычно никто не знает как делать, и зачастую думают что это невозможно

Я писал про доменную область — она везде разная

Это и так понятно — конкретику в студию, или дефайн «сложная доменная область». Фраза «она везде разная» не несёт в себе никакой информации, т.к. большая часть этой «разной» доменной области, с которой сталкиваются на нашем рынке, проявляется в крудах с джейсонами.

а твой финтех — с его алгоритмами это только одно из многого.

...и даже не мой (пока что).

Кстати тут ещё вопрос точки зрения, для меня почти всегда это 100 процентов сложного, так как меня кидают на те задачи которые обычно никто не знает как делать, и зачастую думают что это невозможно

«Не знает, как сделать» не равно «в готовом не может разобраться», о чём и речь. Чем продиктована такая сложность, можно пару примеров? Или всё под NDA?)

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

Согласен, насчёт «не равно». Обычно это не очень сложные вещи, но требуют понимания как работают ваши популярные вендоры под капотом + несколько не совсем тривиальных вещей + иногда, но не всегда хорошое понимание бизнес кейса. Многим кажется такое невозможным из-за не хватки знаний в одной из сфер, с моей колокольни это выглядит более чем осуществимым, с их — нет, так как они чего-то не знают, соотвественно мое решение всегда будет для них сложным, т.к. все в комментариях и доке не опишешь (скорее будешь давать ссылки на многие вещи), но это будет от них требовать прочитать и и понять что они прочитали, а это уже сложно.

Вообщем то что я наблюдаю, люди считают невозможным, то что не решается в лоб, а требует 3 и более технологии/подхода + склеивание этого всего.

ну как бы ты говоришь о том же о чем и я. сложное осталось сложным, а то что было простым, тоже осталось простым

ну во первых, понятие сложное — это не только сложные алгоритмы, может быть сложный контекст (тут обычно проблема в количестве логических сущностей, которые надо брать во внимание). во вторых, я не говорил что сложное составляет 100%, я говорил о том — что сложное, нельзя сделать простым. и вот те 10-20% (может быть больше, смотря что за задача) сложного все равно остаются, и ты их не сделаешь простыми

Значит код написан плохо. Качество кода определяется его понятностью

Не значит. Может да, а может и нет.

Слышали наверное
«Программисты пишут все более „дуракозащищенные“ программы, природа создает все более бестолковых юзеров...»

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

И это в жизни так и есть
например архитекторы, проектировщики вынуждены упрощать решения, подстраиваясь под экспертизу команды

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

я бы уволился, если бы обязали такой код писать :)

Потому что код пишут для людей,

для каких людей?
для любых?

человек не умеет работать с людьми.

с любыми людьми обязан уметь?

Не значит. Может да, а может и нет.

Правильный ответ — значит в большинстве случаев. Даже если (а это «если» далеко не у всех, на секундочку) доменная логика сложная, то сколько именно занимают именно сложные низкоуровневые алгоритмы?

например архитекторы, проектировщики вынуждены упрощать решения, подстраиваясь под экспертизу команды

Можно конкретный пример?

доменная логика сложная, то сколько именно занимают именно сложные низкоуровневые алгоритмы?

бОльшая часть кода обычно — не доменная логика.
а инфраструктурная.

и код то может быть простым. просто плотно использует — свойства фреймворка, общие библиотеки компоненты проекта и т.п.
архитектура может построена на специфике фреймворка, и т.п.
но тому кто плохо знает фреймворк, не въехал в проект, в применяемые в нем паттерны — этот код будет не понятен.

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

Можно конкретный пример?

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

Проектировщик разрисовал сервисы для аnemic, а команда привыкла к rich

Решение предполагало возможности оракл дб, а опа, спецов нет, упрощаем до мускула.

В целом же, рассказывать долго, потому что тогда надо приводить не одну страницу тех задания, спецификаций, чтобы
1. объяснить почему проектировщик выбрал такое решение, и почему оно правильное, а не архитектурная астронавтика
2. в чем заключалась сложность понимания этого решения для существующей команды, и пришлось упрощать, в ущерб конечно каким-то характеристикам

или как в теме о руби недавно
ах, какой был классный корпоративный сайт на рельсах!
но владельцы утомились искать программистов. и в итоге потом перевели сайт на вордпресс

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

Но есть и более краткое правила:
Лучший интструмент тот — которым лучше всего владеет команда
Лучшая методология та — которую хорошо понимает хотя бы треть команды

и код то может быть простым. просто плотно использует — свойства фреймворка, общие библиотеки компоненты проекта и т.п.
архитектура может построена на специфике фреймворка, и т.п.
но тому кто плохо знает фреймворк, не въехал в проект, в применяемые в нем паттерны — этот код будет не понятен.

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

«Плохо знает фреймворк» — это обособленный кейс, я бы его не рассматривал. А если всё остальное именно так, как указано, то проблема только в количестве этого самого кода. Т.е., понятно, что если там какой-то огромный монолит, пусть и спроектирован и написан в целом хорошо, то да, придётся попотеть, но только будет ли это именно так радужно?) В большинстве случаев будет как раз печально — не зря же легаси не любят за типичные проблемы. А если это вообще проект, которому год-два, и в нём сложно разобраться, то с 90% вероятностью «всё очень плохо» ©.

На текущем месте работы я разбирался в первом проекте возрастом 15+, ещё и с крайне весомым количеством низкоуровневой логики (она там занимала большую часть кода, что как бы редкость — очень много фич), и понять большую часть нюансов удалось почти через полгода только (и хотя там всё было написано и спроектировано достаточно хорошо, на одну из подсистем, которая плотно работала с памятью, помню, ушло почти 3 недели, чтобы разобрать до мелочей и подготовить план рефакторинга, т.к. там был просто дичайший уровень cyclomatic complexity с адовым дебагом соответственно, кривой дизайн, неэффективные решения и т.д.). Во всех других случаях, которые я наблюдал, «сложность» была продиктована либо типичными легаси-like причинами, либо неправильным подходом к управлению проектом, которые хоть и могли быть вызваны самыми что ни на есть объективными факторами в своё время, это всё же не делает их лучше ни на грамм).

«Плохо знает фреймворк» — это обособленный кейс, я бы его не рассматривал.

на практике без фреймворков почти ничего не пишется
и, чем лучше понят фреймворк, библиотеки, тем меньше приходится писать своего кода

соответственно, малое количество «понятного» кода — может потребовать от читающего такого же уровня знания фреймворка, который и породил такой небольшой и уныло-простой код

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

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

у меня вообще есть простой тест, на мидловость — а перед тем как сесть писать код — напиши implementation plan. ну или тзшку вольным стилем, как для другого программиста

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

а если в голове пока вот так — то и код другого будет пониматься с трудом.
как в вакансиях и пишут требование
«Умение читать чужой код»

знают уже, «писателей» не умеющих «читать»

ушло почти 3 недели, чтобы разобрать до мелочей и подготовить план рефакторинга, т.к. там был просто дичайший уровень cyclomatic complexity с адовым дебагом соответственно, кривой дизайн, неэффективные решения

недавно по инету пробежал рассказ рядового разработчика Oracle DB
рекомендую нагуглить.

чтобы радоваться всякий раз от легаси — как хорошо что я не в Оракле программист! :)

«сложность» была продиктована либо типичными легаси-like причинами

ну это понятно что если б написать все с нуля, было бы все красивенько :D

и конечно «Я» бы написал с нуля намного лучше!

а доку такого же качества как для фреймворков — пишут редко. дорого потому что.

Такого же, как для фреймворков — это, конечно, позитивная крайность (хотя я вот сейчас отдаю проект с очень подробными доками, которые мной и были написаны), но если у проекта «своя идеология», что иначе не разобраться, и в доке эта «идеология» не описана, то это называется плохими словами и оправданию не подлежит. Если такой подход аргументируется словом «дорого», так тем более.

на практике без фреймворков почти ничего не пишется
и, чем лучше понят фреймворк, библиотеки, тем меньше приходится писать своего кода

соответственно, малое количество «понятного» кода — может потребовать от читающего такого же уровня знания фреймворка, который и породил такой небольшой и уныло-простой код

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

Нормальная ситуация — если человек этого не знает, на код ревью дают понять, где копать, и не пропускают, пока человек не разберётся. Или код ревью — тоже дорого?)

ну это понятно что если б написать все с нуля, было бы все красивенько :D

и конечно «Я» бы написал с нуля намного лучше!

Ну, Вы все эти ситуации описываете с точки зрения а-ля «правда жизни» и работаем, с чем дают, но можно назвать такое более неприглядно). Например, хвала продакт менеджеру, на проекте, который я описывал в прошлом посте, сейчас есть то, чего не было, когда я только начинал над ним работать: 1) хорошая модульная структура; 2) низкоуровневые легаси зависимости побеждены ради добавления .NET Standard версии; 3) т.к. мой план рефакторинга подсистемы работы с памятью тогда отклонили в виду отсутствия ресурсов (мой эстимейт был 3 месяца), зато появился артефакт в виде доки с подробным описанием, как это работает/что где лежит/какие зависимости, и после расширения команды этим занимается уже другой человек, постепенно внедряя решение, которое с точки зрения эффективности в одном аспекте даже лучше моего. Поэтому можно делать нормально (сейчас проекту «на вид» года три-четыре, а не 15+), а можно не делать, потому что бизнес не хочет за это платить... хотя, судя по намёкам того же продакт менеджера, когда он был в должности ниже, то его предложения тоже воспринимались далеко не всеми и не сразу, упираясь в том числе в нежелание команды.

А по поводу

недавно по инету пробежал рассказ рядового разработчика Oracle DB
рекомендую нагуглить.

чтобы радоваться всякий раз от легаси — как хорошо что я не в Оракле программист! :)

Эту анонимную статью я читал, и там, насколько помню, разработчик почему-то не ведёт повествование с точки зрения "бизнеса"/"производства", а явно высказывает своё определённое категоричное мнение по поводу технической части). Поэтому, как минимум(!) пока рынок в Украине перегрет, нет никакого смысла мучать себя и идти на компромиссы, которые ведут к закреплению плохих практик, на которые можно просто не идти, попутно закрепляя хорошие и повышая свою ценность на рынке в том числе.

это называется плохими словами и оправданию не подлежит.

называйте как хотите
большинство проектов такие.

и что значит оправдание — неоправдание?
осудите, побейте камнями, напишите в ООН на поганый проект

Реалии, не только у нас, не только сейчас, а наверное с 70ых годов:

Большинство айти проектов испытывают недостаток в одном из ресурсов:
люди, деньги, время

и вполне себе не редкость что во всех трех

Если такой подход аргументируется словом «дорого», так тем более.

никто не неволит — пусть программист найдет другой проект :)
где и дока есть, и макбуки раздают.

Или код ревью — тоже дорого?)

время разработчика — стоит денег
затраты времени на одно — это минус время с другого

и чем меньше команда, тем время ведущих разработчиков дороже

мне эта арифметика кажется очевидной.

а уж дальше — вопрос достаточности ресурсов:
деньги, время

Ну, Вы все эти ситуации описываете с точки зрения а-ля «правда жизни»

да. естественно.
а на кой мне обсуждать грёзы идеалистов :)

как минимум(!) пока рынок в Украине перегрет, нет никакого смысла мучать себя и идти на компромиссы

не идите :)
и топикастер пусть не идет
и никто пусть не идет.
а если случайно попал, заманили, то делов то — уволился и нашел работу мечты :)

попутно закрепляя хорошие и повышая свою ценность на рынке в том числе.

пусть повышает. в чем проблема то, поганый синьор мешает?
отсутствие доки на проекте?

которые ведут к закреплению плохих практик

так кто об этом должен беспокоиться в первую очередь?
поганому синьору хорошо с такими практиками.
то есть это проблема мидла, верно?

ну так пусть ее и решает тот — ЧЬЯ это проблема.
способов много, выше и в теме писали уже простые и радикальные :)

а на кой мне обсуждать грёзы идеалистов :)

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

так кто об этом должен беспокоиться в первую очередь?
поганому синьору хорошо с такими практиками.
то есть это проблема мидла, верно?

ну так пусть ее и решает тот — ЧЬЯ это проблема.
способов много, выше и в теме писали уже простые и радикальные :)

В том-то и дело, что «поганому» сеньору)). Или сеньору, который работает только ради денег и ему, в общем-то, пофиг на всё остальное, или сеньору, который просто сидит на тёплом месте... но в моём понимании это тоже достаточно печально, как и отсутствие код ревью.
Действительно, а чья же это проблема? Процесс разработки — это проблема тех, кто им должен заниматься по своим должностным обязанностям: лида, PM’а и всех, кто выше. Это как бы одна из определяющих их профпригодности в том числе. Для хорошего (в данном случае, которому не пофиг, или который собирается куда-то расти дальше) сеньора — тоже.

и что значит оправдание — неоправдание?

Ну, вот, то и значит). Приходим к тому, что процессов-то и нет, и на каждый пробел находится какое-то оправдание. А если процессов нет, то чем занимался менеджмент? Говорил «денег на код ревью нет»? Ну, классно). Хотя, здесь немало людей заявляют, что нам и автотесты не нужны, потому что дорого, ещё и типа язвят, что вы носитесь с ними...

осудите, побейте камнями, напишите в ООН на поганый проект

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

пусть повышает. в чем проблема то, поганый синьор мешает?
отсутствие доки на проекте?

А выше не Вы написали про умные книжки и сеньоров, которые от их прочтения автоматически не получаются почему-то?) Кто его будет менторить, кто код ревью ему будет делать (которого даже нет), если «денег нет, но вы держитесь» ©? С кого ему брать пример, если процессов нет, и почему?

не идите :)
и топикастер пусть не идет
и никто пусть не идет.
а если случайно попал, заманили, то делов то — уволился и нашел работу мечты :)

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

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

На самом деле, нет — после разбора полётов с причинами ухода с CTO сделали контр-оффер с внеочередным повышением в должности и предложением собрать другую команду под меня... только у него было своё видение, как нужно поступать дальше, и новая сфера ответственности не только не решила бы те проблемы, о которых я говорил, а я бы ещё нахватался подобного на свою голову из других команд. В общем, я говорил о векторе развития именно моего текущего проекта, а контр-оффер был скорее о том, как дотянуть подобные проекты других команд до того же уровня. Плюс мне ещё объективно далеко до того, чтобы уходить ещё выше в менеджмент — нужно закрывать вопросы по тех. части, поэтому если бы принял контр-оффер, то в перспективе заработал бы синдром самозванца, хотя место было бы ну очень тёплое в плане стабильности. В общем, рано ещё стареть).

Мавр сделал свое дело — Мавр может уходить.

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

это все прекрасно, но далеко от темы.
потому что это все лежит не только вне зоны ответственности(а потому влияния) мидла, а еще и вне его компетенции.
иначе он уже не мидл, если способен так ставить вопросы, и давать цельные предложения по реорганизации процесса разработки

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

ок, я понял, мидлы святые :)

если миддл успел поработать в компаниях с нормальными процессами и пришёл туда, где их нет

так пусть уйдет туда где нормальные процессы :)

Т.о. мы снова упираемся в уровень компании,

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

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

а не какой миддл плохой, пришёл тут, понимаешь, бухтит, жить спокойно не даёт

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

уже ж найдено решение :)

люди, деньги, время — ограничены у любой компании.

вы же рассуждаете как будто они бесконечны, у «правильной компании»

ИМХО, подобный опыт излишне экстраполируется. Если выйти за пределы ситуации топика, я ещё не видел сеньоров, которым было бы прям пофиг на процессы в компании, ведь это их комфорт в том числе. И «любая компания» без процессов, у которой, грубо говоря, овер 20 девелоперов, или скатится на дно в плане комфорта работы, или их задавит технический долг (если проект долгосрочный), или кранчи (если краткосрочный), или будет х*як-х*як и в продакшн. Другой расклад будет исключением, а не правилом.

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

Невольно на ум приходит мой же недавний поиск работы. И хотя я — балувана Галя, которой подавай только распределённые системы посложнее и 100% удалёнку, поэтому выборка совсем маленькая, но, как ни странно, у всех украинских команд были CI, автотесты, код ревью и адекватное распределение ролей (даже в чисто сеньорной маленькой), а рассказов, как им комфортно «сеньорно нарушать правила по велению интуиции», я почему-то ни от кого не слышал. Наверное, это просто всё миддлы, которые от непонимания гениальных идей «настоящих» © сеньоров цепляются за свои глупые миддловские формальности, а сами настоящие сеньоры полностью раскрываются только в компаниях, которые не собираются тратить деньги на процессы). Паззл явно или неявно складывается в сторону, что наличие процессов, интересные проекты и нормальные деньги каким-то неведомым образом тесно связаны друг с другом...

Паззл явно или неявно складывается в сторону, что наличие процессов, интересные проекты и нормальные деньги каким-то неведомым образом тесно связаны друг с другом...

почему это неведомым?
деньги делают деньги, название этой связи

а теперь перечитываем

люди, деньги, время — ограничены у любой компании.

Гугл и Microsoft тоже ограничены — деньгами и временем, с людьми у них полегче
результат этих ограничений на себе нередко ощущают самые обычные пользователи.

я ещё не видел сеньоров, которым было бы прям пофиг на процессы в компании

а я всяких видел. и компании тоже разные.

а рассказов, как им комфортно «сеньорно нарушать правила по велению интуиции», я почему-то ни от кого не слышал.

так про это можно у авторитетных авторов прочитать, когда они рассуждают о градации программистов :)
не о комфорте, а о способности рационально выбирать — следовать правилу или не следовать.

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

сами настоящие сеньоры полностью раскрываются только в компаниях, которые не собираются тратить деньги на процессы

хороший ход, да — доведение тезиса до абсурда :)

ну и сами разбирайтесь с этим хрестоматийным демагогическим приёмом :)

Любой синьор (тру синьор, а не «украинский») отличается 1) умением быстро въехать в большую кучу незнакомого кода 2) умением быстро фиксить «свежий» чужой код 3) умением выдавать много полезного кода за короткое время.

Умеешь так работать? Работай на пару с «синьором».

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

1) умением быстро въехать в большую кучу незнакомого кода 2) умением быстро фиксить «свежий» чужой код 3) умением выдавать много полезного кода за короткое время.

Это ты гонишь. Нужно писать не больше кода в единицу времени, а меньше. И если есть возможность — не писать его вообще. То, что ты привёл просто работоспособный миддл.

Как правило, задачи не решаются удалением существующего кода. Код-таки приходится писать.
И часто, код непростой...

4) Код синьера должен быть понятен по крайней мере мидлу. Иначе это павлин-теоретик, а не синьер. Все эти вычитанные из умных книжек абстракции должны быть упакованы в компонент с нормальным api. Тогда на проекте не будет ситуации, о которой говорит топик стартер

Код всегда в виде каких-то компонент. Но в больших системах кода МНОГО, компонент много тоже и они крупные. Всё это не влазит в голову джуна даже после года на проекте — оттого вопли.

После определенного уровня конструкции из компонентов перестают решать технические задачи и переходят к решению функциональных. Есть такое. Даже как-то задумался, а какие есть очевидные решения для этого. Для того, чтобы джун-мидл мог «втянуться». BDD и cucumber приходит на ум, но это настолько редко используется.

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

Собственно такой подход работает для всех, поэтому большие проекты разбиваются на стримы с отдельным респонсибилити и со временем наращивают экспертизу по этим респонсибилити\модулям\сервисам...
«Девелопер — в кожну дiрку затичка» это подход как раз таки шараг и овно-проектов.

вполне себе можно отдавать ему таски в одтельной части кода, где он уже хоть немного шарит

Это не работает. В современном мире демократии и «тимплея» — джун сам берёт себе таски, какие хочет. И никого не спрашивает.

А потом удивляются/говорят_что_норма пожарам на проекте :-)

Иначе это павлин-теоретик,

Если павлин-теоретик использует хорошую и понятную теорию — то там как раз всё очень хорошо.

Если в команде никто не знает его теорию, а он продолжает ее применять и всем впаривать, потомучто кококо — ничего хорошего нету.

Код синьера должен быть понятен по крайней мере мидлу.

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

Тогда на проекте не будет ситуации

ну а уж как избегать нехороших ситуаций — джуны с мидлами знают лучше тимлидов и пиэмов!

Все эти вычитанные из умных книжек абстракции должны быть упакованы

а может мидлу стоит — почитать эти книжки, не?

в компонент с нормальным api.

так в чем проблема то :)

пусть мидл и напишет этот нормальный api, и сунет в нос синьору — вот какой api ты должен мне обеспечить!
делов то, состряпать спеку на «нормальный api»

оценить дутость синьора по его коду может только другой синьор, не дутый.
а никак не мидл, и тем более не форумная тусовка которая ни единой строчки кода не видела.

болезнью же

а посмотри, как я еще умею программировать, яжсиньор

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

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

Код синьора должен быть понятен в стиле «вот этот кусок делает то-то и то-то»

ну так пусть мидл поучит синьора писать правильный код :)

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

я об этом.

а что там конкретно происходит у топикастера — знать не знаю.
много взаимосключающих версий.

Так кто же такой синьор?

dou.ua/...​ring-programmers/#1635714

на остальное можно ответить в таком же ключе
синьор отличается от мидла примерно так же как программист от кодера

Неоднократно наблюдал такую картину, когда мидл по званию учил писать синьора по званию.

вполне естественное дело — мидл кодит ведь больше чем синьор, обычно.

проработал на проекте 5+ лет, мидл начинает с ним работать и хоба! Не синьор учит мидла, а мидл — синьора.

чему именно учит, проектным решениям в этом проекте? доменной области проекта?
вот в чем вопрос

поучиться же и взрослому можно у ребенка.
но от этого ребенок не становится взрослым.

Это раньше перехаживание в звании было какой-то аномалией

звание, лычки это одно.
разница в роли, в уровне ответственности которую дают.

поэтому то на собеседовании джуна спрашивают о — кодировании
мидла — в каких проектах участвовали, какие решали задачи
а синьора — какова была ваша роль была в предыдущих проектах?

мидл это уровень КАК писать
а синьор — это уровень ЧТО писать, а что — НЕ писать

по другому, если утрировать
мидл решает поставленную задачу написанием кода
синьор — НЕписанием кода

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

все выше мог бы подкрепить цитатами из всяких «Программист прагматик», но...

зная мидлов, это малополезно :)
«возраст» такой. сам таким был.

а сейчас — ревьювишь код, и думаешь
вот же, все красивенько как написано
но, млять, о чем он думал когда писал???
объяснял же, в спеке отмечал указания к выбору реализации, ..., ..., ..

и понимаешь, а — не думал он еще о чем-то больше, чем о своем коде.
он пока, думает о калиграфии, правильном почерке, а не о смысле написанного.

и садишься, и пишешь не код, а на русском языке, еще абзацы в дев гайде, еще абзацы в спеке, еще условий автотестов...

а мидл да, в это время — пишет код, и гордится что пишет кода больше чем синьор

Значит этого синьора надо понижать в звании.

понижайте, разрешаю!

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

Так кто же такой синьор?

случайно, только что в рассылке увидел, очередное, что можно прочитать много где и у кого
Выделил жирным то что считаю ключевым.
Согласен на 99%

итак, что нужно чтобы стать хорошим разработчиком
то есть чем больше качеств из списка, тем разработчик синьористей

1. Аналитическое мышление
Четкого определения аналитического мышления нет, но одно можно сказать точно: если оно у вас есть, вы обладаете хорошей памятью, способны размышлять и анализировать данные, и при помощи всего этого решать проблемы.
К сожалению, это самая важная и нужная черта разработчика программ. Почему «к сожалению»? Ну, это означает, что не каждый способен стать хорошим разработчиком, даже если сильно этого хочет. Наличие аналитического мышления это во многом врожденная черта. Если ее у вас нет, лучше поискать другую сферу интересов.
Решение большого количества алгоритмических и логических задач может повысить уровень аналитических способностей. Однако, выше головы не прыгнешь, у каждого свой предел развития природных талантов.
2. Умение видеть картину крупным планом
Создание программы похоже на игру в шахматы: чтобы выиграть, нужно продумывать свои ходы на несколько шагов вперед. Программируя, нужно иметь в виду не только настоящее, но и будущее. Чтобы быть хорошим разработчиком, вам нужно фокусироваться не только на той маленькой части программы, которой вы непосредственно заняты.
Вам нужно знать не только, КАК что-то реализовать, но и ЗАЧЕМ это делать. Нужно уметь видеть программу в целом, а не только тот ее кусочек, над которым вы работаете в текущий момент.
Нужно понимать, как ваша часть программы влияет на все остальное. Опять таки, вам нужно уметь видеть крупный план картины.
3. Бизнес-ориентированный подход к разработке
Хороший разработчик должен разбираться не только в технических вопросах. В противном случае вы можете быть хорошим кодером, ваш код может быть очень высокого качества, но вы все же не сумеете понять и удовлетворить нужды ваших пользователей.

* к ЗАЧЕМ
я обычно задаю вопрос на код ревью, по поводу кода что мне не нравится, как-то не так попахивает — какую проблему решает вот этот твой код?
зачем, с какой целью он написан вот ТАК? Зачем, с какой целью выбран вот ТАКой подход, ТАКой паттерн? и т.п.

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

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

и бывает конечно, когда код лучше решает проблему, чем я бы наспех написал свой о том же.
а вполне может даже если б и не наспех — все равно мой код был бы хуже.

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

Тут иногда проскакивают персонажи, которые считают, что лучший код — это код без комментариев и хороший код — это самодокументирующийся код.
// here we apply the localization to the current group
currentGroup.applyLocalization();

// and here we convert it; I didn't know how to inject this converter, 
// so I just instantiated it, NEEDS FIXING! - JB 12.03.2009
new GroupConverter(4).convert(currentGroup);

*YEEEEEAAAAAHHHHH!!!* (mike drop)

Должен признаться что полезные коменты — очень большая редкость, а говнкод если и имеет коменты то обычно это еще одно говно, которое проще игнорить, чем понимать о чем оно.

Коменты должны быть в местах которые не очевидны.

а не очевидных мест не должно быть

Ага, так же как и не очевидных требований, и не очевидных либ.

На практике это не возможно.

А если серьезно, то ситуаций, когда

из всех специалистов — разработчик только один, он там работает 5-10 лет и заслуженно может называться сеньйором

лучше избегать.

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

Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это «не его»?

Это, возможно, говорит о том, что это ваша первая работа в айти. Могу ошибаться, но мне так кажется. В любом случае это нормально, если человек в чем-то не может разобраться быстро, это скил, который с опытом приходит. И в нормальных коллективах, с нормальными отношениями внутри коллектива, помочь быстро разобраться в коде новичку будет в интересах всего коллектива.

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

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

Нету ли такого, что что бы вы не написали, сеньйор это все равно считает говнокодом

пусть считает. говнокодом можно назвать абсолютно любой код

и или переписывает сам

ну если ему в кайф в овертайм пусть занимается.

или заставляет переписывать вас так, как это видит он, диктуя свою архитектуру?

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

И еще вопрос: допустим сеньйор написал какой-то модуль и кинул вам на доработку, чтоб вы быстро разобрались в коде и дописали этот модуль. Если код написан хорошо, но быстро разобраться в нем настолько тяжело, что мозги просто закипают — это говорит о том, что работник не создан для программирования и что это «не его»?

То есть модуль не доработан и задача не закрыта этим синиором?

Все зависит от того, как в первый день в опенспейс зайти.

Если, например, заходите в опенспейс, а синьйор полотенце под ноги кидает — ни в коем случае нельзя его поднимать. Просто переступить и всё.

Еще сеньйор может задавать вопрос — «Вилкой в глаз или пофиксишь баг один раз». Правильный ответ — «Что-то я в компании одноглазых не вижу».

Ну и классика. Если сеньйор начинает говорить что-то типа «Есть два бага — один минор точеный, другой блокер блоченый. Какой себе взять, какой джуну отдать?» — сразу загуглите правильный ответ. Иначе багфикс и унижения на код ревью до самого конца.

Если правильно на все вопросы ответили — будете в авторитете и возможно в один прекрасный день станете синьйором.

я — смекалистый Егорка, не боюсь жить в нижней норке

Вот тут обидно было.

Ещё могут спросить, где чалился.

это только когда по этапу идёшь потом уже всё когда приняли

и возможно в один прекрасный день станете синьйором.

не станет придётся сперва не меньше 3-х ходок на +500 сделать за одну одсидку сколько б не дали это не синьор это фраерок

Если обошел Люксофт — ЕПАМ — Глобал — Циклум — можешь смело себе набить КОБ (Коренной обитатель бодишопа) в виде болта положенного на логотип джиры.

На Софтсерві не веслав — не мужик

Причем любой ваш вопрос по проекту его раздражает и мешает ему работать.

Быть сеньором и уметь заниматься людьми это два разных умения.
Чтобы быть сеньором (по уровню знаний) нужно много кодить и все такое.
Чтобы уметь терпеливо рассказывать и обучать — нужно много рассказывать и обучать.
Или эмоциональный интеллект как это сейчас называют.
Вам попался сеньор по уровню знаний, но не по умению обучать/обьяснять/вести_людей.

Нету ли такого, что что бы вы не написали, сеньйор это все равно считает говнокодом и или переписывает сам, если там мало

Похоже он не хочет вами заниматься (это бывает и это нормально, программисты иногда любят кодить, а не возиться с людьми). Возможно вас ему «выдали» не спрашивая хочет ли он этого. Или это первый раз для него, когда нужно вести миддла/джуна.

Синиор не способный обсуждать предметку проекта? Как он вообще стал синиором и сосуществует с окружающими? По уровню знаний судя по описанию похож на истеричку с до 3-х лет опыта.

Так если он один-единственный разработчик в компании, то он одновременно и сеньор и архитектор, и СТО, и директор айти-департамента. Как он ими всеми стал? Так же как и сеньором. Не путем отбора )

потому ты и будешь всегда джуном пока не пойдешь учиться у тех кто умеет

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

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

Підписатись на коментарі