Comments 161
У меня есть ощущение что настрой «мне нет дела что там за продукт, главное что код пишу» очень близок к настрою «мне без разницы какой там код, и насколько хороший код я пишу, деньги то получаю»
Кто это увидит кроме разраба? Мало того — кто это увидит, хоть кто нибудь кроме того, кто полезет именно в конкретный модуль?
У кода есть цель. Я конечно понимаю, что "эффективные манагеры" могут превратить изначальную цель "сделать людям лучше" в фикцию, но сейчас не о них речь. Сейчас речь о человеке, который вместо того, чтобы решать поставленную задачу — вылизывает код. Да он будет стилистически идеальным, но… какой смысл?
Это, простите, какая-то кодомастурбация — получать оргазм, если код идеальный. Я в принципе признаю за людьми право на извращения — у всех свои слабости — главное чтобы это не становилось манией, что уже опасно.
Даже умные мозги для унитаза должны делать то, что этому унитазу положено (не знаю никогда не сталкивался с умными унитазами) — т.е. у них (мозгов) есть цель. Т.е. даже у умного унитаза — есть цель. А тут некий разработчик говорит нам, что цель не важна.
У хобби есть результат — получение удовольствия, расслабление, отдых.
За код же нам — платят. Т.е. заказчик заказывает конкретное ему нужное решение. Это решение мало кто видит, но заказчик обычно платит за две вещи:
- За, собственно, решение
- И предоставление этого решения за указанный срок — чтобы надобность в решении не истекла
И если эти два условия выполняются — то никаких проблем.
В статье же я увидел — код ради кода. Ничего не скажу против того, что красиво написанный код — приятно читать. Это факт — приятно. Но если сравнить "быстро внедрённое решение" приносящее в результате доход, удовлетворение от выполненной задачи или возможность перейти на новые задачи и стать выше уровнем со 125-тью возможностями красиво написать "Hello, world!" на 15 различных языках и фреймворках и все они будут одинаково прекрасны — то… "Hello, world!" — бесполезен.
К тому ж эпопея с "Hello, world!" нарушает основной принцип программирования — KIS.
Если человек пишет код красиво сразу или имеет время на его облагораживание (что случается реже) — это прекрасно.
Но в статье я увидел посыл: задача ничто, код — всё. А эта позиция — ущербна как любая граничная. Баланс он где-то посерединке.
Вышел новый фреймворк? Давайте перепишем проект на Asp.NET MVC под Angular? Плевать что послезавтра релиз, плевать, что большинство команды знает Angular только по названию — внедряем и переписываем! Это путь в бесконечный процесс, за которым… Да даже в резюме нечего написать. Ведь одно дело — перечень решённых задач, а другое — прекрасно выглядящий код, который тем не менее не делает ничего ибо не закончен.
Сколько проектов не вышло, сколько команд распалось из-за того, что хотели сделать "сразу как надо" и облагораживали решение, а в это время конкуренты быстро выпускали продукт и допиливали в процессе?
Типичный индусский подход, для секьюретизации рабочего места.
Не сможет, потому что в (по статье) команду не нанимают людей с альтернативной точкой зрения на продукт. Фанаты кодо- и фреймодрочерства — просто не примут человека с иным мышлением.
У аутстафера — действительно не может быть никакой точки зрения на продукт, просто потому что ваш продукт — это не его продукт. Его продукт — это та часть работы, что ему поручена. Теперь представим ситуацию вы вычленили часть работы, что можно выполнить вне контекста, составили ТЗ, согласовали и аутстафер начал выполнять-выполнять-выполнять… Один фреймворк, смена версии языка, новый паттерн архитектурный. Это вместо того, чтобы написать, оттестировать, рефакторнуть и сдать работу.
Допускаю, что с вашей точки зрения это может быть приемлемым — ведь интерфейс соблюдается, а у вас дофига времени. Но как часто в бизнесе бывает дофига времени? А если учесть, что оплата у аутстафера может быть почасовая — за его эксперименты и обучение платите вы.
Выбирать то в любом случае вам, как тому, кто платит.
Вы все исключительно верно написали. Оплата аутстаферов — как правило посуточная. Моя задача — выжать его за эти сутки по максимуму. Вы думаете, я оставлю ему время на эксперименты с фреймворками? Я оцениваю время на задачу, согласовываю с ним — все, арбайтен. Задачи для аутстафера в принципе не должны превышать 4 часа.
Заказчик обычно даже не знает что ему нужно. Он, иногда, знает как оно должно выглядеть. Мысль, например, о том, что код должен быть поддерживаемым, а не написанным на скорость, приходит потом и не всем. Он такой, может, и не всегда нужен, но этого заказчик тоже не понимает.
И, внезапно, быстро внедренное решение оказывается несовместимым с реальностью, вместо дохода приносит остановку бизнеса и необходимость срочных доработок.
В общем, за заказчика ТЗ додумывать надо. А то этот бедолага разориться раньше, чем осознает и научится. А тогда он с повторными заказами не придет.
Ну это уж проблема постановки и интерпретации задач, но никак не идеальности и чистоты кода. И для того, чтобы постановка и интерпретация задач была нормальной с заказчиком должны работать совсем другие люди, которые код — писали когда-то в далёкой юности, но вместе с тем знают азы его написания, иначе вообще не команда а фигня какая-то (утрирую, конечно).
Чисто субъективно — лично я считаю тот код чистым который удовлетворяет условию:
- Делает то что нужно
- Легко читается и понимается
- От взгляда на него — не хочется найти и убить предыдущего писателя.
2) Легко читается и понимается ВАМИ, субъективно
3) то есть, пока код только ваш — он идеален :)
В общем, вы сами решаете какой код писать
- Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.
- Да это субъективное понятие
- Нет. Я не пишу идеальный код. Ииногда даже костылю, увы. Но и не лицемерю на эту тему. Понятие красоты — действительно у каждого своё.
Да я решаю. И вы — если вы программист. И любой другой программист решает. Главное следовать одному незыблемому правилу — "не делать из едыкода культа" О.Бендер :).
Понятие красоты — действительно у каждого своё.— нет, красота это симметрия, она нравится любому человеческому мозгу т.к. ее проще запомнить и легче воспринимать, т.к образы стуктурны и воспроизводятся отражением, нужно в разы меньше усилий
т.о. это объективное понятие
Не соглашусь. Стандарты красоты у всех разные и зависят как от человека так и от культурных традиций: кто-то получает эстетическое удовольствие от созерцания абстракионизма, а кто-то — называет абстракционизм мазнёй.
На небольшом острове Тонга красотой считаются большие физические размеры. Причём настолько что у первых "красавиц" острова — трудности с передвижением. Я считаю такую "красоту" — сомнительной.
vs
> 1. Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.
что-то вы сами с собой спорить начали
вы делаете элегантное, на сколько считаете нужным, автор делает на сколько считаете нужным. Почему вы делаете как надо, а автору приписываете культ?
Противоречия нет, ключевое — решение задачи. Если оно красивое и элегантное то — это прекрасно. Если не очень, но есть время на приведение в красивость и элегантность — тоже хорошо.
чистый код != решение задачи
ничего не делает != !(делает то, что нужно)
И решать задачу может не только грязный, но даже обфусцированный код.
Логично. И что?
Т.е. вы спросили меня какой код я считаю чистым? Я — привёл пример субъективных критериев — и теперь что вы пытаетесь мне доказать? Что критерии субъективны? Так это факт — ибо они мои. Кому-то и говнокод — вполне себе код. Главное что задача решена.
Я считаю, что код — облагораживать надо, но не возвожу облагораживание кода в абсолют. Также моё мнение, что не стоит прыгать с фреймворка на фреймворк, если до релиза рукой подать, а новый фреймворк может преподнести незапланированный сюрприз.
Вот для них.
Тут на доу недавно HR говорила что плохо доверять бездушному ИИ такую задачу как выбор персонала. Мол не этично. Нуну
Какой-то у меня противоположный автору опыт. При работе в аутстаф компании, я видел код намного хуже. Хотя и сам и пытался рефакторить. Но руководству то это не особо интересно. Им интересней быстрей продать проект. Потом перешел в продуктовую компанию и отношение к продукту было координально другое. Ты делаешь продукт, который приносит компании деньги. Тебе не просто надо написать код, а от того как этот код будет работать дальше — будет зависеть сколько заработает компания (и ты косвенно). Поддерживать потом либо тебе, либо коллеге из соседнего кабинета — на качество кода и архитектуру уже не забьешь.
Так что мне кажется что автор делает слишком обобщенные выводы на основании своего личного опыта. У меня вот опыт другой, но я не возьмусь утверждать что так у всех.
P.S. Сам сейчас работаю как раз в аутстаффе. И после продуктовой(внутри компании) разработки мне больше всего не хватает довольных пользователей. Это же двойное наслаждение — «о как красиво я решил технически!» и «насколько легче стало жить пользователям».
Из последнего, проводил ревью решения написанного аутсорсерами, выдал вердикт — «ужас, ужас, нельзя такое в прод». Хотя все работает, но при малейшем изменении может сломаться. Заказчик сказал — «ну работает же, а сроки уже прошли, давайте в прод».
Остается надеется, что правильные заказчики существуют, как и правильные аутсорсеры, но я пока их не видел, и до выплаты ипотеки вряд ли увижу :-).
У нас самый ээ… как бы вежливо сказать… лютый и код написан аутстаф-командой. Я мало с ними работал, но они копали от забора и до обеда. В итоге там адская лапша с размазыванием функциональности между модулям.
Хотя я и не люблю кровавый энтерпрайз, но автор, пытаясь описать динамичность "галер", описал его так, что вышло только хуже.
Такое ощущение, что это они — те самые люди, которые чисто из-за хайпа готовы прикрутить блокчейн, микросерисы, кафку, пюрефку, просто "А вдруг?"
Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.
Аналогия не очень. Хорошей аналогией был бы врач, которому важно только чтобы операция прошла идеально, а насколько улучшится от этого жизнь пациента и как он будет рад — это хирурга уже не интересует.
А это, кстати, плохой врач?
С моей точки зрения, это очень хороший врач.
Ведь он же старается сделать операцию идеально.
Вот поэтому и хороший.
Идеально — это «пациент не умер на столе»?
Вы думаете так хирурги определяют идеальную операцию?
И если вернутся к оригинальной теме, то хороший девелопер (в данном контексте) это будет мифическая сущность, которая фигачит фичи сотнями, учачвствует во всех конференциях мира с докладами, не допускает багов во время деплоймента в прод, и которая вообще не в курсе что именно она там надевелопила и зачем…
Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.
И знаете, я бы пошел к этому хирургу, который вместо скальпеля использует лапароскопию — тот самый «новый скальпель».
Тут вопрос не в старом-новом, а в подходе к операции. Что важнее хирургу — живой пациент или инструмент попробовать...
Мне кажется, автор просто не успел познать радость создания продукта решающего чьи-то проблемы. А без подобной мотивации реально скучно на одном проекте сидеть больше чем N месяцев. Новые технологии/языки/фреймворки просто позволяют бороться с этой скукой, потому что рождают вызов по их освоению.
Насколько я понял, он успел сделать какой-то инструмент логирования для роботов, но радости ему это не принесло. Вот если бы это самое логирование помогло какую-нибудь реально возникшую проблему решить, то автор может быть и проникся бы.
На днях друг хвастался мне, что завернул на собесе чувака, который работал только в аутстафах
Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании
Адекватность при приёме на работу: уровень «дно донское». Кандидатам очень повезло, что их не наняли и что они не работают бок о бок с такими нанимающими людьми.
И с таким видением, как мне кажется, можно одинаково успешно и комфортно работать над продуктом и в аутстафе.
Синьор постиг тонкую грань того, что и когда делать
Синьор не пишет на, синьор пишет с использованием
Синьор не будет тащить новомодный фреймворк
Синьор не будет писать на устаревших технологиях
Синьору всё равно что делать
Сеньору важно, что он делает
Синьор понимает предметную область
Синьор не зацикливается на предметной области
Синьор никогда, никогда не напишет что-то, с чем я не согласен
Синьор то, синьор это
Не надоело вам?
Размер внутренней ответственности решает. Можешь поддерживать проект так, что б он не рухнул. И свалить не на кого. Джуниор может отмазаться и чинить будет синьор. Синьор может попробовать отмазаться, но чинить всё равно ему (а кому ещё, больше некому).
Формально это не измеримо, поэтому оценивают навыки.
Остальные критерии достаточно субъективны и зависят от многих факторов, например от компании и/или специфики разработки.
Слышал про такой вариант:
Джун — мало ответственности и поэтому за ним нужно следить
Мидл — тот за кем не нужно следить, он сам может за себя постоять
Сеньор — тот кто ответственен за других и себя
Что думаете?
Сеньор — тот кто ответственен за других и себя
Это тимлид.
Эта квалификация параллельна джуно-сеньорской.
Джун — может накодить
Мидл — может еще и задизайнить
Сеньор — еще и понимает все аспекты решаемой проблемы
— Джуниор думает, что всё знает.
— Мидл знает, что ничего не знает.
— Сеньор знает, что ничего не знает, но ему уже всё равно.
Джун должен знать всё.
Мидл должен знать в какой книге находится всё, что знает джун.
Сеньор должен знать где находится мидл.
Миддл — старший лейтенант
Сеньор — капитан
Тимлид — майор
у каждой компании… да что там — у каждого начальника / менеджера свое видение сениора, мида и джуна. много я уж этих матриц соответствия и списков критериев насмотрелся
Или же на этапе скрининг интервью не пропускать дальше неугодных.
Так можно сохранить своё и чужое время.
1) есть риск 5+ лет просидеть на одном проекте в аутсорсе и на древнем стеке, иначе, если постоянно менять аутсорс проекты (а для этого и компании кстати) есть риск стать эникейщиком, так и не научившись делать что-то стоящее от и до
2) почему страдает качество, посыл не мой:
Аутсорсер живёт за счёт разницы между зарплатой и ценой продажи человековремени — поэтому игра, с некоторыми упрощениями, имеет нулевую сумму, а зарплата — конкретный потолок. В продуктовике экономика другая — потери из-за высокой текучки (или даже необязательно высокой — если уходят сотрудники высокого уровня компетенции) существенны настолько, что «как можно меньше» может быть намного выше рынка.
Я тогда не придал этому значения, а сейчас понял — похоже, разработчики, которых по три раза за год продают на чужие проекты, и разработчики, которые пять лет фигачат один продукт — совсем разные профессионалы. Обстоятельно покопавшись в себе, я понял, что не просто отношу себя к первым, но и подсознательно презираю людей, которые больше двух лет работают над одним проектом.
Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
А вот тут непонятно.
Если «по три раза в год попадать на на очередные продукты», то эти продукты — новые, все как один?
В том время как аутстафная разработка — это всего лишь разработка продуктов корпораций силами внешних специалистов.
Откуда там по 3 раза в год новые технологии?
Ведь это такие же «долгоиграющие проекты».
Исключения в виде «коротких» проектов бывают. Но они бывают и в продуктовых и в аутстафных же.
Приходит тело на проект. Плюется, что за говнокод. Начинает переписывать на новый чудо фреймворк. Переписав процентов 5 несчастного легаси, понятно, что самой понятной его части, через пару месяцев, ибо нервы не выдерживают, уходит на другой проект. На его место берут новое тело. Которое плюется, что за говнокод… За год у всех в резюме появляется опыт работы с чудо фреймворком и по нескольку проектов за плечами.
Выход: работает — не трогай, для нового — пиши новый код, если надо изменить старое сначала дублируй в новое место и применяй tick-tock принцип для уменьшения долга.
Главное этот процесс на рельсы поставить и всем объяснить, новичкам — дважды.
Ситуация в статье просто описывает очевидное — мы все разные, а подбор кадров дело тонкое, кого наберешь — так и поплывешь. В разные моменты проекта нужны разные роли от сотрудников — это тоже надо понимать, поэтому лояльность сотрудников очень важна, а это в резюме увидеть можно.
и разобрался в изначальной проблеме которая решалась первым костылем и вместо нагромождения костылей сделал элементарную правку буквально в пару строчек, но на все про все ушло 3 дня — уволили.
Не верю.
Ну премию могли бы не дать — это верю.
Сейчас дефицит квалифицированных — просто так не разбрасываются теми, кто действительно может решить проблему.
Что-то вы не договаривайте.
Решить проблему и «решить» проблему — две большие разницы, но для пользователя и зачастую для заказчика разницы никакой. Для не технического манагера тоже разницы никакой. Для неквалифицированного тимлида или синьора — тоже никакой. Разница заметна только тем кто понимает, а таких точно меньше чем 100%. Поэтому вполне допускаю что человека могли уволить.
Просто если товарищ реально рубит, то расстраиваться точно не стоит. Найдет правильное место с правильными людьми и правильными проектами и будет ему счастье. А это просто эпизод на который и внимания то обращать особо не стоит.
применяй tick-tock принципВот вы так пишете, будто это уже широко известный термин в методологиях разработки софта.
Я погуглил — весь инет завален описанием стратегии выпуска микропроцессоров (тик — микроархитектура, так — техпроцесс), каковое значение я в первую очередь и вспомнил, но не смог сообразить, как это можно распространить на рассматриваемую область.
И только отдельными вкраплениями в поисковой выдаче все же нашлись статьи про чередование «изменение функциональности — наведение порядка». Например, "The Tick-Tock Innovation Model Applied to Agile Methodology". (Привожу ссылку для тех читателей комментов, кто как и я, первый раз встречает этот термин применительно к разработке софта).
Вообще, хороший принцип, и довольно универсальный и очевидный — «есть пауза — наведи порядок». Вопрос только в наличии этих пауз. Если приходится постоянно гнать функциональность, становится не до ликвидации долга. Как говорится, «некогда пилу точить — пилить надо!» Конечно, надо бы всё же выискивать такую возможность, буквально выгрызать… но не всегда получается.
Вон и ниже в комментах пишут:
за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода
Если в продуктовой у тебя заслуженный авторитет (а не из раздутого резюме): волю дают принимать важные архитектурные решения, плотно участвовать и корректировать технологический вектор развития продукта и не лепить блокчейны, кафки, амазоны там где это неумесно, экономя расходы аппаратные и человеко\часы.
Но за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода.
В прошлом году одна из аутстаф-компании на меня обиделась и нежно выгнала, або тот проект который хотели взять планировал чудовищный стек технологий на диких условиях, когда заказчик требует отчет утром (план), вечером — результат (и не сколько годных коммитов), + активный чат со ВСЕМИ членами команды (человек шесть)… Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…
Кроме того, в продуктовой компании, которая на рынок вышла не вчера, есть масса вещей для работы, далеко за пределами той части, над которой трудился с самого начала, я уже не говорю про новые фичи.
ЗЫ: не люблю эти ваши собеседования… там 90% треш… знакомый проходил недавно на позицию middle nodeJs — не прошел, не знал чего-то там по html5. )
Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…
А вы не хотели этот проект ради денег?
кроме того, от геморности проекта ставка не меняется, более того, в этой компании овер-тайм не учитывается, а вдруг часов не хватает — минусуют с зп (по часах ставку определяют), и чем меньше рабочих дней в месяце — тем выше стоимость профуканного часа… и другие странные вещи…
аутстаф )
у каждого свой опыт.
Осторожно, много букв.
Я работаю в стартапе на удалёнке, уровней абстракции между мной и заказчиком — ноль. То есть он мне пишет в скайп что он хочет видеть, мы где-то полчасика беседуем если я чего-то не понял, после чего он уходит на какие-то свои митинги. К концу дня он возвращается и обычно видит всё, что хотел.
Бывают конечно ещё сложносоставные задачи, которые разбиваются на «спринт» по тематике — то есть создаём эпик, начинаем делать первую задачу в понедельник, в пятницу всё работает и деплоится на прод (иногда деплоится в следующий понедельник). Спринт в кавычках, т.к. методологиями по понятной причине никто не заморачивается.
Поначалу меня очень смущало, когда он внезапно с описания задачи переходил на описание своего бизнеса и пересказывания митингов. Но потом я понял, что в общем-то это позволяет мне одному выполнять задачи не менее эффективно, чем это делала команда из пяти человек до меня (полусуществующий БА, два фронтенда, два бекенда). При том что этих пять человек заказчику приходилось микроменеджить лично (вплоть до описания полей в БД для бекенда — как написано, так и сделают, даже если это было набросано за пару секунд и является примером, а так откровенным бредом). Потому их и уволили, собственно, а я плавно перешёл из QA-автоматизации в разработку — сначала вынужденно (пока искал работу), а потом з/п подняли и таки остался.
Самое главное, что эти разработчики не были куплены у галеры, они просто привыкли работать на большом продукте, где между ними и непосредственно заказчиком находится пара слоёв менеджеров, аналитиков, дизайнеров и прочих, которые разжуют всё.
В заключение хочется сказать, что существует два совершенно разных типа людей. Оба называют себя программистами, но при этом одни могут и хотят видеть картину в целом, а для других «за мкадом жизни нет» (то есть за их областью ответственности).
Они нужны в совершенно разных ситуациях, но при этом у первых есть преимущество: любой может целенаправленно абстрагироваться от целей проекта и прогать по джире, но очень сложно научить «марширующего» программиста мыслить более высокоуровнево.
А про отношение вида «состояние проекта в джире важнее, чем в реальности»…
Ну тут вообще уже нечего сказать. Воспитывавшие меня люди такое называли «подстава». Чисто по-человечески так делать нехорошо, если конечно заказчик со своей стороны поводов не давал.
P.S. По работе программирую на трёх языках стабильно и ещё около четырёх знаю по верхам на уровне «увязать вместе чтобы работало» и «понять шо ж там сломалось и почему». Также имею опыт работы с библиотеками, по которым документации нет и не будет, зато есть высокоуровневый диздок или вообще научная публикация в PDF с кучей матана внутри. Но собеседование на разработку скорее всего не пройду, потому что людям нужно, чтобы я на бумажке по памяти прогал с использованием новейших фреймворков :)
И именно такие требования на собеседованиях и появляются из-за засилья аутстафферов, умеющих проходить собесы и концентрирующихся на знании фреймворков, а не на поставленной задаче.
Я люблю программирование потому, что программы облегчают труд людей.
И радуюсь, когда у меня получается новая классная фича.
что я сейчас прочел?
И там и там я видел плохой код, и там и там были проблемы с менеджементом и мамонты технологические и т.п.
Но деление между аутсорс и продукт есть — но оно заключается в личных предпочтениях. Кому-то Интересно постоянно что-то новое, новые подходы/языки/проекты и они хотят драйва. А кому-то интересно укреплять базу, развиваться в глубь. Это как кататься на мотоцикле, прыгать с Тарзанки/парашюта и т.д. Против хождения в одно и тоже места условно каждый день (например смотреть закат).
Но поверьте — специалисты хорошие есть везде, и просиживатели штанов тоже.
Я себя отношу больше к продуктовикам — мне база важнее чем технологии умирающие быстрее чем проект. но это не значит что я буду сидеть на старом языке или не использовать хороший Фреймворк (и точно не значит, что я не в курсе новинок). Просто перед использованием нужно задать вопрос — а что мне это даст? И только если плюсы перевешивают минусы, только тогда использовать.
Но по факту, при смене работы и при приеме на работу я ни когда не смотрю на продукт/аутсорс — все зависит от компании/директора/коллектива.
Если в продуктовую команду на собес приходит человек и с горящими глазами рассказывает как он за год пользовался 50 технологиями, то обязательно задам вопрос — «а ты уверен, что хочешь к нам? У нас не будет кучи технологий, зато будут сложные архитектурные задачи.», а человек в праве сам решать интересно ему это или нет.
Если в аутсорс компанию приходит человек, но ничего не слышал о современных подходах, то также возникает вопрос — «а ты готов постоянно развиваться вширь?», и также человек должен решать сам.
А грамотный лид всегда будет держать хотябы одного разработчика развитого в ширь и хотябы одного в глубь.
Снова много букв…
По своему опыту могу сказать, что да в продуктовых компаниях из года в год делаешь один и тот же код из продукта в продукт, переиспользуешь уже готовые и проверенные решения, хоть и основанные на "старых" технологиях. И это не потому что разработчики не хотят использовать новое, а потому что код, проверен временем, отлинтован, юнит тестирован, проверифицирован, и проревьин. Он надежен, и смысл тратить ресурсы и время на тоже самое, но по современному, нет. Это потенциально занесет ошибки.
Мой опыт говорит, что код продуктовых компаний намного чище и надежнее.
Черт, а что уже пятница? Не успел все комменты прочитать — так какие же фломастеры красивее других?
Он рассказывал не как продукт сделан, а что продукт делает для людей. У нас спрашивал, что мы делаем, а не как и с помощью чего. Мы, конечно не говорили друг другу: «Ему важен продукт, а должно быть насрать», но были единодушны в своем нежелании работать с ним, и навыдумывали много поводов для отказа.
Зато результатами его труда люди пользуются добровольно.
Да и по теме статьи. Непонятно, почему на на аутстафе людям должно быть не насрать на качество кода. Наоборот время нахождения человека на проекте в аутстафе должно быть меньше. Поддерживать их говнокод другим.
Что показательно код, который я видел после аутстаферов действительно был на новом стеке React+Redux+TS. И по нему было видно, что великий комбинатор писал под браузер второй раз в жизни.
Из увиденного как унаследованного так и попавшего на ревью от аутстаферов, которых прислали нам помочь
- три await подряд, ни один из них результаты предыдущих не использовал
- человек мутирует в течение простыни реактовский стейт, затем делает this.setState({...this.state}
- тип данных приходящий от сервера отличается от типа внутреннего представления клиента несколькими полями, при обращении к ним объект приводился к any
Зато будьте уверены у всех в резюме будет React+Redux+TS
Очевидно что эти предположения не только не аксиомы, но и верны только для очень частных случаев, и делать из этого глобальные выводы о природе различий между разными типами разработчиков так себе занятие.
Но в любом случае тема интересная. Как по мне — разработчик, который не понимает и не хочет понимать, что его код делает для бизнеса — это не разработчик, а кодер. Машина для создания кода для другой машины. Очень ограниченное и не очень полезное создание, которое по определению не может писать «хороший» код, где под «хорошим» кодом я понимаю не код, использующий последние фреймворки и фичи из последнего релиза языка X, а код, который полностью отвечает требованиям продукта, который легок в подержке, интеграции и масштабировании. Все это абсолютно невозможно получить от человека которому «насрать на продукт». Вот именно такие «насрать на продукт» кодеры есть говнокодеры, и таких есть везде — и в продуктовых компаниях, и в аутсорсе.
Вообще мне лично гораздо больше нравится определение «Software Engineer», чем «разработчик». Хорошие программисты — инженеры. А инженер просто не может работать, когда ему «насрать на продукт», иначе это не инженер, а так, чернорабочий на подхвате.
Я утверждаю, что разработчик, которому «насрать на продукт», неважно, продуктовик он или аусорсер (хотя среди аутсорсеров таких намного больше), является именно таким плохим разаботчиком. Он будет делать ровно то, что ему сказали, ни на миллиметр меньше, но и не больше ( а если и больше — то не ради продукта, а ради чисто своей выгоды/любопытства). Если вдруг какая-то характеристика фичера вступает в противоречие с другим, бОльшим фичером или просто «опасна» в контексте всего продукта — он этого не увидит и не эскалирует мне. Если его фичер жрет память и CPU в кривых вложенных циклах — ему будет наплевать, потому что никто не определил ему, сколько памяти ему можно брать. Он никогда не придет ко мне и не скажет — а давай вот здесь сделаем вот так, потому что я пил кофе с чуваком из фронтенда, и оказалось, что наши API не учитывают это и это — ему за это не плОтят, ему насрать на продукт. Можно продолжать дальше, но я думаю что мысль ясна.
И вот когда такие разработчики называют себя королями разработки потому что они используют новейшие фреймворки — мне сначала с них смешно, потом грустно, потом они идут искать другое место работы.
Требования — это то, как надо писать код, чтобы его можно было легко читать, поддерживать, рефакторить, переиспользовать. В основном — это выжимка из PSR`ов и "лучших принципов", типа DRY, KISS, SOLID и тд, а также указания где их использовать нельзя в принципе (да, и так бывает). Плюс, мой собственный бред, на тему как надо (будем считать так). Если что — про кривые вложенные циклы там даже написано )))) Всего, в моем случае, это 3 документа на 142 страницы А4 в сумме. Последний раз изменения в эти документы вносились вчера, до этого 2 месяца правок небыло. Выполнение этих требований обязательно для прохождения Code Review. Не выполнение — достаточный, но не необходимый (есть еще ТЗ) аргумент для деклайна PR. ТЗ — требования необходимые для автоматизации конкретного бизнес-процесса, либо требования к ИС в целом. Невыполнение ТЗ — также деклайн. Если разработчик выполнил и требования и ТЗ — его код будет принят и оплачен, вне зависимости от его отношения к продукту.
Я согласен, что с аутсорсерами по другому нельзя, и именно поэтому среди них так много деревянных солдат Урфина Джюса. Лично мне с такими работать неинтересно, и более того, нанимать таких себе в компанию — стрелять себе в ногу. Мне не нужны исполнительные солдаты, мне нужны умные, инициативные и не боящиеся ошибок инженеры, которых прет от того, что они делают.
3 документа на 142 страницы А4
Было бы интересно с сим трудом ознакомиться :)
Поясню: в аутсорс-компании центром прибыли являются менеджеры (PM, аккаунты, по продажам и т.д.), именно они приносят компании деньги. А технические специалисты являются центром издержек. Да, без них никак нельзя, ведь надо кого-то продавать заказчикам. Но, в целом, они находятся на вторых ролях. В итоге все решения принимаются менеджерами среднего и младшего звена. Зачастую даже технические, зачастую вопреки опытным разработчикам в статусе лидов.
Несколько примеров из моей практики:
— Тесты. TDD не было никогда. Как бы разработчики не настаивали. В половине проектов удавалось продавить интеграционные тесты, но при первом же цейтноте менеджеры их отменяли. Пишешь код, который нельзя показать заказчику — валяешь дурака.
— Работа с системой контроля версий. Почему мы не можем показать фичу заказчику, когда её код уже написан? Что значит не можете смержить, потому что ждёте какой-то там кодревью? На лицо явный саботаж. Делайте merge немедленно!
— Самый показательный случай: менеджер попросил срочно поменять реализацию, поскольку в последний день спринта выяснилось, что у заказчика другое видение. Я предложил по быстрому заговнокодить (да, знаю, сам виноват), но с условием, что нужно будет выделить время, чтобы сделать нормально в следующем спринте. Конечно, в следующем спринте мне отказали с аргументом: «На тестовом всё и так работает, а что будет на проде нам совершенно неважно, потому что они будут выливать на прод уже после того, как мы закончим с ними сотрудничество.»
На всё это можно возразить: чувак, а какая тебе разница? Ты работаешь, получаешь за это деньги. Расслабься и получай удовольствие. Но даже если для кого-то это и недостаточно неприятный опыт, то есть пару следствий из такого положения дел.
Во-первых, профессионализм ничего не значит. Более того, он вреден. Лучше писать быстро, а не долго. В итоге имеем, что профессионал, с желанием написать действительно работающий и способный к расширению (для добавления новых фич) код, будет критиковаться. А быстро шлепающий говнокодер нахваливаться. Естественно, расти как профессионал в таких условиях как минимум трудно.
Во-вторых, место профессионализма займёт другое качество. В моём случае это была лояльность. Хорошим был сотрудник, который готов работать на выходных и всем доволен. А тот, который на ретроспективах говорит о проблемах был плохим. Потому что «мы команда, а в команде важно мыслить позитивно.»
P. S. Конечно это мой сугубо личный опыт. Возможно, что есть аутсорс компании, в которых этого нет. Возможно, в продуктовых это тоже присутствует. Но, как мне кажется, продуктовые компании больше смотрят на качество сервиса, которые они предоставляют. Потому что от этого напрямую зависит их прибыль. А, следовательно, приходит понимание ценности экспертизы технических работников.
Профессионализм не может ничего не значить, так как в процессе принятия решений он является ключевым фактором. Если при обсуждении проекта условный разработчик не может описать менеджеру проблемы, которые могут возникнуть, предложить определенные решения и рассказать о плюсах и минусах данных решений, зачем вообще нужен такой разработчик?
И обратное верно — чем лучше развиты экспертные навыки, тем лучше менеджер сможет донести эти моменты до заказчика, а компания, соответственно, получить больше выгоды.
Так что профессионализм в «аутсорсовой» разработке очень даже много значит, не говоря уже о зарплате, уровне ответственности и т.д.
Если же разработчики пишут плохой, неподдерживаемый код, то проекты будут ломаться, заказчики будут уходить, а компания терять деньги. Ни один владелец бизнеса не хочет терять деньги.
По поводу «лучше писать быстро, чем долго» — мне кажется вне зависимости от типа компании, надо быть просто работать эффективно, и не в контексте «эффективных менеджеров», а просто грамотно распределять время на задачи. ИМХО, но я повидал много людей, которые растягивают какие-то простые задачи на недели, а сложные пытаются решить за пару дней, нарушая при этом всевозможные сроки с дедлайнами. Опять же, профессионализм и здесь играет роль.
А если компании действительно абсолютно параллельно на то, как работает человек, я бы задумался над тем, чтобы сменить место работы, ведь никто никого не заставляет)
Как раз дело в том, что бизнес возлагает принятие решений исключительно на менеджмент. Разработчики в принятии решений не участвуют вовсе. Вплоть до технических, про которые я и упоминал. Канал «разработчик» <-> «бизнес» не налажен, объяснить ему про потерю денег не получится (не говоря о том, что бизнес не считает, что разработчик в этом разбирается). Возможность потерять клиента в мифическом будущем не интересует бизнес, потому что через год это через год. А если мы сейчас скажем клиенту, что нам надо, к примеру, не месяц, а два, зато будет качественно, то клиент уйдёт к тому, кто готов сделать за месяц. И мы потеряем клиента прямо сейчас. Что там говорить, если менеджера зачастую не интересует, что будет на следующей неделе, главное выбить показатели текущей.
В итоге менеджмент принимает решения для того, чтобы выдать показатели здесь и сейчас. Мнением технического специалиста не интересуется никто. Следовательно, у технического специалиста нет ответственности. Нет ответственности — его деятельность не имеет значения. В итоге пишешь не предназначенный для прода код по техническим решениям человека без технического бэкграунда.
Да, по поводу ухода из такой компании я абсолютно согласен (да и вообще по поводу любого ухода). Я даже не хочу сказать, что такая бизнес-модель плохая, так делать нельзя и фу-фу-фу. Если бизнес зарабатывает деньги таким образом и процветает, то флаг им в руки. Опять же, возможно это мой личный негативный опыт. Но я не вижу причин, по которым в аутсорс-компании бизнес бы заботился о том: как код написан, насколько там современная версия, сколько мы времени сэкономим в будущем, если сейчас потратим больше времени на изучение чего-то нового и т.д. Чтобы бизнес задавал вопросы разработчику по его экспертизе. Главное это получить деньги с заказчика здесь и сейчас. С этим справляются менеджмент, а разработчики с желанием высказать своё мнение о том, что неплохо было бы написать то, что будет работать и через год; или желанием потратить больше времени сейчас, чтобы сэкономить через пару месяцев, идут лесом. И я вижу предпосылки к тому, что об этом как раз будут заботиться в продуктовых компаниях. И у разработчика будет больше ответственности. И больше смысла ходить в офис.
Вот, не так давно была история про переписывания — habr.com/ru/post/441456.
И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
Врач такой приходит на работу и говорит: Я конечно понимаю что вы, уважаемый пациент, хотите жить. Но тут есть новая методика, которую очень хочется опробовать. Вероятность смерти — на 80% выше, но зато если выживите — будете бегать на 10% быстрее и лечить мне вас потом будет проще и интереснее. А теперь считайте от 10 до 0…
Это такая пасхалочка для внимательных?
Квест? ,-)
Хочу посмотреть на проблему с другой стороны "экрана". То есть со стороны человека, который заказывает музыку.
Для начала, давайте определимся с терминологией. Аутстаф — сотрудник, работающий в другой компании, но предоставленный мне для реализации моих задач. Проходит техническое собеседование для оценки профессиональных навыков. Подчиняется внутреннему распорядку моей компании, делает то, что я скажу, в рамках должностных обязанностей и инструкций. Плачу я за его жопочасы. Аутсорс — сотрудник сторонней компании, которого я в жизни могу ни разу не увидеть. Мне вообще пофигу кто он, где и как работает, сколько получает. Деньги я плачу его работодателю за результат его работы. Сотрудник — сотрудник, который работает в моей компании, ну тут вроде как все понятно.
Моя первоочередная задача — получить от сотрудничества максимальную выгоду.
Если мы говорим об аутстафе — мне выгодно чтобы он писал. Мне не выгодно, чтобы он отвлекался на вникание в продукт. Мне нужно получить от него максимум полезного кода за минимальный промежуток времени. Для этого он получает требования, следование которым делают код полезным, а оценку полезности прозрачной и объективной. Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования. Он сдает код на ревью ровно так же как и мои штатные сотрудники, по результатам которого оценивается соответствие кода ТЗ и тем самым требованиям. Выполнил — молодец. Вот тебе следующее ТЗ. Нет — переделать. Снова не справился — прошу его работодателя прислать нового. Все строго по джире, все строго по часам. Я не хочу платить деньги за образование таких сотрудников. Я не хочу платить деньги за их кофебрейки, разглядывание котиков в интернетиках и их присутствие на митапах, где они абсолютно не нужны (ну понятно, все в разумных пределах, я не надсмотрщик над рабами). Я не хочу платить за вникание. Только бизнес, только код, ничего личного.
Если мы говорим об аутсорсе — все сильно проще. Есть то же самое ТЗ. Как правило, чуть более сжатое, поскольку описывает не одну задачу на несколько часиков, а требования к значительной части продукта, либо к продукту в целом. Да, я закладываю время на обсуждения и уточнения этого ТЗ с второй стороной. Я закладываю в бюждет чуть больше чем изначально в договоре (НИКОГДА в моей практике, финальная стоимость не была равна стоимости по договору). Я отдаю ровно те же самые требования, которые получил аутстафер. Я получаю результат. Я оцениваю результат. Я плачу за результат, если он меня устроил. Все. Больше меня ничего не интересует. В продукт должен вникнуть менеджер, с которым я работаю. Или не должен понимать продукт, но должен правильно понимать ТЗ. Будут ли вникать в него программисты той фирмы — мне не важно.
Мой сотрудник: должен знать все те требования к коду наизусть. Еще лучше — интуитивно понимать их. Должен понимать архитектуру, ожидания от продукта и его философию. Должен, потому что у меня просто не хватит времени писать для всех них подробные ТЗ как для аутстаферов. Должен учиться, развиваться, думать. И я готов за это платить, мне это выгодно, поскольку такие сотрудники экономят и мое время, и бюджеты компании, и вообще — главная ценность софтверной фирмы.
Так что все, что описано автором — вполне себе так и должно быть. И не приплетайте сюда говнокод и рассуждения, кто лучше пишет. Это ровным счетом никак не зависит от того, в какой компании работает человек. Это зависит исключительно от его личных качеств и навыков, а также от умения читать требования заказчика, как внутреннего, так и внешнего, и выполнять их. Если заказчик таких требований не предоставил — его проблемы.
И да, фреймворки и кододрочерство тоже к этой проблеме не имеют никакого отношения. Все должно быть строго регламентировано в рамках ТЗ. Аутсорс или аутстаф, меняющие по желанию стек продукта — нонсенс или идиотизм заказчика.
Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования.
Все должно быть строго регламентировано в рамках ТЗ.
Должно-то оно должно, но проблема в том, что в крупных проектах таких ТЗ не существует (я искренне хотел бы в это верить, но факт есть факт — их нет). При интеграциях, при пересечениях логики — на каждом шажке в крупных проектах есть куча нюансов и подводных камней. В своей практике часто вижу как разработчик-пофигист делает все строго по ТЗ, а шаг влево шаг вправо и упало. И ведь с такими и спорить невозможно — они никогда ни в чем не виноваты. Мозговой центр разработки — это разработчик, а не менеджер. И качество делают разработчики. А «максимум полезного кода за минимальный промежуток времени» на практике почти всегда с течением времени приводит к большим затратам бюджета, нежели экономии здесь и сейчас
Простите, я не знаю как в крупных проектах, я знаю как у меня (на текущий момент — банковская группа). Если те проекты не умеют работать с аутсорсом и аутстафом — пусть не работают. Я — умею. Такой вывод делаю на основании того, что получаю от этого вполне ощутимую прибыль. Именно потому что ТРЕБУЮ делать строго по ТЗ. Если ТЗ написано криво — это только моя ответственность. Если оно написано криво — я получу за те же деньги кучу БЕСПОЛЕЗНОГО кода. Полезный код — это код который легко поддерживается, рефакторится, переиспользуется, автоматизирует бизнес-процессы. Это те требования, которые я к нему предъявляю (точнее результат тех требований). С чего бы он должен приводить к большИм затратам, ну или как минимум, к затратам бОльшим чем код, написанный за большое количество времени? Как тут время вообще коррелируется с качеством? Вы искренне считаете, что "Hello, world!" на который потратили 2 недели будет сильно качественнее чем тот, который смогли написать за 2 минуты? А вам не приходит в голову, что разработчику из вашего примера ТЗ и было написано потому что шаг влево/вправо — и все упадет? Нахрен мне его самодеятельность не нужна в этом случае, я не хочу чтобы что-то падало. От этого страдает бизнес.
Если менеджер не умеет слышать разработку — это действительно очень печально. Отсутствие архитектуры — еще более печально. Тут я Вас прекрасно понимаю, поскольку у самого вполне себе программерский бэкграунд, и через все это неоднократно проходил. Но разговор изначально не о том. В моем случае ТЗ пишу я САМ. А не менеджер компании аутсорсера ДЛЯ МЕНЯ. Я знаю, на сколько все мои системы и модули завернуты в абстракции, где какие имеют коннекторы и так далее. Я знаю архитектуру, а не менеджер. Именно поэтому, мое ТЗ не оставляет шансов менеджеру-аутсорсеру всунуть мне какашку, которую вы описываете, и которая у меня просто не будет работать, а если и будет — за дополнительные деньги. Я ее просто не приму, не заплачу за нее, и даже не буду париться, выслушивая какой я нехороший, поскольку они вот старались, сроки соблюдали и так далее…
В моем случае ТЗ пишу я САМ.
Если ТЗ учитывает особенности реализации проекта, то его очень тяжело написать. У вас много времени отнимает детализация?
Слишком. В последнее время трачу на ТЗ и прочую документацию (за исключением пользовательских мануалов, ими занимаются отдельные люди) до 6 часов в день. В основном, это формализация требований бизнеса (перевод с русского на программерский). Для работы с аутстаферами удалось выделить отдельного человека, иначе вообще кроме бумажек ничего бы не видел. Оставшиеся 2 часа — либо ревью кода, либо живое общение с бизнесом/исполнителями. Кодить времени почти уже нет.
UPD: работа с таск- и баг-трекерами в это время тоже входит.
А мне глубоко фиолетово, что там думает аутстафер, тем более который уже ушел. Мне глубоко пофигу как он пытается меня вокруг чего-то вертеть. Мне сильно по барабану на Ваше мнение относительно эффективности разработчика при микроменеджменте и при вовлеченности. Мне искренне начихать на ваши сомнения относительно моей должности, и на то, на чем они основаны.
А вот размер моей годовой премии меня очень даже интересует. И зависит она исключительно от моего личного KPI, который, во многом, зависит от KPI моего подразделения. И если судить именно по ней — я просто сама деловитость и эффективность.
С уважением, директор департамента развития банковских технологий, ПАО "............"
Не по премиям и зарплатам, а по KPI. Да, это общая оценка, но вот принципы, на которых она строится — вполне конкретны. И показатели вполне объективны (в моем случае, это на 80% RoA, CuS, ClS). Если знаете другой способ оценить эффективность — пишите статью, с удовольствием ее прочитаю, и обещаю хорошо подумать (без какого-либо сарказма). Я, к сожалению, таких способов не знаю.
Что благородней: стать расходником-тонером в принтере, печатающей для Хозяина Деньги, тонером, который меняют каждые три месяца, и которому все равно что и на чем печатать, или стать принтером, печатающим для того же Хозяина те же Деньги?
Принтер меняют гораздо реже, а кроме того, у принтера есть свои собственные предпочтения по размеру и качеству бумаги и прочие интересные особенности.
Стать Хозяином ни в статье, ни в комментах — не обсуждается.
Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании.
Эпизод V: Гребец наносит ответный удар.
Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
Я в таких случаях наоборот, не понимаю бизнес. Консервативных разработчиков очень легко понять, так как эта платформа, которую они знаю и им проще с ней работать. А бизнес, который игнорирует потенциальные проблемы в духе "у вас тут уязвимости, которые никто не закроет, так как продукт не поддерживается" и потенциальное удорожание рабочей силы мне очень сложно понять.
и потенциальное удорожание рабочей силы
Ну какое удорожание, о чем Вы? Саппортер как раз всегда стоит дешевле, чем нормальный разработчик, испытывал это на своей шкуре не раз. Ни разу не видел вакансий, где саппортеру платили бы хотя бы в 2 раза выше, чем нормальному девелоперу, занимающемуся только свежими проектами, а не копролитами мамонта.
Я бросил работу мечты, потому что не переношу продуктовую разработку