Dev-непрофессионализм — главный тренд в отрасли

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

Я приведу свою точку зрения: «Позера от Профессионала отличает воинствующее сопротивление всему конструктивному, звездная болезнь, патологическая невозможность сказать себе „Достаточно“, а также периодические игры с переусложнением существующих решений ради удовлетворения собственного эго и завязывания проекта „на себя“ ».

Проще всего пояснить что-либо на примерах, с этого я и начну:

Причина: Dev-получают премии/бонусы за оперативное запиливание фич/исправление дефектов
Реализация: Особо ушлые товарищи поняли фишку и, не укладываясь в запланированное время, «запиливают» фичу/ «исправляют» дефект ржавыми велосипедами, заботливо собранными со всех помоек интернетов. Их не особо беспокоит, что получившийся ублюдок не взлетит, а лишь покашляв, выбросит очередной NPE. Главное «закрыть» задание, а исправление дефектов/новый этап исправлений идет отдельным процессом со своим, новым ожиданием исполнения, а там и замотанным синей изолентой костылям найдется применение.

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

Причина: Большинство dev «over-engineer» -ят при малейшей возможности; изучая что-то новое не осознают, когда это новое применимо к месту.
Реализация: При отсутствии гонки на время в виде точно выделенного времени на выполнение задания, некоторые разработчики умело дестабилизируют проект, доводя его до маразма.
К примеру, внедрением свежеизученного шаблона он переусложняет технически простое решение («смотрите, как я умею ^_^»), и, по мере роста фичи, уже не в состоянии ни расширять функционал ни отрефакторить за разумное время, Внезапно выяснив, что применение шаблона неразрывно связано с рядом «но».
Грохот падающего приложения на данном участке, как и шум падающих кирпичей из нежного нутра нашего с вами разработчика, насыщен и тонально полон.
QA инженеру на данном этапе, после указания на очевидный провал $programming_language$-guru путем фиксации дефекта в баг-трекере, рекомендуется укрыться в panic-room, т.к. жаркие лучи ненависти не лучшим образом влияют на потенцию.

Причина: Мой код идеален, просто спецификация немного по-деПильному написана.
Реализация: Проект собирается за 4 минуты без интеграционных тестов. Большая часть перекрестных юнит-тестов не проходит, QA smoke suite build conf на CI запускать бессмысленно.
Виноват, разумеется, составитель FRD/user story, сервер, администратор или провайдер, но только не разработчик. Не закрытые потоки, чтение файлов по 1 байту, феерические абстрактные фабрики для дохлой парочки типов, копипаста чуть более, чем везде, приводящая к сваливанию кода. Все это реалии разработки. Когда отмазки заканчиваются, применяется коронный аргумент: «архитектура изначально г*вно, а мы в белом». Не всегда, правда, выходят сухими из воды, и бизнес-гель находит себе применение.

Причина: «Звонок — для учителя»
Реализация: Разгар подготовки релизной версии, QA и dev-ops в мыле, team-lead уже 6-й час на совещаниях и ему там не сладко. Dev при этом в течение дня несколько раз играл в икс-бокс, покурил и обсудил последние политические новости. Видимо, для dev существуют особые правила, а командный дух это не для них. Два дефекта за день закрыл (исправление z-index: 3 часа, обработка 2 пропущенных исключений: 5 часов) — можно и расслабиться.

Причина: Двойные стандарты — второе имя DEV.
Реализация: DEV очень любят писать краткие комменты на техническом языке в JIRA, игнорируя факт, что помимо них трекер читают и junior QA, и люди, зачастую далекие от технической части (BA, PM), обижаясь при этом на справедливые замечания. Имеют свойство давать советы по тестированию, но при этом исподлобья смотрят, когда получают запросы на содействие тестированию (ввести недостающие хуки в api для облегчения тестирования, навести порядок в дурдоме верстки).

Причина: Ловля звезд.
Реализация: Термин варьируется, но в пределах 1,5-3 лет немалое количество разработчиков «ловит звездочку», после чего коэффициент тяжести проблем, указанных выше, можно смело умножать на 2.
В этом словивший звездочку разработчик схож с начинающим автолюбителем, по статистике наибольшее количество аварий происходит между 1 и 3 годами вождения (считает, что уже бог баранки).
В случае с разработчиком, оный начинает презрительно поглядывать на QA (неудавшиеся devs, позорище), PO (губошлепы), PM (переоцененный чувак с дорогим галстуком, не понимающий бизнеса), рекрутеров (прислуга). Дело усугубляется твердой уверенностью, что он глава мироздания в IT фирме, и он всех «кормит», а все остальные нахлебники.
Но есть и положительные стороны явления — словленная звезда способствует скорому переходу разработчика куда-то еще, ведь на нынешнем месте, ему, гиганту мысли, недоплачивают на грани беспредела (либо отправляется на поиски счастья в порядке добровольно-принудительном).
Стоит ли говорить, что качество кода у раненого кардинально не улучшилось с момента «осознания своей Настоящей цены» (+500/прыжок), как и качество английского?

