Comments 31
Эх галера, «любимая» галера.
К слову о галерах… habr.com/ru/company/maxilect/blog/464173
10 из 10. Мне кажется что это не шутка, а выдержка из какой-нибудь книги или тренинга «Как стать успешным руководителем». Прямо всё было на разных работах в той или иной степени.
Продвинутый уровень:
Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков.
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять. А то вдруг без половины разработчиков станет проще и быстрее согласовывать и писать. А если нанять ещё 2n программистов, то можно и себе денег больше попросить, и программистов постоянно укорять: "сколько же вас надо нанять, чтобы хоть что-то делалось".
Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования).
А важную информацию, наоборот надо обсуждать только в ветвящейся переписке с постоянно меняемым списком адресатов.
Заставьте оправдываться за каждый обнаруженный на тестировании баг
Это работает только с джунами. Опытный знает, что он допускает баги. И даже уже гордится некоторыми. Продуктивнее запрещать элементы TDD и максимально усложнить процесс регистрации багов (KPI по количеству, согласование с QA на заведение багов, массовое внесение инцидентов, как багов — тут много приёмов)
Отличная встряска — задержка зарплаты.
На нынешнем рынке труда — слишком одноразовый приём. Лучше намекать на премию, но не платить. Главное — премия должна быть максимально непредсказуемой.
формулируйте ТЗ как можно короче.
С тем же успехом — как можно длиннее. Круто кинуть в разработчика 400-страничной спекой: "Оцени наши доработки в проекте". Наши доработки — это изменение XML схемы, которое следует из требований одного абзаца на странице 324.
Если вы хотите обновить технологический стек, подумайте: чем новее технология, тем она сомнительнее
С тем же успехом можно менять стек каждые полгода-год.
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять
У меня был печальный опыт. На спокойный (слегка подгорающий, как и всегда) проект на 5 разработчиков руководство добавило усиление — «hot house team», как они ее гордо называли. Это такая группа «экстренного» реагирования, состоящая из ~20 бравых работников скайпа и клавиатуры.
Не знаю как они там нам должны были помочь, но работу парализовали знатно. Пару дней долбали, настраивая окружение (по очереди, естественно), пару дней бомбили вопросами, потом заставляли нас вмержить PRы в срочном порядке, с эскалацией к менеджерам и звонками на мобилу. Фиксили баги туда-сюда по четрые раза, ломая все вкруг.
Через 10 дней ада они покинули поле боя… чтобы зажигать на новом проекте.
Норм такой эффективный менеджер. :-)
Всю статью не прочитал. Понятно, что это реальные претензии реального человека по реальным проблемам. Но меня всегда «радует» подход индивидуума (без разницы: программиста, тестировщика, манагера) к обособлению от общей проблемы.
Вот человек пишет:
Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
Понятно, что это вечная тема для холивара.
Вот человек пишет:
Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!
Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.
И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше.
Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
Понятно, что это вечная тема для холивара.
Э-э-э вообще-то это работа манагера контролировать время/сроки.
Если он взял команду, которую собрали «с бору по сосенке», в сроки рассчитывал по команде, которая 10 соответствующих проектов сделали вместе (без текучки кадров). Ну тогда не надо удивятся, что его компетентность ставят под сомнение.
Треугольник (время, ресурсы, сроки) никто не отменял. И правильную оценку рисков то же.
А так да. Манагеры никогда не ошибаются, т.к. ничего не делают. :-)
Если он взял команду, которую собрали «с бору по сосенке», в сроки рассчитывал по команде, которая 10 соответствующих проектов сделали вместе (без текучки кадров). Ну тогда не надо удивятся, что его компетентность ставят под сомнение.
Треугольник (время, ресурсы, сроки) никто не отменял. И правильную оценку рисков то же.
А так да. Манагеры никогда не ошибаются, т.к. ничего не делают. :-)
Классно) Не везде уловил сарказм, но основной посыл понял. Жду поста с вредными советами для разработчиков!
А что о них писать. Вредные советы для разработчиков уже давно написаны.
Типа
1) НИКОГДА! НИКОГДА ни при каких условиях не писать тесты, тем более unit-тесты
2) НИКОГДА! НИКОГДА не использовать стандартные библиотеки для работы. ВСЕГДА писать свою имплементацию. Как минимум ОБЯЗАТЕЛЬНО должны быть реализована своя коллекция и HashMap
3) НИКОГДА! НИКОГДА не использовать системы контроля версий.
4) НИКОГДА! НИКОГДА не рефактрить код.
5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
6) ВСЕГДА (ОБЯЗАТЕЛЬНО), весь код должен быть в одном файле/классе
7) ВСЕГДА (ОБЯЗАТЕЛЬНО) использовать кодогенерацию SQL-запросов в виде конкатенации строк
8) ОБЯЗАТЕЛЬНО для интеграции с внешними системами для полей использовать только один тип String/char[]. Для даты написать свой парсер.
9) Документация для слабаков.
10) В название классов, функций и полей использовать как можно больше сокращений и не документированных умолчаний
11) Комментировать таблицы и поля в БД не нужно. В названиях таблиц и полей использовать сокращения и названия типа tmp1, tmp2, table1, table2 и т.д.
12) Все п-сы, а ты Д`артаньян
Типа
1) НИКОГДА! НИКОГДА ни при каких условиях не писать тесты, тем более unit-тесты
2) НИКОГДА! НИКОГДА не использовать стандартные библиотеки для работы. ВСЕГДА писать свою имплементацию. Как минимум ОБЯЗАТЕЛЬНО должны быть реализована своя коллекция и HashMap
3) НИКОГДА! НИКОГДА не использовать системы контроля версий.
4) НИКОГДА! НИКОГДА не рефактрить код.
5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
6) ВСЕГДА (ОБЯЗАТЕЛЬНО), весь код должен быть в одном файле/классе
7) ВСЕГДА (ОБЯЗАТЕЛЬНО) использовать кодогенерацию SQL-запросов в виде конкатенации строк
8) ОБЯЗАТЕЛЬНО для интеграции с внешними системами для полей использовать только один тип String/char[]. Для даты написать свой парсер.
9) Документация для слабаков.
10) В название классов, функций и полей использовать как можно больше сокращений и не документированных умолчаний
11) Комментировать таблицы и поля в БД не нужно. В названиях таблиц и полей использовать сокращения и названия типа tmp1, tmp2, table1, table2 и т.д.
12) Все п-сы, а ты Д`артаньян
5) Как можно чаще (ВЕЗДЕ) использовать case, elseif и т.д.
Можно поподробнее?
Для Java
Видел в одном проекте такую конструкцию ~ 1000 строк и ~100 условий.
Аналогично для switch/case не встречал правда.
Но теоретически ничто не мешает это сделать.
:-)
if(...) {
} else if(...) {
} else if(...) {
....
} else {
}
Видел в одном проекте такую конструкцию ~ 1000 строк и ~100 условий.
Аналогично для switch/case не встречал правда.
Но теоретически ничто не мешает это сделать.
:-)
Но в этом «вредном совете» говорится, что использование как case, так и elseif — плохо. А что тогда?
Если у вас есть elseif и/или switch/case, то скорее всего здесь какая-то проблема.
Не обязательно, что она есть.
Но если при дополнении/изменении требований количество блоков в операторах увеличивается, то точно этот код надо рефакторить.
Не обязательно, что она есть.
Но если при дополнении/изменении требований количество блоков в операторах увеличивается, то точно этот код надо рефакторить.
Можно где-то подробнее про это почитать? Почему, что не так со switch/case, чем вредно и каким образом рефакторить?
Например тут
А нет у вас под рукой коротенького примера/примеров? У меня, например, почти ежедневно получается очень большое количество вот таких ифов: if not empty/null then add to collection или if collection contains
Вот конкретно такие ифы — плохо? Если эти хорошо, то какие плохо? Если эти плохо, то как быть?
Вот конкретно такие ифы — плохо? Если эти хорошо, то какие плохо? Если эти плохо, то как быть?
сами по себе «if» не плохо, а вот когда в функции есть длинный оператор if/elseif, то стоит задуматься, что что-то здесь не так.
Например вот из «прекрасного»
Например вот из «прекрасного»
if(ro instanceof PPPlanItem) {
PPPlanItem ppRO = (PPPlanItem) ro;
if(ppRO.getSource() == 2)
result = prefix + "oebs/showpoint/" + ppRO.getPlanNo();
else if (ppRO.getSource() == -1)
result = "";
else
result = prefix + "plans/show_point/" + ((PPPlanItem) ro).getPlanNo();
} else
if(ro instanceof PPContractHeader) {
PPContractHeader ppcRO = (PPContractHeader) ro;
if(ppcRO.getSource() == null || ppcRO.getSource() != -1){
if(ppcRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1)
result = prefix + "oebs/showagreement/" + ((PPContractHeader) ro).getNumber();
else
result = prefix + "agreements/show/" + ((PPContractHeader) ro).getNumber();
}
} else
if(ro instanceof PPAdvertisementHeader) {
PPAdvertisementHeader pRO = (PPAdvertisementHeader) ro;
if(pRO.getSource() == null || pRO.getSource() != -1){
if(pRO.getProcurementMethod().toUpperCase().indexOf("КОНКУРС") > -1
|| pRO.getProcurementMethod().indexOf("Из одного источника посредством электронных закупок") > -1)
result = prefix + "oebs/showbuy/" + pRO.getNumber();
else
if(pRO.getProcurementMethod().toUpperCase().indexOf("АУКЦИОН") > -1)
result = prefix + "oebs/showauc/" + pRO.getNumber();
else
result = prefix + "publictrade/showbuy/" + pRO.getNumber();
}
} else if(ro instanceof ExpenditurePayment){
result = ((ExpenditurePayment) ro).getPaymentId() + ", " + ((ExpenditurePayment) ro).getPaymentNumber();
}
Ну содержимое ифов можно конечно выделить в отдельные методы, а вот что/как дальше рефакторить? Первое, что приходит на ум это продублировать тип в текстовом поле ro, и использовать его как ключ в мапке с хандлерами, но эта мапка она прямо вот действительно нужна? Если это 1000 ключей то, наверное, да, а если как тут 4?
Отличная как по мне статья на эту тему
UFO just landed and posted this here
Полагаю, что речь идет о чём-то вроде "мой первый калькулятор на питоне"
UFO just landed and posted this here
Смеялся в голос, хотя подняты далеко не смешные темы. К сожалению, некоторое число работодателей совершенно не увидит сарказма в этой статье, и чем дальше от столицы, тем это число больше.
И, самое главное, ещё один плохой совет — "написали же вы прошлый проект, хотя ТЗ раз двадцать поменяли? Значит и без ТЗ сможете!".
Ещё стоит занижать стоимость разработки перед клиентом, чтобы конкурировать с условными "Рога и копыта", тогда разработчикам нужно будет действительно в 2-3 раза быстрее согласованного делать задачи
Sign up to leave a comment.
Вредные советы работодателю. Как “правильно” взаимодействовать с разработчиком