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

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

Чем разработчик от кодера отличается

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

Эдак каждый может, а вы попробуйте целую статью написать

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

Я думаю, что слова автора про «идущих строго по ТЗ кодеров» скрывают истинный страх перед неумением по этому ТЗ работать.

Всегда легче уговорить клиента/менеджера на что-то попроще.
Я думаю, что слова автора про «идущих строго по ТЗ кодеров» скрывают истинный страх перед неумением по этому ТЗ работать.

Тут скорее речь о том что с одной стороны существуют люди, которые работают строго по ТЗ, даже если ТЗ абсолютно лишён смысла. А с другой стороны есть люди, которые в такой ситуации об этом говорят и предлагают как ТЗ исправитъ/сделать лучше.

Оплату и закрытие работ проводят по тз.

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

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

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


По моему опыту в 90% случаев ошибка одна и та же: клиент не умеет составлять ТЗ :) При этом я знаю достаточное количество программистов, которых это не особо интересует и если им дали ТЗ, то они не думают, а просто делают как там написано. Или как они это понимают.

И все стенания о том что работать по тз не возможно

Работать можно по любому ТЗ. Ну при наличии хоть какой-то фантазии. Проблема только в том что если клеинту результат клиенту не нравится, то по дефолту виноват исполнитель. И если Тз позволяет различные интерпретации и у клиента одна, а у исполнителя другая, то это по дефолту опять же проблема исполнителя.

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

Не все, но это не повод кого-либо принижать.

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

"выглядит ужасно" это субъективно, особенно когда не все любят


( Д И З А Й Н С В О З Д У Х О М )


ну и "переделывать"? отступ добавить это переделывать теперь?




Основная обязанность разработчика — это решить проблему

Нет. Внести свой вклад в решение — да. Как и дизайнера, как и менеджера, как и аналитика. Одни только QA не решают проблему, а проверяют что она решена. И то, тоже решение.




Ну это частности, в целом мне не нравится глобальная мысль статьи. Какое-то элитарно-менеджерское "делим людей на хороших и плохих по полуобъективным параметрам, чтобы было удобнее их дискриминировать".


А чем Начальник отличается от менеджеришки? А чем Кассир отличается от операторишки кассы? А Водитель от автомобильного рулеповорачивальщика?


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

ну и "переделывать"? отступ добавить это переделывать теперь?

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

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

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

Ну, то есть все таки не стоило добавлять отступ?


"Добавь таблицу А в компонент Б"


"Добавил, с отступом перестало умещаться в мобильную верстку, переделал её всю, на эту таску 30 часов и полную регрессию верстки плиз"

Ну, то есть все таки не стоило добавлять отступ?

Есть у меня в частичном подчинении точно такой же разработчик. Сразу сверстает криво, а потом ставит перед выбором:

  • или оставить как есть

  • или сверстать ровно, но потратив на это 30 часов, потому что надо все переделать

Регулярно с ним воюем на эту тему :)

Не знаю, поймете ли, но фишка подхода, к которому призывает автор статьи, в том, что если изначально задуматься, если программисту сходить к "заказчику" и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часов. Да, потратится больше, чем N часов на сделать криво, но это N+M будет меньше чем 30 часов + изначальные N-M.

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

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

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

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

Я не знаю, нужны ли вам тут советы, но напишу. В моем понимании, разработчик занимается непотребством, потому что к категориям "задача сделана" и "задача не сделана" добавляет на свое усмотрение какую-то недиагностируемую третью "задача сделана настолько, насколько захотелось ее сделать сегодня". То есть пытается сдавать вам и заставить вас принимать у него, по сути, неоконченную работу. А если дозволительно одному -- остальные тоже могут начать так делать

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

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

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

Здесь все верно, но вот итог не верен.

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

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

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

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

Давайте работу любого начальника программиста (как его не называй) не взваливать на программиста. Это начальство должно распорядиться сделать МАКЕТ (а не "конечный продукт") и ПОСЛЕ ОБСУЖДЕНИЯ (норм, не норм, изменение ТЗ) далее дорабатывать продукт или его часть.

С остальным частично согласен, но зависит от организации/начальства

Это начальство должно

Как интересно получается. Когда начальство решает что должен или не должен делать программист вас это не устраивает. Но вы почему-то решаете что должно или не должно делать начальство :)


Кстати, а как быть в каком-нибудь скраме где начальство просто отсутствует в контексте проекта? Кто там "должен распорядиться"?