Выводы:
Развивайтесь, изучайте новое, но с умом применяйте знания, не стесняйтесь своего незнания, воинствующая глупость гораздо хуже. Ну а задирать нос — последнее дело.
За свою карьеру в IT я знал всего 2-х превосходных разработчиков, оба пишут на Java. Никто из них не замечен в пафосе, напротив, они осознают, сколь многого они еще не знают, и что границ познания нет.
Возможно, если у вас возникнет вопрос, почему в IT разработчиков-снобов недолюбливают, над ними подшучивают и часто сторонятся, то я постарался привести убедительные примеры в этом топике.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Толстота этого поста переплюнула баттхёрт предыдущего.
Выше, быстрее, сильнее, ДОУ.

Я думал, намного будет... Намного лучше будет это все. И очень плохой вброс, просто очень плохой вброс! Я думал, намного лучше это все будет. Сколько раз сюда ходил — было намного лучше, но на этот раз как-то не удалось. Во-первых, народа мало, вброс — не очень...

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Про мудобыдлоскотоменеджеров не битых спортивным инвентарем, как слкдует, по уязвимым местам своей жалкой и мерзкой тушки, как доморощенных так и заморских:

Антипаттерны мнительности

«Агрессия». «На то и волк в лесу, чтоб пастух не дремал!» Руководитель стремится удерживать подчиненных вне «зоны комфорта». («Настоящие лидеры задают трудные вопросы и выбивают людей из зоны их комфорта. Затем они управляют возникающим стрессом!», © Р.А. Хейфетц, Д.Л. Лори, «Работа лидера», 1997.) Постоянное давление. Нереальные сроки. Сверхурочные. Авралы. Непрерывная критика и понижение самооценки («заодно можно сэкономить на зарплате!»). Грубость. Запугивание. «У нас незаменимых нет!» «Поощрение непричастных и наказание невиновных». Назначение в несколько проектов одновременно. («Чем больше, тем лучше — обязательно что-нибудь провалит! Сотрудник должен все время ощущать свою вину!») Постоянные перемещения людей по горизонтали и вверх-вниз. Обязанности определены самым общим образом: «Ты в ответе за все!» Поручения не зависят от обязанностей. Правила меняются по ходу игры.
«Управление грибами». (Почему грибами? Потому, что грибы держат в темноте и кормят навозом.) Удержание работников в неинформированном и постоянно занятом состоянии. Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Зависимость исполнителей от более информированного начальника. Строгое разграничение прав доступа к проектной документации и исходным кодам. Ограничение доступа в Интернет («а вдруг узнают среднюю зарплату на рынке?»), запрет ICQ, препятствование общению с коллегами из других компаний. Загрузить работой так, чтобы времени на обдумывание чего-либо не оставалось. Постоянно находить какие-нибудь «важные и неотложные» дела.

«Микроменеджмент». Отсутствие делегирования в любом виде. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам. Считает себя самым компетентным. Влезает во все самые мелкие работы, от структуры таблиц в БД до цвета шрифтов в интерфейсе. Вместо объяснения того, что надо делать, постоянные указания на то, как надо делать. Навязывает собственные идеи. «Думать — это моя работа! Просто, делай, как я сказал!» Жестко контролирует, каждый шаг исполнителей.

«Методологическое безумие». Безграничная вера руководителя в методологию с большой буквы «М» — всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Многоступенчатая бюрократия. Все процессы регламентированы. Все делается по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Установлен тотальный контроль соблюдения регламентов. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. Большая часть времени исполнителей тратится на соблюдение правил и писанину, которую никто никогда не читает. Большая доля «сизифова труда».

Антипаттерны некомпетентности

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

«Yes-man!» Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. Руководствуется принципом: «Возлюби Босса своего и никогда не спорь с ним!». Интересы фирмы, команды, продукта и его пользователей не учитываются вовсе. «Босс хочет, что бы мы закончили проект в два раза быстрее. Как? Это ваша забота, вам за это деньги платят!». Не принимает ни одного решения без согласования с Боссом. Испытывает постоянную потребность «угадать и угодить» Культивирует любимчиков в команде, которые никогда с ним не спорят.

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

