Comments 113
Лифт есть мощное средство передвижения, это первое. А также средство транспорта. Лифт должен быть как самосвал: приехал, вывалил и обратно. Это во-первых. Администрации давно известно, что многие товарищи ученые, в том числе отдельные академики, лифтом эксплуатировать не умеют. С этим мы боремся, это мы прекращаем. Экзамен на право вождения лифта, невзирая на прошлые заслуги… учреждение звания отличного лифтовода… и так далее. Это во-вторых. Но монтеры со своей стороны должны обеспечить бесперебойность. Нечего, понимаете, ссылаться на объективные обстоятельства. У нас лозунг: лифт для всех. Не взирая на лица. Лифт должен выдерживать прямое попадание в кабину самого необученного академика...
Усложним задачу, представим что ваша деятельность не финансируется или финансируется недостаточно, а вокруг кадровый вакуум, после чего я с радостью померяюсь яйцами с автором статьи. «По возможности избегайте проектов с хромой бизнес-частью» слишком красивый совет.
А так я полностью согласен, что, конечно, какую-ту часть разработки можно строить на студентах, всегда есть потребность в одноразовом инструментарии, перегонке данных и подобных работах, но пониманию того, как их действия и решения связаны с проблемами в будущем, просто не успевают образоваться. Как и понимание того, что говнокод не приемлем, нигде, никогда, ни в каком случае, и всегда говорит об его авторе самое плохое, что только можно сказать о кодере. Даже если он выражается в том, что человек «сэкономил» на конвенциях оформления.
Вопрос к переводчику, зачем вместо слова «оценки» было использовано «истимейты», в словаре не нашлось перевода?
А так я полностью согласен, что, конечно, какую-ту часть разработки можно строить на студентах, всегда есть потребность в одноразовом инструментарии, перегонке данных и подобных работах, но пониманию того, как их действия и решения связаны с проблемами в будущем, просто не успевают образоваться. Как и понимание того, что говнокод не приемлем, нигде, никогда, ни в каком случае, и всегда говорит об его авторе самое плохое, что только можно сказать о кодере. Даже если он выражается в том, что человек «сэкономил» на конвенциях оформления.
Вопрос к переводчику, зачем вместо слова «оценки» было использовано «истимейты», в словаре не нашлось перевода?
Спасибо за перевод.
Это сжатый пересказ его же книги The Clean Coder.
www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
Достойная книга. Надеюсь, что будет всё больше людей, которые её прочитают и осознают.
Это сжатый пересказ его же книги The Clean Coder.
www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
Достойная книга. Надеюсь, что будет всё больше людей, которые её прочитают и осознают.
Если вы о том, что она изменит мир — то, сомневаюсь. К сожалению, и книга, и статья говорит о частном случае, предлагая бороться с посредственностью (в работе, в учебе, в жизни — в данном случае, в области разработки ПО). Но не освещает корневые проблемы, и не предлагает методов их решения.
Отлично, если человек захочет работать лучше. Но текущая система мироустройства, пораждающая кризисы, надувающая финансовые пузыри, стимулирующая замену квалифицированной рабочей силы малооплачиваемой (аутсорсинг, привлечение мигрантов, экономия на обучении и развитии), итд итп, используя такие инструменты, как урезание бюджетов, нехватка квалифицированной рабочей силы, внешние факторы — быстро восстановит (дис)баланс.
Да, посредственность, и наплевательское отношение к работе — в любой области — это ужасно. И в масштабе страны может привести к инфраструктурным катастрофам. Но одними стимулирующими речами вроде данной статьи их не устранить.
Отлично, если человек захочет работать лучше. Но текущая система мироустройства, пораждающая кризисы, надувающая финансовые пузыри, стимулирующая замену квалифицированной рабочей силы малооплачиваемой (аутсорсинг, привлечение мигрантов, экономия на обучении и развитии), итд итп, используя такие инструменты, как урезание бюджетов, нехватка квалифицированной рабочей силы, внешние факторы — быстро восстановит (дис)баланс.
Да, посредственность, и наплевательское отношение к работе — в любой области — это ужасно. И в масштабе страны может привести к инфраструктурным катастрофам. Но одними стимулирующими речами вроде данной статьи их не устранить.
Мы принадлежим к поколению, которому выпало переживать и бояться не фантомов и эгоистических мелочей вроде воспетого ранним Маяковским гвоздя в сапоге, а действительно колоссальных катаклизмов, которые изменят облик не только наших стран и народов, но и всего человечества.
Прежде чем изменить мир — постарайтесь изменить себя. Я тоже верил, что «щас заговнокодим» — лучший подход, если нет времени/денег. Как оказалось — если сразу писать хорошо — то работа идёт быстрее. Если «драйвиться» тестами — то не делаешь кучи лишнего (и не забываешь о действительно нужном) — и как результат работа идёт быстрее.
Да, эта книга не именит мир. Да, она не сделает толпы джунов профессионалами. Но если следовать изложенным там советам — вашей компании будет чуть лучше житься
Да, эта книга не именит мир. Да, она не сделает толпы джунов профессионалами. Но если следовать изложенным там советам — вашей компании будет чуть лучше житься
>Представьте что мы все временно перенеслись в параллельную вселенную
>Так вот мой вопрос: сколько раз на дню вы вверяете свою жизнь if-у, который написал 22х летний кодер в 3 утра?
Попробую угадать, как человек живущий в этой вселенной и за МКАДом: ноль?
>Так вот мой вопрос: сколько раз на дню вы вверяете свою жизнь if-у, который написал 22х летний кодер в 3 утра?
Попробую угадать, как человек живущий в этой вселенной и за МКАДом: ноль?
В Вашем замкадье тундра?
Как человек же живущий за МКАДом задам встречный вопрос: а что, энергия к нам просто так подвозится? Газ, опять же. Не говоря уж про светофоры, школы и больницы… Можно ещё вспомнить ракеты, что нацелены на весь земной шар. Спутники. Да, это жизненно важные области, и писал их не 22х летний кодер в 3 утра, а 27 летний в 2. Сильно легче? Даже в одной из вымирающих деревень, в которой я был (ни школы, ни дорог, ни магазина, никакой инфраструктуры почти) электричество подведено. Спутниковые тарелки стоят. Уверен, что и интернет там есть (раньше-то деревня жила, следовательно «лапша» должны остаться). Так что я думаю даже самые коренные жители Африки так или иначе зависят от if'ов. Вопрос в плотности.
Я думаю что это весьма идеалистическая точка зрения, не имеющая возможности существовать в реальности. Достаточно вспмомнить о дилеме выбора Быстро — Качественно — Дешево и то, что только у двух кругов могут быть пересечения. Либо дорогая команда супер-профи ( что почти не встречается в коммерческой разработке ПО ), либо страдает качество или сроки. И обычно страдает качество, потому что продукт без применения в бизнесе не имеет смысла если он вышел позже конкурентов. Здравых мыслей у него много конечно, но в реальности все вместе маловероятно (
Для угоды всем, мы часто используем некое подобие MVP — если планируем запустить N фитч, но не успеваем, то выкатываем, скажем, N-2, но вполне стабильных, остеивая малоприоритетные. Бизнес не очень страдает (результат все-таки есть) и пользователи рады, потому-что не были в курсе планов.
В некоторых проектах такой подход не подойдет, увы. Например в программировании каких-нибудь железяк, которые потом нереально перепрошить. Или в гос.заказах, в которых перед началом разработки утверждается список фич, и выкинуть нечто просто нереально — без единой закрытой фичи денег за проект не получишь ни копейки.
Любая из данных оценок носит субъективный характер.
У меня есть некий проект, я, как заказчик оценил его бюджет в 100.000 $, качество для меня — чтобы система работала и выполняла свои фунции с заранее обговоренной степенью отказа от обслуживания (допустим 99.9%). Сроки я поставил в 2 месяца. Прихожу к одному разработчику и прошу его предложить срок объявляя только первые два параметра (бюджет и качество), он заявляет, что он с командой из 2 человек завершит этот проект за год. Второй разработчик примерно такой же квалификации заявляет, он не сможет обеспечить подобное качество никогда, третий объявляет что его сроки — 2 месяца. Чудо? Мы получили бюджет-качество-сроки именно те, которые хотели?
Для понимания — пример взял из личной жизни, старт пилота 01.06.
У меня есть некий проект, я, как заказчик оценил его бюджет в 100.000 $, качество для меня — чтобы система работала и выполняла свои фунции с заранее обговоренной степенью отказа от обслуживания (допустим 99.9%). Сроки я поставил в 2 месяца. Прихожу к одному разработчику и прошу его предложить срок объявляя только первые два параметра (бюджет и качество), он заявляет, что он с командой из 2 человек завершит этот проект за год. Второй разработчик примерно такой же квалификации заявляет, он не сможет обеспечить подобное качество никогда, третий объявляет что его сроки — 2 месяца. Чудо? Мы получили бюджет-качество-сроки именно те, которые хотели?
Для понимания — пример взял из личной жизни, старт пилота 01.06.
Вы получили бюджет-качество-сроки лишь в том случае, если всё будет именно так, как вам сказали изначально. А не то, что сначала вам называют, скажем, сроки в два месяца, а через месяц говорят «ой, вы знаете, я тут недооценил сложность проекта, мне нужно ещё полгода и лимон баксов».
Исполнитель — заинтересованная сторона, его оценки по срокам и бюджетам часто бывают излишне оптимистичны — ведь ему нужно получить этот проект. Поэтому единственный расклад, при котором данные вам обещания реально чего-то стоят — когда они зафиксированы на бумаге вместе с санкциями за их нарушение. Соответственно, для этого исполнитель должен быть кем-то, с кого при случае можно будет эту компенсацию взыскать. Команда же из трёх человек может потенциально просто слиться — и дальше всё будет зависеть от вашего умения договариваться с нашими судами.
Исполнитель — заинтересованная сторона, его оценки по срокам и бюджетам часто бывают излишне оптимистичны — ведь ему нужно получить этот проект. Поэтому единственный расклад, при котором данные вам обещания реально чего-то стоят — когда они зафиксированы на бумаге вместе с санкциями за их нарушение. Соответственно, для этого исполнитель должен быть кем-то, с кого при случае можно будет эту компенсацию взыскать. Команда же из трёх человек может потенциально просто слиться — и дальше всё будет зависеть от вашего умения договариваться с нашими судами.
Возможно, я чего-то не понял, но… На мой взгляд, подобный манифест должен быть прозрачным для команды (я имею, что команду нужно подталкивать и наставлять к тому, чтобы каждый её участник самостоятельно пришел к выводам, написанным выше, вместо декларирования этих выводов перед лицом команды в формате ожиданий), иначе это походит на слова человека, функция которого сводиться лишь к объявлению планки качества и применению дисциплинарных мер за её превышение, что уже дает подрыв авторитета и есть шагом к Fear-driven Development.
Я знаю, с оценки по времени всегда проблемы. Это такие штуки которые кладут на вас ответственность.
Кстати, по тексту часто встречается дистанцирование от команды. Например, в данном случае, проблемы с оценкой времени — это всегда вина руководителя, как и большинство остальных проблем отдела, поскольку их решение находится в кругу ответственности руководителя, следовательно, наличие проблем в отделе — недоработка именно руководителя. В таком положении дистанцирование от команды сродни переводу стрелок на них.
Когда на вас начнут давить вопросами в стиле «А можно как-нибудь быстрее?» я ожидаю услышать «Нет».Во-первых, не следует допускать разработчиков к общению с другими отделами в формате планирования без личного участия. Подобные вопросы должны быть адресованы руководителю. Во-вторых, практически всегда «можно быстрее», доходчиво объяснив менеджерам — или работа занимает столько времени, сколько было озвученно, или упрощается исходная задача — при наличии ряда свойств проекта (проект уже в возрасте, основа дохода — реклама, и т.п.), этот выход часто является единственным способом заработать деньги. Доводилось сталкиваться с несколькими руководителями, которые не предлагали варианты, услышав подобные требования по ускорению. Закономерно — их всех уволили или сняли с должности по одной и той же причине — рецедив срыва сроков по крупным заказам.
проблемы с оценкой времени — это всегда вина руководителя
Здесь имеется в виду впринципе оценка, и то что разработчики иногда боятся её давать, потому что потом придётся к ней успевать, а это накладывает ответственность и стресс.
Умножать сроки на три, понятно, задача менеджмента и правильности сроков от разработчиков никто не требует. Просто чтобы хоть какие-то цифры были
Так будет через 30 лет. Пока что спрос гораздо выше предложения, а технологии меняются слишком быстро, чтобы ответственность стала критерием №1 при наборе программистов.
Боюсь, так не будет еще очень долго. Мой любимый пример: строительство (домов, дорог и т.п.) — там за тыщи лет мало что изменилось.
Когда на вашей памяти в вашем городе падал новострой?
Думаю, ежедневно где-то падает новострой. У кого кубики рассыпаются, у кого дачный сортир падает, у кого еще что.
А вы чего спросить-то хотели?
А вы чего спросить-то хотели?
Я тоже не совсем понял, к чему вы это спросили, но на всякий случай поделюсь показательным примером: в 2009-м году в Шанхае рухнула новостройка.
Таки меньше года назад в Караганде рухнула новостойка, а заодно снесли весь жилой комплекс, потому что другие дома оказались тоже не ахти, в родном Петропавловске сносят еще не сданную 9-этажку. Так что падают, еще как.
Может ради интереса стоит сходить на строй площадку? У меня вон под окном несколько — чтот я сомневаюсь, что тысячи лет назад использовали подобные технологии. И да, недавно я переехал из хрущевки в новострой — знаете, за 50-60 лет изменилось ОЧЕНЬ многое.
Если разговор об ответственности — посмотрите, за что могут посадить строителей, и за что могут посадить программиста. Думаю вопрос отпадёт сразу.
P.S. В российской империи, инженер, проектировавший мост, перед первым пуском поезда должен был стоять под мостом. Вы когда-нибудь видели подобный уровень ответственности в программировании?
Если разговор об ответственности — посмотрите, за что могут посадить строителей, и за что могут посадить программиста. Думаю вопрос отпадёт сразу.
P.S. В российской империи, инженер, проектировавший мост, перед первым пуском поезда должен был стоять под мостом. Вы когда-нибудь видели подобный уровень ответственности в программировании?
Традиционный вопрос. Вы хотите купить себе мега-супер смартфон.
Варианты:
1. Безопасный, быстрый, с приложениями, которые никогда не сбоят. Срок появления — 2049 год
2. Большей частью безопасный, местами подтормаживающий, приложения изредка падают. Срок появления — 2022 год.
3. Кое-как безопасный, весьма задумвчивый иногда, приложения падают иногда. Срок появления — завтра.
4. Дырявое ведро, с которым опасно появляться в интернете, всегда тормозит, приложения падают раз пол-часа, а раз в день он виснет наглухо и его нужно перезагружать. Ещё он путает номера в телефонной книге и может пропускать звонки. Срок появления — уже доступен.
А дальше вы понимаете, что победителем в этом конкурсе будет №3. Хотя №4 тоже хапнет кусок рынка, но быстро сдуется (на следующий день). Номер два будет иметь своих фанатов, но не получит большой доли рынка. Номер один будет снят с произодства в 2048 году.
Варианты:
1. Безопасный, быстрый, с приложениями, которые никогда не сбоят. Срок появления — 2049 год
2. Большей частью безопасный, местами подтормаживающий, приложения изредка падают. Срок появления — 2022 год.
3. Кое-как безопасный, весьма задумвчивый иногда, приложения падают иногда. Срок появления — завтра.
4. Дырявое ведро, с которым опасно появляться в интернете, всегда тормозит, приложения падают раз пол-часа, а раз в день он виснет наглухо и его нужно перезагружать. Ещё он путает номера в телефонной книге и может пропускать звонки. Срок появления — уже доступен.
А дальше вы понимаете, что победителем в этом конкурсе будет №3. Хотя №4 тоже хапнет кусок рынка, но быстро сдуется (на следующий день). Номер два будет иметь своих фанатов, но не получит большой доли рынка. Номер один будет снят с произодства в 2048 году.
Товарищ неадекватен в своих экстремальных суждениях и несдерживаемой агрессии, такого CTO я бы точно не хотел.
Ваш босс приходит и говорит «Мне это надо к четвергу. Делай что хочешь, но мне это нужно к четвергу».
Знаете что надо делать в такой ситуации? Надо сесть и написать самый лучший код который можете.
И если вы верите что написание хорошего кода поможет вам разрабатывать быстрее — в аврале вы будете писать его ещё лучше. Если вы верите что тесты ускоряют разработку — в аврал вы будете писать их ещё больше.
Это он серьезно?
И при этом «Говорите нет» и «Если вы называете дату — вы врёте, вы не можете успеть к этой дате, она слишком точна. Я хочу услышать диапазон. ».
Т.е., если начальник выдаёт срок — вы обязаны к нему успеть.
Если вы выдаете срок — вы лжете.
Вы обязаны уметь говорить нет.
И параллельно всегда успевать к названной другими дате «без отговорок».
Прям какой то набор лозунгов. Пятилетку в три года…
Или не лозунгов даже. А скорее «светлое будущее, к которому мы обязаны стремиться», но которое на 100% не достижимо.
Т.е., если начальник выдаёт срок — вы обязаны к нему успеть.
Если вы выдаете срок — вы лжете.
Вы обязаны уметь говорить нет.
И параллельно всегда успевать к названной другими дате «без отговорок».
Прям какой то набор лозунгов. Пятилетку в три года…
Или не лозунгов даже. А скорее «светлое будущее, к которому мы обязаны стремиться», но которое на 100% не достижимо.
Вы как-то умудрились смешать не очень связанные вещи.
Первая о том, что в любой ситуации нужно писать хорошо сразу, а не сооружать набор костылей с расчётом, что потом всё можно будет поправить. «Потом» обычно не наступает, потому что за одним авралом сразу идёт следующий. И когда на пятом ваши костыли развалятся, может оказаться уже неважно, что первые четыре вы успели в срок.
Вторая об оценке сроков. Если вы знаете, что не успеете, не надо внушать людям оптимизм. Даже если они этого хотят. Даже если требуют. Вы уже знаете, что не успеете. Они могут узнать об этом сейчас (и, возможно, найти выход) или в последний момент. Не оттягивайте, говорите сразу.
Про дату сюда же. Вы не можете гарантировать то, чего не знаете. Например, «с 80-процентной вероятностью я сделаю это за 5 дней». Тут можно либо сказать «сделаю за 5 дней», либо (если начальник адекватен — автор себя представляет именно таким) сказать «сделаю за 4—6 дней», либо (если не очень) сказать «сделаю за 6 дней» и настаивать на этом сроке.
Первая о том, что в любой ситуации нужно писать хорошо сразу, а не сооружать набор костылей с расчётом, что потом всё можно будет поправить. «Потом» обычно не наступает, потому что за одним авралом сразу идёт следующий. И когда на пятом ваши костыли развалятся, может оказаться уже неважно, что первые четыре вы успели в срок.
Вторая об оценке сроков. Если вы знаете, что не успеете, не надо внушать людям оптимизм. Даже если они этого хотят. Даже если требуют. Вы уже знаете, что не успеете. Они могут узнать об этом сейчас (и, возможно, найти выход) или в последний момент. Не оттягивайте, говорите сразу.
Про дату сюда же. Вы не можете гарантировать то, чего не знаете. Например, «с 80-процентной вероятностью я сделаю это за 5 дней». Тут можно либо сказать «сделаю за 5 дней», либо (если начальник адекватен — автор себя представляет именно таким) сказать «сделаю за 4—6 дней», либо (если не очень) сказать «сделаю за 6 дней» и настаивать на этом сроке.
Разве первый пункт об этом? Вам дали ограниченный срок. Вы не должны говорить, что не успеете за этот срок покрыть тестами код или там ещё что-то, нет, вы обязаны в этот срок успеть, причем с идеальным качеством, никаких костылей. Не должны спорить. Но одновременно, если таки вам дали возможность влиять на срок — сообщать о том, что этот нереально. Как это? Как мне узнать, угадать, что от меня сейчас требуется? А вот у автора я должен одновременно не спорить о сроках и уметь говорить «нет».
Про «не должны говорить» вы же сами придумали. Вот приходит к вам шеф и сообщает, что к нам завалились злые люди, и если мы не запилим фичу к понедельнику, нас каждый день будут штрафовать на миллион. В этот момент ему глубоко плевать на все ваши «нет, успеть невозможно», и он даже готов оплачивать все переработки в десятикратном размере. Вы можете ему сказать, что шансов нет, он будет про это знать. Но после вы всё равно сядете и постараетесь успеть к понедельнику.
Так вот, даже в этом случае не надо говнокодить. Нужно делать так же хорошо, как обычно, а то и лучше. Первый пункт об этом.
PS: Не утверждаю, что автор прав. Я лишь к тому, что тут нет логических противоречий.
Так вот, даже в этом случае не надо говнокодить. Нужно делать так же хорошо, как обычно, а то и лучше. Первый пункт об этом.
PS: Не утверждаю, что автор прав. Я лишь к тому, что тут нет логических противоречий.
Ускорение всегда достигается за счет чего-то другого. Обычно это качество кода. А в вашем случае что?
Концентрация усилий именно на «злом» проекте (в ущерб другим), переработка, стимуляторы, отказ от перекуров и/или кофе-бриков и т. п. Вообще в стрессовом состоянии организм вообще, и мозг в частности способен на большее, чем в обычном, но долго такого режима не выдержит. Ну и стресс стрессу рознь, конечно.
Когда спрашивают — нужно говорить «нет», а когда ставят перед фактом «нужно вчера» — нужно просто брать и делать, но так жк качественно как обычно.
Вот мне тоже интересно насчет тестов. Разве тесты просто «ускоряют разработку», а не «ускоряют разработку послезавтра»?
В целом интересно, но перевод получился уж слишком академичный. Явно слова подобраны качественно но по смыслу построения фраз получается «моя идти бить восьмилапых». Текст очень напомнил результат работы гугл-транслейта.
Пара примеров из статьи:
Это такие штуки которые кладут на вас ответственность.
Я жду что ничего не будет хрупким. Я устал слушать о таких частях системы.
С таким переводом смысл остался за кадром, проще прочесть в оригинале чем ломать голову.
Пара примеров из статьи:
Это такие штуки которые кладут на вас ответственность.
Я жду что ничего не будет хрупким. Я устал слушать о таких частях системы.
С таким переводом смысл остался за кадром, проще прочесть в оригинале чем ломать голову.
Есть одна область программирования, которую прекрасный Uncle Bob успешно игнорирует — прототипирование. Там нужны именно ручные тесты, качество и производительность кода не имеет особого значения, тогда как сроки крайне важны. Это может быть стартап, выпускающий новый продукт, или эксперименты у крупного веб-продукта на небольшой аудитории.
Отказ от прототипирования — заведомо показатель некомпетентного технического руководителя. Другой вопрос, что в случае успеха прототип должен быть допилен до адекватного состояния, что, к сожалению, делается далеко не всегда, и это уже прямая вина технического руководства.
Отказ от прототипирования — заведомо показатель некомпетентного технического руководителя. Другой вопрос, что в случае успеха прототип должен быть допилен до адекватного состояния, что, к сожалению, делается далеко не всегда, и это уже прямая вина технического руководства.
Технический директор должен не «ожидать» а выстраивать процесс так, чтобы он работал в соответствии с требованиями.
Вместо того, чтобы ожидать, что качество кода будет на должном уровне нужно выстроить процесс code review, ввести парное программирование и пр…
Вместо того, чтобы ожидать, что продукт может быть задеплоен по первому требованию, нужно выстроить процесс разработки соотвествующим образом ( постоянная автоматическая интеграция, тесты и пр… )
Вместо ожидания стабильной производительности нужно разобраться что приводит к замедлению работы комманды. Выделить время на рефакторинг.
В целом складывается впечатление, что автор не желает принимать на себя отвественность и не понимает, что от него, как от технического директора, руководство компании в первую очередь ожидает, что он грамотно выстроит процессы, а не будет сидеть и ожидать от подчиненных, что они самостоятельно самоорганизуются в соотвествии с его хотелками.
Вместо того, чтобы ожидать, что качество кода будет на должном уровне нужно выстроить процесс code review, ввести парное программирование и пр…
Вместо того, чтобы ожидать, что продукт может быть задеплоен по первому требованию, нужно выстроить процесс разработки соотвествующим образом ( постоянная автоматическая интеграция, тесты и пр… )
Вместо ожидания стабильной производительности нужно разобраться что приводит к замедлению работы комманды. Выделить время на рефакторинг.
В целом складывается впечатление, что автор не желает принимать на себя отвественность и не понимает, что от него, как от технического директора, руководство компании в первую очередь ожидает, что он грамотно выстроит процессы, а не будет сидеть и ожидать от подчиненных, что они самостоятельно самоорганизуются в соотвествии с его хотелками.
Чувствуется советский подход: «зачем спрашивать подчинённых, когда я лучше знаю, что нужно делать». Задача руководства, в первую очередь,— определиться с требованиями, следить за их исполнением и корректировать, где это требуется. И вы не поверите, если конкретное решение разделяют исполнители (потому что они участвовали в принятии решения) — оно внедряется куда эффективнее и с гораздо большим энтузиазмом.
Именно в ответ на таких «менеджеров» и «руководителей» появляются движения типа такого:
programming-motherfucker.com
Именно в ответ на таких «менеджеров» и «руководителей» появляются движения типа такого:
programming-motherfucker.com
Полностью с Вами согласен. Собственно это я и имел в виду, «определиться с требованиями, следить за их исполнением и корректировать, где это требуется» это и есть создать технологический процесс производства сотфа.
Требования — в посте. Вы предложили методы решения соответствующих требований. Создавать технологических процесс действительно необходимо, просто хоть сколько-то квалифицированные программисты и их непосредственных технический менеджмент и сами хорошо понимают, как _лучше_ в конкретном случае решать соответствующие требования, и почему эти общие требования важны и удобны. Именно поэтому тех.диру может быть достаточно просто сформулировать требования и вместе с техническим персоналом выбрать оптимальное решение, которое внедрять уже совместными усилиями, а не личной волей тех.дира, который лучше подчинённых знает, как они должны работать.
Извините, просто наелся такого неквалифицированного менеджмента с завышенным самомнением и непониманием принципов совместной работы.
Извините, просто наелся такого неквалифицированного менеджмента с завышенным самомнением и непониманием принципов совместной работы.
UFO just landed and posted this here
Хотеть не вредно…
Требования хорошие и даже правильные.
А я хочу квартиру.
За три рубля возле кремля.
А я хочу квартиру.
За три рубля возле кремля.
Напоминает напутствие молодому строителю коммунизма. Такое впечатления что вот сидят все и думают: «Так, мне сегодня работать хорошо или плохо? А, что Вы говорите, надо хорошо? Ох, ну спасибо, помогли определиться. Так и сделаю, пожалуй!».
Вижу в комментариях много негатива в адрес сути статьи… Странно. На самом деле, статья во многом отражает и мою точку зрения. Многие из фраз я чуть ли не дословно использовал в недавних спорах с коллегами. Очень многие из этих мыслей уже давно крутятся в моей голове.
Многие почему-то ждут, что начальство решит, что нужно использовать модульные тесты. Алло, кто здесь инженеры? Кто должен знать, как лучше разрабатывать софт? Кто должен автоматизировать свою работу? Кто должен выбирать себе подходящие инструменты или создавать новые по необходимости?
Отговорки «мы пишем грязно и быстро (а быстро ли?), потому что нам дали мало времени» меня просто убивают. Я ведь сам был на митингах, руководство спрашивает разработчиков, сколько им нужно времени! Оставляйте себе время на диагностику, лечение будет стоить существенно дороже. Самое ужасное, что этот криво написанный код годами используется как основа, новый пишется в том же стиле, и через небольшое время уже никто не хочет что-либо менять.
Программистам давно пора оглянуться вокруг. Посмотреть на результаты работы инженеров, архитекторов, врачей. Вам приятно было бы ездить на машине, которая потребляет двести литров бензина на 100км и у которой иногда отваливаются колёса? А жить в здании, которое рушится каждый месяц? А может, после операции по удалению аппендицита недосчитаться руки? Так почему ничто меня нынче так не удивляет, как корректно работающая программа? Нам всем пора стать более ответственными за результат своего труда.
Можно возразить, что не важно, как написана программа, пока она работает. А вам хотелось бы видеть под капотом вашего автомобиля груду кривого хлама, непонятно как работающего (для многих, возмножно, оно так и выглядит, но на самом деле это не так)?
Многие почему-то ждут, что начальство решит, что нужно использовать модульные тесты. Алло, кто здесь инженеры? Кто должен знать, как лучше разрабатывать софт? Кто должен автоматизировать свою работу? Кто должен выбирать себе подходящие инструменты или создавать новые по необходимости?
Отговорки «мы пишем грязно и быстро (а быстро ли?), потому что нам дали мало времени» меня просто убивают. Я ведь сам был на митингах, руководство спрашивает разработчиков, сколько им нужно времени! Оставляйте себе время на диагностику, лечение будет стоить существенно дороже. Самое ужасное, что этот криво написанный код годами используется как основа, новый пишется в том же стиле, и через небольшое время уже никто не хочет что-либо менять.
Программистам давно пора оглянуться вокруг. Посмотреть на результаты работы инженеров, архитекторов, врачей. Вам приятно было бы ездить на машине, которая потребляет двести литров бензина на 100км и у которой иногда отваливаются колёса? А жить в здании, которое рушится каждый месяц? А может, после операции по удалению аппендицита недосчитаться руки? Так почему ничто меня нынче так не удивляет, как корректно работающая программа? Нам всем пора стать более ответственными за результат своего труда.
Можно возразить, что не важно, как написана программа, пока она работает. А вам хотелось бы видеть под капотом вашего автомобиля груду кривого хлама, непонятно как работающего (для многих, возмножно, оно так и выглядит, но на самом деле это не так)?
Погодите. Вы хотите сказать, что ни единого проекта не делается по принципу «так ребята, сколько вам нужно времени? С учетом того, что релиз должен быть 13 сентября, и ни секундой позже, иначе мы опоздаем. Нет, новых людей мы нанимать не будем, или будем, но в середине проекта, когда сам их ввод затормозит процесс».
Дома по такому принципу не строятся. И не лечат по такому принципу. И автомобили не выходят на рынок. А вот софт пишется, причем не редко, мягко говоря. Кто то себе может позволить тратить именно столько времени, сколько нужно (Blizzard например Warcraft 3 делала реально годами, да не только она и не только их. Но и у них бывают косяки.).
Далее, к домам не бывает требований «а давайте перестроим дом в речной параходик». А к софту бывает. И даже по принципу «если ваша фирма не перепишет, другая перепишет, вы просто не профессионалы, раз не можете дом превратить в космический корабль за 3 копейки и 2 месяца.» И ведь находятся те, кто перестраивают. Правда, летят такие коробки не далеко и «низенько-низенько», но это уже иной вопрос.
Так что я, как программист — за изменения к лучшему. И как «заповеди правильной разработки» это тоже верно. И надо к этому стремиться, это факт. И придем мы к нормальному, инженерному подходу в разработке рано или поздно. Более того, кое кто так и работает. Но всегда, всегда будут области где написать «грязно и быстро, а выйдя на рынок и захватив долю — переписать» будет нужнее, более эффективной стратегией, чем «потратить денег на профессионалов, сделать всё качественно, выйти позже других и отбить у них аудиторию».
Короче, все советы в полном объёме удастся наверняка выполнять, но не в любой ситуации. А автор, как лично мне кажется, отталкивает подходом «лучше не выходит на рынок вообще, чем выходить с посредственным продуктом» — по крайней мере, для меня его лозунги выглядят именно так.
Дома по такому принципу не строятся. И не лечат по такому принципу. И автомобили не выходят на рынок. А вот софт пишется, причем не редко, мягко говоря. Кто то себе может позволить тратить именно столько времени, сколько нужно (Blizzard например Warcraft 3 делала реально годами, да не только она и не только их. Но и у них бывают косяки.).
Далее, к домам не бывает требований «а давайте перестроим дом в речной параходик». А к софту бывает. И даже по принципу «если ваша фирма не перепишет, другая перепишет, вы просто не профессионалы, раз не можете дом превратить в космический корабль за 3 копейки и 2 месяца.» И ведь находятся те, кто перестраивают. Правда, летят такие коробки не далеко и «низенько-низенько», но это уже иной вопрос.
Так что я, как программист — за изменения к лучшему. И как «заповеди правильной разработки» это тоже верно. И надо к этому стремиться, это факт. И придем мы к нормальному, инженерному подходу в разработке рано или поздно. Более того, кое кто так и работает. Но всегда, всегда будут области где написать «грязно и быстро, а выйдя на рынок и захватив долю — переписать» будет нужнее, более эффективной стратегией, чем «потратить денег на профессионалов, сделать всё качественно, выйти позже других и отбить у них аудиторию».
Короче, все советы в полном объёме удастся наверняка выполнять, но не в любой ситуации. А автор, как лично мне кажется, отталкивает подходом «лучше не выходит на рынок вообще, чем выходить с посредственным продуктом» — по крайней мере, для меня его лозунги выглядят именно так.
что ни единого проекта не делается по принципуДелается, разумеется. Но далеко не всегда. Но не всегда. Просто глупо самому назначать сроки, а потом самому жаловаться, что тебе не хватило времени сделать нормально.
Как инженер и просто образованный человек я понимаю, что абсолютных истин не бывает. Но это то, к чему мы должны стремиться.
Да, автор не упомянул о прототипах. К счастью, прототипы люди пишут на выброс: они либо заменяются качественным кодом, либо просто выбрасываются, т.к. фокус не удался.
Дома по такому принципу не строятся. И не лечат по такому принципу. И автомобили не выходят на рынок. А вот софт пишется, причем не редко, мягко говоря. Кто то себе может позволить тратить именно столько времени, сколько нужно…
Далее, к домам не бывает требований «а давайте перестроим дом в речной параходик». А к софту бывает.
Это неверные представления о порядке вещей, которые как раз и поддерживаются рассказами о «22-летних кодерах, пишущих в 3 часа ночи».
Пока архитектор проектирует, заказчик может менять свои представления о том, чего он хочет, и вбрасывать все новые и новые задачи. Готовые дома иногда перестраиваются, и даже дворцовые комплексы эта чаша не минует. То же самое — с любыми техническоми разработками. Не надо только путать процессы инженерного проектирование и конвейерной сборки.
Софтостроение «к нормальному, инженерному подходу в разработке» пришло уже давно. 22-летние кодеры писали по ночам 15-20 лет назад, а сейчас им по 40 и более, большой багаж опыта за плечами и за важные вещи отвечают именно они, а не вчерашние студенты.
И никто серьезные проекты за пару месяцев не делает, потому что серьезные проекты не финансируются без серьезного планирования.
Насчет «релиза к 13 сентября» — ну, так в колхозе председатель тоже может потребовать от механика, чтоб взял две раздолбанные сеялки и собрал из них одну работающую к посевной… Не надо только думать, что это — норма, и что весь мир так работает.
UFO just landed and posted this here
Вы видели аналитиков, из-за нерадивой работы которых падают системы? А может, дизайнеров, из-за которых некорректно обрабатываются финансовые транзакции? Или, быть может, технические писатели мешают расширяемости вашей системы?
На моей практике 99% ошибок допускают именно те люди, которые занимаются реализацией логики системы. Думаю, эта работа одна из самых сложных и ответственных, и именно на таких людей ориентирована эта статья. А архитекторы, к счастью, обычно опытные люди, вышедшие из рядовых программистов, их ошибки редки, обходятся довольно дорого, и выявляются обычно ещё на этапе реализации. По поводу команды сборки… Я довольно редко встречаю людей, которые занимаются только этим. Обычно за сборки отвечают несколько разработчиков по совместительству. В особо крупных проектах, в которых я работал, за это отвечал один человек на продукт, работающий на полную ставку. С его стороны осечек не было практически никогда.
Да, слово «программист» мне тоже не очень нравится, а уж слово «кодер» вызывает у меня изжогу. Я предпочитаю «software engineer» или просто «инженер».
На моей практике 99% ошибок допускают именно те люди, которые занимаются реализацией логики системы. Думаю, эта работа одна из самых сложных и ответственных, и именно на таких людей ориентирована эта статья. А архитекторы, к счастью, обычно опытные люди, вышедшие из рядовых программистов, их ошибки редки, обходятся довольно дорого, и выявляются обычно ещё на этапе реализации. По поводу команды сборки… Я довольно редко встречаю людей, которые занимаются только этим. Обычно за сборки отвечают несколько разработчиков по совместительству. В особо крупных проектах, в которых я работал, за это отвечал один человек на продукт, работающий на полную ставку. С его стороны осечек не было практически никогда.
Да, слово «программист» мне тоже не очень нравится, а уж слово «кодер» вызывает у меня изжогу. Я предпочитаю «software engineer» или просто «инженер».
UFO just landed and posted this here
UFO just landed and posted this here
Я слышал об этом и даже хотел включить в первый абзац предыдущего комментария после «финансовых транзакций». Я так понимаю, выделенные вами словосочетания как раз и выявляют вину именно разработчиков, ведь это они отвечают за дизайн и используемые практики разработки.
UFO just landed and posted this here
У меня всё прекрасно с терминологией. В реальной жизни любой человек, отвечающий за разработку программного обеспечения, совмещает в себе несколько ролей. Более того, конкретный круг обязанностей каждой роли сильно варьируется от компании к компании, да даже в рамках одной компании. Да и понятие «архитектура», к примеру, такое же «конкретное», как и «энергия» в физике. Все знают, что она есть, но никто не знает, что это такое. Каждый представляет её себе по-своему.
За «software design» и «development practices» в моём понимании должны отвечать те, кого вы называете «кодерами». Повторюсь, меня от этого слова коробит, я сразу представляю себе улюбащихся индусов с группового фото разработчиков IE6, не в обиду жителям Индии будет сказано.
Мне лично сложно как-то вписать себя в вашу красивую систему понятий. Я занимаюсь архитектурой (а именно выделением модулей и связей между ними, описание контрактов компонент), активным написанием кода и частенько ковыряюсь в проектной системе сборки просто потому, что вижу в ней серьёзные изъяны, а отдельного билд-инженера у нас нет (хотя компания довольно большая). В один день я могу писать High-Level Design спецификацию, потом писать низкоуровневый код на с++, править скрипты CMake и конфигурацию CI-сервера, потом сваять пару скриптов для автоматизации на python. Кто я в вашей классификации?
С аналитиками, дизайнерами и тестерами всё немного прозрачней, но они то в примере с Therac-25 точно невиновны.
За «software design» и «development practices» в моём понимании должны отвечать те, кого вы называете «кодерами». Повторюсь, меня от этого слова коробит, я сразу представляю себе улюбащихся индусов с группового фото разработчиков IE6, не в обиду жителям Индии будет сказано.
Мне лично сложно как-то вписать себя в вашу красивую систему понятий. Я занимаюсь архитектурой (а именно выделением модулей и связей между ними, описание контрактов компонент), активным написанием кода и частенько ковыряюсь в проектной системе сборки просто потому, что вижу в ней серьёзные изъяны, а отдельного билд-инженера у нас нет (хотя компания довольно большая). В один день я могу писать High-Level Design спецификацию, потом писать низкоуровневый код на с++, править скрипты CMake и конфигурацию CI-сервера, потом сваять пару скриптов для автоматизации на python. Кто я в вашей классификации?
С аналитиками, дизайнерами и тестерами всё немного прозрачней, но они то в примере с Therac-25 точно невиновны.
UFO just landed and posted this here
Отчего же, мои обязанности прописаны в договоре. Но что мне остаётся делать? Если я написал библиотеку, а билд-инженера нет, мне нужно ждать, пока компания его наймёт, чтобы включить модуль в сборку? Или мне нужно мириться с отсутствием CI-сервера потому, что его настройка, занимающая в сумме 2 несчастных часа, не входит в мои прямые обязанности? Мне нужно перестать писать тесты потому, что я не тестер и мне не платят за нахождение багов? Мне нужно повторять раз за разом рутинные действия, т.к. я не в должности автоматизатора и писать скрипты — не моя работа?
UFO just landed and posted this here
у вас в компании что-то не так с организацией труда
Абсолютно верно. Людям прекрасно живётся без модульной архитектуры, тестов и CI. Они бояться трогать код и частенько подпирают его костылями.
И что я дожлен сделать по этому поводу? Уволиться? Смириться? Или всё же примером показать преимущества лучших практик, упростить их использование настолько, чтобы они стали неотъемлимой частью общего цикла разработки?
Более того, очень мало компаний, в которых с организацией труда всё идеально (Google?). Я уже работал в очень крупном проекте, в котором роли каждого человека были расписаны досконально. Повлиять на работу такой «системы» очень сложно. Что дали, тем и пользуйся. И да, я не вернусь туда ни за какие деньги.
UFO just landed and posted this here
За «software design» и «development practices» в моём понимании должны отвечать те, кого вы называете «кодерами».Если даже за development practices, по-вашему, должны отвечать кодеры, то за что в таком случае должен отвечать CTO?
Да и насчёт ответственности кодеров за software design — тоже очень спорное утверждение. Как минимум потому, что кодеров в крупном проекте бывает много, и у каждого есть свой предыдущий опыт работы и, соответственно, свой собственный взгляд на то, как ту или иную вещь делать. Дать им возможность каждому решать за себя, в каком стиле писать вверенный им кусок проекта? Получится хаос. Заставить их сесть и коллегиально вырабатывать единую архитектуру и стиль? Убьют кучу времени, прежде чем договорятся, и всё равно нет гарантии, что выбранное решение взлетит.
Именно поэтому в крупных проектах есть разделение ролей. Есть архитекторы, которые на основе своего опыта и компетенции выбирают некое генеральное направление развития проекта, и есть рядовые разработчики, которые в этом направлении проект тянут. Нет, конечно, можно потенциально нанять людей с квалификацией архитектора на позицию рядовых разработчиков, но такие люди знают себе цену, и она высока. Так что целая команда из таких спецов сожрёт бюджет проекта с меньшей отдачей, чем команда более «приземлённых» специалистов во главе с одним архитектором.
Не знаю, сколько времени должно быть у CTO, чтобы проверять соблюдение всех development practices. И, возможно, мы слегка по-разному трактуем словосочетание «software design».
Реальный пример: для нашей задачи нам нужен быстрый поиск, мы решаем использовать для этой цели Elastic. Подходяещго клиента для наших нужд нет. Мы говорим «кодерам»: вам нужно написать модуль с интерфейсом I.
Вот выделить внутренние классы для решения этой задачи — это software design или уже архитектура и «генеральное направление развития проекта»? С моей точки зрения решение «мы решаем использовать для этой цели Elastic,… нужно написать модуль с интерфейсом I» — это работа CTO и генеральное направление. А проектирование реализации модуля, его скурпулёзная и надёжная реализация — тот самый «software design». Конечно, отлично, если CTO сможет проконтролировать каждый шаг и найдёт ошибки дизайна, переполнения счётчиков и ситуации гонки в результате code-review. Но я так понимаю, посыл статьи (и моя точка зрения) — «кодер» должен быть сознателен и ответственнен за свою работу, он должен принимать больше ответственности, заботиться о сроках, тестах и интеграции самостоятельно, а не просто слепо выполнять волю начальства по инерции.
Реальный пример: для нашей задачи нам нужен быстрый поиск, мы решаем использовать для этой цели Elastic. Подходяещго клиента для наших нужд нет. Мы говорим «кодерам»: вам нужно написать модуль с интерфейсом I.
Вот выделить внутренние классы для решения этой задачи — это software design или уже архитектура и «генеральное направление развития проекта»? С моей точки зрения решение «мы решаем использовать для этой цели Elastic,… нужно написать модуль с интерфейсом I» — это работа CTO и генеральное направление. А проектирование реализации модуля, его скурпулёзная и надёжная реализация — тот самый «software design». Конечно, отлично, если CTO сможет проконтролировать каждый шаг и найдёт ошибки дизайна, переполнения счётчиков и ситуации гонки в результате code-review. Но я так понимаю, посыл статьи (и моя точка зрения) — «кодер» должен быть сознателен и ответственнен за свою работу, он должен принимать больше ответственности, заботиться о сроках, тестах и интеграции самостоятельно, а не просто слепо выполнять волю начальства по инерции.
Для меня «development practices» — это что-то вроде «с сегодняшнего дня мы работаем по методологии scrum» или «каждая фича делается в отдельном бранче» или «весь UX должен автоматизированно теститься через Selenium». Некие базовые моменты. При этом, естественно, просто лозунгом отделываться нельзя — нужно при необходимости создавать инструкции, как достигать поставленных целей — или нанимать тех, кто будет составлять такие инструкции.
И это действительно работа СТО. Его за тем в команду и приглашают, чтобы он создал «правила игры» для этой команды.
«Software design» — это, в моём понимании, синоним архитектуры. Но не только на уровне типа составления диаграммы классов, а, в том числе, и выбор инструментария под проект. То есть, целый комплекс действий, превращающий требования к продукту глазами заказчика во фронт работ для разработчиков.
Это работа для архитектора. Он должен решить, с помощью каких технологий проект будет реализовываться, из каких компонент состоять, где будет нужно закладывать потенциал для лёгкого расширения на будущее, а где расширяемость лишь сожрёт дополнительные ресурсы и по сути не нужна.
Организация сode-review и прочих производственных вещей — это задача team lead'а. Он отвечает за процесс внедрения development practices в рабочий процесс и в соответствие результата работы команды заявленному software design'у. Иногда явно выделенного тимлида не существует, и менеджеры полагаются просто на сознательность разработчиков. Но в конечном итоге всё равно находится кто-то, кто сечёт в проекте лучше всего, у кого менеджеры интересуются текущим положением вещей в проекте, перспективами поспеть к очередному milestone'у и т.д. Наконец, всегда есть кто-то, кто помогает новичкам влиться в проект, вводит их в курс дела, как принято работать конкретно в этой конторе, кто проводит технические собеседования наконец.
Также существует отдельная задача — разложить вытекающий из software design'а фронт работ на отдельные задачи, сгруппировать эти задачи по этапам и согласовать на них сроки. Это обычно работа менеджера проекта, хотя не без технических консультаций со стороны тимлида.
А вот задача кодеров — это просто выполнять те отдельные задачи, которые им по результатам работы всех вышеперечисленных лиц достаются, выполнять согласно установленным в команде правилам. Всё. Устанавливать сами правила — это не их задача и не их компетенция.
Конечно, если в команде принято писать на свой код автотесты — то кодер должен их писать. Но, опять же, не его задача — не спать ночами и думать, как бы улучшить процесс разработки, не перейти ли на другой ЯП или не реализовать ли систему автотестирования.
При этом заботиться о сроках — это задача кодера лишь в том случае, когда он влияет на этих сроков назначение. Потому как бывают ситуации, когда команде даётся просто набор задач и ставится условие: закрыть эти задачи к такому-то числу. Тут уж всё зависит от того, является ли названный срок реалистичным. Если менеджер накосячил и назначил нереальные сроки — это уже его проблемы, и рядовые программисты не обязаны рвать задницу, чтобы эту проблему решить.
И это действительно работа СТО. Его за тем в команду и приглашают, чтобы он создал «правила игры» для этой команды.
«Software design» — это, в моём понимании, синоним архитектуры. Но не только на уровне типа составления диаграммы классов, а, в том числе, и выбор инструментария под проект. То есть, целый комплекс действий, превращающий требования к продукту глазами заказчика во фронт работ для разработчиков.
Это работа для архитектора. Он должен решить, с помощью каких технологий проект будет реализовываться, из каких компонент состоять, где будет нужно закладывать потенциал для лёгкого расширения на будущее, а где расширяемость лишь сожрёт дополнительные ресурсы и по сути не нужна.
Организация сode-review и прочих производственных вещей — это задача team lead'а. Он отвечает за процесс внедрения development practices в рабочий процесс и в соответствие результата работы команды заявленному software design'у. Иногда явно выделенного тимлида не существует, и менеджеры полагаются просто на сознательность разработчиков. Но в конечном итоге всё равно находится кто-то, кто сечёт в проекте лучше всего, у кого менеджеры интересуются текущим положением вещей в проекте, перспективами поспеть к очередному milestone'у и т.д. Наконец, всегда есть кто-то, кто помогает новичкам влиться в проект, вводит их в курс дела, как принято работать конкретно в этой конторе, кто проводит технические собеседования наконец.
Также существует отдельная задача — разложить вытекающий из software design'а фронт работ на отдельные задачи, сгруппировать эти задачи по этапам и согласовать на них сроки. Это обычно работа менеджера проекта, хотя не без технических консультаций со стороны тимлида.
А вот задача кодеров — это просто выполнять те отдельные задачи, которые им по результатам работы всех вышеперечисленных лиц достаются, выполнять согласно установленным в команде правилам. Всё. Устанавливать сами правила — это не их задача и не их компетенция.
Конечно, если в команде принято писать на свой код автотесты — то кодер должен их писать. Но, опять же, не его задача — не спать ночами и думать, как бы улучшить процесс разработки, не перейти ли на другой ЯП или не реализовать ли систему автотестирования.
При этом заботиться о сроках — это задача кодера лишь в том случае, когда он влияет на этих сроков назначение. Потому как бывают ситуации, когда команде даётся просто набор задач и ставится условие: закрыть эти задачи к такому-то числу. Тут уж всё зависит от того, является ли названный срок реалистичным. Если менеджер накосячил и назначил нереальные сроки — это уже его проблемы, и рядовые программисты не обязаны рвать задницу, чтобы эту проблему решить.
СТО раз. Архитектор два. Team-lead три. «Учитель» четыре. Тех. Пис. пять. Менеджер проекта шесть. Плюс штат кодеров и, пожалуй, один-два тестера (которые вдобавок тестят не только систему, но и юзабилити). Много для проекта? Почти всегда (посчитаем зарплату всех этих кадров).
Объединим СТО и Архитектора, Team-lead'а и Менеджера, ТехПиса и «Учителя». Функции тестера можно умеючи на кого-нибудь перекинуть. Много для проекта (снова считаем зарплату)? Много.
Объединим… СТО-Архитектор-ТехПис («ну ты же разбираешься!»), Менеджер-Team-lead-«Учитель». Стоп. Два управляющих? Я что, сам себе не начальник? Сократить…
Беда лишь в том, что такими сокращениями и объединениями вопрос выгоды является крайне спорным. Точнее, беда не в этом. Беда в том, что начальство не понимает, как мы работаем и почему надо обеспечить все условия для качественного выполнения задачи с первого раза. Но это уже беда компании, что их Аналитик (если он есть вообще) не просчитывает «долгие деньги» от такой «экономии». А отсутствие должного планирования вообще бич для многих компаний…
И вот в этих условиях всю ответственность за косяки начальства на себя придётся брать рядовым кодерам (хотя и кодерами их уже не назовёшь). «Менеджеры» же предпочитают старую схему: один начальник, много подчинённых. Один технический директор — много «кодеров». Ладно если ещё технический директор сам из этой среды, понимает что и как. По этому поводу много возмущались тут же, на Хабре.
Теперь ответ на вопрос «что делать». Выполнить на досуге работу аналитика и придти с ней к начальству. То есть, работая на скорость, а не на качество, мы ежемесячно теряем n человекочасов, что даёт потерю в n денег. Более того, значительное время приходится уделять не своим обязанностям, в то время как разделение труда себя успешно зарекомендовало ещё несколько сотен лет назад. Наняв <таких-то> людей, мы сможем сократить временные, а, следовательно, и финансовые издержки на полпорядка. Что означает выход на окупаемость в первом же месяце их работать. Далее, есть проблема с материальным обеспечением (ну мало ли, столы неправильно стоят, кофе и печенек хватает только до обеда...), что тоже ведёт к прямым потерям. Таким образом, при текущей организации труда мы теряем <много> денег. Вот вам листок с расчётами, вот рекомендации. Работу стороннего аудитора и аналитика я выполнил бесплатно. Иногда срабатывает, если начальство разбирается в бизнесе, а не «поставлено» кем-то.
Объединим СТО и Архитектора, Team-lead'а и Менеджера, ТехПиса и «Учителя». Функции тестера можно умеючи на кого-нибудь перекинуть. Много для проекта (снова считаем зарплату)? Много.
Объединим… СТО-Архитектор-ТехПис («ну ты же разбираешься!»), Менеджер-Team-lead-«Учитель». Стоп. Два управляющих? Я что, сам себе не начальник? Сократить…
Беда лишь в том, что такими сокращениями и объединениями вопрос выгоды является крайне спорным. Точнее, беда не в этом. Беда в том, что начальство не понимает, как мы работаем и почему надо обеспечить все условия для качественного выполнения задачи с первого раза. Но это уже беда компании, что их Аналитик (если он есть вообще) не просчитывает «долгие деньги» от такой «экономии». А отсутствие должного планирования вообще бич для многих компаний…
И вот в этих условиях всю ответственность за косяки начальства на себя придётся брать рядовым кодерам (хотя и кодерами их уже не назовёшь). «Менеджеры» же предпочитают старую схему: один начальник, много подчинённых. Один технический директор — много «кодеров». Ладно если ещё технический директор сам из этой среды, понимает что и как. По этому поводу много возмущались тут же, на Хабре.
Теперь ответ на вопрос «что делать». Выполнить на досуге работу аналитика и придти с ней к начальству. То есть, работая на скорость, а не на качество, мы ежемесячно теряем n человекочасов, что даёт потерю в n денег. Более того, значительное время приходится уделять не своим обязанностям, в то время как разделение труда себя успешно зарекомендовало ещё несколько сотен лет назад. Наняв <таких-то> людей, мы сможем сократить временные, а, следовательно, и финансовые издержки на полпорядка. Что означает выход на окупаемость в первом же месяце их работать. Далее, есть проблема с материальным обеспечением (ну мало ли, столы неправильно стоят, кофе и печенек хватает только до обеда...), что тоже ведёт к прямым потерям. Таким образом, при текущей организации труда мы теряем <много> денег. Вот вам листок с расчётами, вот рекомендации. Работу стороннего аудитора и аналитика я выполнил бесплатно. Иногда срабатывает, если начальство разбирается в бизнесе, а не «поставлено» кем-то.
Статья то немного не о том…
Трудно увидеть в себе недостатки. Трудно принимать ответственность. Трудно улучшать свою работу, затачивать самодисциплину. Этому надо учиться, и это только от самого человека зависит, начальники тут бессильны. Максимум что начальник может — попытаться нанять программистов в шаолиньском монастыре :)
ЗЫ, это я тоже про критику статьи
Трудно увидеть в себе недостатки. Трудно принимать ответственность. Трудно улучшать свою работу, затачивать самодисциплину. Этому надо учиться, и это только от самого человека зависит, начальники тут бессильны. Максимум что начальник может — попытаться нанять программистов в шаолиньском монастыре :)
ЗЫ, это я тоже про критику статьи
«которым плевать на даты» — наверное, имелись в виду все-таки свидания (которые тоже dates).
Мне в целом понравилось. Но есть, на мой взгляд, нюансы:
Это происходит из-за накопления технического долга. Оценка технического долга и планирование работ по его устранению — должностные обязанности тим лида. Если технический директор не смог нанять руководителя проекта, который не смог нанять тим лида, который умеет работать с техническим долгом — это проблема технического директора. Не умеет нанимать людей и следить как они выполняют работу — ну кто ему доктор?
Почему, на мой взгляд, возникают сложности с расширяемостью? Потому что в программе можно делать заготовки под расширяемость в различных направлениях — а можно не делать. Делать стоит денег и требует совместных усилий технического директора и руководителя проекта чтобы просчитать вероятность расширения программы в том или ином направлении, предугадать будующее, сбалансировать сроки и цену. Пришлось отдать почку чтобы добавить кнопочку на сайт? Значит вместо того, чтобы обсуждать с руководителем проекта планы по развитию и закладывать бюджет и сроки на добавление в программу заготовок по расширяемости — отдыхал в баньке с девочками как настоящий крутой босс. Некомпетентный технический директор — залог процветания рынка почек.
У автора оригинального поста уже кто-нибудь спросил — эти 20 часов в неделю предоставляет работодатель как оплаченное время, или ребята наивно полагают, что за те деньги, что они готовы платить, у них будут работать спецы, которые в неделю сначала 40 часов работать на них, потом каким-то волшебным образом восстанавливают ману и еще 20 часов изучают новые технологии? Так крайне мало кто может, нанимать таких ребят трудно и плохо масштабируемо. А бизнем не очень любит азартные игры на тему «а что с нами будет, если уволятся адепты Вася с Петей? Найм специалистов с такими умениями за такие деньги — везение и лотерея чистой воды. А если за три месяца не наймем?»
Я ожидаю что ваша продуктивность будет оставаться стабильной. Я не хочу чтобы вы работали быстро поначалу, а потом замедлялись.
Это происходит из-за накопления технического долга. Оценка технического долга и планирование работ по его устранению — должностные обязанности тим лида. Если технический директор не смог нанять руководителя проекта, который не смог нанять тим лида, который умеет работать с техническим долгом — это проблема технического директора. Не умеет нанимать людей и следить как они выполняют работу — ну кто ему доктор?
Когда бизнес хочет внести изменения вы говорите «Конечно! Нет проблем, мы внесем их и нет, вам не придётся отдавать почку чтобы это себе позволить»
Почему, на мой взгляд, возникают сложности с расширяемостью? Потому что в программе можно делать заготовки под расширяемость в различных направлениях — а можно не делать. Делать стоит денег и требует совместных усилий технического директора и руководителя проекта чтобы просчитать вероятность расширения программы в том или ином направлении, предугадать будующее, сбалансировать сроки и цену. Пришлось отдать почку чтобы добавить кнопочку на сайт? Значит вместо того, чтобы обсуждать с руководителем проекта планы по развитию и закладывать бюджет и сроки на добавление в программу заготовок по расширяемости — отдыхал в баньке с девочками как настоящий крутой босс. Некомпетентный технический директор — залог процветания рынка почек.
Рассчитывайте тратить дополнительные 20 часов в неделю на вашу карьеру. Это то, чем занимаются профессионалы.
К рабочим это не относится.
У автора оригинального поста уже кто-нибудь спросил — эти 20 часов в неделю предоставляет работодатель как оплаченное время, или ребята наивно полагают, что за те деньги, что они готовы платить, у них будут работать спецы, которые в неделю сначала 40 часов работать на них, потом каким-то волшебным образом восстанавливают ману и еще 20 часов изучают новые технологии? Так крайне мало кто может, нанимать таких ребят трудно и плохо масштабируемо. А бизнем не очень любит азартные игры на тему «а что с нами будет, если уволятся адепты Вася с Петей? Найм специалистов с такими умениями за такие деньги — везение и лотерея чистой воды. А если за три месяца не наймем?»
Все вроде бы хорошо, но есть несколько нюансов.
1).Менеджерам хотелку бы поуменьшить нужно. Иногда случается такое что наваливают работу на 2-х — 3-ех человек которой должны заниматься 10-15. А потом «я хочу, я хочу» и т.п.
2). К классике жанра относится — заплатить 3 копейки и хотеть получить качественное ПО.
3). Особенно в больших организациях такое бывает, что один менеджер что бы прогнуться под другим менеджером подписывается под что-то. А потом — вы девелоперы вы и делайте. (Хоть как-то не сделайте, неважно что будет ломаться — потом пофиксите и т.п. а не сделаешь — уволю к чертям собачьим).
1).Менеджерам хотелку бы поуменьшить нужно. Иногда случается такое что наваливают работу на 2-х — 3-ех человек которой должны заниматься 10-15. А потом «я хочу, я хочу» и т.п.
2). К классике жанра относится — заплатить 3 копейки и хотеть получить качественное ПО.
3). Особенно в больших организациях такое бывает, что один менеджер что бы прогнуться под другим менеджером подписывается под что-то. А потом — вы девелоперы вы и делайте. (Хоть как-то не сделайте, неважно что будет ломаться — потом пофиксите и т.п. а не сделаешь — уволю к чертям собачьим).
1) Получившийся в итоге факап это проблема менеджера, а не разработчика
2) Странная позиция. Напоминает учителей и врачей которые плохо учат и лечат, мотивируя это тем, что им мало платят.
Если мало денег — попроси больше. Кадровый дефицит у нас это легко позволяет.
Делать не так профессионально как ты можешь потому что тебе мало платят — это неуважение к себе и своей профессии.
3) Опять же, разработчикам увольнением никто и никогда не грозит в силу жестокого кадрового дефицита нашей индустрии.
Не нравится менеджмент — идёшь в другую контору.
2) Странная позиция. Напоминает учителей и врачей которые плохо учат и лечат, мотивируя это тем, что им мало платят.
Если мало денег — попроси больше. Кадровый дефицит у нас это легко позволяет.
Делать не так профессионально как ты можешь потому что тебе мало платят — это неуважение к себе и своей профессии.
3) Опять же, разработчикам увольнением никто и никогда не грозит в силу жестокого кадрового дефицита нашей индустрии.
Не нравится менеджмент — идёшь в другую контору.
Ну, клёво, товарищ перечислил, что ему нужно. Но задача техдира не что, а как, и вот про это почти ничего.
btw, вспомнился анекдот. На железной дороге решили исследовать проблему аварий и выяснили, что при авариях чаще всего повреждается последний вагон, чтобы уменьшить количество повреждений, приняли решение последний вагон отцепить.
Уж не знаю почему, но вот вспомнилось, когда читал текст.
btw, вспомнился анекдот. На железной дороге решили исследовать проблему аварий и выяснили, что при авариях чаще всего повреждается последний вагон, чтобы уменьшить количество повреждений, приняли решение последний вагон отцепить.
Уж не знаю почему, но вот вспомнилось, когда читал текст.
Справедливые ожидания вашего программиста. Чего я ожидаю от руководства.
1) Честности. Я устал от мотивационных спичей и тим билдинга. Мне не нужны мероприятия раз в год, когда небожители сходят с Олимпа, чтобы пожать руку простым программистам и рассказать про космические корабли на просторах Большого театра. Просто скажите правду — «я капиталист, вы мои рабочие (субподрядчики), вы зарабатываете мне деньги. Сейчас я плачу вам столько, потому что не могу платить меньше, вы уйдете. Может быть, я буду платить больше, если будет дефицит на рынке. Но если будет нужно, я уволю любого».
2) Выполнение обещаний. Ждете проекты в срок? А как насчет сервера, который мы ждем уже год? Как насчет вопроса, который я задал месяц назад и на который до сих пор нет ответа, не смотря на еженедельное напоминание?
3) Занимайтесь своим делом. Это лично мое дело, когда приходить в офис и приходить ли вовсе. Если я согласился на какие-то митинги или на конференции, я буду в срок, но порой мне бывает нужно остаться дома и закончить то, что я кодил вчера до 2х утра.
4) Признавайте ошибки. Будьте конкретными. Не «произошли накладки в процессе коммуникации с клиентом», а «менеджер Василий был с бодуна и подписал все, не читая, и теперь вы должны за 1 месяц написать систему управления космическим кораблем»
5) Уважайте мое профессиональное мнение. Если я говорю, что что-то надо делать так, то не нужно командным путем заставлять меня делать иначе.
Спасибо за внимание.
1) Честности. Я устал от мотивационных спичей и тим билдинга. Мне не нужны мероприятия раз в год, когда небожители сходят с Олимпа, чтобы пожать руку простым программистам и рассказать про космические корабли на просторах Большого театра. Просто скажите правду — «я капиталист, вы мои рабочие (субподрядчики), вы зарабатываете мне деньги. Сейчас я плачу вам столько, потому что не могу платить меньше, вы уйдете. Может быть, я буду платить больше, если будет дефицит на рынке. Но если будет нужно, я уволю любого».
2) Выполнение обещаний. Ждете проекты в срок? А как насчет сервера, который мы ждем уже год? Как насчет вопроса, который я задал месяц назад и на который до сих пор нет ответа, не смотря на еженедельное напоминание?
3) Занимайтесь своим делом. Это лично мое дело, когда приходить в офис и приходить ли вовсе. Если я согласился на какие-то митинги или на конференции, я буду в срок, но порой мне бывает нужно остаться дома и закончить то, что я кодил вчера до 2х утра.
4) Признавайте ошибки. Будьте конкретными. Не «произошли накладки в процессе коммуникации с клиентом», а «менеджер Василий был с бодуна и подписал все, не читая, и теперь вы должны за 1 месяц написать систему управления космическим кораблем»
5) Уважайте мое профессиональное мнение. Если я говорю, что что-то надо делать так, то не нужно командным путем заставлять меня делать иначе.
Спасибо за внимание.
Всецело поддерживаю.
На самом деле, к этому списку ответных требований каждый разработчик может добавить какие-то свои личные «справедливые ожидания».
Например, меня лично угнетает сама концепция однобокости взаимоотношений работодателя и работника. То есть, если работодатель хочет, чтобы ты любил свой проект как родную маму и вкалывал как лошадь на его благо, а в свободное время читал книжки для повышения своей квалификации — это справедливое ожидание. А если ты так и не дождался негласного ежегодного пересмотра зарплаты и вынужден клянчить прибавку у своего менеджера — то это уже «сложный вопрос» и тебе «нужно доказать обоснованность» своих требований.
Или, например, когда ты думаешь, остаться ли тебе на текущем месте работы или перейти в другую контору на интересный тебе проект — в личном общении менеджер вешает тебе лапшу на уши, мол, у заказчика на наш проект огромные планы, тут на годы вперёд открытый фронт работ и серьёзный бюджет, а через несколько месяцев проект запиливают, а команду распихивают по другим отделам, заставляя заниматься по сути совершенно другими задачами. Например, меня как backend разработчика на С++ под винду переводили в команду к мобильным разработчикам — клепать UI на Objective-C. Хотя даже в процессе перевода обещали позицию, где можно будет подучиться и попрактиковаться с Java. При этом работодатель искренне считает, что сделал тебе одолжение — не уволил, а взял на позицию, где тебе придётся сначала учиться, а потому первую пару месяцев от тебя, так и быть, не ждут полноценной отдачи.
А что касается непосредственно изложенных в статье пунктов, то, как тут уже отмечали, в них нет ничего плохого — если, конечно, работодатель готов выделять ресурсы на их внедрение. По сути, работник продаёт работодателю определённое количество часов своего времени. Если СТО хочет, чтобы работник и продукт его труда удовлетворяли интересующим его критериям — пускай он либо уложит в купленное у работника время процесс «повышения квалификации», либо наймёт работников, которые его удовлетворяют с самого начала.
Только, как это часто бывает, компании сначала публикуют вакансии с нереальной зарплатой и нереальными требованиями, но оставляют ремарку типа «если вы чего-то из вышеперечисленного не знаете — всё равно пишите». Потом на собеседовании ищут слабые места соискателей, чтобы сбить цену и потом при приглашении на работу иметь позицию типа «ты не наш идеал, и приглашая тебя, мы делаем тебе одолжение».
А потом у начальства резко образуется амнезия, и они требуют чтобы ты впахивал по полной программе, а если вдруг чего-то не знаешь — ликвидировал эти пробелы своими силами. Если не смог этого сделать — увольняют после испытательного срока. Если смог — здорово, молодец, работай дальше. Но та нереальная зарплата из изначального объявления о вакансии тебе всё равно не светит.
На самом деле, к этому списку ответных требований каждый разработчик может добавить какие-то свои личные «справедливые ожидания».
Например, меня лично угнетает сама концепция однобокости взаимоотношений работодателя и работника. То есть, если работодатель хочет, чтобы ты любил свой проект как родную маму и вкалывал как лошадь на его благо, а в свободное время читал книжки для повышения своей квалификации — это справедливое ожидание. А если ты так и не дождался негласного ежегодного пересмотра зарплаты и вынужден клянчить прибавку у своего менеджера — то это уже «сложный вопрос» и тебе «нужно доказать обоснованность» своих требований.
Или, например, когда ты думаешь, остаться ли тебе на текущем месте работы или перейти в другую контору на интересный тебе проект — в личном общении менеджер вешает тебе лапшу на уши, мол, у заказчика на наш проект огромные планы, тут на годы вперёд открытый фронт работ и серьёзный бюджет, а через несколько месяцев проект запиливают, а команду распихивают по другим отделам, заставляя заниматься по сути совершенно другими задачами. Например, меня как backend разработчика на С++ под винду переводили в команду к мобильным разработчикам — клепать UI на Objective-C. Хотя даже в процессе перевода обещали позицию, где можно будет подучиться и попрактиковаться с Java. При этом работодатель искренне считает, что сделал тебе одолжение — не уволил, а взял на позицию, где тебе придётся сначала учиться, а потому первую пару месяцев от тебя, так и быть, не ждут полноценной отдачи.
А что касается непосредственно изложенных в статье пунктов, то, как тут уже отмечали, в них нет ничего плохого — если, конечно, работодатель готов выделять ресурсы на их внедрение. По сути, работник продаёт работодателю определённое количество часов своего времени. Если СТО хочет, чтобы работник и продукт его труда удовлетворяли интересующим его критериям — пускай он либо уложит в купленное у работника время процесс «повышения квалификации», либо наймёт работников, которые его удовлетворяют с самого начала.
Только, как это часто бывает, компании сначала публикуют вакансии с нереальной зарплатой и нереальными требованиями, но оставляют ремарку типа «если вы чего-то из вышеперечисленного не знаете — всё равно пишите». Потом на собеседовании ищут слабые места соискателей, чтобы сбить цену и потом при приглашении на работу иметь позицию типа «ты не наш идеал, и приглашая тебя, мы делаем тебе одолжение».
А потом у начальства резко образуется амнезия, и они требуют чтобы ты впахивал по полной программе, а если вдруг чего-то не знаешь — ликвидировал эти пробелы своими силами. Если не смог этого сделать — увольняют после испытательного срока. Если смог — здорово, молодец, работай дальше. Но та нереальная зарплата из изначального объявления о вакансии тебе всё равно не светит.
Касательно «я попробую». Если назван не конкретный срок, а что-то вроде «это займет дня/недели/месяца 4, если повезет, то 3, в худшем случае 5), то можно сказать „да, я попробую уложиться в 3“ лищней отвественности не добавляет. Но заказчик (пускай внутренний) должен понимать, что это аналогично „да, я попробую бросить кубик и выбить 5 или 6“. Пока я будут работать, он пускай молится, чтобы мне повезло и никаких подводных камней не встретилось — может поможет :)
Пост действительно выглядит как будто спустившийся с заокеанских небес новый начальник, полностью оторванный от реальности, пытается мотивировать бессловесное стадо разработчиков, но в принципе это объяснимо. Этот самый «дядя Боб», автор текста, с 1990 года занимается не программированием, а «консультированием», а также книжки пишет. Поняно, что он больше живет в мире теории и блестящей самопрезентации.
Но я подумал: может в его книжках и правда есть секреты, благодаря которым написание тестов ускоряет разработку, а растерянные QA ничего не находят. Пролистал оглавление. К сожалению там набор банальностей: пишите осмысленные комментарии, делайте функции короткими, обрабатывайте ошибки правильно. Мдааа… Ну, надеюсь понятно, что даже самое скрупулезное следование этим советам не приведет к тому, что QA останутся без работы. У нас в деревне таких дядь Бобов булшиттерами кличут.
Но я подумал: может в его книжках и правда есть секреты, благодаря которым написание тестов ускоряет разработку, а растерянные QA ничего не находят. Пролистал оглавление. К сожалению там набор банальностей: пишите осмысленные комментарии, делайте функции короткими, обрабатывайте ошибки правильно. Мдааа… Ну, надеюсь понятно, что даже самое скрупулезное следование этим советам не приведет к тому, что QA останутся без работы. У нас в деревне таких дядь Бобов булшиттерами кличут.
Думается мне, что если всего лишь переименовать статью в «К чему надо стремиться в своей работе, чтобы стать высокооплачиваемым незаменимым профессионалом», то комментарии стали бы совершенно другими.
Если переименовать статью в «К чему надо стремиться в своей работе, чтобы стать высокооплачиваемым незаменимым профессионалом» — то она станет 100% фарсом и ложью. Один только пункт «Мы поддерживаем друг друга» чего стоит! К этому должно и будет стремиться руководство — а нормальный, вменяемый специалист этого всегда будет избегать. Потому что пока я в компании уникален, как специалист и профессионал — мне достаётся куча плюшек, уступки, меня «целуют в зад». Но научив своего соседа своим уникальным, придуманным и опробованным мною, приемам — я сразу теряю эту уникальность. А вместе с ней теряю и те самые плюшки. Ну и зачем оно мне надо? И такое мнение есть по большинству пунктов. Сама по себе идея статьи верная — но вот изложение этой идеи рассчитано только на «верхушку» фирмы, на руководство.
UFO just landed and posted this here
Меня не могут вызвать в выходные или из отпуска — это одна из положенных плюшек… :) А если меня трамвай переедет — то компании придется искать специалиста с таким же или более высоким уровнем компетенции. И этому я не буду мешать ни после того, как меня переедет трамвай — ни до этого. Но сам себе конкуренцию готовить я не обязан.
UFO just landed and posted this here
Для того, чтобы очень попросить — надо очень сильно мотивировать, Теми самыми же плюшками. Если за выходной я заработаю так же, как за рабочую неделю — то да, я буду считать это достаточной мотивацией для смены своего рабочего графика.
UFO just landed and posted this here
На последнем месте работы стаж 2 года. И надо сказать, что это место работы я не искал — меня на него «переманили». То есть я пришел на рабочее место уже изначально на привилегированных условиях. И условия эти мне достались именно из-за уникальности, как специалиста. :) То же самое было на предыдущем месте работы. И на предшествующем предыдущему. Так что я могу вполне уверенно сказать, что уникальность больше несет плюсов, чем минусов.
Мне кажется, суть в том что «Мы поддерживаем друг друга» в 99% случаев — это наглая ложь. В редких случаях когда ваш начальник не потакает клиенту и не даёт ему растечься фичекрипом по дереву, когда он действительно поддерживает вас и осознаёт когда сроки на имплементацию действительно разумные, тогда я как программер к нему бы ушёл с любой работы даже на меньшую зарплату. И работал бы согласно ожиданиям. Но ведь это же не так.
В реальности мы имеем индивида который в лучшем случае держит вас в известности относительно желаний клиента. И нас как программистов ставят в позицию, когда на «А это сможешь к Пятнице?» мы отвечаем «Смогу, но появится куча левых тесткейсов, а о scalability можно и не думать.» И начальник перестал слушать нас на «Смогу». Позже выясняется что юзеров не десять, а тысяча, и нужно не к пятнице, а прямо сейчас. И мы переводим стрелки на QA потому что кучу левых тесткейсов «Прям щас!» мы делать не имеем ни малейшего желания, нам ещё ядро функционала переписывать до трёх утра потому что костыль на тысяче юзеров сдохнет. И мы всё равно остаёмся крайние, потому что яиц своих у начальника нет чтобы ответственность на себя взять.
Вот эту уёбищность мы терпим, терпим, а потом уходим. Проблема в том что даже уйдя мы уже привыкли писать гуано-подобный код. Надо переучиваться и т.д.
В реальности мы имеем индивида который в лучшем случае держит вас в известности относительно желаний клиента. И нас как программистов ставят в позицию, когда на «А это сможешь к Пятнице?» мы отвечаем «Смогу, но появится куча левых тесткейсов, а о scalability можно и не думать.» И начальник перестал слушать нас на «Смогу». Позже выясняется что юзеров не десять, а тысяча, и нужно не к пятнице, а прямо сейчас. И мы переводим стрелки на QA потому что кучу левых тесткейсов «Прям щас!» мы делать не имеем ни малейшего желания, нам ещё ядро функционала переписывать до трёх утра потому что костыль на тысяче юзеров сдохнет. И мы всё равно остаёмся крайние, потому что яиц своих у начальника нет чтобы ответственность на себя взять.
Вот эту уёбищность мы терпим, терпим, а потом уходим. Проблема в том что даже уйдя мы уже привыкли писать гуано-подобный код. Надо переучиваться и т.д.
хехе… директор??? гыгы… да иди ты в жопу директор =)
(с) Мосяня =)
(с) Мосяня =)
Слушайте, а ему уже написали в ответ статью про то, что программисты ожидают от нормального директора? А то фигня какая-то получается: мы и то должны, и это: в долгах, как в шелках, а он лишь будет говорить нам «хочу к четвергу то-то».
Вы выходите на дорогу и в каждой машине есть несколько процессоров, каждый из которых выполняет код.
Два в карбюраторе и по одному на каждый дворник
Агрессивное обучение — это как? В процессе рычать и кусаться? Или сразу уже выбегать с книжкой и топором на улицу?
Ну за всё хорошее, против всего плохого! Осталось всего лишь найти идеальных людей
>Я расскажу, чего я от вас жду, и это определит ответ на вопрос, профессионалы ли мы.
Когда вопрос ставится таким образом, мне сразу же вспоминается это отличное видео:
Когда вопрос ставится таким образом, мне сразу же вспоминается это отличное видео:
Sign up to leave a comment.
Справедливые ожидания вашего технического директора