Ваш вопрос отлично раскрыт в книге Scrum black book.

Не знаю, поймете ли, но фишка подхода, к которому призывает автор статьи, в том, что если изначально задуматься, если программисту сходить к «заказчику» и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часов.
Зачем вы вообще нужны в этой цепочке тогда? Почему заказывает «заказчик», а оцениваете и принимаете работу вы?
оформил баг / улучшение
А может ТЗ писать нормальное? Да не, бред какой-то.

И еще из другого вашего комментария:
если программисту сходить к «заказчику» и показать, как это выглядит, высказать свои опасения и акцентировать внимание на узких местах, то можно с первого раза сделать корректно, при этом затраты будут значительно меньше, чем 30 часов
Если проект чуть больше калькулятора, то эти согласования будут отнимать уйму времени, а где тогда взять время код писать? Почему те, кто общаются с клиентом: менеджеры, руководы, продаваны, в итоге не могут сформировать достойное ТЗ? «А какой бы нам отступ сделать между табличками? Хм, отдадим на откуп программисту.», а в итоге «Почему так некрасиво? Надо было вот так вот! Где твоя дизайнерская жилка!?»

А может ТЗ писать нормальное? Да не, бред какой-то.

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

Не придумывайте отсебятину, почитайте хотя бы вики Процесс_разработки_программного_обеспечения
Тот, кого вы называете «кодер» и есть программист. А кроме того есть еще куча профессий.
Просто кодить описанные ситуации с языка человека на язык компьютера
Ах, если бы это было «просто». А если по существу, то программист может участвовать в выработке требований, разработке архитектуры, конструировании, тестировании и т.п., а не только формочки «клепать». Давайте сюда добавим еще разработку дизайна приложения, согласования его с заказчиком, расчет стоимости проекта… этот список можно продолжать довольно долго. Расширение зоны ответственности заставляет страдать не только программиста, но и результат его работы, стоит это учитывать, когда на очередном «митинге» будет обсуждаться «почему Вася программист ни строчки не написал за неделю, а зарплату получил?»
если был такой набор данных, если этакий, если нажал на кнопку и свернул приложение в фон и т.д.
Бывает, встречаются однотипные ситуации, когда есть готовые решения или же Best practice, и этого достаточно, чтобы доказать свою точку зрения, в случае непонимания со стороны руководства/менеджеров/заказчика. В остальном должен быть документ, описывающий набор ситуаций, связанных с работой приложения, в которых поведение/внешний вид приложения должны быть четко определены.

Просто кодить описанные ситуации с языка человека на язык компьютера?

Да. Вот только не "просто":

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

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

сделай сразу хорошо.

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

https://www.youtube.com/watch?v=Ct-lOOUqmyY

Обратное тоже очень даже вероятно: добавил отступ, задача ушла в тест, тестировщик протестил, время потратил, отдал заказчику. А заказчик: а зачем тут отступ?… и в баг-треккер на доработку.

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

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

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

Вполне себе понятное - "Однажды работник Демьян пришёл к хозяину дома и спросил..."

Меня всегда интересовало, если Лукьян такой офигенный, то почему он работает "на дядю", а не на себя? А если Демьян такой хреновый, то за что хозяин ему платит этих самых 2 рубля?

Для меня те, кто рассказывают эту притчу, сравни герою анекдота:

Журналист берёт интервью у миллиардера:

- Скажите, что помогло вам добиться успеха?

- Убеждение, что деньги сами по себе не играют никакой роли. Важна только работа.

- И это помогло вам разбогатеть?

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

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

Меня всегда интересовало, если Лукьян такой офигенный, то почему он работает "на дядю", а не на себя?

Например потому что не готов братъ на себя риски. Потому что если что вдруг случится, то разорится "барин". А Лукьян пойдёт и найдёт себе другого на которого будет работать за те же 15 рублей.


А если Демьян такой хреновый, то за что хозяин ему платит этих самых 2 рубля?

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


Интересно, а в европейском-американском менталитете есть шутейка, аналогичная "демьяну с лукьяном"?

Я не знаю есть ли "шутейки", но вот разделение на "демьянов с лукьянами" есть однозначно. в том числе и по зарплатам.


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

В том то и дело что это разная работа.


Там ведь всё просто: не соответствуешь норме минимальной выработки — гуляй, вася!