«Нет времени точить пилу!» (в англоязычной википедии у этого антипаттерна другое, более жесткое название — «Headless chicken»). Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический труд («у плохих генералов всегда много героев»). Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. «Это надо было сделать еще вчера!» Работа постоянно выполняется под давлением нереальных сроков. Обучение, анализ, проектирование и рефакторинг — «Это все потом!». Постоянные сверхурочные и авралы. Большой проблемный код.

Браво! А можно вас попросить создать из вашего коммента отдельный топик: «Управленческий непрофессионализм — главный тренд в отралис».

опа, а куда делся топик про управленцев? спёрли?

Видимо под нож топик попал — кому-то на хвост наступили :)

Может кузняк обиделсо или хмиль? кто там из них самый главный?

Непрофессионализм разработчиков вызван многими причинами. На мой взгляд, одна из них, это банальное желание начальника избавиться от подчиненных, которые быстро развиваются, умны, эрудированны, и очевидно могут навредить «авторитету» годами сидящему на попе «лидеру». Быть авторитетом для джуниора, или человека слабовольного, ограниченного духовно и умственно, без претензий, позволяющего себя унижать — гораздо проще. Таким образом, квалифицированные профи часто не являются большей и постоянной частью команды, а лишь кратковременными учасниками разгребающими [удалено цензурой]. Управлять без оскорблений, угрозами увольнения и прочими приемами жалких клоунов-менеджеров, быть настоящим лидером — гораздо труднее. Пилить зарплатку и ничего не делать, к сожалению, хочется многим особенно, когда лень и мозгов нет. Настоящие лидеры есть, но, к сожалению, в Украине это чаще люди осознающие свою ущербость, серость, выживающие и получающие повышение исключительно за счет навыков раздражения языком чувствительных тканей других, вышестоящих людей, в местах выделения продуктов жизнедеятельности. Они — жалкие паразиты, пытающиеся хоть как-то самоутвердиться унижая тех кто их превосходит в интеллекте, может творить, менять работы и страны. Этих мерзавцев-нахалов выводит из себя факт, что без них все прекрасно могут обойтись и зарабатывать деньги, радоваться жизни и своей работе. Им нужно всунуть свою подлую рожу в то, что их не касается и плести свои клоунские интриги изученные на курсах, отравлять жизнь всем вокруг получая за это деньги.

Поинтересуйтесь, откуда взялся лично ваш менеджер, а также что он такого собственно умеет, знает, или создалл в совей жизни. Управляет ли он/она вами на самом деле или только мешает вам и проекту? Профайлики у многих «эффективных» довольно жалкие на самом деле. Щеки при этом надуваются до размеров могущих привести к дефектам внешности. Уход целой командой в случаях когда выясняется что менеджер мешает помогает сделать менеджеров немного лучше :) Не стоит стесняться изменить мир к лучшему!

К предыдущему посту:
В программировании нет повторяющихся задач. После третьего повторения однотипного действия программист пишет утилиту, которая это действие автоматизирует. Никто пока не знает, каким местом программист думает и как он этим местом это делает. Бессмысленно сажать за его спиной нормировщика-контролера с секундомером. Что он увидит и измерит? Не стоит заставлять программистов работать больше, устраивать сверхурочные, авралы и субботники. Работать больше, это совсем не значит — работать продуктивнее. Наоборот. Излишнее давление и суета приводят к непродуманным решениям, большому проблемному коду и многочисленным последующим дорогостоящим переработкам.

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

Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа.

Телу необходимы деньги и безопасность.
Сердцу — любовь и признание.
Разуму — развитие и самосовершенствование.
Душе — самореализация.
Предоставьте все это вашим сотрудникам, и эффективность их труда возрастет многократно. (Как? Это вопрос из другой области — теории мотивации. А мы здесь, в основном, — о практике демотивации.) В противном случае профессионалы найдут все это в другой компании, а в вашей останутся только посредственности.

Все правила демагога в одном месте, а то Архангел Гавриил постоянно растекается мыслею по древу:

lurkmore.to/...равила_демагога

Ждем новую тему: PM-непрофессионализм— главный тренд в отрасли

Пост как-будто написан про украинскую политику ;)

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

собственно, все сводится к трем вариантам:
а) пациент — дурак
б) пациент — мудак
в) на проекте — бардак

Вообще не вижу проблем в вышесказанном.

Я думал, намного будет... Намного лучше будет это все. И очень плохой вброс, просто очень плохой вброс! Я думал, намного лучше это все будет. Сколько раз сюда ходил — было намного лучше, но на этот раз как-то не удалось. Во-первых, народа мало, вброс — не очень...

Может вентилятор помощнее надо? :)
И эта... измельчить побольше :)

