Comments 184
Чем разработчик от кодера отличается
Кодер - это такой термин, который придумали программисты, выполняющие работу с большей долей творческой составляющей, чтобы возвысить себя над теми, кому не повезло оказаться в конторе или на должности с рутинной работой по ТЗ. Ну или просто над начинающими разработчиками.
Эдак каждый может, а вы попробуйте целую статью написать
Я думаю, что слова автора про «идущих строго по ТЗ кодеров» скрывают истинный страх перед неумением по этому ТЗ работать.
Тут скорее речь о том что с одной стороны существуют люди, которые работают строго по ТЗ, даже если ТЗ абсолютно лишён смысла. А с другой стороны есть люди, которые в такой ситуации об этом говорят и предлагают как ТЗ исправитъ/сделать лучше.
Оплату и закрытие работ проводят по тз.
Тз согласовывают со всеми сторонами, если в тз есть ошибки, нужно переделывать тз и сделать разбор возникновения ошибки. С орг выводами.
И все стенания о том что работать по тз не возможно, это признак "эффективных" менеджеров срезающих углы в погоне за процентом от сделки.
Тз согласовывают со всеми сторонами, если в тз есть ошибки, нужно переделывать тз и сделать разбор возникновения ошибки. С орг выводами.
По моему опыту в 90% случаев ошибка одна и та же: клиент не умеет составлять ТЗ :) При этом я знаю достаточное количество программистов, которых это не особо интересует и если им дали ТЗ, то они не думают, а просто делают как там написано. Или как они это понимают.
И все стенания о том что работать по тз не возможно
Работать можно по любому ТЗ. Ну при наличии хоть какой-то фантазии. Проблема только в том что если клеинту результат клиенту не нравится, то по дефолту виноват исполнитель. И если Тз позволяет различные интерпретации и у клиента одна, а у исполнителя другая, то это по дефолту опять же проблема исполнителя.
И какие бы орг выводы вы не делали, но работу в такой ситуации придётся переделывать. Или клиента можно потерять. Или деньги не получить. Или всё вместе.
Программист получает задачу «добавить ещё одну такую же табличку ниже существующей» делает такую же табличку и добавляет её в стык к существующей (так что между ними только пара пикселей). Выглядит это ужасно, и очевидно, что придётся переделывать.
"выглядит ужасно" это субъективно, особенно когда не все любят
( Д И З А Й Н С В О З Д У Х О М )
ну и "переделывать"? отступ добавить это переделывать теперь?
Основная обязанность разработчика — это решить проблему
Нет. Внести свой вклад в решение — да. Как и дизайнера, как и менеджера, как и аналитика. Одни только QA не решают проблему, а проверяют что она решена. И то, тоже решение.
Ну это частности, в целом мне не нравится глобальная мысль статьи. Какое-то элитарно-менеджерское "делим людей на хороших и плохих по полуобъективным параметрам, чтобы было удобнее их дискриминировать".
А чем Начальник отличается от менеджеришки? А чем Кассир отличается от операторишки кассы? А Водитель от автомобильного рулеповорачивальщика?
И конечно более инициативный разработчик, который ещё и умеет общаться очевидно лучше, но давайте без вот этих вот намеков, что просто делают свою работу только кодеры убогие, а Настоящий Разработчик и кофе начальнику вовремя подаст, и бухгалтерию приструнит и клиента утихомирит
ну и "переделывать"? отступ добавить это переделывать теперь?
Именно. Сам факт того, что задача закрылась, ушла в тест, тестировщик потратил время на тест, сходил к менеджеру, поговорил, оформил баг / улучшение и вернул на разработчика - это траты на переделку, которых можно было избежать, сделай сразу хорошо.
А если еще и окажется, что добавив отступ оно перестанет умещаться на мелких устройствах и надо будет всю верстку менять...
А если еще и окажется, что добавив отступ оно перестанет умещаться на мелких устройствах и надо будет всю верстку менять...
Ну, то есть все таки не стоило добавлять отступ?
"Добавь таблицу А в компонент Б"
"Добавил, с отступом перестало умещаться в мобильную верстку, переделал её всю, на эту таску 30 часов и полную регрессию верстки плиз"
Ну, то есть все таки не стоило добавлять отступ?
Есть у меня в частичном подчинении точно такой же разработчик. Сразу сверстает криво, а потом ставит перед выбором:
или оставить как есть
или сверстать ровно, но потратив на это 30 часов, потому что надо все переделать
Регулярно с ним воюем на эту тему :)
Не знаю, поймете ли, но фишка подхода, к которому призывает автор статьи, в том, что если изначально задуматься, если программисту сходить к "заказчику" и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часов. Да, потратится больше, чем N часов на сделать криво, но это N+M будет меньше чем 30 часов + изначальные N-M.
программисту сходить к "заказчику" и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах
С принятым в отечественных организациях подходом "я начальник, ты дурак" это может быть сложнее, чем вы себе представляете.
С принятым в отечественных организациях подходом "я начальник, ты дурак" это может быть сложнее, чем вы себе представляете.
Это уже частный случай, причем не тот, что рассматривается в статье. В таком подходе конечно не годятся советы. Я рассуждаю про адекватную компанию, где заказчик - это кто-то из старших менеджеров, кто ответственен за проект в целом и задает направление. Либо просто непосредственный менеджер, кто способен дать ответ либо транслировать вопрос дальше, например, к дизайнеру.
Я не знаю, нужны ли вам тут советы, но напишу. В моем понимании, разработчик занимается непотребством, потому что к категориям "задача сделана" и "задача не сделана" добавляет на свое усмотрение какую-то недиагностируемую третью "задача сделана настолько, насколько захотелось ее сделать сегодня". То есть пытается сдавать вам и заставить вас принимать у него, по сути, неоконченную работу. А если дозволительно одному -- остальные тоже могут начать так делать
Заказчик зачастую имеет поверхостное представление о том, что он хочет. По этому и не понятно как все строить изначально. По этому нужен некий макет. И, конечно, на это нужно время, которого у разработчика нет, потому что в глазах других людей, разработчик умеет читать мысли и понимать с полуслова.
Заказчик зачастую имеет поверхостное представление о том, что он хочет. По этому и не понятно как все строить изначально. По этому нужен некий макет.
Здесь все верно, но вот итог не верен.
То решение, которое разработчик сделал как "финальное", без выяснения дополнительных деталей, и есть макет. Разница же между хорошим и плохим разработчиком в том, станет этот разработчик далее развивать макет и приводить его к финальному решению или нет. В статье как раз призыв не обзывать макет финальным решением, пуская его в прод и ожидая, что теперь заказчик увидит и может переделает.
Поэтому начинать делать как-то - это хорошо. Но оставлять сделанное как-то - это плохо. В процессе реализации появляются дополнительные детали + уже можно что-то показать, поэтому хороший разработчик возьмет это все, пойдет к "заказчику", покажет что получается и озвучит узкие места, после чего вместе они выработают корректное решение.
В примере в статье можно было сделать так: добавить вторую таблицу под первую, кинуть в нее пару ячеек для примера и уже с этим идти к заказчику с вопросом, норм или не норм, акцентируя дополнительно внимание на отступе.
В примере все супер звучит, так как писал его менеджер.
Только в жизни задачу на добавление таблички кинули на бекенд разработчика. Он добавил табличку, показал ее продукту, тот сказал отдать в тестирование. Тестирование выявило, что в сафари она криво отображается.
Тестировщик сообщает проджекту, что задача не готова. Ее возвращают бекенд разработчику. Выясняется, что за верстку отвечают фронты, которых в цепочке поставки задачи вообще не было. Отдают задачу фронтам. Они правят баг в сафари. И спрашивают, почему табличка сделана не по дизайну и не хватает кнопок в дизайн-системе. Отдают табличку на согласование дизайнерам и нужно добавить недостающие кнопки.
Дизайнеры делают кнопки, отдают фронтам. Выясняется, что с таким кол-вом кнопок в новом дизайне поехала верстка в ИЕ. Задачу возвращают на доработку. Исправляют. Показывают пользователям.
Менеджер с коллегами за пивом: почему эти кодеры не могут просто сделать задачу?!
Давайте работу любого начальника программиста (как его не называй) не взваливать на программиста. Это начальство должно распорядиться сделать МАКЕТ (а не "конечный продукт") и ПОСЛЕ ОБСУЖДЕНИЯ (норм, не норм, изменение ТЗ) далее дорабатывать продукт или его часть.
С остальным частично согласен, но зависит от организации/начальства
Это начальство должно
Как интересно получается. Когда начальство решает что должен или не должен делать программист вас это не устраивает. Но вы почему-то решаете что должно или не должно делать начальство :)
Кстати, а как быть в каком-нибудь скраме где начальство просто отсутствует в контексте проекта? Кто там "должен распорядиться"?
Не знаю, поймете ли, но фишка подхода, к которому призывает автор статьи, в том, что если изначально задуматься, если программисту сходить к «заказчику» и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часов.Зачем вы вообще нужны в этой цепочке тогда? Почему заказывает «заказчик», а оцениваете и принимаете работу вы?
оформил баг / улучшениеА может ТЗ писать нормальное? Да не, бред какой-то.
И еще из другого вашего комментария:
если программисту сходить к «заказчику» и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часовЕсли проект чуть больше калькулятора, то эти согласования будут отнимать уйму времени, а где тогда взять время код писать? Почему те, кто общаются с клиентом: менеджеры, руководы, продаваны, в итоге не могут сформировать достойное ТЗ? «А какой бы нам отступ сделать между табличками? Хм, отдадим на откуп программисту.», а в итоге «Почему так некрасиво? Надо было вот так вот! Где твоя дизайнерская жилка!?»
А может ТЗ писать нормальное? Да не, бред какой-то.
Если у вас в ТЗ будут расписаны все все мелочи, типа отступов, поведения в каждом крайнем случае, каждое если (если был такой набор данных, если этакий, если нажал на кнопку и свернул приложение в фон и т.д.), то чем вы как программист будете заниматься? Просто кодить описанные ситуации с языка человека на язык компьютера? Так это и есть кодинг, которым занимается кодер. Все все все уже продумано, надо только закодировать.
Тот, кого вы называете «кодер» и есть программист. А кроме того есть еще куча профессий.
Просто кодить описанные ситуации с языка человека на язык компьютераАх, если бы это было «просто». А если по существу, то программист может участвовать в выработке требований, разработке архитектуры, конструировании, тестировании и т.п., а не только формочки «клепать». Давайте сюда добавим еще разработку дизайна приложения, согласования его с заказчиком, расчет стоимости проекта… этот список можно продолжать довольно долго. Расширение зоны ответственности заставляет страдать не только программиста, но и результат его работы, стоит это учитывать, когда на очередном «митинге» будет обсуждаться «почему Вася программист ни строчки не написал за неделю, а зарплату получил?»
если был такой набор данных, если этакий, если нажал на кнопку и свернул приложение в фон и т.д.Бывает, встречаются однотипные ситуации, когда есть готовые решения или же Best practice, и этого достаточно, чтобы доказать свою точку зрения, в случае непонимания со стороны руководства/менеджеров/заказчика. В остальном должен быть документ, описывающий набор ситуаций, связанных с работой приложения, в которых поведение/внешний вид приложения должны быть четко определены.
сделай сразу хорошо.
Так не бывает. Программисты иначе мыслят и делають то что им сказано.
Вспомните видео где программист отец для своего ребенка готовит по инструкции.
Если в организации есть дизайнер, то чтобы уместилось, это работа не только программиста, но и дизайнера. А если программист будет дизайнерить, общаться с клиентом, то нахрена нужны в организации дизайнеры, менеджеры и кто-нибудь ещё, которые получают не низкую зарплату и нихрена не работают?
а Настоящий Разработчик и кофе начальнику вовремя подаст, и бухгалтерию приструнит и клиента утихомирит
у вас комплексы, похоже какие-то, или личный опыт. В статье нигде не сказано про кофе начальнику или утихомиривание клиента. непонятное ёрничание.
Вполне себе понятное - "Однажды работник Демьян пришёл к хозяину дома и спросил..."
Меня всегда интересовало, если Лукьян такой офигенный, то почему он работает "на дядю", а не на себя? А если Демьян такой хреновый, то за что хозяин ему платит этих самых 2 рубля?
Для меня те, кто рассказывают эту притчу, сравни герою анекдота:
Журналист берёт интервью у миллиардера:
- Скажите, что помогло вам добиться успеха?
- Убеждение, что деньги сами по себе не играют никакой роли. Важна только работа.
- И это помогло вам разбогатеть?
- Нет, я разбогател, когда сумел убедить в этом подчинённых.
Интересно, а в европейском-американском менталитете есть шутейка, аналогичная "демьяну с лукьяном"? Или они в принципе не смогут представить себе ситуацию, когда одну и ту же работу выполняют настолько по-разному и за неё платят настолько разные деньги? Там ведь всё просто: не соответствуешь норме минимальной выработки - гуляй, вася! И никакого крепостничества.
Меня всегда интересовало, если Лукьян такой офигенный, то почему он работает "на дядю", а не на себя?
Например потому что не готов братъ на себя риски. Потому что если что вдруг случится, то разорится "барин". А Лукьян пойдёт и найдёт себе другого на которого будет работать за те же 15 рублей.
А если Демьян такой хреновый, то за что хозяин ему платит этих самых 2 рубля?
Потому что ему можно сказать "копай отсюда и до обеда и он будет копать". И иногда действительно надо просто копать и всё.
Интересно, а в европейском-американском менталитете есть шутейка, аналогичная "демьяну с лукьяном"?
Я не знаю есть ли "шутейки", но вот разделение на "демьянов с лукьянами" есть однозначно. в том числе и по зарплатам.
Или они в принципе не смогут представить себе ситуацию, когда одну и ту же работу выполняют настолько по-разному и за неё платят настолько разные деньги?
В том то и дело что это разная работа.
Там ведь всё просто: не соответствуешь норме минимальной выработки — гуляй, вася!
Ну да, если "Демьян" даже "копать" перестанет, то ему и 2 рубля никто не будет платить :)
Они не просто могут, они по карьерной лестнице именно таких и двигают. Кто не просто сделаль, а договорился, учёл, спросил, продавил (и презентовал какой он молодец в конце). А те кто «соответствует норме минимальной выработке» очень рискуют обнаружить, что их работу отдали на аутсорсинг.
Отличная статья, давно порывался написать что-то такое, но все было лень, а тут и за меня сделали. Надо теперь раздать ее всем тем, кого до этого учил этим подходам.
Основная обязанность разработчика — это решить проблему
Нет, основная обязанность разработчика — разрабатывать
«основная задача продавщицы - подавать водку и хлеб с полки, больше она покупателю ничего не должна, тем более улыбаться, быть вежливой, предложить еще что-то или про акцию напомнить»
Продавщица в первую очередь должна своему работодателю (это он ей платит зарплату, хоть и с тех денег, что идут от покупателей). Как бы это цинично не звучало.
Вот именно такая и нужна. Которая по скриптам улыбается, предлагает пакеты, товары по акции и прочее даже если покупателю это не интересно или раздражает. Некоторые также устраивают периодические проверки на сколько эти скрипты исполняются. И лишают премий если что не так. А у них ползарплаты это премия, бывает.
Тогда не вижу причин почему разработчик не может уволиться и начать разрабатывать в течении всего своего свободного времени? Можно ведь писать код, заливать его на гитхаб и тем самым выполнять свою основную обязанность.
П.С. Если вы не знали цель бизнеса - зарабатывать деньги. Цель разработчика - помочь бизнесу зарабатывать деньги через решение проблем. Качество решения имеет значение, но оно не первостепенно. Самое главное решить проблему.
вот такая зашоренность некоторых разработчиков и печалит. сродни «а булки растут на деревьях»
не люблю это слово «совок», но чувствуется, что некоторые «совок» не застали, но он в них сидит.
вот и получается еще одно определение: тот, кто занят процессом («разрабатывает») - кодер, а тот, кто занят достижением результата, которого от него хотят - разработчик
Тогда не вижу причин почему разработчик не может уволиться
Может, но не хочет. Распространенную причину см. далее
цель бизнеса — зарабатывать деньги. Цель разработчика — помочь бизнесу зарабатывать деньги через решение проблем
Нет, цель разработчика — зарабатывать деньги. Помощь бизнесу интересна только постольку поскольку этот бизнес дает что-то взамен
Нет, цель разработчика — зарабатывать деньги.
И много он заработает если будет писать код в ящик? Или если будет писать код, который не нужен заказчику (= тому, кто платит деньги)?
И много он заработает если будет писать код в ящик? Или если будет писать код, который не нужен заказчику (= тому, кто платит деньги)?Кто-то уже отменил маркетплейсы?
Я что-то пропустил, и на маркетплейсах платят за код, который никому не нужен :)? Там этот вопрос (написать что-то нужное и побыстрее, а не просто ради процесса) вообще во главе всего
Я что-то пропустилДа, контекст беседы.
И тот факт, что на маркетплейсах нет заказчика. Можно его эмулировать анализом спроса и пр., но конкретной сущности, которая тебе говорит, что делать нет. Поэтому можно делать что хочешь, и что-то периодически начинает приносить деньги.
Так «то, что хочешь» или «то, что приносит деньги»?
Как только вам захочется денег вы начинаете слушать нытьё покупателей (ну, чтобы покупали больше). И тут вы переходите на тёмную сторону. Вдруг выясняется, что какой-то говнокод в нужное время важнее идеально написанного через год. И если глупая свистелка принесёт больше, чем встроенный компилятор хаскелля, то делать придётся сначала ее.
Заканчивается все тем, что вы нанимаете помощников и пишете статью на Хабр о том, что с безынициативными исполнителями каши не сваришь. Круг замкнулся.
много он заработает
Без понятия. Зависит от заказчика
А вообще, что это вы сразу крайности рассматриваете? Я же ясно написал:
Помощь бизнесу интересна только постольку поскольку этот бизнес дает что-то взамен
Вот бизнес и разработчик и договариваются. Разработчик не подчинен бизнесу, и вот это:
помочь бизнесу зарабатывать деньги через решение проблем
не основная его (разработчика) задача. Потому что как у человека у него есть желания, исходя из которых он и действует
Несколько раз было в моей практике. Время от времени наша компания закупает новое оборудование, компьютеры для нас. Большими партиями, по 20-50 штук за раз. И каждый раз, когда такая партия приходила, старшой админ шел по комнатам и делал запрос на помощь от сильных программистов / дизайнеров / тестировщиков. Само собой без принуждения, кто хочет помочь - помогает, кто не хочет - не помогает. Я ходил каждый раз. И каждый раз был этому рад. Я помог коллегам, я решил проблему, я размял мышцы. 15 минут хождения по офису с дорогой техникой в руках и дело сделано. Все в плюсе.
Что касается девопса, первый девопс у нас действительно разворачивал разработчик, на попробовать. Второй разворачивал тоже разработчик. Затем выделили специального человека, кто пожелал взять это все на себя. По опыту собеседований знаю, что многие разработчики занимались девопсом, когда это еще не было отдельным видом деятельности.
Надеюсь, я ответил на ваш вопрос.
Работодатели ведут себя так, как допускает текущая конъюнктура на рынке труда с поправкой на ценность конкретного работника.
В конце нулевых-начале первых у нас весь отдел программистов заставили убирать остатки строительного мусора после ремонта. Я тогда был зелёный-неопытный, сейчас бы удалился до приведения рабочего места в пригодное состояние, тогда где-то через день слёг с симптомами орви на полторы недели (кстати, еще за три-четыре года до этого на собеседованиях было незазорным спрашивать у кандидата, на сколько часто он будет брать больничный, сейчас в IT подобный вопрос - это тревожный звоночек). В то же время, могли зайти со словами "нужны сильные программисты" и это обычно означало, что надо перенести чтото тяжелое.
Через 2-3 года после того случая, в той же конторе, при переезде на другой этаж на время ремонта, от нас требовалось только компактно сложить свои вещи, остальное делалиспециально нанятые носильщики (кто хотел - сам свой комп переносил, учитывая ценность данных там, многие не доверяли системник носильщикам). После этого, фраза "нужны сильные программисты" стала означать необходимость донести пакеты с ништяками (чай/кофе/молоко/печеньки и т.п.) от машины до кухни, всякие тяжести носить уже не приходилось (хотя не - было пару раз, например, однажды выбрали самых сильных чтобы каркас серверной стойки на 2й этаж поднять). Кто носил тяжести остальные разы, не знаю, мб. посчитали, что дороговато программистов отвлекать и стали внедренцев со 2го этажа звать.
Если он хочет быть ценным для работодателя, что выразится в его зарплате и должности, а не тем, кто всегда последний в очереди на повышение и которого сократят при любом кризисе - то да, бывает что иногда и нужно.
Ага. Еще уборщицы. Но не все, а примерно 0.001% - подобрать уроненую бумажку за собой, например. Перетащить сервер, если нужно прям щас, а грузчика ждать долго. Перевести одну фразу для младшего коллеги который сам неправильно перевел.
А за другими надо?
Да. Например если я прихожу в переговорку перед собеседованием и вижу что там предыдущие пользователи оставили бумажку. Я ее выкину в мусорку.
перевод видимых человеку строк в вашем приложении.
Тоже кусочек работы можно сделать. Например если софт международный то обычно на своем языке и на английском автор лучше переводчика знает специфические термины.
Все зависит от ситуации. Обычно полезно чуть-чуть думать за тех с кем вазимодействуешь и уметь делать чуточку их работы, конечно, учитывая свои и их ограничения.
Степень этой чутсчки КМК отличается в зависимости от ситуации. Вот в гаражном стартапе Джобс ручками сам что-то паял, а в Эппле - перестал.
Всё так. Но это не отменяет факта, что при прочих равных выберут разработчика с хардовыми + софтовыми скилами, а не с только хардовыми. Ну или бабла больше дадут. На совсем стартовом этапе логично вкладывать усилия в изучение второго фреймворка. Но когда знаешь уже пять фреймворков и стоит выбор, выучить шестой или подтянуть софтовые скилы - тут выбор очевиден.
Немного оффтопа.
Меня лично всегда демотивировала позиция "разработчик должен разрабатывать" или "таксист должен возить людей с места на место". В конечном итоге, любая работа = помощь кому-то в решении его проблемы. Таксист помогает мне вовремя добраться до аэропорта. Программист помогает N людям в своей компании, автоматизировав некий процесс. Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины - это банально скучно. Размен денег на время. Не понимаю, короче, такого.
хорошая статья. и комментарии ценные. предварительно можно понять, кто в них засветился: кодеры или разработчики
Не может потому что крепостной.
по той же причине, по какой барину нужен Лукьян.
барин не может в одиночку все делать сам, поэтому нанимает Лукьяна и перекладывает на него ту часть работу, которую Лукьян может хорошо делать. Да и Лукьян не во всем может быть хорош, и в одиночку со всем не справится и ресурсов таких нет, как у барина
Еще у барина есть собственность.
барин не может в одиночку все делать сам, поэтому нанимает Лукьяна и перекладывает на него ту часть работу, которую Лукьян может хорошо делать. Да и Лукьян не во всем может быть хорош, и в одиночку со всем не справитсяЗвучит прямо как партнёрство, но совсем им не является.
Если кратко:
Проявлять инициативу.
Знать границы проявления инициативы.
узнавать и уточнять, что и зачем делаешь, взаимодействуя с коллегами - это проявлять инициативу?
а где в статье про границы инициативы?
Например, в тексте про Лукьяна и Демьяна. В конце Лукьяна хвалят, потому что он проявил инициативу и разрулил проблему. Но неявно еще и потому, что знал "границы инициативы".
Прежде всего, он ориентируется в ценах. Если бы не сумел сторговаться за 18, а сторговался бы за 24 - стоило бы брать? Возможно, да. Возможно, нет. Это подскажет только опыт работы с проектом "закупки сена". У него он есть и он не хуже своего барина знает, сколько телег сена стоило бы взять по 24, а сколько по 18. Опыт раздвигает границы инициативы.
Но, если бы ему предложили за 30 и не сбивали бы цену, стал бы он брать, не посоветовавшись с более знающим "барином"? Очень верояно, нет, побежал бы уточнять - так как это уже за "границами" и шанс получить по шапке за такую закупку становится достаточно вероятным.
Я услышал ключевую идею автора так.
Классная статья, спасибо!
Почему-то такую технику осуперменивания разработчиков я встречал в компаниях, где разработчики занимались кодированием меньшую часть своего рабочего времени (2-3 часа), а остальную часть как раз и занимало это осуперменивание. Сюда входят погружение в домен, погружение в корп. культуру, море встреч разной степени полезности (которого никак не избежать, если от разработчиков требуют суперменства). Это все очень сильно выматывало эмоционально, а результат все равно получался посредственным.
Для меня наоборот является негативным моментом, если компания слишком пропитана своей продуктовостью и хочет ей пропитывать всех вплоть до уборщицы. Как правило, в таких компаниях все занимаются всем, но не тем, что у них прописано в трудовом договоре и на что они договаривались при найме. И текучка там огромная из-за постоянных осупермениваний, которые в целом приводят адским переработкам и последующему выгоранию.
Компания мечты для многих, это та что складывает проработанные задачи в джиру и не отвлекает разработчика и мгновенно отвечает на его вопросы. При этом быстро принимает решения.
Речь ведь не об идеальном мире. Понятное дело, что идеальных компаний очень мало и у каждого свое представление идеального мира. Речь о балансе между основными обязанностями (писать код и поддерживать функционал) и второстепеннонавязанными (погружение в доменную область, аналитика, менеджмент).
Обычно когда от разработчика начинают требовать очень много второстепенного, начинаются различные внутренние (а тем ли я в этой жизни занимаюсь?) и внешние (конфликты с навязывателями обязанностей и постоянное уточнение того, чем ты в итоге должен заниматься) разногласия, что очень усложняет жизнь.
Обычная песня: не можем найти толковых аналитиков - взвалим все на разработчиков.
Основная обязанность разработчика — это решить проблему
Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность
Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны
чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных
Область проблем, которую вы вменяете в ответственность разработчику, понятна.
Проблема дурной спецификации (которую, черт возьми, для того и писали, чтобы ей следовать) — проблема разработчика. Проблема дурного процесса (менеджеру приходится микроменеджерить) — проблема разработчика.
Что должен делать разработчик? Разработчик обязан решать проблемы и быть беспроблемным!
потому, что так увеличивается твоя эффективность
Нет, так штопаются дыры в процессах/компетенциях других кадров бизнеса: нанимателю выгодно иметь такого "славного парня" в штате. Но "продаётся" это под соусом саморазвития/личного роста, после чего "штопка" вменяется в обязанность, потому что "ну ты же не какой-то там кодер, а Разработчик".
Я вовсе не отвергаю инициативу, саморазвитие, и компетенции "вбок", но меня возмущает, когда это впаривают в обязанности и ожидания. Может != обязан, и имеет полное право отказаться, если не находит в этом явной материальной выгоды для себя.
Пример - врач, если он работает в больнице, не обязан заниматься хозяйственными и финансовыми делами больницы.Его задача - взаимодействовать с клиентами-пациентами, их родными, службами больницы и другими врачами по лечебным делам. Для других задач есть отдельные люди, которые получают зарплату. Вот если врач откроет частную практику - тогда да, он может ее обустраивать, но тогда он уже как-бы и владелец.
То же самое с разработчиком. Если он один из основателей бизнеса- это одно. А если наемный работник, тем более без опционов, то заниматься бизнес-проблемами - вне его компетенции. И его зарплаты. Если в сложную минуту он все-же вытащит бизнес на своем горбу надрываясь на несвойственных для него задачах ему потом не скажут спасибо, а то и с легкостью выпихнут на улицу лечить надорванный горб.
Все это, конечно, очень красиво. Вопрос в том, будет ли менеджер (или любой другой заказчик) так же одухотворенно стремиться мне навстречу и изучать структуру базы данных с архитектурой приложения, чтобы предлагать оптимальные решения и делать более точные постановки задач ради процветания продукта и нашего дружного коллектива.
Есть некоторые сомнения.
А для чего менеджеру лезть в структуру базы данных? Это не его зона ответственности. Задача менеджера ("заказчика") - придумать продукт, который можно продать дороже, чем затраты на его разработку + когда он сделан, таки продать его. Задача разработчика - реализовать продукт, соответствующий требованиям, с минимальными издержками. Все работают в тандеме, пытаясь сократить лишние траты, так как в конечном итоге из разницы будет выплачиваться зарплата как менеджеру, так и разработчику.
Вниканием в предметную область разработчик сокращает издержки на производство конечного продукта - понятная причина делать это. От того, что менеджер вникнет в струтуру базы данных, никому, в том числе и разработчику не будет профита. Поэтому этого не происходит и не будет происходить.
Отож. У менеджера есть зона ответственности, а для программиста у того же менеджера есть проникновенная речь о том, какая мы все дружная семья и нефиг в своей зоне ответственности сидеть как сыч, а надо работать за себя и за того дядю.
Всякое хождение навстречу должно быть взаимным.
Я повторюсь, что это не хождение навстречу. Задача разработчика - сделать продукт, соответствующий требованиям от менеджера с минимальными издержками. Вникание в предметную область относится к способам уменьшения издержек. Менеджер ищет способы как дороже продать, программист ищет способы, как дешевле произвести. Предметная область - это межграничная территория, демилитаризованная зона, в каком то смысле. Поход туда != поход навстречу.
Подобные суждения возникают из-за непонимания, как монетизируется конкретный кусок кода, реализованный программистом. Я уже выше в другом треде писал, про полезность мышления о работе не как о создании кода, а как решение чьей-то проблемы, "боли", которая достаточно болит, чтобы заплатить X рублей (или потратить Y часов внутренней разработки в случае внутренней задачи - не суть важно). При таком подходе вопроса "почему эти менеджеры не хотят изучать базы данных" просто не возникло бы. Потому что менеджер - про найти боль и придумать способ лечения, а программист - про сделать лекарство, быстро, качественно и недорого в требуемых в данной ситуации пропорциях.
Постарался донести мысль, возможно, путано. Но как могу :)
Задача разработчика - сделать продукт, соответствующий требованиям от менеджера с минимальными издержками.
Больше дешевого г*в*н*кода. Издержки минимальны. Если менеджер не желает вникать, что там за структуры в нутре базы данных - к этому паттерну всё скатится, рано или поздно.
Формулировка хороша тем, что именно в ней особенно ясно виден парадокс: ради избавления от боли менеджера суетиться должен программист.
Ради избавления от боли клиента. Это третье лицо, ради удовлетворения потребностей которого работают менеджер и разработчик. Разработчик без менеджера не продаст результат работы своего труда, менеджеру без разработчика нечего будет продавать клиенту.
Возможно, мы говорим о разном. Я вижу, что в ваших комментариях слово менеджер употребляется синонимом "дяди", на которого работает программист. В конечном итоге работают не на дядю, а на клиента, который даёт деньги на зарплату и менеджера и разработчика.
Совсем в конечном итоге можно дотянуть цепочку до работы на благо человечества (с риском погрузиться в депрессию). Лично я предпочитаю более приземленный горизонт, во всяком случае пока вопросы моего повышения, зарплаты или отпуска решает не клиент.
Это называется stakeholder economy
Ради избавления от боли клиента. Это третье лицо, ради удовлетворения потребностей которого работают менеджер и разработчик.
Разработчик (да и менеджер, в основном, тоже, если он наемный работник) работают ради удовлетворения потребности владельцев бизнеса в получении прибыли. И деньги на зарплату разработчику дают владельцы бизнеса, а откуда они их берут — это, в общем-то, не вопрос разработчика. Так что избавление от боли клиента — это чисто потребность владельцев бизнеса. Разработчик может заняться этим только если ему это владелец поручил (за соответствующую плату, например), а он на это согласился. А так в должностную инструкцию разработчика такая деятельность обычно не входит.
PS Необходимые пояснения для тех, кому мой подход кажется чрезмерно ограниченным. Поскольку мы живем и действуем в рыночной экономике, то вопрос что там «в конченом итоге» нас волновать не должен. Мы просто стремимся максимизировать выгоду для себя, а остальную работу — сделать так, чтобы это было максимально выгодно всем — делает рыночный механизм.
И это реально работает, причем, работает лучше чем социализм с его принципом «общее благо выше личных интересов». Почему так получается — это вопрос скорее не для обсуждения на Хабре, главное — что так получается на практике, и этого достаточно.
И в частности, что касается предмета этой статьи, рынка труда в разработке: разработчик тоже максимизирует выгоду для себя, и этого с его стороны достаточно для достижения эффективности в рамках всего общества.
Задача разработчика — реализовать продукт, соответствующий требованиям, с минимальными издержками.
С объективной, чисто материальной точки зрения, минимизация издержек — это вопрос, которым должен быть озабочен исключительно бизнес. Потому что только владельцы бизнеса получают выгоду от минимизации издержек, а потому в ней заинтересованы. А для разработчика, если он наемный работник, вопрос минимизации издержек в целом лежит вне круга материальных интересов. Его область ответственности — реализовать продукт, не превысив при этом установленный ему бизнесом лимит издержек. Если же бизнес ошибся и установил слишком мягкий лимит — это исключительно проблемы бизнеса.
Все работают в тандеме, пытаясь сократить лишние траты, так как в конечном итоге из разницы будет выплачиваться зарплата как менеджеру, так и разработчику.
Нет, разница — это прибыль (или убыток) только владельца бизнеса. Для разработчика же все обстоит по-другому и весьма просто: уровень зарплаты разработчика определяется состоянием рынка труда. И, кстати, для бизнеса выплата зарплаты разработчику тоже является частью издержек, снижающих потенциальную прибыль. И, как и любые издержки, бизнес стремится уровень оплаты разработчика «оптимизировать». Если может, конечно: в данный момент, например, у бизнеса с этим — объективные трудности.
Но уж в любом случае бизнес стремится побудить разработчика за те же деньги выполнять больший объем работы — а потому подобные статьи появляюся и будут появляться.
PS Для менеджера все немного сложее — оценка менеджера достаточно высокого уровня на рынке труда довольно сильно зависит от успехов предприятия, где он работает. А потому у менеджера объективная заинтересованность в этом успехе достаточно велика.
В отличие от разработчика — разве что он сможет при найме доказать бизнесу эту самую свою дополнительную полезность за пределами своих функций.
Я полностью согласен с написанным. Это логичный и прагматичный подход.
Если всё же начать копать глубже, то мы перейдем в область этики. Часто этот "мягкий лимит" устанавливает сам программист. Типичная ситуация в не-IT компаниях, так как кроме самого разработчика экспертизы в технической части нет. Корректно ли по отношению к работодателю работать с эффективностью 75%? Или игнорировать возможности делать что-то лучше и продуктивнее, когда эта возможность видна невооруженным глазом? Делать меньше, когда тебя не контролируют. И так далее.
Но тема морали слишком необъятна, чтобы ее поднимать )) Поэтому ну ее нафиг.
разработчик должен не только уметь программировать, но и
Разработчик должен делать только то, что прописано в трудовом договоре. А на каком основании от него требовать то, за что ему не платят?
То есть уметь договариваться.
То есть выполнять менеджерские функции (а может даже немного функции психолога)?
раскладывать проблему на задачи
Опять функция менеджера в чистом виде.
Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение
Еще аналитика и проектирование.
руководитель тратит сил на управление сотрудником
О, опять менеджмент.
Интересная картина получается, за одну зарплату разработчик должен выполнять несколько дополнительных функций. А на свою работу у него в результате время-то останется? А если он свои прямые обязанности не успеет выполнить, то тогда что?
Еще один интересный момент. Когда работа вот таких «многостаночников» идет без проблем, то все довольны. Но вдруг по какой-то причине контракт сорвется и нужен будет козел отпущения (к примеру, что бы чью-то задницу прикрыть). А тут как раз разраб сделал отступление от ТЗ (возможно даже правильное). Отличный будет повод повесить на него всех собак.
Так что да,
Это история, только жвачка в красивой обертке. Ну а еще немного про то, как сэкономить денег балабольством и компенсировать некомпетентность одних за счет дополнительной работой других.непро любовь, мир, жвачку и миссию компании
Я понимаю вашу позицию, но всё вышеперечисленное - оно не в интересах работодателя, а в интересах работника. И тут уже вам самим решать, как себя вести. Можно подходить к работе сугубо формально, получать сугубо оговоренную зарплату и сидеть ровно своей задницей на одном и том же месте, пока, возможно, не подвернётся какой-то шанс. Эта стратегия более безопасна, но имеет меньше перспектив карьерного/финансового роста. Можно подходить к работе инициативно, предлагать что-либо, брать на себя менеджерские функции и функции психолога, и если вы не совсем уж в болоте работаете, это даст свои плоды - вы будете быстрее продвигаться и карьерно, и финансово. Но да, есть дополнительные риски, чем больше инициативы, тем больше и ответственности.
Обе стратегии имеют место быть, нельзя говорить, что одна хуже другой - подбирать их нужно под ваш конкретный психотип. Кому-то больше подходит первая, кому-то вторая.
В текущих реалиях это уже не так. Можно проявлять инициативу и быть славным скакуном, на котором будут ездить годами без плюшек и перспектив (встречался с такими - печальное зрелище), а можно не выходить за рамки своих обязанностей и через время сменить работу на более комфортную и высокооплачиваемую просто придя на собеседование в другое место.
Для разработчиков повышение сейчас иногда приобретает негативный характер. Повышают до лида, при этом повысив зарплату до среднеразработческой по рынку, но при этом начинают требовать так, будто обеспечили старость человеку беззаботную.
Откуда растут ноги такого отношения в общем-то понятно. Программист — высококвалифицированный работник и по большому счету все эти функции действительно может выполнять (и зачастую выполняет ибо больше просто некому). Но заявлять, что ДОЛЖЕН и никак иначе, это уже перебор. Понятное дело, работодателю так дешевле, но выливается такой подход в переработки (хорошо если оплачиваемые) и выгорание.
И ровно отсюда же происходят анекдоты «тыжпрограммист». Хотя это нифига не анекдоты, лично мне предлагали магнитофон починить.
Причем тут какой-то психотип и стратегии, когда нам с порога заявляют, что разработчик ДОЛЖЕН не только разрабатывать, но и еще выполнять кучу функций?
Там не так заявляют. Там заявляют "разработчик должен делать вот это и это, если он хочет быть лучшим профессионалом". Т.е. он никому там не должен кроме самого себя. И в общем-то так оно и есть, инициативность и эти самые "софт-скиллы" вредят только в каких-то исключительных случаях, а вот пользу нередко приносят.
Другое дело, что кому-то все эти "функции" ничего не стоят, а для кого-то вызывают раздражение и забирают время его основной работы. Вот поэтому я и говорю, что это зависит от психотипа. Вот лично вам, насколько я понимаю, это даётся тяжело и вызывает раздражение :) Значит, вам не подходит.
Там заявляют «разработчик должен делать вот это и это, если он хочет быть лучшим профессионалом».
Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы.
И если сотрудник экономит время и внимание руководителя, то он становится ценным для него. И эту ценность можно потом обменять на более высокую зарплату или должность, более интересную и ответственную работу и т.д.
То есть для роста (и не только зарплаты) разработчику, очевидно, имеет смысл развиваться в разные стороны.
В общем, развиваться надо в разные стороны, и не потому, что так говорит Agile или твой начальник, а потому, что так увеличивается твоя эффективность, а значит и ценность на рынке.
Дааа, «профессионалом». Тогда почему везде речь про БАБКИ? Может все-таки потому что владельца бизнеса не интересует профессионализм, а только минимизация издержек? В каком вообще месте разработке (как написанию качественного кода, за что программисту непосредственно и платят) поможет знание, например, финансовой сферы? Или «софт-скиллы»?
Вот лично вам, насколько я понимаю, это даётся тяжело и вызывает раздражение :)
Раздражение или тяжесть тут вообще ни при чем. Данная статья — манипуляция с целью сократить издержки работодателя за счет работник путем формирования чувства неполноценности. Типа если ты работаешь за пятерых, то ты молодец и все такое, мы тебе даже зарплату сделаем выше (но никак не в 5 раз), а если хочешь выполнять только то, о чем договорились, то ты плохой, негодный работник. Я даже могу сказать, к чему такой подход приводит. Мне известен случай, когда айтишников натурально пытались заставить мыть полы (бесплатно, конечно), причем происходило это совсем в не маленькой компании. Понятное дело, это совсем уж из ряда вон, но направление именно то, которое здесь обсуждается.
Дааа, «профессионалом». Тогда почему везде речь про БАБКИ?
Ну так работу мы работаем за эти самые бабки :) И мы сами, и начальники, и хозяева бизнеса. Я не вижу в том ничего плохого - я сам люблю вкусно поесть, попутешествовать, хорошую квартиру в хорошем районе, машину, и тому подобное житейское барахло, которое всё требует бабок для обретения. Поэтому приходится их зарабатывать.
В каком вообще месте разработке (как написанию качественного кода, за что программисту непосредственно и платят) поможет знание, например, финансовой сферы? Или «софт-скиллы»?
Вы знаете, вот как раз на этот вопрос я могу вам долго рассказывать. У меня нет ИТшного образования. Я экономист-математик. Программировать я любил с детства, но учиться пошёл на кибернетику. Когда меня спрашивали ребята из тусовки, чего я туда попёрся, я почти в шутку говорил: "А я буду вашим начальником". И так и получилось - придя на работу в контору, которая занималась разработкой финансового софта, я вдруг оказался единственным чуваком из 70 ребят в разработке, который не просто умеет код писать, а понимает, что и зачем он делает. И да, я за три с половиной года работы там стал начальником отдела. А некоторые другие ребята, видя, насколько знание предметной области помогает в работе, пошли получать заочно вышку в финансовой сфере, просто ради вот этого.
Да, работодатель получил от меня несколько больше, чем получил бы просто от, кхм, кодера. Но и я получил больше, чем просто кодер. И наконец, понимание предметной области избавляет от кучи дурацкой рутинной работы по уточнению требований у аналитиков. Потому что идеальных ТЗ, по которым можно сесть и писать, ничего не спрашивая, не существует в принципе.
Я даже могу сказать, к чему такой подход приводит. Мне известен случай, когда айтишников натурально пытались заставить мыть полы (бесплатно, конечно), причем происходило это совсем в не маленькой компании
Слушайте, ну любой из нас может попасть как в хорошую компанию, так и в болото. Это никак не зависит от вашей манеры себя вести. Если вы работаете в болоте, то вас и со всей вашей круговой обороной от непрофильных задач потопят, если вы оттуда не свалите вовремя.
Ну так работу мы работаем за эти самые бабки :)
Так я и не отрицаю степени влияния бабок. Но зачем их подменять профессионализмом, о котором речи не было?
Да, работодатель получил от меня несколько больше, чем получил бы просто от, кхм, кодера.
Я за вас рад, но какое это отношение имеет к качеству написания кода?
Потому что идеальных ТЗ, по которым можно сесть и писать, ничего не спрашивая, не существует в принципе.
Это одна из причин, почему разработчики могут выполнять функции аналитика.
Слушайте, ну любой из нас может попасть как в хорошую компанию, так и в болото.
Угу, и такие статьи побуждают плодить такие болотные компании. Вот конкретно это мне не нравится.
Был админом в л... одной организации. После 8 лет работы и смены 3 директоров (на угодное высокому чем-то-водителю, не владельцы) на всех сотрудниках висело по х2,5 обязанностей. Многие уволились, я одним из последних. Остались пенсионеры, которым нечего терять. Они как выполняли самый минимум, так им и хорошо. Сейчас, как говорят, опять меняют "высшего" и с вероятностью не меньше 60% поменяют директора. А я наконец дождался вакансии в другой организации - по её меркам получаю копейки, но они выше прежней зарплаты почти в 1.5 раза. Работать приходится побольше, зато нервы в порядке.
лично мне предлагали магнитофон починить
Хм. Я б не обиделся. В конце концов, у меня рабочий день нормирован. Попросили починить магнитофон - ок, сегодня починю, а завтра займусь кодингом. Или не завтра, а послезавтра. А что, я раньше магнитофонов не чинил, сами попросили, вот пока разберусь, как там всё устроено, так и сделаю, мне же в удовольствие спокойно разобраться в чём-то новом.
Я техник по 1 образованию. Могу починить магнитофон, но в нерабочее время и за отдельные деньги. Не устраивает цена? Отдохну подольше.
Аналогично с кодингом. Попросили написать небольшую программку - договорились о сроках, оплате и все довольны.
Хм, как будто вас кто-то заставляет в рабочее время делать два дела одновременно. То есть магнитофон то вас просят починить в рабочее время и платят вам за это зарплату. То есть "цена" и "отдохну подольше" здесь не особо аргументы.
Другое дело если вы это не умеете или вам это просто не интересно.
А если он свои прямые обязанности не успеет выполнить, то тогда что?
когда он сделает чужую работу его уволят за невыполнение своей ))))
Разработчик (инженер-программист) требует в аналогичной ситуации только описания на уровне юзер-сторис или скриншота/куска лога с проблемой. Способ решения он вам сам скажет — возможно, даже не связанный с программированием (ибо engineer-first, software-second). То есть он может сообщение о проблеме (потребности) перевести в решение. Это уже совершенно другой уровень квалификации, самостоятельности и ответственности.
Ну и в качестве анекдота, различителный тест на кодеров и инженеров. В журнале сообщение о Null Pointer Exception:
// ... somewhere in the code abyss
foo.bar();
Инженер вздыхает, и начинает думать о том, какой контракт у цепочки вызовов? Допустим ли тут null? Не является ли это симптомом более глобальной проблемы?
Кодировщик спокойно пишет:
if(foo!=null) foo.bar(); // NPE fixed!За такие фиксы надо канделябрами
Сiдайте у колок, малята, сiй час дiду Панас расскаже вам казочку...
Пришлось дiду Панасу работать над одной программой, обрабатывающей данные из базы, соответственно, данных, в которой была забита информация про автомобили. Типа, марка, цвет, пробег, и всё такое. Написана эта программа была (что немаловажно) последователями шестирукого божества из далёкой-далёкой страны.
И увидел дiд Панас в этой программе строчку типа if record_id = 643428 then next и долго ей удивлялся. А потом по приколу убрал эту строчку — и программа упала.
"Ну, ни фига себе!" — подумал дiд Панас и стал разбираться. Оказалось, что в базе для одного конкретного автомобиля из 100500 в качестве значения одометра было записано значение типа 5 915 345. Что является нонсенсом, потому что редкий автомобиль в мире наездил больше миллиона (а тем паче двух миллионов) миль. А тут клерк, вбивавший значение в базу, тупо проигнорировал запятую на одометре, и вместо 591 534,5 вбил то самое число. А программа от такого невъ… ыразимого числа фигела и падала с арифметическим переполнением.
А последователи шестирукого божества, получив тикет "программа падает при обработке объекта с ID=643428" решили проблему. Ну, как могли. Ведь не падает же больше!
Ну наконец-то хоть кто-то слово "инженер" произнес, а то я думал, что придётся самому.
Как всегда, расскажу историю из жизни..
Проверил почту - вижу, уведомление: заявка на создание отчёта. Начинаю думать - как лучше сделать. Вижу, что в одном месте можно трактовать двояко. Т.е. в зависимости от того, как считать - можно получить два результата. Задаю в заявке вопрос "а как надо". Мне перезванивают и говорят "а нам всё равно! делай "как быстрей", нам надо перед руководством отчитаться, что мы отчёт внедрили, тем самым производительность труда подняли..."
А есть ли у Лукъяна право на принятие решения о выгрузке сена?
А точно ли Лукъян уверен, что хозяину нужно было то сено, а не мешок комбикорма? Если он управляющий хозяйством, то хозяин пока его устраивает рентабельность имения вообще не должен лезть в микроменеджмент Лукъяна.
Если бы оба — и Демьян, и Лукъян поступили одинаково, то у хозяина было бы 2 мешка сена, а ему нужен один.
Какие рабочие обязанности Демьяну объявляли при найме? Бегать по вопросам или управлять имением? Вот приеду я в автосервис, а мне вместо замены масла еще и химчистку сделают, и счет за это выставят, буду ли я рад?
Ну и еще 1000 и 1 недостаток у вашей притчи, она служит очень плохой иллюстрацией реальных отношений начальник/подчиненный.
А уж особенно на энтерпрайз-проектах с 20-кой девелоперов в тиме чем меньше таких Лукъянов будет, тем лучше, а то день до релиза, Лукъян сделал git push origin develop с бесценным рефакторингом о котором его никто не просил, и не пойми когда делать регрессию и не ляжет ли прод.
Судя по тому, что ему платят больше, он учел все эти обстоятельства и регулярно учитывает
Притча как притча. Другой вопрос, что она не очень хорошо раскрывает особенности именно разработки программ, но в рамках самой притчи все адекватно.
А есть ли у Лукъяна право на принятие решения о выгрузке сена?
Если хозяин его за это не прибил, значит такое право есть.
Если бы оба — и Демьян, и Лукъян поступили одинаково, то у хозяина было бы 2 мешка сена, а ему нужен один.
Если они бы оба были такие умные, то сами бы договорились и распределили полномочия, не допуская ненужных действий.
Другой вопрос, что хозяину не обязательно нужно сразу два Лукьяна. А вот простой Демьян очень может быть нужен.
Собственно говоря, притча не о том, что Демьян должен работать на этого конкретного хозяина так же, как Лукьян, чтобы зарабатывать столько же. Притча о том, почему труд разных категорий работников оплачивается по разному, и почему работник без соответствующих умений не может претендовать на более высокооплачиваемую категорию. Момент, что мест для двух Лукьянов в системе данного хозяина не предусмотрено,
А уж особенно на энтерпрайз-проектах с 20-кой девелоперов в тиме чем меньше таких Лукъянов будет, тем лучше, а то день до релиза, Лукъян сделал git push origin develop с бесценным рефакторингом о котором его никто не просил, и не пойми когда делать регрессию и не ляжет ли прод.
В разных случаях нужны разработчики разных типов.
Иногда нужны тупые исполнители (именно тупые, и чем тупее, тем лучше). А иногда, наоборот, креативные разработчики, способные в любой момент самостоятельно принимать решения. А уж потребность в промежуточных позициях
В частности, целью разработки не всегда является коммерческий продукт на продажу. Иногда это что-то исследовательское. И тогда "простые кодеры" будут совершенно неуместны.
Но в любом случае разработчик должен быть хоть немного погружен в предметную область и хоть немного разбираться в проекте, в котором участвует. Иначе результатом будут костыли и неэффективный код. И никакой аналитик не донесет до разработчика все необходимое, если он не будет представлять себе проект в целом (хотя бы в самых общих чертах) и не будет иметь никакого представления о том, что этот проект собственно делает.
Основная обязанность разработчика — это решить проблему.
Полностью согласен.
Помимо этого, надо аккуратно вести список всех решённых проблем. Желательно с какими-то метриками по результатам. Чтобы потом, на Performance Review (не знаю, как это лучше по-русски написать), были основания для повышения зарплаты, получения должности и т.п.
Ну и разумеется, хорошо и правильно, когда решенные проблемы согласуются с планом личного развития разработчика. При условии, что такое вообще есть в компании.
В идеале такой список должен вести руководитель. Но, да, абсолютно нелишним будет записывать его самостоятельно. А на ревью свериться, что "достижения" по вашему мнению и мнению руководителя как минимум сильно пересекаются и курс саморазвития выбран верный (если в компании не налажена культура давать фидбэк сразу после замеченного достижения - что ещё лучше).
Основная обязанность разработчика — это решить проблему.
И дьявол как всегда в деталях…
Разработчик должен решить проблему так, чтобы не возникло новых проблем и под обязательным контролем.
Я был свидетелем тому, что двум разработчикам дали волю и объявили их разработчиками-архитекторами с полномочиями, вплоть до выбора ПО для двух новых модулей. Разработчики и выбрали — то ПО, которое согласовалось с планом их личного развития…
В обоих случаях разработка была провалена сначала по затратам времени, а потом по функциональности/нагрузке. В результате оба новых модуля были переписаны с нуля. Общие потери стоили проекту около человеко года.
Так и я видел подобное много раз и на самых разных уровнях. Это не слишком приятно, я согласен. Главное, чтобы это не происходило систематически. Да, сделали ошибку, поняли, поправили бизнес-процессы там или что-то другое, работаем дальше.
Бизнес, а в особенности High-Tech, сопряжен с огромными рисками. Никуда от этого, к сожалению не деться. Есть средства снижения рисков, но ситуация, как вы описали выше, всё равно может возникнуть.
В реальности всё несколько иначе.
...
Хозяин усмехнулся и повернулся к своему первому работнику:
--Видишь какой инициативный и компетентный Лукьян? А ведь я плачу ему на 10% меньше, чем тебе. Только, тссс...
--Эй, Лукьян, возьми вон ту самую большую лопату и раскидай по полю вон ту самую большую кучу навоза. В помощники тебе - этот наш новый работник. По ходу объясни ему как тут всё устроено и научи держать в руках лопату.
...
Хозяин удивлённо:
--Повысить Лукьяна? Зачем? Я идиот, что ли? А кто мне будет закрывать все дыры, которые закрывает Лукьян?
В помощники тебе - этот наш новый работник. По ходу объясни ему как тут всё устроено и научи держать в руках лопату.
Это уже повышение. Выполнения ли это в бОльшие деньги - зависит от Лукьяна. Как себя продаст.
Основные паттерны работы с кодом и декомпозицией как были актуальны 20—30 лет назад — например, тот же DDD, — так и остаются.
DDD появился менее 20 лет назад. По крайней мере автором термина считается Ерик Эванс (Eric Evans), который написал Domain-Driven Design: Tackling Complexity in the Heart of Software примерно в 2003 году.
Да и вообще, вы недооцениваете скорость изменений - непосредственно инструментальная работа с кодом радикально изменилась даже за последние 15 лет. ООП (и проектирование и программирование) несколько раз существенно поменялись даже за последние 20 лет, а уж еще больше за предшествующие 10 лет, например, GoF написали книгу про паттерны в 1994 году, С++ 1990 года был хипстерской свежатиной, Java появился в 1995, C# писался в 1999-2000, Linux - 1991, git - 2005 год. Подходы к проектированию тоже поменялись радикально. Тестирование пережило вообще серию революций (напр. TDD появилось 20 лет назад).
Короче, если вы ищете тех, кто разрабатывает по принципам 20-30-летней давности, у меня для вас плохая новость. Впрочем, если вы ищете тех, кто 20-30 лет назад обладал современными концепциями разработки ПО, у меня другая плохая новость.
Имхо, ДДД тут просто не очень к месту упомянули, ибо он сам как методология — новый, но является по сути прикладной проекцией общей теории систем, которая как раз практически не менялась.
И вот имея именно фундаментальные, не-процессные и не-методологические знания, освоить новый тулинг и методологию — задача куда более простая, чем тупо зубрить их не понимая базиса, откуда они взялись. Паттерны и иже с ними выводятся из этих самых фундаментальных знаний чуть ли не на автомате, ибо в случае написания кода "против шерсти" начинает чесать задницу изнутри мысль о том, что "что-то тут не то", как-то "не смотрится" и всё тут :-)
И вот имея именно фундаментальные, не-процессные и не-методологические знания, освоить новый тулинг и методологию — задача куда более простая, чем тупо зубрить их не понимая базиса, откуда они взялись
Согласен на 100%. Но временной горизонт в статье выбран неверно. За 20-30 лет поменялось почти всё. Ну, я не знаю даже что осталось, только "Искусство программирования" и еще несколько по алгоритмам из книг той эпохи можно использовать практически. Даже МЧМ Брукса (но это еще более раннее) отчасти устарела и имеет больше философскую и историческую ценность, чем практическую. Но всё еще обязательна к прочтению.
если вы ищете тех, кто разрабатывает по принципам 20-30-летней давности, у меня для вас плохая новость. Впрочем, если вы ищете тех, кто 20-30 лет назад обладал современными концепциями разработки ПО, у меня другая плохая новость.
Да хоть 500 лет назад, и что с того? Есть что-то "современное" и получшее?
Искренне хочу послушать про современные на сегодняшний день концепции разработки ПО для программиста, и про то, почему вы считаете, что что-то из приведённого вами же списка потеряло актуальность.
У меня уже есть что возразить, но я хотел бы вперва выслушать, т.к. ваши слова вызывают полное недоумение
Искренне хочу послушать про современные на сегодняшний день концепции разработки ПО для программиста, и про то, почему вы считаете, что что-то из приведённого вами же списка потеряло актуальность.
А перечисленное не очень-то потеряло актуальность. И оно как раз и есть кирпичики современного фундамента разработки. Просто их не было 20-30 лет назад, поэтому если искать тех, кто разрабатывает по принципам 20-30-летней давности, то у них не будет этих кирпичиков, а если искать тех, у кого они были 20-30 лет назад, то проблема в том, что на Земле таких людей не было.
В начале они требуют от разработчиков, глубокое знание предметной области, софтскилы, знание потребностей бизнеса. А потом ноют, что разработчиков днем с огнем не сыщешь. А те что есть просят такую ЗП, что хоть банкроться.
<:o)
Ну а почему бы и не покошмарить в пределах разумного. Разве тимлид должен быть неприкасаемым авторитетом для нижестоящих? Так это противоречит посылу статьи. Может новенький окажется столь активным и способным в здоровой конкуренции так пусть шевелит бородачей ).
Не вижу противоречий. Нужны оба типа программистов. Когда ставлю себя на место владельца бизнеса, то вижу такой расклад:
1) Нужен "конвейер" с дешевой рабочей силой, работающей строго по ТЗ, т.е. предсказуемо по срокам и качеству. Здесь нужны будут кодеры. Здесь всё должно быть предсказуемо, без неожиданностей, без субъективных факторов, без зависимости от конкретных работников.
2) Нужно некоторое количество людей для грамотной настройки "конвейера", для правильного выбора инструментов, для разработки чего-то прорывного (чтобы обойти конкурентов, захватить новую нишу и т.д.), для вникания в задачи заказчика. Здесь желательны разработчики с большой буквы, знающие предметную область и т.д.
Тут проблема скорее в том, что разработчики не спешат рождаться сразу сеньорами. Их надо учить работать (а никто толком не знает как это делать, даже вузы...) Таким образом, команда разработчиков вынуждена мириться с людьми, которые «умеют только в готовое ТЗ», потому что нужно время пока они пройдут «курс обучения в сочетании с выполнением производственных норм», и не станут полноценными членами общества. :-)
Заменяем название должности "программист" на более абстрактное понятие "разработчик" и получаем тезис Основная обязанность разработчика — это решить проблему.
Если разработчик решает проблемы и задачи бизнеса, то почему он (зачастую) не получает свою долю прибыли?
Вообще, этот тезис похож на перекладывание ответственности за процессы согласования и уточнений ТЗ с бизнеса на программиста.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему.
На этот раз риторический вопрос, а кто выступает в роли "разработчик", бизнес или программист? Другими словами, кому принадлежат права на разработку?
Всё проще.
Кодер — это человек, который пишет код.
Программист — это кодер, подкованный в Computer Science и своей предметной области
Высокооплачиваемый, ценный программист — это программист, который берет на себя часть обязанностей своих руководителей.
Например, который знает, что нам нужно сено, не проходит мимо возможности его купить и самостоятельно обо всём договаривается.
А если серьезно, то это часть общей тенденции, порожденной необоснованным уважением к гуманитарным заменителям рационального мышления.
Вместо логики у кучи людей критика и диалектика, а вместо планирования — вот это все.
необоснованным уважением к гуманитарным заменителям рационального мышления
а что такое "гуманитарный заменитель рационального мышления" в вашем понимании?
Все, чем марксисты махают.
it argues that social problems are influenced and created more by societal structures and cultural assumptions than by individual and psychological factors.Как бы не вижу в этом тезисе ничего нерационального.
В любом случае, речь о том, что люди всю эту светотень противопоставляют логике. Попытка объяснить, например, что некоторое утверждение просто ложно, а значит, ложно и все из него вытекающее, вызывает поток наукообразной философской болтовни, которая ничего не доказывает.
Я действительно очень сожалею, что мне не заходит философия (в основном; Лема или Толкиена или Честертона читать нравится). Может, интеллект не тот. Общепринятым у адекватных людей инструментом спора, обоснования чего-то, опровержения чего-то является логика, а не что бы там ни было еще.
Да и по пути в сени я заметил негоже скучающую суженую вашу в неприкрытом томлении и решил что неплохо было бы усмирить ее страсти.
Хозяин усмехнулся и повернулся к своему первому работнику:...
Позиция понятна, написано правильно, но я всё же триггернусь. Достаточно частая ситуация, в том числе в командах экосистемы Сбера, когда на одного бэкендера, одного фронтендера и одного QA приходится директор проекта, менеджер проекта, пара аналитиков и пара-тройка менеджеров абсолютно неясного назначения. Не считая ещё кадровиков, бухгалтеров, менеджеров по закупкам непонятно чего и прочих. При этом технари сами общаются с клиентами, сами общаются с интеграционными партнёрами, сами налаживают взаимодействие с другими командами, сами пишут себе таски в трекер, сами пишут документацию, сами планируют релизы, сами организуют найм и т.д. и т.п. Возникает закономерный вопрос, а нужен ли решающему проблемы разработчику вообще "барин"?
Возникает закономерный вопрос, а нужен ли решающему проблемы разработчику вообще «барин»?
Не нужен, если он готов ещё и бегать за этими клиентами, уговаривая заключить с ним контракт.
Есть ещё вариант нанять продажника на сервисную позицию, увольнять при плохих показателях и писать статьи о том, что хороший продажник должен понимать продукт вплоть до технических деталей.
Или например банальная ситуация с больничными. Если я сотрудник и заболел, то это головная боль моего работодателя. Зарплата мне платится и когда я болею. А кто там меня будет замещать думать тоже должно начальство.
Если я контрактник/самозанятый, то все мои больничные оплачиваю я сам. И сам должен как-то решать вопрос с заменой на время больничных и отпусков.
По кряней мере у нас это выглядит именно так.
Чем разработчик от кодера отличается