Ну да, если "Демьян" даже "копать" перестанет, то ему и 2 рубля никто не будет платить :)

Они не просто могут, они по карьерной лестнице именно таких и двигают. Кто не просто сделаль, а договорился, учёл, спросил, продавил (и презентовал какой он молодец в конце). А те кто «соответствует норме минимальной выработке» очень рискуют обнаружить, что их работу отдали на аутсорсинг.

Как раз таких редко двигают по карьерной лестнице. Потому что на текущей позиции условный Лукьян может получать БОЛЬШЕ, чем его начальник. И «больше геморроя за ту же зарплату» Лукьяна не особо интересует, а поставить его начальником с заметным увеличением и так большой зарплаты — зачастую душит жаба.

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

Основная обязанность разработчика — это решить проблему

Нет, основная обязанность разработчика — разрабатывать

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

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

Такая продавщица не нужна своему менеджеру/владельцу. А работодатель продавщицы — покупатель. Нет покупателя — нет и продавщицы.

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

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

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

вот такая зашоренность некоторых разработчиков и печалит. сродни «а булки растут на деревьях»

не люблю это слово «совок», но чувствуется, что некоторые «совок» не застали, но он в них сидит.

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

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

Может, но не хочет. Распространенную причину см. далее


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

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

Нет, цель разработчика — зарабатывать деньги.

И много он заработает если будет писать код в ящик? Или если будет писать код, который не нужен заказчику (= тому, кто платит деньги)?

И много он заработает если будет писать код в ящик? Или если будет писать код, который не нужен заказчику (= тому, кто платит деньги)?
Кто-то уже отменил маркетплейсы?

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

Я что-то пропустил
Да, контекст беседы.

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

Так «то, что хочешь» или «то, что приносит деньги»?

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

Заканчивается все тем, что вы нанимаете помощников и пишете статью на Хабр о том, что с безынициативными исполнителями каши не сваришь. Круг замкнулся.

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

Без понятия. Зависит от заказчика


А вообще, что это вы сразу крайности рассматриваете? Я же ясно написал:


Помощь бизнесу интересна только постольку поскольку этот бизнес дает что-то взамен

Вот бизнес и разработчик и договариваются. Разработчик не подчинен бизнесу, и вот это:


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

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

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

Несколько раз было в моей практике. Время от времени наша компания закупает новое оборудование, компьютеры для нас. Большими партиями, по 20-50 штук за раз. И каждый раз, когда такая партия приходила, старшой админ шел по комнатам и делал запрос на помощь от сильных программистов / дизайнеров / тестировщиков. Само собой без принуждения, кто хочет помочь - помогает, кто не хочет - не помогает. Я ходил каждый раз. И каждый раз был этому рад. Я помог коллегам, я решил проблему, я размял мышцы. 15 минут хождения по офису с дорогой техникой в руках и дело сделано. Все в плюсе.

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

Надеюсь, я ответил на ваш вопрос.

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

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

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

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


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


Кстати, удивлён, что у вас были отдельные дизайнеры и тестировщики, ЕВПОЧЯ.

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

Практика показывает, что гораздо эффективнее с этой точки зрения три других стратегии:


  1. Подлизываться к начальству и быть с ним в друзьях.
  2. Писать адовый говнокод, чтобы никто, кроме вас, не то что не хотел, а и не мог его поддерживать.
  3. Стать местным экспертом в узкой, но важной для команды области.

Пункты 2 и 3 хороши только если вы решили прекратить развиваться как программист. Т.к. ни один вменяемый руководитель не будет давать вам другие задачи или повышать/переводить. Ибо заменить вас не кем.

Судя по тому, что вы говорите о повышении-переводе, не уверен, что мы под развитием программиста понимаем одно и то же.


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


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


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

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

Не знаю где вы у меня в сообщении увидели рос в таком смысле :)

Не знаю, как его иначе интерпретировать (про что я написал в первой же фразе).


Рад, что со всем прочим вы согласны.

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

Но не все, а примерно 0.001% — подобрать уроненую бумажку за собой, например.

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


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

И отвечать, если вдруг уронишь или что? Спасибо, ну его нафиг.


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

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

А за другими надо?

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

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

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

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

Степень этой чутсчки КМК отличается в зависимости от ситуации. Вот в гаражном стартапе Джобс ручками сам что-то паял, а в Эппле - перестал.

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

Немного оффтопа.