Читаем «Психбольница в руках умалишённых»:
«Пользователь не должен получать компьютерное образование, чтобы решать посредством компьютера простые каждодневные задачи начального уровня. Пользователь не обязан обладать цифровой сноровкой, чтобы получать электронную почту или совладать с видеомагнитофоном и микроволновой печью. Более того, пользователи не должны получать компьютерное образование, чтобы применять компьютеры в корпоративных приложениях, где они уже владеют предметной областью. Так, бухгалтер, сведущий в общих принципах бухучета, не должен получать компьютерное образование, чтобы применять компьютер в своей работе. Ему должно хватать познаний в предметной области.»
:)

Как же быть с законами Мерфи ?

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

Ой, Оксана, простите, я вас без КАПСА не признал.
Я ничего аргументировать не собираюсь — я же говорил, что это отлично, когда кто-то нихрена, кроме своей предметной области, не знает.


Аргументируйте пожалуйста, НАЧЕРТА мне самой знать и уметь как менять смеситель или класть плитку. А также, зачем мне вникать в госпроцессы оформления бумаг, если по факту я должна прийти в госслужбу и она меня за 15 минут обслужить?
А, ещё... зачем мне знать как ремонтируется утюг, микроволновка или холодильник :)

Вибачайте, заради бога, шо уліз в чужу суперечку, але таки треба дещо знати. Просто
щоб не переплачувати, бо багато мастаків полюбляють “нагрівати” малообізнаних у предметі замовлення.
А госслужба — та да, вона должна обслужить. ГАИ начебто теж госслужба, та з нею без належного знання документообігу та усіх законів та підзаконних нормативних актів, котрі вони смачно порушують, узагалі виживати неможливо.
бо багато мастаків полюбляють “нагрівати” малообізнаних у предметі замовлення
Не, ну прочитать и посмотреть КАК меняется прокладка на ютубе я конечно могу. И даже перерыть “стос паперів” прежде чем обратится в госслужбу. Но ПОЧЕМУ Я ЭТО САМА ДОЛЖНА ДЕЛАТЬ — вы мне скажите? Я должна очень общих чертах знать, что и как, чтобы меня не надули. Но я не должна сама класть эту плитку или оформлять документы!
То есть я должна убедиться, что при расчёте зарплаты программа выдаёт верную цифру, но я не должна как бухгалтер знать внутреннюю БД и ручками выискивать все-все-все данные для формулы, если они вычисляются по 1-2-3 алгоритмам.
Я должна только выбрать название метода вычисления И ВСЁ!
И желательно, чтобы это занимало не более 3-5 кликов. И все эти клики были очевидны в применении, а не ...->...->...->...->...->...error

Порядок цифры надо бы уметь адекватно воспринимать без оглядки на бухгалтерскую программу. А то мало ли, заработаете еще мильЙон. и шо тогда ?

Порядок цифры надо бы уметь адекватно воспринимать без оглядки на бухгалтерскую программу
Это всё он воспринимает в рамках своей компетенции бухгалтерской. И знает ОТЛИЧНО.
Проблема в том, что программа написанная кривыми руками имеет кучу загогулин и переадресаций, которые никаким образом к вычисляемым цифрам не относятся — а только проявление гибкости-во-хребте разработчиков :)

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

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

Я немного поправлю — не обязательно покупать мерс — можно купить деу-матиз за стоимость всё тех же жигулей и тоже знать только

лишь куда бензин залить
:)

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

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

Расскажите-ка нам о природе гравитационного взаимодействия

В природе существует 4 вида воздействий: гравитационные, электромагнитные, сильные и слабые.

гравитация — универсальное фундаментальное взаимодействие между всеми материальными телами. В приближении малых скоростей и слабого гравитационного взаимодействия описывается теорией тяготения Ньютона, в общем случае описывается общей теорией относительности Эйнштейна. Гравитация является самым слабым из четырёх типов фундаментальных взаимодействий. В квантовом пределе гравитационное взаимодействие должно описываться квантовой теорией гравитации, которая ещё полностью не разработана. (wikipedia)

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

Вы ведь не какая-то там «потреблядь», чтоб пользоваться тем, чего не знаешь, верно?

Это гравитация пользуется нами, а не мы ею.

А заодно и пусть расскажет как действует утюг и как электричество беГГГёт по проводам :)

так олень все равное не поймет, смысл метать бисер.

А смысл оленю знать как происходит фотосинтез в дереве, чтобы съесть его листочки?

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

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

В контексте ваших с Габи пафосных высказываний — разницы нет.

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

А вот тут мы уже отошли от ваших тезисов. Пост Габи разбирать не будем, т.к. там он прямым текстом запрашивал от пользователя знания физики и химии (ха! химия — это лишь часть физики!).

