О чем НЕ говорят разработчики или 7 любимых выражений программистов

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

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

    В повседневной жизни я стараюсь не употреблять слово «программист». Оно для меня несет негативный оттенок и сразу вспоминаются 90-е, когда кого только программистами не называли. Они и картриджи у принтеров меняли и бабушкам-бухгалтерам помогали их первый комп осваивать. Помните это нетленное «Ты же программист!»? В общем дискредитировало себя это слово.

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

    001. А у меня на компе работает


    Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы!


    010. Какой мудакпользователь так (с)делает?


    Чувак! Пользователи не мудаки. Это те люди, которые вынужденно или нет пользуются творением рук твоих и что самое интересное платят за это. Зарплата твоя откуда берется? Не знаешь? А я знаю. Тот самый Иннокентий Петрович, которого ты уже 3 раза назвал мудаком, заплатил нам за годовую подписку.
    Наши любимые пользователи круче любых тестеров и выделывают такие финтеля, что все за голову берутся. Но это не их косяк, а наш. Раз сделали, значит мы им это позволили и нам отвечать за последствия и разбираться с ними. В практике мировой индустрии ПО есть не один случай, когда убежденность «Какой мудак так сделает?» приводила к убыткам в сотни тысяч долларов. Ну и кто в итоге оказался мудаком?

    011. Тестеры нифига не протестировали! Чем они там ваще занимаются?


    Чувак! Запомни раз и навсегда, что тестеры не отвечают за качество ПО. Все, что они делают — это измеряют его качество и говорят тебе высокое ли оно, достаточное, либо полная шняга. Отвечает за качество ПО в первую очередь его проектировщики и разработчики. Если ты замутил говнобилд и отдал тестерам, а они там промохали критическую багу и выпустили его в продакшен, то это в первую очередь твой косяк, а не их. Хотя им тоже прилетит за то, что не заметили. Твоя задача разрабатывать код так, как будто ты последний рубеж и за тобою только продакшн и миллионы пользователей. Не надо рассчитывать на то, что тестировщики отловят все баги и у тебя будет возможность их поправить. Никто кроме тебя твой код лучше не знает. Пиши тесты, задавай вопросы, устраняй крайние случаи и да прибудет с тобою сила! В мире немало компаний, где тестировщиков в привычном нам понимании вообще нет. И ничего, живут.

    100. Какой идиот это писал?


    Как не печально, но существует значительная, ненулевая вероятность того, что ответ на данный вопрос окажется таким: «Я? Ёпт!». Нет идеальных людей, все мы делаем ошибки, срезаем углы в условиях жестких ограничений, да и учимся мы писать идеальный код всю жизнь. Большинство нормальных разработчиков тянет поблевать, когда они видят свой собственный код в начале карьеры. И это нормально. Помни об этом и подумай в следующий раз прежде чем называть кого-либо идиотом. Разработка ПО — это командная игра и не стоит портить отношения в команде ради мелкой фигни. Лучше пообщайся с челом и объясни ему что не так в приватном разговоре. Если он адекватный, то будет только тебе благодарен. Либо ты прозреешь, что совсем не исключено.

    101. Готово на 99%


    Это просто классика. Победить это невозможно, но бороться надо. Чувак запомни, когда я спрашиваю статус твоей задачи, в подавляющем большинстве случаев меня интересует ответ на единственный вопрос: «Когда задача будет завершена?». Через час, 2 часа, завтра к вечеру или в пятницу. Меня не очень интересуют интимные подробности твоих непростых взаимоотношений с очередным плагином к jQuery. И уж тем более не надо мне говорить про 99%. Как показывает моя практика 1% может растянуться и на час, и на день, и на неделю. Качественная детализация, планирование и оценка сроков выполнения задач одна из важнейших характеристик зрелого разработчика. Поэтому, когда твой тим-лид в следующий раз спросит тебя о готовности твоей задачи, ты ему четко ответишь «Через 3 часа будет готово» и, что самое важное, сдержишь это обещание. Если ты такую оценку дать не готов, то нужно четко и ясно объяснить почему, и правильно установить ожидания, чтобы никого не подвести.

    110. Это невозможно!


    Чувак. Во-первых, мы оба знаем, что это возможно. Нет таких задач в индустрии, которые не могла бы решить мотивированная команда или разработчик. Когда нам что-то действительно интересно и нужно, мы горы сворачиваем и делаем это. Билл Гейтс написал FAT пока летел на самолете из Нью-Йорка в Сиэттл (знаю, что байка). Если ты говоришь мне «Это невозможно», то это хорошо известный признак выраженной фрустрации, связанной с данной задачей. Самое главное в такой ситуации — это не пытаться придумывать надуманные аргументы и загонять проблемную ситуацию еще глубже. Так можно и до серьезного конфликта дойти. Вместо того, чтобы сказать «Это невозможно!» необходимо просто взять паузу, подумать, остыть, а затем сесть со своим тимлидом или руководителем и проговорить проблему. Если он у тебя адекватный, то решение возникшей проблемы будет найдено и только укрепит твою репутацию.

    111. Я такую ерунду делать не буду.


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

    Спасибо за внимание, с Новым Годом и надеюсь этот пост сделает мир чуть лучше!

    P.S. Извините за немного резкий и фамильярный стиль изложения. Так надо.
    P.P.S. Предлагайте свои паттерны в комментариях. Уверен, я еще не все познал.

    Only registered users can participate in poll. Log in, please.

    Вы кто?

    • 29.8%Программист1051
    • 43.7%Разработчик1539
    • 7.6%Ацкий менеджер или тимлид269
    • 3.7%Эрик Гамма131
    • 15%Сочувствующий529
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 310

      +7
      Редкий случай, когда у меня статья не вызывает диссонанса. Всё так.

      PS всё равно не хочу делать эту ерунду :(

        0
        Распечатать и повесить на стенку. Отличный пост!
          0
          Спасибо!
          +71
          >> Когда я спрашиваю статус твоей задачи, в подавляющем большинстве случаев меня интересует ответ на единственный вопрос: «Когда задача будет завершена?».

          Ну так и спрашивайте «когда примерно задача будет завершена?», чтоб не получать ответы «статус „сине-красный“».

          >> Тестеры не отвечают за качество ПО

          Странные у вас какие-то тестеры… у нас отдел с тестерами называется именно «отдел качества ПО», и именно они по тест-картам, которые составляются по описанию архитектуры и прочим техническим и функциональным тестам, прогоняют всевозможное тестирование: модульное, функциональное, интеграционное… перед тем, как будет принято решение отдавать в продакшн или нет.

          >> Никто кроме тебя твой код лучше не знает

          Баян, но тестеры мучают программы зачастую лучше, чем разработчик.
            –21
            1. Вы ни разу не сталкивались с ситуацией, когда на вопрос «Когда задача будет завершена?» вам начинают рассказывать про «интимные подробности твоих непростых взаимоотношений с очередным плагином к jQuery»?
            2. Про «Тестеры не отвечают за качество ПО» Вы меня к сожалению не услышали. Можно спросить, а за что у вас разработчики отвечают тогда?
              +15
              1. Сталкивался, и исходя из своего опыта и опыта разработчика пытаемся вместе перевести это в человеко-часы. Вам ниже ответили про предсказание будущего.

              2. За разработку ПО по ТЗ, первичной проверке соответствия ПО этому ТЗ. Формально альфа-тестирование. Тестеры отвечают именно за «можно или нельзя ставить ПО на боевые сервера». Они даже не тестеры, а QA, что подразумевает нечто большее. И еще, баги есть везде, и это нормально, это такой же артефакт разработки как и прочие. И это не вина разработчика, что он промухал баг. Хотя получат по шапке все, но не конкретно разработчик.
                +1
                На мой взгляд разработчик должен реализовать ПО по ТЗ и тестировать то, что сотворил в рамках реализации конкретной задачи.
                Если разработчик отдал в отдел качества не проверенную задачу, то почти наверняка она вернется к нему со списком багов. Это так называемая «разработка через ошибки» приводит к:
                — срыву сроков разработки
                — низкому качеству ПО
                — росту команды разработки
                  +2
                  Если разработчик провел проверку и ничего не нашел, но на тестах QA продукт повзрывался, он всё равно вернется и приведет к тому, что вы описали. Но не расстреливать же за это разработчика? Тестирование разработчиком безусловно должно быть, но оно явно не должно быть основополагающим и решающим.
                    –1
                    согласен в таком изложении. Хотя поанализировал бы, почему разработчик не нашел ошибки…
                      +1
                      Возможно потому, что в какой-то момент его отвлекли от задачи очередным емайлом(звонком/обращением/заданием/вопросом) которое вырвало его из контекста текущей разработки или тестирования.
                        +2
                        А еще возможней потому, как мать не может убить своего ребенка — он знает свою систему, и знает, как с ней обращаться, поэтому ему и в голову не придут самые абсурдные юзкейсы, в отличие от человека, которому дан интерфейс, а он даже доку не читал — «все должно быть понятно и интуитивно, и я получу именно то, что хочу, если сделаю так и так». А тараканы в голове у всех разные и самые невероятные.
                        Как говорил Эйнштейн, бесконечны только вселенная и человеческая глупость. А глупыми мы бываем все, и юзеры и разработчики — хотя бы 5 минут в день.
                          +3
                          Как говорил Эйнштейн, бесконечны только вселенная и человеческая глупость.

                          Насчет Вселенной он, кажется, не был уверен.
                    +4
                    Это вы исходите из ситуации, что ТЗ существует и оно вменяемое. Иногда на голову сваливается уже утверждённая и подписанная спецификация, в которой катастрофически не хватает детализации. У аутсорсеров такое часто, особенно если субподряд — заказчик с конечным заказчиком чё-то там договорились, а разработчикам потом хоть стреляйся.
                +23
                Абсолютно с вами согласен. Именно QA отвечают за качество продукта.

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

                Во-вторых, у программиста может никогда не быть таких настроек окружения, в которых тестируют тестировщики.

                В третьих, что самое главное, даже крутой программист — посредственный тестировщик. И ему в голову не придет использовать продукт таким образом, каким это может сделать хороший QA. Ну, или каждый второй «одаренный» пользователь.
                  –3
                  Именно QA отвечают за качество продукта.


                  То есть, если
                  — в среду разработчик Роман отдал код на проверку
                  — в четверг QA Кузьмич нашёл кучу багов
                  — в пятницу релиз и ничего не исправлено и не перетестировано,

                  то за качество продукта отвечает QA? Нет, по уму он в данной ситуации QA даёт информацию о качестве ПО главному на проекте, который должен принять решение о релизе или переносе оного.
                    +3
                    Так всё верно. Проджект менеджер читает отчёт специалиста из QA Кузьмича о найденых дефектах и решает, отправлять ли продукт в продакшен. И тут уже возможны четыре ветки событий:
                    1) Качество ужасное и идти в продакшен нельзя. Тут влетает Роману, поскольку он не смог выпустить продукт в соответствии с ТЗ в разумные сроки.
                    2) Качество ужасное, но ПМ решает идти в продакшен. Компания терпит убытки из-за найденых дефектов, влетает, в первую очередь, ПМу.
                    3) Качество среднее, продакшен, но обнаружилось несколько проблем, не отловленных командой Кузьмича. В этом случае виноват QA, поскольку предоставил неверную информацию о качестве продукта.
                    4) Качество ужасное, ПМ решает идти в продакшен, софтина выстреливает, все счастливы. Роман и Кузьмич едят бесплатные печеньки на кухне, ПМ катается на новом мерсе.

                    При разборе полётов (первые 3 сценария) ПМ всё равно влетит, но причины разные.
                    –1
                    1. Никто не требует от программиста знать код всего проекта, но он должен отвечать за то, что изменил. Если он изменил в одном месте, а в другом из-за этих изменений посыпалось, кто виноват? QA? Кто в первую очередь должен анализировать изменения кода?
                    2. Если будет в проде найден баг, а разраб скажет, что у него это не воспроизводилось, т.к. среда разработки другая, то что, не чиним баг?
                    3. Разработчик обязан выполнить юс кейсы из ТЗ по реализуемой задаче на своей среде разработки. Чтобы не было слез умиления или восклицаний типа «Ой...», когда грозный тестировщик поманит пальчиком крутого программиста.
                      +1
                      Здесь нужно разделить модульное/интеграционное тестирование и функциональное.
                      В первом случае тестирование всецело лежит на программисте, это его зона ответственности.
                      Во втором — тратить силы разработчика на проверку всех возможных вариантов поведения пользователя нерационально, разработчик должен проверять основные usecase'ы, а для всего остального и предназначен отдел тестирования и QA.
                        0
                        а я шо? я только за)
                        но обычно то программисты не проводят модульного тестирования и я как выступаю против этого.
                          0
                          Странно. Я-то думал, что сейчас уже писать свой код не подрывая его хотя бы минимальны набором тестов не принято :)
                        0
                        Вот это вот «кто виноват» ужасно вредный вопрос и ни к чему хорошему не приводит. У нас стали говорить «не кто виноват, а как сделать так, чтобы это больше не случилось». Такой подход гораздо конструктивней и безопасней
                        0
                        QA отвечает за проверку качества, а не за само качество результата разработки.

                        QA проверяет «производное качество» — «качество ТЗ» умножено на «качество разработки». Соответствует ли продукт или фича заявленому производному качеству или нет, и на сколько. Когда результат разработки попадает в QA, эго качество подразумевается, а QA проверив выставляет уровень соответствия качеству. Дальше ПМ решает как быть с результатом разработки такого уровня соответствия… внедрять или править.
                        +5
                        Да, более того, когда программист (разработчик) заканчивает задачу, он устал, глаз замылился, что-то мог упустить и тому подобное. Тестер же полон сил, имеет свежий взгляд и, как верно подмечено в комментарии выше, может так вывернуть данные, как никому и в голову больше не придёт. Впрочем, конечно, это не освобождает от обязанности программиста: так, именно он, зная алгоритм, может прикинуть узкие места, если подумает об этом.
                          +2
                          Видать вы работаете на отличных проектах.
                          У меня на всех проектах тестировщики в мыле, а программисты как раз… нет
                          (соотношение программистов к тестировщикам везде было 2 к 1)
                            0
                            Бывает и такое. Мало тестировщиков, значит, или плохо поставлен процесс тестирования.
                              +2
                              Значит у Вас «программисты» просто не вовлечены в процесс обеспечения качества вашего продукта.

                              Есть же типовые хорошо известные примеры для решения проблемы «занятости», описанной Вами:
                              — программисты дополнительно пишут автоматизированные тесты, тогда в «мыле» круглосуточно может быть система «непрерывной интеграции\тестирования»
                              — тестировщик не забивает на забывает про тест план, тогда программисты могут помочь выполнить ручные тесты, причем четко и формально, т.е. без привнесения своей субъективности разработчика!

                              А, соотношение «2 разработчика и 1 QA инженер хорошей квалификации» является идеальным для большинства случаев.
                              Конечно, бывают исключения. Например, этап багфиксинга может потребовать бОльшее количество QA инженеров, которое может значительно превышать количество разработчиков, поправивших маленький-маленький баг в ядре системы перед выпуском.
                          +6
                          Ну ведь если задача — ерунда, нужно спорить и пытаться это доказать. Задача же менеджера дать понять, что «просто так надо». Часто бывает, что клиент придумал очередную чушь, но не понимает, что это конкретная реальная чушь.
                            +52
                            Пункт 100 очень спорный: «Как показывает моя практика 1% может растянуться и на час, и на день, и на неделю.»

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

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

                            Вы требуете от программиста предстказывать будущее. Ни больше, ни меньше.
                              –42
                              А что вы тогда хотите от руководства? Чтобы он слетало в будущее и рассказало вам будет ли у вас зарплата в следующем месяце? Работая руководителем часто приходится делать вещи, которые никогда еще не делал: работать с клиентом, которого видешь в первый раз, разбираться с налоговиками даже не представляя как. Особенно доставляют сторонние контрагенты и субподрядчики.

                              Вы требуете от руководства предсказывать будущее. Ни больше, ни меньше.
                                +17
                                Эстимейты — не точная наука.
                                +23
                                Тут нужно прояснить очень важный момент: вы платите за работу или за конечный результат? Если второй вариант — претензий нет. Если первый — то вы платите за то, что программист не сидит ковыряясь в носу, а решает проблему. Решил он ее к какому-то вашему сроку или нет — это уже к (де~)мотивации. Но формально он сидел и решал проблему. А значит деньги ему полагаются, и ему пофигу на то, что у вас там с налоговиками. Он свою часть трудового договора выполнил.
                                  –42
                                  А еще есть места где платят за работу? У меня бизнес, а не благотворительность.
                                    +27
                                    Представьте себе. И по моему скромному мнению на таких работах, где платят за работу (а такое могут себе позволить либо гос.компании либо крупный бизнес), разработчикам и прочему ИТ-люду, живется лучше, чем в малом бизнесе, где постоянно горят сроки, царит финансовая нестабильность, а разработчики виноваты в срывании сроков, особенно которые ПМ сам проставил ибо пообещал это заказчику без согласования с разработчиками.
                                      –29
                                      Сочувствую Вам
                                        +35
                                        Судя по вашему посту сочувствовать нужно вашим разработчикам.
                                          –29
                                          Могу познакомить. Они крутые. И даже пишут на Хабре.
                                            +22
                                            Странный показатель крутости, вот если б они были в Форбс… Впрочем, было бы интересно обсудить с ними их отношение к вышеуказанным вами пунктам.
                                        0
                                        Есть люд, который прется от челленджей и решения задач на пределе своих возможностей,
                                        и есть люд, у которого единственная ценность — «чтоб не трогали» и чтобы встать с рабочего кресла ровно в пять вечера.
                                        Вторых в штуках больше (особенно в гос. и крупных компаниях), но я бы не стал их ценности равнять с ценностями вообще всех представителей отрасли.
                                          +9
                                          Челленджи и решения задач на пределе возможностей это интересно многим и в гос/крупных компаниях. Поверьте, у нас тоже есть разработчики, которые не бегут в 5 вечера домой, а засиживаются, если они поймали поток и до вечера, и по выходным. Но, ключевой момент, на который я хотел бы обратить ваше внимание — это чувство стабильности, в частности чувство уверенности в том, что определенного числа будет зарплата. И она резко не уменьшится от того, что он 4 ночи решал убойную задачу, но так и не смог ее выполнить в срок. И именно эту уверенность больше дает крупный бизнес, нежели малый (по крайней мере по моему опыту).
                                            0
                                            Очень часто это чувство стабильности — ложное, разработчиков запросто отправляют на сокращение при кризисе, реорганизации конторы (централизуя разработку в один город и не ваш), смене собственников и т.п.
                                            При этом у очень многих велик соблазн ничего нового не воспринимать и не пытаться, а окопаться на своем десятилетнем говнокоде, который уже сгнил настолько, что его развивать никто не сможет.

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

                                            Я видел людей со «стабильными рабочими местами», которых отправили на помоечку с их большими проектами на дельфи 3 и фокспро. Общаясь с теми кто давно в полиграфической отрасли, я наслышан о множестве тех, кто не осилил перейти с наборных столов на софт для верстки и так же пошел на помоечку (несмотря на работу в крупной и стабильной компании).
                                              +12
                                              Вы правы в том, что даже работа в крупной компании не гарантирует трудоустройства, но там в этом смысле всё честно: либо ваши услуги нужны и у вас их покупают по оговоренной цене, либо они не нужны и вы оказываетесь на улице.

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

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

                                              Далеко не для всех людей этот вопрос является ключевым. Тем более стабильность==отсутствие риска, а без рисков не бывает крупных выигрышей.
                                          0
                                          Если разработчик решает задачу и делает это вовремя (ну или в пределах нормы, кому-как удобнее это воспринимать) — работодатель оплачивает именно работу. Если же разработчик не решает задачу или решает очень долго — гнать такого разработчика, имхо.

                                          Конечный результат — готовый продукт, ни разу не видел, чтобы он оценивался в зп разработчика. Даже «сайты за 5 копеек» оцениваются иначе.
                                            +23
                                            Если вам понравится такое сравнение, то программисты — это как футболисты. Футболист выходит на поле и старается сделать всё для победы своей команды, но случаются и поражения. Однако платить футболисту приходится независимо от результата, потому что поражения неизбежны. Не могут же всегда все побеждать, кому-то приходится и проигрывать. Да, за особо крутую победу можно и наградить сверх нормы, но недоплатить нельзя. Это не благотворительность, а особенность бизнеса, в котором стопроцентный результат невозможен по определению.

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

                                            P.S. А я люблю слово «программист». Оно у меня ассоциируется не с девяностыми, а с рассказами Лема и Азимова. Программист — это звучит гордо, это там же, где космонавт и физик-ядерщик. Неужели какие-то бабушки или бухгалтеры так круты, чтобы перебить большую литературу?
                                              –1
                                              И Стругацкие еще
                                              +12
                                              Проблема в том, что бизнес у вас, а не у ваших сотрудников. Для них это таки работа. И если они выполняют свою работу, а у вас ничего не клеится, то это будут ваши личные проблемы, а не сотрудников
                                                0
                                                Вы не поверите, но во множестве мест платят, даже не за работа, а за то что ты приходишь и сидишь на работе.
                                                Есть 20 рабочих дней в месяце, вот ты должен отсидеть все 20 дней.

                                                Как пример 2 варианта:
                                                1) Программист приходит на работу и 4 часа работает, а вторые 4 часа отдыхает (делает вид что работает или самообучается) и так все 20 дней
                                                2) Программист приходит на работу и работает все 8 часов, но только 10 дней, а остальные 10 дней просто не ходит на работу. (самообучается дома)

                                                Кем будет доволен начальник?
                                                (В моей практике довольны будут 1, а 2 уволят )
                                                  0
                                                  Есть и рациональное зерно в выборе первого: он должен показывать большую работоспособность в общем случае — не пишет код 4+ часов подряд, мозг в половине случаев свежее.
                                                +8
                                                Программист — это как ученый-экспериментатор. Для поиска хорошего решения может понадобиться один эксперимент, а может и пятьдесят. Эдиссон, вон, больше 1000 эксперименов провел, пока лампочку изобретал.
                                                  0
                                                  К моменту, когда он занялся лампочкой, Эдиссон был уже очень состоятельным человеком и мог себе позволить такое количество экспериментов. Наемному разработчику никто подобного не позволит ;).

                                                  Да и как-то не правильно сравнивать разработчика и ученого-экспериментатора. Второй прожигает деньги в надежде получить результат, а от первого требуется результат, иначе он вообще не нужен.
                                                    –5
                                                    Как то вы совсем немного преувеличиваете, чуть менее, чем полностью.
                                                    Программирование в 95% проектов — это рутина от начала и до конца. Это давно уже из элитарного искусства превратилось ремесло.

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

                                                      И не будет этого 1%, который неизвестно когда будет готов.
                                                        –4
                                                        Я не понимаю, где это я назвал программистов лентяями! Хотя да, хороший программист должен быть в меру ленивым, но у этого образа совсем не негативный образ!

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

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

                                                        На двух последних проектах, которые должны быть сделаны за 3 и 4 месяца соответственно, был один и тот же диалог:
                                                        — Чет все надоело…
                                                        — А давайте попробуем новый фреймворк?!
                                                        — А давайте!
                                                        Первый проект закончили за 10 мес и заказчик соскочил. Второй — 7 месяцев. Ну и кто виноват?

                                                        И да, лажают не только программисты. Лажают и ПМ, и аналитики.

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

                                                          +1
                                                          И такие программисты есть, которые не любят изучать новое, приходится их заставлять. Я и предлагаю — чтобы избежать проблем, берите нетворческих людей, таких тоже много. Зачем вы ищете экспериментаторов ))
                                                            +1
                                                            Минусуют как раз творческие люди.
                                                            Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. Пока не понимаю.
                                                              0
                                                              Чтобы изучить фреймворк — ничего творческого. Но который раз я пытаюсь донести мысль, а вы всё в сторону уходите. Ну есть же программисты, профессионалы, которым работа не интересна. Которые работают от забора до обеда. Которые не любят изобретать велосипеды. Нет в документации по фреймворку такой фичи — до свидания, это сделать невозможно. Напишут в поддержку, чтобы фичу под них запилили и будут ждать.

                                                              Вы так хотите работать с такими программистами. Вот мне интересно, что у вас с ними получится.
                                                                +2
                                                                Да вроде я вас хорошо понимаю)
                                                                Многих 35+ летних программистов вы выдели, у которых глаза горят при решении каждой задачи? Я очень редко. Почему? На мой взгляд потому, что они уже перепробовали 1000 и 1 фреймворк/язык и понимают, что в их жизни ну нет творчества.Они зачастую работают с 9 до 18. И просто выполняют свою работу. Или подаются в начальники. Или уходят из профессии. И да, это печально.
                                                                Я знаю, что в twitter, google, jetbrains and etc все иначе. Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.
                                                                А теперь посчитайте, сколько рабочих мест создают первые и сколько вторые. По моим подсчетам хорошо, если 1 к 20.
                                                                Моя мысль не в том, что творчества в программировании нет.
                                                                  +2
                                                                  >>>Но есть также ваяние бизнес фич/отчетов/поддержка бухгалтерии и т.д., где места для творчества почти нет.

                                                                  Там есть некоторое место для творчества, если человек думает о том как он работает, а не тупо переводит с человеческого языка на машинный. Конечно там творчества маленькое, не мирового масштаба, но оно есть. Представьте себе некоторый спектр: пусть абсолютное отсутствие творчества, это рабочий на конвеере завинчивающий гайку, причем, не думая о работе вообще, а чистое творчество — ученый придумывающий единую теорию всего 100% времени. Мне кажется любой программист где-то между этими точками, только от рода его работы и подхода к ней зависит, где именно.
                                                              0
                                                              Если к вам на собеседование приходит человек, который не может рассказать, как работает ArrayList, и вы его таки возьмете на работу, он вам творчески создаст продукт из хромированных костылей.
                                                              Если вы мне объясните, что творческого в том, чтобы изучить то, что сделали другие, я наверное пойму. У абсолютного большинства программистов время сейчас уходит на изучение в основном на изучение чужого.
                                                                0
                                                                Если по себе судить, в одно время я переизобрёл контейнеры STL. Да, не осилил документацию и мне казалось, что я сделаю лучше. В итоге после мучений со своими костылями я сейчас с удовольствием пользуюсь STL и понимаю, почему там сделано так, а не иначе. Знаю несколько нюансов, которых нет в документации.

                                                                Хотя я изобретал их в своём личном проекте, но вероятно сделал бы тоже самое в рабочем, если бы в то время была потребность. С точки зрения работодателя наверное это ужасно, но без этого я бы просто не смог вырасти.
                                                                  +1
                                                                  я же не против — изобретайте, творите, улучшайте. Но сначала изучите то, что уже есть. Это первая заповедь инженера.
                                                                    0
                                                                    О как!

                                                                    Предположим, я хочу пройти курс по машинному зрению (теории категорий, etc, не важно). Но мы ведь взрослые люди и понимаем, что почитав книжку пол-выходного, я ничего толком не изучу. Ну никак, чудес не бывает. Надо серьёзно поработать хотя бы часов 200 на этой теме. А где взять столько времени? Отсюда и «А давайте попробуем новый фреймворк...»
                                                                      +1
                                                                      А в чем противоречие? Если вы начали исследование новой для вас области знаний с книги, значит вы не будете изобретать велосипед по незнанию. Т.е. поступите как хороший инженер. Или ученый, если вам это сравнение больше нравится.

                                                                      Просто я за целесообразность в поступках.
                                                                      Например, если программист говорит «чойта я устал от spring mvc, давайте попробуем play», то где тут здравый смысл?
                                                                      Или другой, весьма самовлюбленный и вместе с тем средний программист, натолкнувшись на свое неумение работать с hibernate, перескакивает на eclipselink. И там совершает другие ошибки, которые выплывают уже на проде. Где тут целесообразность в использовании нового фреймворка?

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

                                                                      Творите, все только выиграют от этого. Но опирайтесь в своем творчестве на знания других, а не на свое незнание.
                                                            +4
                                                            Программирование больше похоже на составление рецепта, чем на выпекание по готовому
                                                              +1
                                                              Отличное сравнение)
                                                              А теперь посчитайте, сколько ресторанов хотя бы с одной звездой Мишлен и сколько заведений, не имеющих их. Что творческого в том, чтобы приготовить картошку по деревенски?
                                                                +1
                                                                Если бы вы отвечали на мой коммент, вы бы написали «создать новый рецепт картошки по-деревенски»
                                                                  +1
                                                                  я все правильно ответил, но давайте отвечу более полно: рецепт нового блюда придумывают доли процента, а готовят по готовому рецепту все остальные.
                                                                  Для первых это может быть творчеством(если было сотворено реально что то хотя бы чуточку уникально и не является откровенным г.), а для всех остальных — рутина.
                                                                    +2
                                                                    В программировании то же самое, только готовое блюдо по рецепту делает робот. Иногда его называют компилятор. Если привлекают человека, значит блюдо по существующему рецепту не подходит иначе бы его просто скопировали
                                                                      +3
                                                                      В-общем, примерно такая же аналогия уже много лет используется в рассуждениях о ПО, например у Мартина нашего Фаулера — попробуйте почитать там.

                                                                      А вот тут повеселее

                                                                      Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
                                                        +2
                                                        Вы знаете, в моей жизни было 3 случая, когда программист называл срок (2-5 дней), в назначенный день назывался новый срок. И так 2-3 месяца. В 2-х первых случаях проекты закрылись и люди не получили всех денег, на которые рассчитывали.
                                                        А ведь люди работали, решали задачи. А выхлопа не было. И по барабану им было на бизнес. Но пострадал и бизнес и люди.
                                                        +25
                                                        Программисты от руководства ничего не хотят. Хотя нет, они хотят ТЗ, которое известно до разработки продукта и не поменяется до его конца. Но очень часто приходится работать не по ТЗ, а по ХЗ.

                                                        Ну нету у менеджера хорошего расписанного ТЗ до начала проекта. Оно устаканится, когда устаканится. А у программиста нету знания сроков завершения его задач. Когда они завершатся, тогда завершатся.
                                                          +7
                                                          Работая программистом тоже весьма часто приходится делать вещи, которые никто никогда еще не делал.
                                                            0
                                                            Строго математически практически любая программа уникальна. Не могу с Вами не согласиться.
                                                            0
                                                            Со многими вашими утверждениями я согласен, но в целом складывается ощущение, что вы стараетесь избежать ответственности. Вам, как руководителю дана власть казнить и миловать, назначать людей и назначать сроки. В первую очередь от ваших решений зависит проект.
                                                            + 001. А у меня на компе работает
                                                            Согласен, я готов был плюнуть в лицо тому разработчику, который так ответил на подробное сообщение о баге. Это может быть оправданием тому, что баг попал в продукт, но не может быть оправданием отказу исправлять этот баг.
                                                            010. Какой мудакпользователь так (с)делает?
                                                            Решение о предполагаемом поведение пользователя должно содержаться в требованиях к задаче. Если вы оставили это решение исполнителю, не удивляйтесь результатам.
                                                            + 011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
                                                            Задача исполнителя качественно выполнять поставленную задачу. Если он допустил ошибку — это его вина. За свой код нужно отвечать самому, тестирование — всего лишь контроль.
                                                            ? 100. Какой идиот это писал?
                                                            Я, как разработчик, имею право выражать своё мнение по поводу умственных способностей других разработчиков. Не относитесь к этому слишком серьёзно :)
                                                            101. Готово на 99%
                                                            Планировать — это задача руководителя. Спихивать её на исполнителя — это очень некрасиво. Оценить сколько времени замёт отдельная задача очень сложно, но когда у вас есть 100 задач, то тут вам на помощь приходит статистика и распределение вероятностей и точность существенно увеличивается. Исполнитель может помочь вам разделив задачи на несколько категорий, например «совсем простые», «понятно как делать», «что-то сложное и непонятное», и статистика по таким группам будет на много точнее. А требовать конкретный срок выполнения в часах, а потом требовать точного соблюдения этого срока — это порочная практика, которая не даст точности и будет держать исполнителей в постоянном стрессе.
                                                            Главная задача исполнителя — сделать хорошо и как можно скорее поставленную задачу. Если он выполняет это, но вы не успеваете сдать проект или продукт не нравится пользователям, то это проблема руководителя.
                                                            110. Это невозможно!
                                                            Если воспринимать дословно, то это безусловно ложь. Но чаще всего разработчик имеет ввиду, что «это делать сложно, а пользы немного». Например выбранный фреймворк этого сделать не может, и придётся сильно его допиливать. Постарайтесь в этом случае выяснить на сколько сложно это будет сделать, самостоятельно оценить выгоду от задания и принять решение, стоит ли оно того.
                                                            + 111. Я такую ерунду делать не буду.
                                                            Это не ответ истинного джедая, такой ответ конечно принимать нельзя. Возможно разработчик не понимает важности данной задачи. Постарайтесь объяснить ему, какой профит принесёт проекту эта задача, тогда её выполнение принесёт удовольствие разработчику и он с радостью её сделает.

                                                            Ну вот, а хотел написать короткий ответ по конкретному вопросу :)
                                                              0
                                                              Постарайтесь объяснить ему, какой профит принесёт проекту эта задача, тогда её выполнение принесёт удовольствие разработчику и он с радостью её сделает.

                                                              Только если он этот профит проекта примет как личный профит. Грубо говоря, если задача увеличит доход на 10%, а программист не получит даже разовой премии, то…
                                                          • UFO just landed and posted this here
                                                            +10
                                                            тестеры не отвечают за качество ПО

                                                            Позволю себе не согласиться. В нынешние времена понятие/профессия «тестер» все больше упраздняется, на замену этому давно пришел QA (Quality Assurance), который как раз таки отвечает за качество ПО. И на этапе проектирования, и на этапе разработки, и на этапе отправки в продакшн и после оной.

                                                            И, простите уж меня, зануду, но
                                                              +1
                                                              Цитата из книги Джеймса Баха Lessons Learned in Software Testing:
                                                              It’s all too easy to think of yourself as the guardian of quality. But you [QA] don’t create quality, and you don’t take it away. [...] Quality comes from the people who build the product, and that is sometimes a heavy burden for them to bear.
                                                                +2
                                                                Это не отрицает того факта, что QA гарантирует ее (кволити) конечному пользователю. Соответственно является ответственным за то, что гарантирует.
                                                                  0
                                                                  А каким образом QA, который не написал ни строчки кода, может гарантировать качество этого самого кода? Он может только констатировать его качество. Иначе у вас получается, что во всех сырых продуктах виноват QA отдел.
                                                                    +3
                                                                    QA гарантирует качество продукта, а не кода. Для гарантии качества кода существует код-ревью. Насчет того, кто виноват — так виноваты по итогу все — и разработчик, и куа, и менеджер. А вообще, как выше уже упоминалось, во многих компаниях, тестировщики/куа как таковые отсутствуют. Есть SDET'ы (например, в Мелкософт), которые как бы и тестированием занимаются, но в разрезе всяческих аджайл-практик (TDD, BDD, ATDD). Кстати, этот подход мне более всего импонирует, т.к. и в QC, и в QA как в отдельной единице команды я все меньше вижу смысла в последнее время
                                                            • UFO just landed and posted this here
                                                                +2
                                                                Многие вещи понимаешь только тогда, когда переходишь на другую сторону силы. Когда ты являешься разработчиком, всё это работает почти на уровне рефлексов :)) Подсознательное желание не тратить время на глупые (с твоей точки зрения) вещи.
                                                                  0
                                                                  Согласен. Разработчик с опытом обеспечения уверенности в качестве продукта очень дорогого стоит.
                                                                  +2
                                                                  На мой взгляд, слишком категорично.

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

                                                                  Практический любой пункт имеет право на жизнь, если добавить после фразы обоснование.
                                                                    +75
                                                                    001. А у меня на компе работает

                                                                    Как правило, такое начинают говорить в ответ на N-цатое к ряду сообщение от QA/пользователя, состоящее из слов «у меня не работает». Причем, как показывает практика, в половине случаев проблема в рука/голове QA/пользователя. Так что это такая тактичная вариация на тему: «Отвали или скажи человеческим языком, что не так».
                                                                    010. Какой мудакпользователь так (с)делает?

                                                                    По ситуации. Иногда кто-то гордо отстреливает себе ногу, жамкая не глядя на «OK» в messagebox'ах с восклицательными знаками, а потом начинает вопить: «Усе пропало!11». Мудаков по ту сторону хватает, а удовлетворение мудаков не входит в должностные обязанности разработчика — за этим в саппорт.
                                                                    011. Тестеры нифига не протестировали! Чем они там ваще занимаются?

                                                                    Опять-таки ситуационно-справедливое утверждение: если фатальные проблеы возникли в экзотических конфигурациях, а разработчик проверил на одной-двух общеупотребительных, кто тут виноват? И поправьте меня, но время разработчика стоит дороже времени QA, так что тщательное и всестороннее тестирование программистом идет в убыток компании.
                                                                    100. Какой идиот это писал?

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

                                                                    Проблема заключается в том, что вопрошающий, как правило, страдает от крайней степени безделия. И реалистичная оценка «через пару дней» вызовет массу вопросов: «А почему так долго? Да это же как два байт переслать! Да я на школьной олимпиаде такое за 20 минут кодил...» — начиная с какого-то момента становится проще «кормить завтраками», чем проводить разъяснительную работу с человеком, которого «интимные детали не интересуют».
                                                                    110. Это невозможно!

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

                                                                    Это политкорректный вариант: «Ты меня вусмерть достал, сейчас напишу заявление и ищи других идиотов, которым будешь парить мозг».

                                                                    Если в твоей команде часто всплывают озвученные высказывания, это повод призадуматься над вопросом: «Толи лыжы не едут, толи я какой-то-не-настолько-грамотный-руководитель».
                                                                      –79
                                                                      Ужас какой у Вас в голове…
                                                                        –8
                                                                        Хочу просто выразить с вами солидарность, не расстраивайтесь, вас минусуют убогие программисты (как и меня видимо), а не разработчики. К сожалению, таких пока что большинство. Ну на хабре так точно.
                                                                          –7
                                                                          Подтверждаю!
                                                                            0
                                                                            Если минусуют убогие программисты, то пусть плюсанут разработчики.
                                                                            0
                                                                            Да просто аудитория хабра сильно помолодела, вот отсюда и непонимание вас.
                                                                            +23
                                                                            Прямо таки с языка сняли:)
                                                                            Отличное дополнение исключениями к правилам в самой статье.
                                                                              +13
                                                                              Добавлю, по последним двум из РЕАЛЬНОЙ практики:
                                                                              110 — заставляли пропихнуть по RS485 (ModBus) поток в несколько раз больший чем возможно — 100 раз в секунду опрашивать 50 показателей, плюс ещё кучу всего раз в полсекунды (ещё около 200 параметров). Пофиг на скорость работы RS485 и на протокол ModBUS, устройство с которого тягались данные просто не успевало формировать их с указанной в ТЗ скоростью. Вывод: Невозможно. Компромисс 25 раз в секунду с постобработкой данных.

                                                                              111 — пихать SQL запросы к защищённой корпоративной СУБД Oracle напрямую по незащищённому каналу передачи данных по внутреннему протоколу. Мало того что небезопасно так и требуется УНИВЕСАЛЬНОСТЬ отдачи данных, и работать должно с ЛЮБОЙ СУБД, будь то оракл, линтер или вообще файловая база на XML. Предложенный мной безболезненный и универсальный метод обхода проблемы (расширение протокола соответствующими заголовками и обёртка над СУБД библиотеками) был отвергнут как «Работать программисту с SQL запросами проще». Что с этим было уже не застал, т.к. уволился. :)
                                                                              0
                                                                              Только Гамма не Эрик, а Эрих (Erich).
                                                                                –6
                                                                                Я долго думал какой вариант поставить. Решил все-таки на Эрике остановиться :-)
                                                                                +30
                                                                                В трех битах 8 значений, отсутствие антипатерна 000 режет глаз, очевидно, автор не программист и не developer.
                                                                                  –32
                                                                                  Я точно не программист согласно моему же определению. А насчет своих качеств как разработчика готов поспорить :-)
                                                                                  +21
                                                                                  Вот оно, подросло новое поколение КЭПов. Вырвалось из своих школьных застенков и несет в мир неоспоримые ценности.
                                                                                  Спасибо юный КЭП.
                                                                                  И да, кстати, ты более не достоин звания ШКОЛОТА, и теперь мы все видем как ты встал на тропу взросления. Да, еще остались словечки вроде «Чувак», и злотворное влияние «Камеди Клаба» в виде мата в заголовках, но ничего, Хабрахабр выкует из тебя настоящего человека, правильным путем идете товарисч.
                                                                                  Ждем от вас статей из серии, == сравнивает значения а = присваивает и это не одно и тоже, и бесцелера, единица не ноль, чувак, усвой это раз и навсегда!!!
                                                                                    0
                                                                                    может и не выкует настоящего человека — у него больше сотни раз менялся рейтинг, а в итоге всего +6 — кажется мне, что заминусуют его раньше
                                                                                      –9
                                                                                      > и теперь мы все видем как ты встал на тропу взросления
                                                                                      Тоже мне, папаша. Умные (али как тебе удобно «взрослые») люди себя так не ведут. Да и пишут пограмотнее.

                                                                                      > злотворное влияние «Камеди Клаба» в виде мата в заголовках
                                                                                      Ну и сидите на своих «аншлагах» да «бенни хилсах». В «Камеди», а так же его ответвлениях, есть много интеллектуального юмора, откинув ширпотреб из пошлости.

                                                                                      > Хабрахабр выкует из тебя настоящего человека
                                                                                      А из тебя уже вряд ли.
                                                                                        +4
                                                                                        Не могли бы вы привести пример интеллектуального юмора из камеди клаба?
                                                                                          –8
                                                                                          Посмотрите Костю Пушкина, Белого, или того же Слепакова с его песнями. Наша раша вон, полна сарказмом и иронией: от заботливых депутатов до антикоррупционной борьбы с преступностью. Вполне интеллектуальный юмор.
                                                                                            0
                                                                                            Сергеича забыли. Вот уж кто пошутит, так пошутит
                                                                                          +2
                                                                                          Интеллектуальный юмор есть в КВНе, «Вечернем квартале» и шоу «Уральских пельменей». Может быть даже в «ХБ».
                                                                                          В «Камеди Клабе» — матершинный двор — интеллектом и не пахнет. Не в деньгах и приглашенных гостях он меряется. Там остались буквально единичные личности, которые хоть как-то более-менее в рамках цензуры и здравого смысла шутят…

                                                                                          UPD: прочел ваш коммент от 12:24.
                                                                                          У нас явно разные критерии интеллектуального юмора… «Наша Раша» — вообще трэш ещё тот — интеллекта там ещё меньше чем в «КК».
                                                                                            –3
                                                                                            Да. Разные, как и люди. Что вы все заладили, цензура, матершинный двор, будто это так страшно, что аж… что аж страшно… :) Вы почитайте Есенина или Маяковского и спросите у них, почему они такие гении и не смогли без мата некоторые свои труды написать. Того же Маяковского я читал в детстве, так как у него тоже есть детские стишки, и ничего же. Молодец же он :) Это всего лишь жанр такого искусства, и не более… выражение чувств, эмоций.
                                                                                        0
                                                                                        Не ожидал увидеть видеть такой пост заминусованным. Видать, вы кого-то за живое задели :)
                                                                                        • UFO just landed and posted this here
                                                                                            –10
                                                                                            > появился еще один человек, указывающий, кому место в профессии а кому нет

                                                                                            Неа, вам никто ничего не указывает. Автор просто написал статью на хабр, используя стиль, который, возможно, позволит лучше донести определенные мысли и взгляды, заострить внимание на обсуждаемых проблемах. А вы (и, судя по всему, многие другие) почему-то очень лично текст восприняли. Мне так кажется.
                                                                                            –1
                                                                                            А на самом деле вполне предсказуемая ситуация. Чувак :) (он же автор) рассказал свою точку зрения менеджера. А менеджеров уж очень не любят разработчики (а их по голосованию 32%+41%), да и тем более обсуждаются часто возникающие фразы и ситуации, которые направлены не в пользу программистов, а на пользу всего проекта в целом. Вот и обиделись! С кем не бывает! А кто-то даже может на этом спекулирует, мол, поддержку большинство, КАРМАвознесут мое почтение! И будет счастие, тоже смогу опускать комменты и посты! А чо… тоже власть…
                                                                                            +33
                                                                                            no offence, но уж больно типичная позиция «я крутой бизнесмен делаю деньги а вы все исполнители и должны служить мне хорошо» сквозит в этом посте.
                                                                                            В общем, вспомнилось видео про семь красных линий. И в очередной раз подумалось, что человек без опыта работы техническим исполнителем (программистом, разработчиком — как хотите называйте) не особо-то достоин оказаться на позиции управленца в техническом проекте.
                                                                                              –22
                                                                                              Григорий, раз уж Вы прочекали мой хабрапрофиль, ты сделайте нормальный due diligence и я уверен Вы измените свое мнение обо мне
                                                                                                –21
                                                                                                Машин, вина и азартных игр я кстати ничуть не стесняюсь :-) Мне они действительно нравятся, как и огромному количеству других разработчиков.
                                                                                                +9
                                                                                                Это невозможно — потому что это займет много времени, очень много времени, вы сначала будете ходить два дня, пытаясь выторговать строки по-меньше, рассказывая «вот Вася П. сделал бы, вот я бы сделал бы», потом соберете заседание с таких же тупых и совершенно оторванных от деталей реализации чуваков, после придете и скажете — мы тут подумали, на это уйдет два дня, так и пропишем. Хотя на это по доброму, чтобы оно работало, и работало без проблем, нужно как минимум две недели. Пример утрированный, но это невозможно — зачастую это попросту слишком долго, девелопер уже имел проблемы с чуткой оценкой и попытками ей соответствовать, и ему на*** не надо еще раз это делать. Или другими словами — очень много менеджеров — тупые мудаки, которых непонятно как и за что взяли на работу — они совершенно ничего не понимают в работе тех, кем должны управлять.
                                                                                                  +9
                                                                                                  По поводу пункта 111: меня как то попросили сделать логарифмическую шкалу с нулем.
                                                                                                    +1
                                                                                                    а меня просили научить приложение сохранять Gif анимацию с промежутком между сменой кадров равным нулю.
                                                                                                      +2
                                                                                                      Следующий полупрозрачно накладывать на предыдущий?
                                                                                                    +4
                                                                                                    Еще бывает разновидность 110 — сделать конечно возможно, но оно не имеет смысла.

                                                                                                    Нам как то заказчик дал задание, что то типа психологического теста с подсчетом баллов по хитрой формуле, а по получившимся баллам определять результаты. Так вот, по тестам диапазон баллов получался от 0 до 15, а диапазоны для вычисления результатов были от 0 до 70 (диапазоны для примера, деталей уже не помню).

                                                                                                    Долго спорили с заказчиком и доказывали что где то явно ошибка — он реагировал так же как пишет ТС:
                                                                                                    «Вы можете как в ТЗ сделать? Можете! Значит делайте».
                                                                                                      +1
                                                                                                      Все 7 выражений суть «Отвали» и «Плевать». Именно они — шаблоны поведения, требующие изучения причин. А причины у компаний свои, что и вызывает острую дискуссию, где каждый прав в контексте своей ситуации.
                                                                                                        +3
                                                                                                        Это невозможно!

                                                                                                        А что, очень часто это действительно невозможно. Особенно если ставившему задачу предложить несколько вариантов когда что-нибудь можно выкинуть из ТЗ и всё станет возможно, а он упирается, ему нужно всё и сразу, все требования критические и нужны обязательно. Тогда это действительно невозможно и точка.
                                                                                                          +5
                                                                                                          Запомни раз и навсегда, что тестеры не отвечают за качество ПО. Все, что они делают — это измеряют его качество и говорят тебе высокое ли оно, достаточное, либо полная шняга.


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

                                                                                                          Безусловно это не значит, что разработчики не отвечают за качество тоже, хоть и несколько иначе. Но вот так вот сделать отдел контроля качества — отделом красивых репортов…

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

                                                                                                            1. Ответственность за качество продукта несет руководство компании. (см. семейство стандартов ISO 9000 — толковые документы, если используются не только для формальной сертификации компании и получения золотой таблички на стенку офиса)
                                                                                                            2. В компании знают более корректный перевод слова «control» — «управление», соответственно, Quality Control переводят, как Управление качеством. Тогда не возникает ассоциаций с «контролером-вахтером-билетером».
                                                                                                            3. QA специалист знает, что управление качеством тесно связано с метрологией, а метрология — с различными измерениями. Поэтому, QA специалист знает и умеет производить различные измерения и несомненно делает это в процессе удостоверения качества программного продукта.
                                                                                                            4. В процессе обеспечения качества продукта участвуют все сотрудники организации, вовлеченные в процесс его производства.

                                                                                                            а в остальном у Вас всё точно :-)
                                                                                                            +15
                                                                                                            Я как-то привык своих людей называть разработчиками (developers)...

                                                                                                            А я уж подумала Вы их «чуваками» называете.
                                                                                                              0
                                                                                                              Интересно что пост никто не минусует а вот автора в комментах заминусовали)). Мысли в посте все-таки правильные, просто немного категорично высказаны, а в комментах и с переходами на личности. Peace!
                                                                                                                +3
                                                                                                                Если навести мышку на рейтинг поста, будет видно кол-во голосов «за» и «против»:

                                                                                                                image

                                                                                                                Так что и минусуют, и плюсуют пост. Почти поровну.
                                                                                                                  –7
                                                                                                                  Знал, что будет хабрасуицид. Приятно удивлен, что рейтинг в плюсе. Пока. Очень неоднозначная тема получилась. Явно на больное наступил.
                                                                                                                  • UFO just landed and posted this here
                                                                                                                      –3
                                                                                                                      Это же всего лишь статья на Хабре, а не пособие на все случаи жизни и не воинский устав. Я не случайно в самом начале написал, что недолюбливаю шаблоны. Это взгляд со стороны на РЕАЛЬНЫЕ антипаттерны для разработчиков. Допускаю, что многим такое резкое тыканье носом не понравилось. Да и хватает говноменеджеров с их говнометодами и для кого-то некоторые высказывания как красная тряпка. Но это всего лишь статья на Хабре :-) Интересно — читай и делай выводы. Не нравится — проходи мимо. Жизнь сама все по местам расставит.

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

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

                                                                                                                        Не слишком ли скромный критерий успеха для человека который управляет разработчиками — а они и есть аудитория статьи?
                                                                                                                          –2
                                                                                                                          Статья — хорошая, давно ждал подобного, чтобы не спорить с отдельными разработчиками по каждому поводу. Взятая позиция в комментариях — неудачная. Не потому что неправильная (а как тут вообще можно судить о правильности?), а потому что направлена на вызов баттхерта, и успешно его вызывает. Вот и бьют в ответ, как могут. Хотя определенно есть и возражения по делу.
                                                                                                                        +14
                                                                                                                        > Явно на больное наступил

                                                                                                                        Ага, приятно так считать, когда многие не согласны со сказанным. Типа это дураки злобные, а я в белом.
                                                                                                                          –1
                                                                                                                          Я так не считаю, не надо мне приписывать того чего нет. Количество плюсов и минусов у статьи на мой взгляд показательно. Определенно многим она показалась полезной и интересной. Хотя точно также многим увиделась злобной и пафосной. Богатство и полярность мнений — это замечательно.
                                                                                                                            0
                                                                                                                            > Я так не считаю, не надо мне приписывать того чего нет.

                                                                                                                            Где я приписываю. Это ваши слова (цитирую) «Явно на больное наступил». Откуда тогда такая уверенность, как не из желания считать себя в белом.
                                                                                                                      0
                                                                                                                      Напомнило черную книгу менеджера.
                                                                                                                        –9
                                                                                                                        Лучшая похвала. Серьезно. Спасибо!
                                                                                                                        +10
                                                                                                                        На Хабре есть замечательная статья Как из болота вытягивать ITшника или об общении в стрессовых ситуациях . Почти все приведенные «антипаттерны» из вашего топика отлично укладываются в модель реакций из той статьи (отрицание — 001, 011 гнев — 010, 011, 100, торг — 110, 111, депрессия, принятие ).

                                                                                                                        Таким образом, использование этих антипаттернов подчиненными Вам людьми не что иное, как нормальная человеческая реакция. Скажу больше — такая реакция чаще всего говорит не в Вашу пользу. Не хотите получать антипаттерны в ответах, не пользуйтесь антипаттернами в вопросах. Поменяйте модель вашего поведения и люди не будут Вам в ответ говорить эти слова. Ваша задача, как руководителя: не допускать перехода собеседника в состояние гнев и депрессия, а стремиться максимально быстро дойти до состояния принятия.
                                                                                                                          0
                                                                                                                          А давайте на примере разберем. Ситуация следующая. От клиента пришла критичная бага, тестеры посмотрели — воспроизводится, назначили на Вас Артем. На следующий день я у Вас интересуюсь «Артем, что у нас с багой 4567, до сих пор открыта, а приоритет — топовый?». Вы мне отвечаете: «А у меня на компе все работает, не могу воспроизвести». Немного утрирую, но тем не менее что я сделал не так?
                                                                                                                            +9
                                                                                                                            Не наладили коммуникацию между Артемом (у которого не воспроизводится) и QA (у которых воспроизводится)?
                                                                                                                              0
                                                                                                                              А что значит «не наладили» если до этого Артем и QA общались друг с другом много, много раз?
                                                                                                                                +2
                                                                                                                                Ок, если рассматривать ситуацию налаженных коммуникаций, то может тогда следует вникнуть в причину, по которой QA и разработчик так и не смогли сделать так, чтоб баг воспроизводился у разработчика? Не рассматриваете ситуацию, что QA и разраб всю ночь пытались воспроизвести у разраба, но так и не смогли и не нашли причину, по которой в окружении разраба всё работает, а в окружении тестера — нет?
                                                                                                                                  0
                                                                                                                                  Очень даже допускаю, что ситуацию объясняет, но никак не приближает нас к ее решению. + Все-таки что я сделал не так? Вернемся к нашему самому первому вопросу. Вы считаете ответ «А у меня на компе все работает» приемлемым?
                                                                                                                                    +1
                                                                                                                                    Ну если вы при этом уточнили, что проблема в том, что не могут понять почему в одном месте воспроизводится, а в другом нет, и при этом они работают над проблемой — вы можете лишь ждать.

                                                                                                                                    Ответ «А у меня на компе все работает» — нет, а вот ответ «А у меня на компе все работает, не могу воспроизвести» — для меня было бы приемлемо и я бы полез изучать вопрос глубже.
                                                                                                                                      0
                                                                                                                                      Т.е. в конечном итоге мы пришли к общему знаменателю как я надеюсь. И для Вас, и для меня ответ «А у меня на компе все работает» является неприемлемым в такой ситуации. И тем не менее тысячи разработчиков каждый день так делают. О чем собственно и статья.
                                                                                                                                        +2
                                                                                                                                        Заметьте, что вы пришли к общему знаменателю только после серии уточняющхе комментов. Могло быть «у меня не воспроизводится и они не могут повторить еще раз» или «у меня не воспроизводится, я послал письмо с уточняющими вопросами и они пока не отвечают». Мне кажется, или в каждом пункте нужно пояснение с разбором РАЗНЫХ ситуаций или этот список тривиален. То есть у тех, кто не понимает о чем идет речь такое вызовет только раздражение а остальным просто ничего не даст
                                                                                                                                          0
                                                                                                                                          Был у меня на прошлой работе баг… Воспроизводился только в Сафари, только на Маке, у ПМ в ЛосАнжелесе. Ответ был — не могу воспроизвести. Ну не покупать же Мак для мелкого бага с отображением :)
                                                                                                                                          А баг тот так три месяца и провисел пока я там еще работал…
                                                                                                                                            0
                                                                                                                                            Очень интересно, не связано ли это с ошибкой в обработке/парсинге дат в Сафари на Маке…
                                                                                                                                              0
                                                                                                                                              У меня на такой случай 2 виртуалки: Виндовс для IE и Mac для сафари и iOS(хотя iPad в офисе был, но бывал занят).
                                                                                                                                                0
                                                                                                                                                Не, локально не получилось бы, а пробрасывать ВПН — там какие то вечно проблемы были, помнится.

                                                                                                                                                Я как-то раз настраивал, консультируясь с чуваком хорошо в этом разбиравшемся. Но через время та система та умерла, а мужик уволился)
                                                                                                                                                0
                                                                                                                                                А нельзя было удалённо подключиться к майку менеджера для отладки? Включить логгирование для него? Виртуалки с макос бывают?
                                                                                                                                                  0
                                                                                                                                                  Ну, проблема в том что разработка была только на удаленном сервере — локально поднять было очень сложно все зависимости, просто посмотреть удаленно не вариант, мак тот был не девелоперский и доступа к сандбоксам у него не было, виртуалку под убунтой ставить чтобы она могла конектиться через впн к удаленному серверу я не умел.

                                                                                                                                                  Вобщем городить огород на несколько человекочасов ради визуального бага не всегда даже на маке имевшем место ( на других вроде не было, не помню уже ) — было слишком уж.
                                                                                                                                                    +1
                                                                                                                                                    Это скорее вонтфикс чем норепро
                                                                                                                                        +2
                                                                                                                                        Простите, а вы уверены, что вы знаете, что такое «менеджер»?
                                                                                                                                      +4
                                                                                                                                      Я не говорю о клинических случаях кретинизма среди подчиненных. Ваш пример говорит о некомпетентности сотрудника и подтверждает Ваши тезисы. Но есть примеры, которые Ваши тезисы опровергают (см. мой комментарий ниже).

                                                                                                                                      Т.е. условно «все матери — женщины, но не все женщины — матери». Я согласен, что плохие специалисты часто используют Ваши антипаттерны. Я не согласен с тем, что использование антипаттернов говорит о том, что специалист — плохой и не может носить гордое звание «разработчика»
                                                                                                                                        –9
                                                                                                                                        Артем,

                                                                                                                                        Нескромный вопрос, но тем не менее, с каким количеством разработчиков Вам приходилось иметь дело по жизни в качестве руководителя? Моя практика непосредственной работы с сотнями из них подтверждает, что даже самые талантливые и крутые из них регулярно выдают эти самые паттерны и именно в режиме «клинических случаев кретинизма», как Вы их описываете. А они далеко не кретины. Я общался со многими другими лидерами айтишных команд и у них вся та же симптоматика регулярно возникает. Не встречались еще мне исключения. Неужели Вам совсем приведенные шаблоны не знакомы в вашем коллективе?
                                                                                                                                          +3
                                                                                                                                          У меня ситуации бывают и посложнее в том смысле, что мне приходится доказывать разработчикам, что они не правы, и при этом я не являюсь их руководителем :). И шаблоны мне ваши знакомы. Я просто не пытаюсь оценивать уровень разработчика по факту использования этих шаблонов. Я просто стараюсь решить возникшую проблему, не давая оппонентам лишних поводов использовать шаблон.

                                                                                                                                          Вы же сами говорите, что даже самые талантливые и крутые используют шаблоны. И они не кретины. А это значит, что на лицо «классический дебют»: е2 — е4, дурак — сам дурак и т.п. В этом случае нужно просто рвать шаблон пока отрицание оппонента не сменилось гневом. Иногда достаточно просто спросить: что тебе нужно, Вася, чтобы решить проблему в кратчайший срок?
                                                                                                                                            0
                                                                                                                                            Дак и я не оцениваю. Опять же Вы приписываете мне те качества, которых у меня нет. Просто я отношусь к разработчикам как к взрослым, самостоятельным личностям, отвечающим за свои слова и поступки, а не как к детям маленьким, которых нужно оберегать, холить и лелеять, а не расстраивать суровыми реальностями окружающего мира.
                                                                                                                                              +1
                                                                                                                                              Зря :) Разработчиков как раз зачастую надо оберегать, холить и лелеять :) habrahabr.ru/post/146169/
                                                                                                                                                –3
                                                                                                                                                Моя задача создать им все необходимые условия для эффективной работы и достойно ее оплачивать. Оберегать, холить и лелеять — это к мамам этих разработчиков или женам.
                                                                                                                                          –2
                                                                                                                                          «Я не согласен с тем, что использование антипаттернов говорит о том, что специалист — плохой и не может носить гордое звание «разработчика»»
                                                                                                                                          + Тут Вы мне приписываете высказывание, которого я не говорил.
                                                                                                                                            +4
                                                                                                                                            Так название статьи об этом говорит: О чем НЕ говорят разработчики или 7 любимых выражений программистов
                                                                                                                                            При этом в вводной части Вы поясняете, что термин «программист» — носит негативную окраску, а «разработчик» — наоборот.

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

                                                                                                                                            Моя мысль, если кратко: Лучше употреблять антипаттерны в речи, но при этом в итоге решать проблему, чем не употреблять и при этом не решать проблему. Плохой, потому что не справился, а не потому что позволил себе высказаться в процессе.
                                                                                                                                              –3
                                                                                                                                              Сложно с Вашей мыслью не согласиться, но все-таки речь, как правило, имеет отношение к сознанию. Как говорят «что на уме, то и на языке». И употребление антипаттернов в речи таки непосредственно коррелирует с поведенческими шаблонами.
                                                                                                                                                +3
                                                                                                                                                А если посмотреть на ситуацию с другой стороны? Человек, вступивший в диалог обозначил свое отношение к проблеме, пусть и с использованием антипаттерна. Т.е. он поднял «флажок», что проблема выводит его из зоны комфорта. И вы видите этот флажок и можете на него реагировать — помочь, подсказать, подключить дополнительные ресурсы. А другой просто промолчал. Вы восприняли его молчание, как согласие и ждете сообщения о решении проблемы. А в итоге время упущено, а проблема так и не решена.
                                                                                                                                                –2
                                                                                                                                                + Я думаю Вы знакомы с таким выразительным приемом как гипербола. Меня пугает, что столько людей все написанное восприняли буквально.
                                                                                                                                            +4
                                                                                                                                            Скорее всего, просто кинули на Артема баг в джире, вместо того, чтобы, зная, что Артем так может сказать, подойти к нему, обьяснить, как важно починить именно этот баг, убедиться, что у Артема все есть, чтобы с этим разобраться и сделать вовремя.

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

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

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

                                                                                                                                              ПС. Ну или наняли плохово программиста, который вам банально врет.
                                                                                                                                              +12
                                                                                                                                              Уточню по поводу «антипаттернов» в вопросах.

                                                                                                                                              А у меня на компе работает чаще всего является ответом на наезд без конкретики из серии «У нас ничего не работает!!!». Пользователь пишет это в BugTracking, копию отправляет начальству, и при этом у меня нет никаких данных, чтобы начать анализ проблемы. И в ответ я включаю «отрицание»

                                                                                                                                              Какой идиот это писал? — это обычно реакция на просьбу не в зоне ответственности исполнителя. Например: «Привет, там Вася два месяца писал код, но не успел закончить до отпуска. Заказчику я пообещал, что фичу накатим сегодня, там кое-что поменять надо, но дел буквально на 5 минут. Ты разберись и сделай по-быстренькому»

                                                                                                                                              Это невозможно и Я такую ерунду делать не буду обычно случаются, когда начальство считает, что лучше меня разбирается в системе и моем коде. Или когда «хотелка» выходит за рамки треугольника «срок-бюджет-качество», при этом начальство треугольник расширять не хочет. Невозможно в данном контексте относится к нереальному по моему мнению бюджету/сроку, а Ерунда к моему нежеланию снижать качество продукта костылями.
                                                                                                                                                –3
                                                                                                                                                Артем, возможно я не прав, но все-таки в большинстве случаев для приведенных Вами ситуаций объяснения гораздо проще и банальнее. На тему «Какой идиот это писал?» даже уже мем есть про «фатальный недостаток» любого кода. Это не отрицает возможности и существования более сложных ситуаций, описанных Вами.
                                                                                                                                                  +1
                                                                                                                                                  «Какой идиот это писал?» — это просто выплеск эмоций. Чаще всего возникает как реакция на неожиданную стрессовую ситуацию. Когда человеку на ногу падает кирпич, человек, конечно, может прореагировать спокойно. Но я не буду осуждать такого человека, если он позволит себе пару крепких выражений. И это точно не будет являться для меня критерием оценки его, как личности в целом.
                                                                                                                                                    –2
                                                                                                                                                    Мне кажется Вы опять усложняете и ищете оправдания. Если для разработчика покапаться в чужом коде — неожиданная стрессовая ситуация, то это как бы немножко не профессионально?
                                                                                                                                                      +2
                                                                                                                                                      Править чужой код всегда стресс, но профессионал с этим справляется. Если за спиной не стоять с секундомером. Я утрирую, но в штатной ситуации править чужой код обычно не заставляют.
                                                                                                                                                        0
                                                                                                                                                        Есть очень много разных штатных ситуаций, почитайте например про collective code ownership. Да и в опенсурсе сплошь и рядом. Конечно, это требует навыка.
                                                                                                                                                          +1
                                                                                                                                                          Вы упустили ключевое слово — заставляют. Если в конторе практикуют методологии коллективного владения кодом, то это штатная ситуация, в которой эмоции типа WTF? и Какой идиот это писал? просто не возникнет. В opensourсе Вы тоже идете вполне добровольно.
                                                                                                                                                            0
                                                                                                                                                            Вы вначале написали «Править чужой код всегда стресс» я так понял что всегда, получается, и заставляют. Но если акцент на этом слове, то можно согласиться
                                                                                                                                                    +10
                                                                                                                                                    > проще и банальнее

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

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

                                                                                                                                                    Т.е. они опытным путем пришли к тому, что тупо идти в отказ («невозможно») — более выигрышная стратегия, позволяющая не заколебаться и выпускать свои задачи в срок и с годным качеством.
                                                                                                                                                    И это не обязательно проблема в вашем менеджменте, могут быть и последствия травмы полученной у предыдущего работодателя.
                                                                                                                                                      –3
                                                                                                                                                      Такая позиция мне гораздо ближе и она на мой взгляд более реалистична. Знакомая ситуация. Тем не менее в целом я считаю разработчиков, умеющих грамотно объяснять и отстаивать свою позицию, более ценными, чем тупо уходящих в отказ и при прочих равных предпочту первых. Отсюда и шаблон. + У многих он возникает от некоторой общей инфантильности и интровертности.
                                                                                                                                                        +16
                                                                                                                                                        Отстаивать позицию имеет смысл только перед компетентными людьми. А некомпетентный мои доводы не поймет, но поймет, что задача решаема и включит административный ресурс. И ладно бы мне просто поставили задачу, мне еще установят срок ее решения (со мной его не согласовав) и потом спросят за качество. Да, еще мне будет делегирована вся ответственность за возможный «провал», но возможная «победа» пойдет в зачет «креативщику», а не мне. У нас в конторе, как в футболе — выигрывает «команда», а проигрывает «вратарь». Поэтому, когда возможно, я отвечаю: «Невозможно!!!».

                                                                                                                                                        З.Ы. Это тоже гипербола, прошу не понимать буквально
                                                                                                                                                          0
                                                                                                                                                          Просто описание моего предыдущего места работы! Самое смешное — там уже растеряли весь отдел разработки и были вынуждены заполнить его студентами. Интересно на кого теперь давят эти администраторы и как делают карьеру.
                                                                                                                                                            0
                                                                                                                                                            Зачем работать только в таком месте, где все так гиперболически как у Вас описано?
                                                                                                                                                              0
                                                                                                                                                              Идеальных мест не бывает. Во всяком случае, я таких не встречал. А работу делать надо. Чтобы кто-то имел возможность свободно и радостно творить, кто-то другой должен обеспечивать ему комфортную инфраструктуру. В нашей стране почти всю инфраструктуру (ЖКХ, транспорт, связь) обеспечивают «монстры» из моего гиперболического примера. И всем этим монстрам нужны ИТ-специалисты. У этих специалистов своя мотивация: кто-то работает за опыт, который не смог бы получить в маленькой организации; кто-то держится за соц. пакет и белую зарплату; а кто-то пытается сделать действительность чуточку лучше «изнутри». Есть такой старый анекдот про чукчу: «Ну, что, жена… Этих детей отмоем или новых наделаем?» Оба подхода имеют право на жизнь. Вы предлагает делать новых, а кто-то старается отмыть старых
                                                                                                                                                            +2
                                                                                                                                                            Нашел, кстати, у Вас в Избранном статью Основная особенность наших разработчиков (раньше ее не читал). Там автор удивляется тому, что русский программист слишком часто говорит «невозможно». В комментариях (а их более трех сотен) куча примеров ситуаций, объясняющих почему мы это делаем.
                                                                                                                                                              0
                                                                                                                                                              Там автор привел совершенно конкретную ситуацию в которой разработчик упёрся без видимых на то оснований. Плюс автор поработал с разработчиками из других стран и культур и ему есть с чем сравнивать. Я впрочем тоже. И я с ним полностью согласен, что неоправданная упертость (stubbornness) одна из отличительных характеристик разработчиков из России, которая порою может перевешивать все их многочисленные достоинства.
                                                                                                                                                            0
                                                                                                                                                            Разве дело программистов приоритезация задач? Программист называет свою оценку, а PM уж решает выполнять или нет и в каком порядке. Если задачи оценены, то «впихивание до кучи» приводит только к разрастанию кучи во времени и отодвигает релиз/сдачу этапа. Если менеджемент этого не понимает, надо его учить или увольняться.
                                                                                                                                                              0
                                                                                                                                                              У нас это бывает так: в начале месяца ПМ говорит «задача А очень важная, давайте постараемся её закрыть, по итогам всем будет премия». Но в середине месяца прилетают задачи Б, Ц, Д, которые срочные и делать надо сейчас. В итоге программист вынужден делать всякую текучку, но манагер искренне верит, что все мотивированы на задачу А и тоже её попытаются сделать.
                                                                                                                                                                0
                                                                                                                                                                А программист не намекает менеджеру, что в месяце фиксированное количество дней и что само переключение между задачами небесплатно? Есть ли что-то типа кабан доски с фиксированным work-in-progress? Как отслеживается трудоемкость задач? Что менеджер думает о статье Спольски «О вреде премирования?
                                                                                                                                                                  0
                                                                                                                                                                  Менеджер сам в мыле лавирует между прилетающими задачами и выбирает, какую задачу не сделать, чтобы обидеть не слишком важного начальника. Намекать не нужно, все всё понимают, но есть хотелка от собственника срочная, есть отчётность для непонятно откуда возникших аудиторов, и в итоге (с т.з. основных заказчиков) программисты целый месяц балду пропинали и ничего не сделали.

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

                                                                                                                                                                        Если всем плевать на прозрачные планы можно начать работать спокойно в стиле канбана — не берётся за новое пока не сделаем текущее + expedite lane с фиксированным wip на срочные таски
                                                                                                                                                                          0
                                                                                                                                                                          Наверное, так и получается, только без канбан-досок и прочего фетиша. А терминологией я не владею )) translate.google.com/#en/ru/expedite%20lane, а к wip ближайшее словарное слово — wipe ))
                                                                                                                                                                            +1
                                                                                                                                                                            Канбан — просто способ визуализации общий принцип — не берем новое, пока кто-то не освободится (вернее пока количество задач в работе не становится меньше чем экспериментально подобранное число work in progress) есть отдельная полоса пропускания для срочных задач — expedite lane, но туда тоже нельзя помещать больше определённого количества. Отслеживаем среднее время прохождение через процесс и очереди на каждом этапе.
                                                                                                                                                                      +2
                                                                                                                                                                      Вы описали случай, когда менеджер плохо справляется со своими обязанностями. Это его работа — разъяснять и отпинывать все что не согласуется с целями. В т.ч. и непосредственное руководство. Потому что ситуация гонки задач классическая и так всегда и везде.
                                                                                                                                                        +5
                                                                                                                                                        Неужели с точки зрения манагеров наши ответы именно это означают? Отсутствие взаимопонимания между менеджерами и разработчиками это путь к фейлу прямой.
                                                                                                                                                          +10
                                                                                                                                                          Судя по отсутствию пункта 000 автор сам не до конца знает то, подо что стилизует список :)

                                                                                                                                                          За остальными пунктами может скрываться примерно по миллиону разных ситуаций.

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

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

                                                                                                                                                          Думаю, еще в этом ответе — «это сделать невозможно» — раздражает упрямая категоричность.

                                                                                                                                                          Как и в тоне автора поста.

                                                                                                                                                          Будь гибче, чувак!
                                                                                                                                                            +20
                                                                                                                                                            Такое ощущение что статья написана не разработчиком, а каким-нибудь менеджером. Причем таким матерым менеджером, который в разработке никогда не участвовал, а сразу заканчичвал «Менеджмент и маркетинг» (это, кстати, в моем понимании ругательство и оскорбление :))

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

                                                                                                                                                            1. А у меня на компе работает. «Я разработчик, я не хочу настраивать ИДЕ, я хочу клац-клац, Ф5 и в продакшн». Слава богу мы уже не те программисты, которые картриджы меняли. Если у меня на компе работает — значит код рабочий, пускай админ разбирается с косяками настройки окружения. Если код написан в соответствии с требованиями, на указанном в требованиях языке, на указанной версии языка, с разрешенными требованиями библиотеками — не проблема программиста заниматься его запуском где-либо кроме собственной машины.

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

                                                                                                                                                            3. Тестеры нифига не протестировали, чем они вообще занимаются? Если я — последний рубеж — прошу разделить зарплату отдела тестирования между отделом разработки и упразднить этот отдел «контроля качества» за необоснованностью его существования. Одно дело если тестер попытался что-то сделать, а оно в принципе не работает, но тут смотри пункт 1 — у меня на компьютере запускается. Если нет то это клинический случай. А если тестер нашел хитрый баг на специфической комбинации параметров при совмещении модулей от нескольких разработчиков — то на то он и нужен, этот тестер.

                                                                                                                                                            4. Если это писал я то я идиот. Иногда полезно это осознавать. Если речь идет о формулировке то я согласен — не стоит так грубо говорить в команде, слова можно подобрать другие. Но если код — говнокод — его автор должен быть найден и тыкнут носом. Даже если это я сам. В образовательных целях, очевидно же что кто-то умнее и опытнее, а кто-то нет, как можно передать опыт от человека к человеку или осознать что ты стал лучше чем был когда-то если не находить говнокод и не признавать его низкое качество?

                                                                                                                                                            5. Формулировка дурацкая, конечно. Но есть такая хорошая шутка что надпись 99% Complete при установке виндоус радует только первые полчаса. Любой разработчик знает что бывает вроде бы мелкая проблема решение которой может потребовать неопределенно долгого времени. А так как разработчики это инженеры, а не менеджеры, они не приучены ни врать ни блефовать, и если не могут дать точный ответ о необходимом времени — дают такой точный ответ, какой умеют. Потому что если я скажу «будет готово через 3 часа», хотя сам в этом не уверен и через три часа готово не будет я не смогу как менеджер сказать «Ну, не получилось, нужно еще три недели», вместо этого я буду чувствовать себя плохо, моя мотивация упадет, самооценка пострадает, эффективность понизится, лояльность к команде, поставившей меня в такие условия ухудшится… ну в общем я надеюсь понятно для менеджера выразился.
                                                                                                                                                            Вообще менеджер или тим-лид это «прокладка» между разработчиком и человеком. И он обязан уметь понимать язык разработчика и переводить на человеческий. Поэтому он должен выслушать тираду про проблему с jQuery, задать наводящие вопросы и в документе написать «ориентировочно 3 часа, высокий риск задержки».

                                                                                                                                                            6. Да, возможно всё. Но мне несколько раз доводилось говорить «Это невозможно». Почему? Это была экспертная оценка аналитика, исходя из понимания сложности задачи, затрат на ее выполнение и имеющихся ресурсов. Если разработчик говорит что что-то невозможно значит этому есть причины. Можно до них докопаться, выяснить насколько они оправданы и либо согласиться с такой оценкой либо найти пути решения. Но если разработчик говорит «это невозможно» не вдаваясь в подробности менеджеру, с которым давно работает — этому менеджеру следует подумать, скорее всего его умственные способности были оценены негативно.
                                                                                                                                                            Впрочем, этот пункт — поле для отдельной полемики об устанавливаемых задачах и предоставляемых ресурсах на их решение. Как говорится «Менеджер думает что если взять 9 женщин то можно родить ребенка за месяц».

                                                                                                                                                            7. Если у человека есть определенная профессиональная гордость и она обоснована — разве это не хорошо? Если время человека стоит больше, значительно больше чем время другого человека, который мог бы решить эту задачу и он сообщает об этом — это замечательно! Это возможность оптимизации затрат. Конечно иногда нецелевое использование ресурсов оправдано, но чаще всего нанятый владельцем бизнеса менеджер просто не задумывается о том, что забивает гвозди микроскопом и выступает с позиции «тебе за это платят — делай что я говорю». Очень печальная ситуация, которая не способствует развитию, зато способствует деградации, потере самоуважения, понижению мотивации, ухудшению отношения к коллективу, толкающему на это, пониижению эффективности труда разработчика и в результате приводит к увольнению. И должно уволиться несколько хороших разработчиков чтобы высокое начальство наконец догадалось что проблема в менеджере и наконец-то от него избавилось.
                                                                                                                                                            Если разработчику предложить помыть полы в рабочее время он скорее всего тоже не согласится. Причем чам выше зарплата этого разработчика тем более вероятно что он не согласится. Так вот есть в нашей области задачи, сложность которых аналогична мытью полов и является оскорбительной для достигнутого человеком профессионального уровня. И чем выше уровень — тем больше таких задач. Хотя у нас, конечно, люди как правило работы не боятся и сеньер девелоперы бодро носят мебель или коробки с чем попало, потому что у компании видимо нет денег на грузчиков.

                                                                                                                                                            Извиняюсь за пропитанный негативом к менеджменту текст. Но люди считающие других «ресурсами» несколько надоели своим отсутствием желания понимать область, в которой работают. Особенно ту часть области где оказывается что вокруг тоже люди, ничуть не хуже себя любимого.
                                                                                                                                                              +2
                                                                                                                                                              1. Если у вас на компе работает, вполне возможно, что есть какой-то параметр, который пользователь не указал в багрепорте и его надо уточнить. Это если цель сделать качественное ПО, а не отказаться

                                                                                                                                                              2. Если у вас в разработке роль безмолвного исполнителя ТЗ бага, вероятно, прошла через приоретизацию при помощи того де человека, что и составлял т.з. соответственно, он уже учёл требования к пользователю — т.е. посчитал его неопытных а не мудаком.

                                                                                                                                                              3. Иногда полезно подумать, почему вообще бага возникла и как так больше не делать. Как такие баги находить быстрее? Не стоит ли тестерам сообщить — какие места лучше протестировать поподробнее и какие автоматические тесты лучше написать? Наше дело не искать виноватых, а вместе делать качественное ПО.

                                                                                                                                                              4. Согласен, правда я бы не тыкал, а задавал наводящих вопросы сначала — иногда есть какие-то обстоятельства, которых не знаешь.

                                                                                                                                                              5. На на доступном менеджеру языке обозначить причину задержки. Постараться разбить задачу на маленькие порции, чтобы говорить либо о 100% сделанной порции либо о несделанной. Поискать другие варианты или попросить коллегу покопаться вместе. В следующий раз перед оценкой отделить те куски, в которых ты не уверен и сообщить менеджеру. Сначала написать короткий прототип, в котором изучить сомнительные места jQuery. «Будет готово через 3 часа, если все пойдет гладко, но чтобы сказать точно надо сначала попробовать вот это — через полчаса скажу точнее».

                                                                                                                                                              6. Может быть ленивый разработчик, тупой менеджер или сочетание :).

                                                                                                                                                              7. Если предполагаемая «ерунда» не входит в обязанности разработчика, адекватный человек сообщит это другими словами не провоцируя конфликт.

                                                                                                                                                                0
                                                                                                                                                                Статья начинается с того, как хорошо что программисты уже не меняют картриджы, а являются специализированными разработчиками. Поэтому:
                                                                                                                                                                1. Параметры на компьютере пользователя — не проблема разработчика. Как и неправильно составленный баг-репорт. У нас же целый отдел обеспечения качества, который непонятно чем вообще занимаются!
                                                                                                                                                                2. Проблема разработчика — делать по ТЗ. А ТЗ — проблема аналитика. Если разработка выполнена по ТЗ — какие могут быть вопросы к разработчику?
                                                                                                                                                                3. Взаимодействие разработчика с тестером — хорошо. Позиционирование разработчика как «последний рубеж» единственно несущий ответственность за качество всей разработки — либо плохо либо признак ситуации когда разработчик один и он же и тестер и аналитик и архитектор. А над ним стоит только менеджер, который капает на мозг сроками.
                                                                                                                                                                5. Работа разработчика — разрабатывать. А вот работа менеджера — обеспечивать процесс. Менеджер должен знать язык разработчика, а не наоборот. Если разработчик знает язык менеджера — это очень хороший разработчик, который наверное сам скоро станет менеджером, потому что платят больше. Кстати именно от разбиения на порции рождается ответ «готово на 99%» :)
                                                                                                                                                                7. Слова, слова, я подозреваю что дело не в формулировке, а в сути. Если посыл будет мягким — он все-равно будет посылом и именно это не нравится автору. Да и опять же — разработчик не должен уметь общаться с людьми, он должен уметь разрабатывать. А менеджер должен уметь его понимать.

                                                                                                                                                                4. Вопрос вкуса, навеное. Когда мне начинают задавать наводящие вопросы и я догадываюсь что там косяк — мне кажется что со мной обращаются либо как с ребенком либо пытаются подтрунивать. Лучше сразу сказать — я считаю этот код плохим потому что. Если мне будет что ответить — я отвечу. И в споре родится истина. Если не будет — признаю свою неправоту и запомню как надо.
                                                                                                                                                                Но при этом есть очень обидчивые на прямое указание ошибки люди, которым как раз и надо задавать наводящие вопросы создавая эффект будто они сами нашли ошибку и более хороший путь решения. Тоже бывает, все мы разные.
                                                                                                                                                                  0
                                                                                                                                                                  Интересно, что в каждом пункте вы пытаетесь доказать, что разработчик не виноват, а я пытаюсь показать, как должен действовать разработчик для выпуска более качественного продукта.

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

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

                                                                                                                                                                  3. Согласен, все несут ответственность. Не ищем виноватого, а делаем что можем, чтобы было лучше

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

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

                                                                                                                                                                  4. Ну вопросы я практикую, когда уверен менее чем на 90% что косяк. Иначе можно просто высказывать в мягкой некатегоричной форме
                                                                                                                                                                    +1
                                                                                                                                                                    Этому есть простое объяснение — статья обязывает разработчика к чему-то. А разработчик действительно не виноват. Я согласен с тем что он может — он может и дебаггинг на стороне клиента сделать, и ТЗ улучшить и тестирование провести и научиться с людьми общаться. Но ведь еще он может поменять картридж в принтере, может поуправлять проектом, поносить коробки с этажа на этаж. Он все это может, но не должен как пытается убедить нас автор статьи.

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

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

                                                                                                                                                                      Все работают на общее благо как могут, но дело каждого знать — где он принимает решение, а где он моет использовать возможность совещательного голоса.

                                                                                                                                                                      Еще по поводу разделения труда — вот такой пример — почему нету специального человека для завязывания шнурков — он будет все делать быстрее и качественнее?

                                                                                                                                                                      Вы читали книжки от 37signals?
                                                                                                                                                                        +1
                                                                                                                                                                        Нет, не читал.

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

                                                                                                                                                                        А вот человек для завязывания шнурков рано или поздно появится. Либо этот процесс будет автоматизирован/упразднен. Доказательств у меня аж два.
                                                                                                                                                                        Первое теоретическое: когда-то один человек и убивал мамонта, и свежевал его, и резал, и готовил, и ел. А теперь цепочка людей от выращивающего животных до поедающего мясо состоит из нескольких десятков разных профессий. И представитель одной зачастую даже не представляет себя в роли представителя другой. То что сейчас нам кажется очевидным и элементарным, тем что должен уметь каждый человек через сотню другую лет может быть уже совсем иначе. Ведь пару сотен лет назад каждый уважающий себя джентельмен был обязан уметь фехтовать и стрелять, а сейчас этим занимаются либо спортсмены, либо бандиты либо милиция либо армия. Ну либо любители, в порядке хобби.
                                                                                                                                                                        Ах да, второе практическое. Я не умел завязывать шнурки где-то до 10-11 лет. То-есть у меня получалось, но плохо, поэтому мне их обычно завязывала мама. При этом я был первым учеником в классе, я читал и писал с первого класса лучше других, знал математику, легко все запоминал. Голова работала отлично, а мелкая моторика рук не очень. Когда появится нейроинтерфейс для управления компьютером — дай бог чтобы программисты вообще ходить не разучились и за них этого не делали «узкие специалисты».

                                                                                                                                                                        Кстати пока писал подумал… А ведь такой человек есть! Только вместо того чтобы завязывать другим шнурки он оптимизировал процесс: молнии, липучки, резинки. Обувь без шнурков — это и есть результат работы специального человека по завязыванию шнурков. И кто скажет что он справился со своей работой не быстрее и качественнее обывателя?
                                                                                                                                                                          0
                                                                                                                                                                          С моей точки зрения что-то подобное и языками программирования — когда появились ЯВУ возникла возможность быть постановщиком сам себе — в один мозг влезает формальный язык и предметная область
                                                                                                                                                              +6
                                                                                                                                                              > 001. А у меня на компе работает

                                                                                                                                                              Нормальная фраза, как начало диалога. Я после этого обычно начинаю искать различия в dev и test среде, совместно с QA. Еще варианты — удаленная отладка, запись логов/дампов, удаленный доступ.

                                                                                                                                                              > Запомни раз и навсегда, что тестеры не отвечают за качество ПО.

                                                                                                                                                              До меня уже высказались — не ясно зачем тогда уже нужны тестеры. У разработчика в большинстве случаев тестирование это юнит-тесты, нагрузочные тесты, возможно UI тесты. Если он будет прогонять все варианты, на всех платформах, браузерах итд вы такие сроки получите… Кроме того опять же — иногда QA находят в моем коде такие повороты, которые я бы сам искал долго. Именно из-за юзероского подхода (а что если нажать две кноки сразу итд).

                                                                                                                                                              > 100. Какой идиот это писал?

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

                                                                                                                                                              > Меня не очень интересуют интимные подробности

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

                                                                                                                                                              > 110. Это невозможно!

                                                                                                                                                              Как правило в этой фразе есть недоговоренность «в эти сроки, за эти деньги, с такой командой». Можешь тыкать сколько угодно FAT-ом, но Azure за ночь в одиночку с нуля не склонировать. Как и Win не написать. Будешь спорить?

                                                                                                                                                              PS: честно говоря жалко твоих разработчиков, если конечно только у них не такая огромная ЗП и такие интересные проекты чтобы тянуть все, включая QA.
                                                                                                                                                                +1
                                                                                                                                                                Считаю, что это ценная статья.
                                                                                                                                                                Но, её ценность совсем не в «правильности утверждений и выводов», а в том, что эта статья хорошо демонстрирует мировоззрение большой части отечественных разработчиков.

                                                                                                                                                                Мой личный опыт НЕ позволяет мне согласиться с большинством(!) утверждений и выводов из этой статьи. И, предполагаю, что мои аргументированные возражения по всем таким пунктам превысят объем самой статьи.

                                                                                                                                                                IMHO Не эффективно делать такое в этом комментарии. Тем более, что мои возражения просто будут выражать другую субъективную\мою точку зрения по каждому пункту статьи. И в идеале нужен будет арбитраж по альтернативным мнениям для установления «истины», но принципы демократии принятые Хабре не помогут нам в этом. («большинством голосов установить удобное нам значение числа Пи»).
                                                                                                                                                                Поэтому, я избрал другой путь…

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

                                                                                                                                                                Именно эти различия и определяют наше отношение к шаблонам проектирования, процессам разработки и выпуска ПО, к QA процессам и специалистам, и, в конце концов, к самоопределению «разработчика»\«программиста»\«оператора ЭВМ» во всех этих процессах.

                                                                                                                                                                  +3
                                                                                                                                                                  Это невозможно!

                                                                                                                                                                  Хочется прокомментировать эту фразу. Зачастую, если программист её произносит, это значит, что он не мотивирован решать задачу. Вопрос — почему? Причин может быть множество, но наиболее вероятная — программиста не привлекали к её обсуждению. Менеджеры где-то там у себя посовещались и просто выдали программисту готовое задание, даже не поинтересовавшись, что он думает по этому поводу. А он, между прочим, не просто технарь-обслуга, как робот выполняющий любые капризы менеджеров, а ответственное лицо. У которого есть и сроки, и представление чего будет стоить внедрение такой-то фичи.

                                                                                                                                                                  Эта фраза — естественная реакция программиста на задачу, которая сваливается на него как снег на голову и насчёт которой ему понятно, что за него уже всё решили, делай-делай, не отвлекайся.
                                                                                                                                                                    +1
                                                                                                                                                                    Часть пунктов являются, как минимум спорными, на что неоднократно указали в комментариях.

                                                                                                                                                                    Часть — очередное изложение превосходной классической книги «The Progmatic Programmer» (Andrew Hunt & David Thomas). Даже, если автор не читал эту книгу, то многие утверждения из неё на хабре появлялись далеко не единожды.

                                                                                                                                                                    В общем, мне этот пост видится пафосной жижицей.
                                                                                                                                                                      –2
                                                                                                                                                                      Автор молодец! Не смотри на рейтинг, покуда карма позволяет — пиши! :) С новым годом!
                                                                                                                                                                        –1
                                                                                                                                                                        А чё «001. А у меня на компе работает!»?
                                                                                                                                                                        Чё не «000»?
                                                                                                                                                                          +2
                                                                                                                                                                          Как много раз упоминается «Чувак»…