Меня лично всегда демотивировала позиция "разработчик должен разрабатывать" или "таксист должен возить людей с места на место". В конечном итоге, любая работа = помощь кому-то в решении его проблемы. Таксист помогает мне вовремя добраться до аэропорта. Программист помогает N людям в своей компании, автоматизировав некий процесс. Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины - это банально скучно. Размен денег на время. Не понимаю, короче, такого.

Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины — это банально скучно

Согласен, но речь про "должен", про минимальные требования так сказать. Можно (но не обязательно) относиться к своей деятельности глубже

Тогда прошу прощения. Мой комментарий был написан в парадигме "должен и ничего другого".

Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины — это банально скучно.

Вам скучно.


Мне вот код писать интересно, я делаю это даже в свободное время и бесплатно. А эмпатия и социальщина — это скучно и по-неприятному сложно.

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

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

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

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

Или менеджеры

Мне всегда было интересно, а зачем вообще Лукъяну из той притчи барин, если он сам всё умеет? Почему он не организует собственное хозяйство?

Не может потому что крепостной.

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

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

по той же причине, по какой барину нужен Лукьян.

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

Еще у барина есть собственность.

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

Если кратко:

  • Проявлять инициативу.

  • Знать границы проявления инициативы.

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

а где в статье про границы инициативы?

Например, в тексте про Лукьяна и Демьяна. В конце Лукьяна хвалят, потому что он проявил инициативу и разрулил проблему. Но неявно еще и потому, что знал "границы инициативы".

Прежде всего, он ориентируется в ценах. Если бы не сумел сторговаться за 18, а сторговался бы за 24 - стоило бы брать? Возможно, да. Возможно, нет. Это подскажет только опыт работы с проектом "закупки сена". У него он есть и он не хуже своего барина знает, сколько телег сена стоило бы взять по 24, а сколько по 18. Опыт раздвигает границы инициативы.

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

Я услышал ключевую идею автора так.

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

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

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

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

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

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

Обычная песня: не можем найти толковых аналитиков - взвалим все на разработчиков.

Основная обязанность разработчика — это решить проблему

Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность

Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны

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

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


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


Что должен делать разработчик? Разработчик обязан решать проблемы и быть беспроблемным!


потому, что так увеличивается твоя эффективность

Нет, так штопаются дыры в процессах/компетенциях других кадров бизнеса: нанимателю выгодно иметь такого "славного парня" в штате. Но "продаётся" это под соусом саморазвития/личного роста, после чего "штопка" вменяется в обязанность, потому что "ну ты же не какой-то там кодер, а Разработчик".


Я вовсе не отвергаю инициативу, саморазвитие, и компетенции "вбок", но меня возмущает, когда это впаривают в обязанности и ожидания. Может != обязан, и имеет полное право отказаться, если не находит в этом явной материальной выгоды для себя.

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

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

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

Есть некоторые сомнения.

А для чего менеджеру лезть в структуру базы данных? Это не его зона ответственности. Задача менеджера ("заказчика") - придумать продукт, который можно продать дороже, чем затраты на его разработку + когда он сделан, таки продать его. Задача разработчика - реализовать продукт, соответствующий требованиям, с минимальными издержками. Все работают в тандеме, пытаясь сократить лишние траты, так как в конечном итоге из разницы будет выплачиваться зарплата как менеджеру, так и разработчику.

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

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

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

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

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

Постарался донести мысль, возможно, путано. Но как могу :)

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

Больше дешевого г*в*н*кода. Издержки минимальны. Если менеджер не желает вникать, что там за структуры в нутре базы данных - к этому паттерну всё скатится, рано или поздно.

Ну так иногда (даже часто) и нужно быстро и пофиг как.

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

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

Если процесс двусторонний, то тут не обсуждать надо, а завидовать и изучать список вакансий.

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

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

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

Это называется stakeholder economy

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