«Зачем мне знать что-то о сантехнике — я заплачу и прокладку поменяет работник жека»
В данном случае, инструментом выступает работник ЖЕКа. А умение собрать обращаться с сантехникой — «гравитационным взаимодействием»
«Зачем мне знать что-то о недвижимости — я заплачу и сделку проведет риелтор»
В данном случае инструмент — это риелтор, а Гражданский Кодекс — учебник квантовой физики.

Ну и так далее.

менеджера видно сразу — много слов и минимум смысла.

Ну, ок, если так. Буде аналогично думают остальные 95% — мне оно только в радость.

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

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

Бгг. А почему без капса тогда? Шаблон потрескивает.

Мне пристало мыслить нешаблонно и нестандартно :)

И какая у вас школа и с каким аттестатом вы её закончили? :) И какие у вас награды за школьные годы? Ну я сначала просто спрошу — а вдруг вы действительно умнее :)

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

P.S. что бы я вам не ответил на ваш вопрос вы будете продолжать флудить.
Правило демагога № 1 (актуальна для вас)
Если тебе задают неудобные вопросы — отвечай вопросом на вопрос, например, спроси оппонента, почему его это так интересует, или поступай как музыкальная личность. А потом незаметно съезжай на другую тему — всё равно через несколько постов все забудут, какой вопрос был задан вначале. Контрмера: зае*бать оппонента ссылками на пост с вопросом, и с пеной у рта требовать ответа. Выигрывает наиболее упоротый.

рукалице, де ви тут

около-технической
знайшли?

DOU когда-то был ресурсом, на котором обсуждались IT-шные и около-айтишные вещи. Обсуждение девелоперов и QA-ев в профессиональном разрезе — около-технично или около-IT-шно.

Обсуждение президентских выборов, детей, ноотропов и прочей требухи — накручивает рейтинг просмотров рекламы, не более того, не имея к IT никакого отношения (если опустить эффект бабочки).
Как говорил император Веспасиан: «деньги не пахнут».

DOU когда-то был ресурсом, на котором обсуждались IT-шные и около-айтишные вещи.
Да, помню, когда-то так и было: dou.ua/...opment-process .

Цього топіка це не стосується.
Можливо краще підняти дійсно важливу тему, що вас турбує у новому топіку?
А не намагатись цирк перетворити на театр?
На ваш розсуд, звісно

Обсуждение президентских выборов, детей, ноотропов и прочей требухи
— Василий Иванович, белые лезут!
— Не до грибов сейчас, Петька, вот разобьем контру, тогда и пособираем.

Всё человеческое и несчастным айтишникам не чуждо :) Или вы скажете, что не кушаете и в туалет не ходите?

Зовсім ніякої?
Навіть початкової? :)

Правило демагога № 2 (тоже про вас)
Помни — оппонент всё время должен доказывать, что он не верблюд. Если он будет доказывать любую ерунду, то у него не будет времени разоблачать тебя, и зрителям будет казаться, что ты ведёшь себя натурально.

Ну это вы меня убеждаете, что всё-всё-всё-всё мне нужно знать. Вот я и пытаюсь вычислить что же вы знаете. На деле — вы знаете магические клавиши Стг1+С и Стг1+\/
:)

Правило демагога № 3 (угадайте про кого:-)
Если в посте оппонента 90% неотразимых аргументов, на которые нечего возразить, проигнорируй их. Затем найди слабое место в оставшихся 10% и раскрути его.
+ Сперва добейся

Кроме правил демагога вы ещё что-то знаете?
По факту — не вижу.
Сколько там у вас правил? У меня упопротости получить ответ от вас штук на 10 больше :)

Признайтесь, вам доплачивают за количествео нерелвантных комментов?

Вы утверждаете, что пользователь должен знать всё.
Что пользователь должен знать кроме предметной области ещё и кучу программистских штучек.
Вы апеллируете тем, что программист тоже должен знать как ввинтить шуруп и вы это знаете.
Вас спрашивают — что вы кроме вверчивания шурупа знаете?
Вы копипастите из вики абзацы из учебника по физике.
Вас конкретно спрашивают, что вы из физических законов знаете и как вы ежедневно применяете их на практике.
Вы начинаете постить тупые картинки, что ваш оппонент считает, что школа не нужна.
Когда вас конкретно спрашивают — чему же вас выучила школа — вы начинаете морозиться и приводить правила демагога.
У кого нерелевантность?
.
Начинаем сначала.
Если вы пишете программу для хирурга по обслуживанию его пациентов — должен ли он детально вникать во все хитросплетения вашего воспалённого мозга, заставляющего этого хирурга 10 раз кликать, чтобы завести пациента? Или вы в первую очередь польёте свою голову холодной водой и задумаетесь, А ЧТО НУЖНО тому хирургу? А то неровён час он перед операцией заставит вас учить как на латыни называются все те органы, которые он собирается у вас оперировать :)

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