Разработчик (да и менеджер, в основном, тоже, если он наемный работник) работают ради удовлетворения потребности владельцев бизнеса в получении прибыли. И деньги на зарплату разработчику дают владельцы бизнеса, а откуда они их берут — это, в общем-то, не вопрос разработчика. Так что избавление от боли клиента — это чисто потребность владельцев бизнеса. Разработчик может заняться этим только если ему это владелец поручил (за соответствующую плату, например), а он на это согласился. А так в должностную инструкцию разработчика такая деятельность обычно не входит.
PS Необходимые пояснения для тех, кому мой подход кажется чрезмерно ограниченным. Поскольку мы живем и действуем в рыночной экономике, то вопрос что там «в конченом итоге» нас волновать не должен. Мы просто стремимся максимизировать выгоду для себя, а остальную работу — сделать так, чтобы это было максимально выгодно всем — делает рыночный механизм.
И это реально работает, причем, работает лучше чем социализм с его принципом «общее благо выше личных интересов». Почему так получается — это вопрос скорее не для обсуждения на Хабре, главное — что так получается на практике, и этого достаточно.
И в частности, что касается предмета этой статьи, рынка труда в разработке: разработчик тоже максимизирует выгоду для себя, и этого с его стороны достаточно для достижения эффективности в рамках всего общества.
Задача разработчика — реализовать продукт, соответствующий требованиям, с минимальными издержками.

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

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

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

Я полностью согласен с написанным. Это логичный и прагматичный подход.

Если всё же начать копать глубже, то мы перейдем в область этики. Часто этот "мягкий лимит" устанавливает сам программист. Типичная ситуация в не-IT компаниях, так как кроме самого разработчика экспертизы в технической части нет. Корректно ли по отношению к работодателю работать с эффективностью 75%? Или игнорировать возможности делать что-то лучше и продуктивнее, когда эта возможность видна невооруженным глазом? Делать меньше, когда тебя не контролируют. И так далее.

Но тема морали слишком необъятна, чтобы ее поднимать )) Поэтому ну ее нафиг.

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

"Основное различие между кодером и разработчиком состоит в том, что кодер думает что знает, чем отличается разработчик от кодера, а разработчик знает, что никакой разницы нет". (c)

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

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

То есть уметь договариваться.

То есть выполнять менеджерские функции (а может даже немного функции психолога)?

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

Опять функция менеджера в чистом виде.

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

Еще аналитика и проектирование.

руководитель тратит сил на управление сотрудником

О, опять менеджмент.

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

Еще один интересный момент. Когда работа вот таких «многостаночников» идет без проблем, то все довольны. Но вдруг по какой-то причине контракт сорвется и нужен будет козел отпущения (к примеру, что бы чью-то задницу прикрыть). А тут как раз разраб сделал отступление от ТЗ (возможно даже правильное). Отличный будет повод повесить на него всех собак.

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

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

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

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

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

А как одно отменяет другое? Никто ж не запрещает прокачаться и свалить в другое место на другую должность/другие деньги.

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

Причем тут какой-то психотип и стратегии, когда нам с порога заявляют, что разработчик ДОЛЖЕН не только разрабатывать, но и еще выполнять кучу функций? О которой, скорее всего, даже и речи не было при приеме на работу. А менеджер не хочет пару багов исправить? Или аналитик реализовать пару формочек? Может начальник схему БД спроектирует? Нет? Вот это номер, разработчик ДОЛЖЕН за всех выполнять часть их работы, но почему-то функции разработчика на себя никто не хочет брать.

Откуда растут ноги такого отношения в общем-то понятно. Программист — высококвалифицированный работник и по большому счету все эти функции действительно может выполнять (и зачастую выполняет ибо больше просто некому). Но заявлять, что ДОЛЖЕН и никак иначе, это уже перебор. Понятное дело, работодателю так дешевле, но выливается такой подход в переработки (хорошо если оплачиваемые) и выгорание.

И ровно отсюда же происходят анекдоты «тыжпрограммист». Хотя это нифига не анекдоты, лично мне предлагали магнитофон починить.

Причем тут какой-то психотип и стратегии, когда нам с порога заявляют, что разработчик ДОЛЖЕН не только разрабатывать, но и еще выполнять кучу функций?

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

Другое дело, что кому-то все эти "функции" ничего не стоят, а для кого-то вызывают раздражение и забирают время его основной работы. Вот поэтому я и говорю, что это зависит от психотипа. Вот лично вам, насколько я понимаю, это даётся тяжело и вызывает раздражение :) Значит, вам не подходит.

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


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


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


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


В общем, развиваться надо в разные стороны, и не потому, что так говорит 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" решили проблему. Ну, как могли. Ведь не падает же больше!

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

4GL?

Ну наконец-то хоть кто-то слово "инженер" произнес, а то я думал, что придётся самому.

Как всегда, расскажу историю из жизни..

Проверил почту - вижу, уведомление: заявка на создание отчёта. Начинаю думать - как лучше сделать. Вижу, что в одном месте можно трактовать двояко. Т.е. в зависимости от того, как считать - можно получить два результата. Задаю в заявке вопрос "а как надо". Мне перезванивают и говорят "а нам всё равно! делай "как быстрей", нам надо перед руководством отчитаться, что мы отчёт внедрили, тем самым производительность труда подняли..."

Вообще не согласен с примером про сено. Может просто хозяин (менеджер, продакт оунер и т.п.) просто не умеет ставить задачи, а Лукъян, который с ним проработал 10 лет, просто знает что он хочет, потому что он каждый день его просит в то время, как Демьян — ньюкамер?

А есть ли у Лукъяна право на принятие решения о выгрузке сена?

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

Если бы оба — и Демьян, и Лукъян поступили одинаково, то у хозяина было бы 2 мешка сена, а ему нужен один.

Какие рабочие обязанности Демьяну объявляли при найме? Бегать по вопросам или управлять имением? Вот приеду я в автосервис, а мне вместо замены масла еще и химчистку сделают, и счет за это выставят, буду ли я рад?

Ну и еще 1000 и 1 недостаток у вашей притчи, она служит очень плохой иллюстрацией реальных отношений начальник/подчиненный.

А уж особенно на энтерпрайз-проектах с 20-кой девелоперов в тиме чем меньше таких Лукъянов будет, тем лучше, а то день до релиза, Лукъян сделал git push origin develop с бесценным рефакторингом о котором его никто не просил, и не пойми когда делать регрессию и не ляжет ли прод.

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

Судя по тому что у Демьяна с Лукьяном гэп в зарплате в 7.5 раз хозяин тут вдвойне дурак )))

Почему?

Притча как притча. Другой вопрос, что она не очень хорошо раскрывает особенности именно разработки программ, но в рамках самой притчи все адекватно.

А есть ли у Лукъяна право на принятие решения о выгрузке сена?

Если хозяин его за это не прибил, значит такое право есть.

Если бы оба — и Демьян, и Лукъян поступили одинаково, то у хозяина было бы 2 мешка сена, а ему нужен один.

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

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

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

А уж особенно на энтерпрайз-проектах с 20-кой девелоперов в тиме чем меньше таких Лукъянов будет, тем лучше, а то день до релиза, Лукъян сделал git push origin develop с бесценным рефакторингом о котором его никто не просил, и не пойми когда делать регрессию и не ляжет ли прод.

В разных случаях нужны разработчики разных типов.

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

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

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

Основная обязанность разработчика — это решить проблему.

Полностью согласен.
Помимо этого, надо аккуратно вести список всех решённых проблем. Желательно с какими-то метриками по результатам. Чтобы потом, на Performance Review (не знаю, как это лучше по-русски написать), были основания для повышения зарплаты, получения должности и т.п.
Ну и разумеется, хорошо и правильно, когда решенные проблемы согласуются с планом личного развития разработчика. При условии, что такое вообще есть в компании.

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

Основная обязанность разработчика — это решить проблему.


И дьявол как всегда в деталях…

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

Я был свидетелем тому, что двум разработчикам дали волю и объявили их разработчиками-архитекторами с полномочиями, вплоть до выбора ПО для двух новых модулей. Разработчики и выбрали — то ПО, которое согласовалось с планом их личного развития…

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

Так и я видел подобное много раз и на самых разных уровнях. Это не слишком приятно, я согласен. Главное, чтобы это не происходило систематически. Да, сделали ошибку, поняли, поправили бизнес-процессы там или что-то другое, работаем дальше.
Бизнес, а в особенности High-Tech, сопряжен с огромными рисками. Никуда от этого, к сожалению не деться. Есть средства снижения рисков, но ситуация, как вы описали выше, всё равно может возникнуть.

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

Увы они стремительно замещаются "кодерами", "разрабами" и прочими современными it терминами.

Все просто. Обычно каждый айтишник считает что он разработчик, а кругом одни говнокодеры

Потому, что пока ты(я/мы) учился софт скиллам, углублял знания области, выяснял задачи бизнеса, анализировал конкурентов.. он писал код и учил алгоритмы, и теперь решает аналогичные задачи в 10 раз быстрее, код его эффективнее, и несколько разных мест работы дали хороший ап как по знаниям так и по ЗП.