если вы пишете софт, который предназначен для управления каким-либо зондом внутри тела пациента
Не, вы
пишете программу для хирурга по обслуживанию его пациентов
до зондов и куда они вставляются мы ещё не дошли :)

Так сколько вам платят за комменты?

Повторюсь — Я ИДЕЙНЫЙ ТРОЛЛЯКА :)

Да ну, Gabriel, перестаньте, у Оксаны яркие и релевантные комментарии, просто она так выражается по простому, что вообщем-то плюс для форума, я так думаю. Ну, на крайний случай, мне читать интерестно, когда кепсы не переюзаны конечно ;-)

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

Заставь дурака принести тюбетейку — он принесёт её вместе с головой :)

Конкретно по интерфейсам тут, скорее всего, Джобс с Раскиным наследили. Потому что CUA был универсальнее и учился за пару дней.

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

Кастомер приходит с проблеой ЗА РЕШЕНИЕМ.
А вот за решение вам обычно этот кастомер платит...

Кастомер приходит с проблеой ЗА РЕШЕНИЕМ.

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

Кроме того, кепс в этом высказывании показался лишним, так как подчеркивает очевидный факт...

потому как от Вас ничего другого и не ожидают
Иногда это и верно...
Я допустим в парикмахерской ЧЁТКА И ЖЁСТКА ставлю свои требования. Если меня удовлетворяют на 100%+ — то я у них постоянный клиент на года — пока парикмахерша не уволится :) Но зачастую маститые парикмахеры с кучей дипломов почему-то считают, что ЛУЧШЕ знают, как должна выглядеть моя причёска, не меняющаяся уже более 15 лет...
.
И эта... ПРИВЫКАЙТЕ к моему капсу. Ну или пейте валерьянки, если он вас раздражает :)

а вы шифт держите, чтобы быть в тонусе? или все-же CAPS-LOCK ?
:-)

Подскажите как на андроиде шифт держать одновременно печатая :)

довгий тап на шифті вмикає капслок

Такой неловкий момент, когда сказал с сарказмом, а тебя восприняли ВСЕРЬЁЗ :)

Да я просто пытаюсь понять, как на андроиде удерживать одновременно две клавиши печатая (ну чтобы тот же шифт УДЕРЖИВАТЬ). Не, ну он конечно у меня мультитач, но таких чудес эквилибристики за ним не наблюдала :)

Достойный ответ тестеров-автоматизаторов (или тестерш) из известного топика :)

Толстота этого поста переплюнула баттхёрт предыдущего.
Выше, быстрее, сильнее, ДОУ.

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

В целом получилось более уныло чем статья о QA. А ведь написать есть что

Шото я ниасилил: TL вас подставил, а потом поделил премию с PM или на проекте просто не было QA и все шло сразу в прод?

Поясняю:
1) вы делаете быстро
2) быстро = с багами
3) вам не дают премию.
4) TL знал об этой ситуации и ввел вас в заблуждение
5) продукт с багами, заказчик «негодуэ»
6) выходит TL в маске Бэтмена и «спасает» проект, бросив на локализацию багов других девов и вас в т.ч. бесплатно (если молодые нубы), либо за обычную ставку.
7) Проект спасен и PM дает премию TL за «разруливание» ситуации, он не будучи дураков, отстегивает часть назад.

получается статья про вас: чик-чик и в продакшен.

на самом деле много компаний так работает и получают хорошую прибыль
Модель называется «najebi-soseda» — типичная модель бизнес-поведения в СНГ, что имело место в 90-х при тотальном дефиците, но встречается и сейчас, среди товарищей, «живущих на 2%».

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

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

вы ещё скажите что у вас такого не было)))
2) у нас такого не было. Все тщательно тестировалось и выверялось на qa-env, stage-env, pre-production (другой кластер по соседству с боевым). За 3 года в продакшене не было ни одного дефекта. Просто перделка заказчика за год поменялась, что он пытался выдать как баг, ткнули носом в ТЗ — отпустило.

Вывод: пишите ТЗ, ибо заказчик — такой олень!

Добросовестность, сдержанность и скромность;
определенно первоочередные качества определяющие «профессионала» разработчика в глазах. QA:)

Первоочередные качества, которые ценятся коллегами. Не зависимо от специальности.

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