В реальности всё несколько иначе.

...
Хозяин усмехнулся и повернулся к своему первому работнику:

--Видишь какой инициативный и компетентный Лукьян? А ведь я плачу ему на 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)

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

Ну а почему бы и не покошмарить в пределах разумного. Разве тимлид должен быть неприкасаемым авторитетом для нижестоящих? Так это противоречит посылу статьи. Может новенький окажется столь активным и способным в здоровой конкуренции так пусть шевелит бородачей ).

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

1) Нужен "конвейер" с дешевой рабочей силой, работающей строго по ТЗ, т.е. предсказуемо по срокам и качеству. Здесь нужны будут кодеры. Здесь всё должно быть предсказуемо, без неожиданностей, без субъективных факторов, без зависимости от конкретных работников.

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

Если не брать во внимание специфичные сферы деятельности (клепаем, например, сайты на движке по шаблону) — программирование имеет общее не с производством, а с научно-исследовательскими или опытно-конструкторскими работами. Причем, большая часть рутинной работы (там где надо было раньше стопятьсот конструкторов с кульманами для усердного черчения) уже автоматизирована. С этими допущениями, над каждым кодером работающим строго по ТЗ придется поставить архитектора/тимлида/whatever — который напишет ему на русском языке, что надо сделать. И опять же, с этими допущениями — если этот квалифицированный человек сразу будет писать на языке программирования — то это будет, вероятно, быстрее (язык программирования специально сделан для таких объяснений, в отличие от русского), качественнее (потому что голова и руки принадлежат одному человеку, а не разным), и дешевле (потому что минус один кодер).

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

Заменяем название должности "программист" на более абстрактное понятие "разработчик" и получаем тезис Основная обязанность разработчика — это решить проблему.

Если разработчик решает проблемы и задачи бизнеса, то почему он (зачастую) не получает свою долю прибыли?

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

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

На этот раз риторический вопрос, а кто выступает в роли "разработчик", бизнес или программист? Другими словами, кому принадлежат права на разработку?

Всё проще.


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


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

Сначала напридумывают всякой ерунды, обмажутся методологиями, скрамами да аджайлами, наберут менеджеров, которые, чтобы изобразить полезность напридумывают еще больше ерунды поверх, а потом удивляются, а почему вы не проявляете инициативу? А зачем мне её проявлять, когда в штате есть человек, который за это зарплату получает? В примере про двух работников на самом деле работник не к хозяину дома приходит с вопросом, а к менеджеру. И чья это была задача — сформулировать для него проблему таким образом, чтобы ему не пришлось двадцать раз бегать? Правильно, менеджера. Если я сам все сделаю за менеджера, то зачем нам такой менеджер нужен? Он же потом еще и обижаться будет, что я подрываю его авторитет и лезу вперед батьки в пекло, нарушая его менеджерские планы и аджайл-метрики.
На самом-то деле кодер — это такое логическое устройство. =)

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

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

а что такое "гуманитарный заменитель рационального мышления" в вашем понимании?

Дык я ж перечислил. Риторика, «критическая теория» и диалектика.

Все, чем марксисты махают.
Погуглил «критическую теорию».
it argues that social problems are influenced and created more by societal structures and cultural assumptions than by individual and psychological factors.
Как бы не вижу в этом тезисе ничего нерационального.
Это не тезис.

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

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

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

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

Я, наверное, неаккуратно сформулировал, но эти две противоборствующие силы именно что постулируются. В критической классовой теории aka марксизме силы делятся по марксовским классам, в критической расовой — по признаку «белый или миноритис», квир — по ориентации и самоидентификации, и так далее.

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

Если мне платят мою зарплату и ещё дополнительно и зарплату менеджера, то почему бы и нет? Особенно если работаю я и дальше свои условные 40 часов, а не 80 :)

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

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

Хозяин усмехнулся и повернулся к своему первому работнику:...

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

Возникает закономерный вопрос, а нужен ли решающему проблемы разработчику вообще «барин»?

Не нужен, если он готов ещё и бегать за этими клиентами, уговаривая заключить с ним контракт.

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

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


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


По кряней мере у нас это выглядит именно так.

Самое забавное, что баре сами редко такими вопросами занимались. Большая их часть ничего вообще в хозяйстве не смыслила и хозяйством занимались управляющие (помните Обломова и его друга Штольца?). А так сказка хорошая… прям как про Генри Форда
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.