Хорошо хоть добросовестность вопросов не вызывает :)
Тут как в старом анекдоте — «Сарочка, не путайте суету с темпераментностью».
Скромность позволит руководителю понять, что он не пуп земли, а лишь человек, который решает проблемы команды. Ну а раз так — то либо он их решает, либо меняет работу.

Ну а сдержанность очень даже позволяет дожимать свое решение.

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

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

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

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

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

+ еще забыли, что я вполне вероятно считаю, «разработчик — это только умение стучать по клавишам».

«Ты был неплох,совсем неплох парень, но пока я здесь-ты всегда будешь вторым!» ©
Интересная мысль про звездную болезнь — наблюдал признаки у некоторых людей.
В остальном скучно и неинтересно до зевоты.

Особенно забавно читать, что QA-ям не нравятся шаблоны, рефакторинг и инжениринг в приложениях. Скажу вкратце: пофиксить баг и внедрить очередную перделку не так просто, как вам кажется со стороны черного ящика. Можно фиксить баги молниеносно, в этом случае по итогу уже на 2-3 спринте будет ситуация

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

Если девелопер пошел в реинжиниринг — это не от хорошей жизни, просто если он не поменяет архитектуру, не порефакторит, не покроет тестами, то через 3-4 спринта уже нечего будет тестировать и фирма потеряет проект. Вам-то пофиг в шо клацать, а для девелоперов и (особенно PM) это тяжело терять код, проект и деньги.

Дело усугубляется твердой уверенностью, что он глава мироздания в IT фирме, и он всех «кормит», а все остальные нахлебники.
Можно очень просто понять кто в фирме основной работник — исключая других из процесса. Если убрать девелопера — делать продукт будет некому и вся остальная пищевая цепочка идет в лес. Без QA продукт будет не такой уж user-friendly и (возможно) более забагованный, но будет. Поэтому опять мимо.

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

P.S. В целом девелоперы страстно не любят копипасту, а вы в этом топике скопипастили 50+% текста другого топика, что свидетельствует о вашей ленности.

Нэ залик! Вот не надо было писать лишь бы написать.

Ловля звезд.
Большинство dev "over-engineer«-ят при малейшей возможности, изучая что-то новое не осознают, когда это новое применимо к месту.
Такое встречается. Одна из реальных проблем нашего рынка и не только.
.
К сожалению, остально во многом это «уколоть в ответ».
Их не особо беспокоит, что получившийся ублюдок не взлетит, а лишь покашляв, выбросит очередной NPE.
Разработчик за внесенный баг, обычно, получает люлей, особенно если это постоянно происходит. В то же время:
Типовый подход — придраться к верстке
на 10-й странице, хотя команда работает над интеграцией.
не слышал чтобы КуА огребал, за то что нашел баг. Да не мажор, но баг же.
.
засыпая в широковещательной рассылке всех, включая вице-президента, уточнениями и вопросами по фиче
Рылли? Разработчик который по своей воле ввязывается в переписку? Это совсем не типично, большинство разработчиков таки интроверты. Второй «укол в ответ», а не реальный факт.
.
Разгар подготовки релизной версии, QA и dev-ops в мыле, team-lead уже 6-й час на совещаниях и ему там не сладко. Dev при этом в течение дня несколько раз играли в футбол
Тут сразу 2 момента:
1) Вы в курсе кто такие dev-ops? Подсказка: админы — это просто ops.
2) И вот во время запары КуА и админы не побегут первым же делом к разработчикам (или их тим-лиду) с фразой «У нас ниче не работает сделай что-то»? Рылли?
.
Двойные стандарты — второе имя DEV.
Еще один «укол в ответ». Проблема того что
DEV очень любят писать краткие комменты на техническом языке в JIRA, игнорируя факт, что помимо них трекер читают и junior QA, и люди, зачастую далекие от технической части (BA, PM), обижаясь при этом на справедливые замечания.
Она есть. Частично она возвращает нас к предыдущей теме. Частично — это таки проблема того что дев не всегда хорошо коммуницируют.
Так и напишете, это проблема, но она не про «двойные стандарты».
ввести недостающие хуки в api для облегчения тестирования
О, эт лично для меня больная тема. Какие нах «хуки для тестирования»? Если вызов реально нужен __пользователям__ то его добавляют, а вот засерать АПИ, верстку и тд для удобства тестирования, в ущерб архитектуре — это снова отсыл к вопросам профессионализма того кто проверяет. Но может на примере вы сможете объяснить свою позицию лучше.
.
P.S. Добавьте ссылку на первоначальный топик dou.ua/...ums/topic/9938
Какие нах «хуки для тестирования»?
Тут QA правий в своїх претензіях. Якщо, наприклад, життя заставляє розробчика тестувати власний код, то добавити дебажні фішки не так уже й накладно, і архітектура вистоїть. Звичайно, естетика коду важливіша за зручність в тестуванні, коли про це просить стороння людина (яка, тим більше, не усвідомлює глибину художнього замислу за строками незрозумілих букв).
Якщо, наприклад, життя заставляє розробчика тестувати власний код, то добавити дебажні фішки не так уже й накладно, і архітектура вистоїть.
Нет. Повторяю:
Если вызов реально нужен __пользователям__ то его добавляют
Если “хук” нужен, если он улучшает юзабельность АПИ, то его добавят, а если придумали тест как попало и просто нет желания сделать +1 вызов, то надо слать нах.
Но может на примере вы сможете объяснить свою позицию лучше.

Можливо, ми говоримо про різні ситуції. Я за «хуки» в таких, наприклад, кейсах: якщо баг пов’язаний з часом (тайм-аут, зміна дати), то даємо тестерам ф-ї для контролю/правки часу; якщо потрібно багато кроків (99-а покупка глючить), робимо кнопку «виконати _щось_ 20 раз»; якщо ознаки неправильної роботи не очевидні, добавляємо інфо-панель (мигаючий червоний квадратик скраю вікна). Звичайно, це все прописуємо, наскільки можливо, в окремому модулі, де потрібно, вставляємо #ifdef NOT_FINAL_RELEASE.

якщо баг пов’язаний з часом (тайм-аут, зміна дати), то даємо тестерам ф-ї для контролю/правки часу; якщо потрібно багато кроків (99-а покупка глючить), робимо кнопку “виконати _щось_ 20 раз”;
в ущерб архитектуре — это снова отсыл к вопросам профессионализма того кто проверяет.
.
якщо ознаки неправильної роботи не очевидні, добавляємо інфо-панель (мигаючий червоний квадратик скраю вікна).
А вот это уже реальный баг/ПМ-баг, оно не информативно для пользователя и это надо исправлять. А если информирование пользователя нормальное, но тестеру хочетсо мигания, то его надо слать лесом ибо см выше.
.
Звичайно, це все прописуємо, наскільки можливо, в окремому модулі, де потрібно, вставляємо #ifdef NOT_FINAL_RELEASE.
А вы понимаете что предлагаете тестировать в среде заведомо отличной от среды эксплуатации? И тестировать систему в нектором роде отличную от той которая пойдет в продакшн?
А вот это уже реальный баг/ПМ-баг, оно не информативно для пользователя и это надо исправлять.
Я мав на увазі внутрішнє тестування. Користувачі ніякі інфо-панелі не побачать.
А вы понимаете что предлагаете тестировать в среде заведомо отличной от среды эксплуатации?
Звичайно, ми ризикуємо задля зручності QA. Остаточні тести потрібно проводити на релізному білді, в свій час. А поки йде активна розробка, можна добавити тестерам комфорту в їх роботі, вони оцінять :)

видимо QA-и все еще переживают баттхерт от оригинала :-)

Ждем статью «PM-непрофессионализм — главный тренд в отрасли»

Может вы напишите с высоты опыта CEO ?

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

Yes sir!
В течение нескольких месяцев сделаю.
(но сначала нужно набрать материала).

Есть еще свободная тема: «CEO-непрофессионализм — главный тренд в отрасли»

«Наблюдательный совет акционеров-непрофессионлизм — главный тренд в отрасли»

Есть еще тема: «Президент-непрофессионализм — главный тренд в области».

Как много нераскрытых тем. :-)

Тогда уж не в области, а в стране :)

Я знаю место, где продают офигенные циркули. А где профессионально обучают быть президентом ?

Профессионально или проФФессионально?

Академия ФСБ, Гарвард, Енакиевский горный техникум.

Ну вообще-то, все приведённые проблемы, и тут, и в предыдущей статье — это как раз последствия «PM-непрофессионализма»

А как же БА-непрофессинализм? :)

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

В целом цикл статей о непрофессионализме, который начал Gabriel Angelos, может получится очень даже ничего.
Нет.
Статью про куа раскритиковали куа. Статью про девов — девы.
Вот так дальше и будет в каждой «новой, теперь с малиновым вкусом», статье.
Статью про куа раскритиковали куа.

Испытать баттхерт и писать «сам дурак» != раскритиковать. Статью про девов и критиковать нечего, это всего-лишь подделка как например отечественный автопром по сравнению с зарубежным.
Подумаю про кого следующего написать статью :-)
Хорошо быть анонимом.

Там еще выше предлагали Заказчик- непрофессионализм — главный тренд в отрасли.

Підписатись на коментарі