×Закрыть

Когда толковый программист задает идиотские вопросы — это хороший знак

Хороший программист ленив и туп?

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

— Слушай, а какой у нас вызывается метод, когда приходит уведомление об отправке сообщения?
— Какой отправки?
— Успешной отправки сообщения.
— Какое уведомление?
— О том, что все хорошо. С кодом «200».
— Что значит «все хорошо»?
— Ну, когда приходит уведомление с кодом «200» и сообщение доставлено получателю.
— Почему ты думаешь, что должен вызываться какой-либо метод?
— Кто-то же должен триггерить ивент.
— Какой ивент?

И так далее.

Учиться общению нужно у военных

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

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

Борисполь-Руление, AUI001, предполетная проверка.
AUI001, Борисполь-Руление, слышимость 5.
AUI001, слышимость 5, до связи.

В реальной жизни это было бы похоже на:

Жена, Муж, предужинная проверка.
Муж, Жена, борщ 5.
Жена, борщ 5, до связи.

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

Перенимаем опыт

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

1) Принцип дублирования информации. Необходим тогда, когда передающий не уверен в том, что его услышали. Например, в доктрине армии США четко прописан такой момент:
«Вы должны всегда повторять миссию дважды, чтобы любой из тех солдат, кто невнимательно слушал, имел шанс узнать о том, что ему предстоит делать.»

2) Принцип дополнительной информации, согласно которому следует выбирать такие конструкции и слова, которые исключат неверное толкование сообщения. Например, в той же гражданской авиации США есть список слов, призванных улучшить голосовую связь:
Вместо короткого «Yes» употребляется более различимое «Affirmative». Вместо бубнящего «No» используется более четкое «Negative». Много лишних букв, зато меньше шансов для недопонимания.

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

В армии США, опять-таки, никто не говорит «11 часов», но говорят «eleven hundred hours» (1100). Точно так же никто не говорит «три часа». Вместо этого говорят «zero three hundred hours» (0300). Лишняя информация? Возможно. Допускает ли такая подача двусмысленное толкование? Никак нет.

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

Пример из жизни

За участие в политической массовке студенту пообещали 50-100 грн. Он рад и надеется в конце дня получить свою сотню. Но вечером куратор дает ему 50, а на удивленные распросы отвечает: «я же тебе говорил, 50-100 грн, всё по-честному». — И он прав.

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

Бытовые конфликты: когда виноваты все
Молча передавая водителю маршрутки 20 гривен, вы заставляете его думать, нарушая одну из краеугольных заповедей юзабилити — «Don’t make me think». Теперь ему нужно считать пассажиров и проводить вычисления. Возможно, потребуется учесть и то, что парень, передающий двадцатку, вошел с девушкой. «Они вместе? Тогда я должен посчитать за двоих». Но по факту оказывается, что эту двадцатку передал кто-то другой, в результате чего водитель выдает неправильную сдачу, парень начинает злиться, идет цепная реакция негатива. Хотя, замешано всё было на недопонимании и виноваты оказались абсолютно все: Парень, который не уточнил, за скольких он платит; водитель, который не удосужился переспросить; и тот пассажир в глубине салона, который просил парня передать двадцатку, но не проявил должной конкретики. Guilty!

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

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

LinkedIn

Лучшие комментарии пропустить

— Примите инвойс!
— Кого?
— По буквам: Инна, Николай, Вова, Олег, Йосип, Сергей!
— Б**дь, кто все эти люди?

Например, в той же гражданской авиации США есть список слов, призванных улучшить голосовую связь:
Вместо короткого «Yes» употребляется более различимое «Affirmative». Вместо бубнящего «No» используется более четкое «Negative».

Блин, 8 лет меня мучал вопрос — почему в counter-strike используются ’Affirmative’, ’Negative’, ’Roger That’ вместо простых yes, no.

Спасибо =).

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

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

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

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

Аналогично в разработке. Например, в продукте есть действие связанное с окончанием некоего события, и оно называется finishEvent, это значит оно везде и должно так называться. Не closeEvent, не endEvent, не terminateEvent и так далее. Аналогично все URLы, связанные с ним и все переменные должны содержать именно слово finish. Код-бьютифаеры пока не умеют это отслеживать, увы. Если вы это сами как тимлид не проконтролируете, то количество хаоса, который случайно нагенерят девелоперы будет огромным. Испытано на своей шкуре, больше не хочу.

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

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

113 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Когда передаю деньги за проезд всегда говорю за скольких людей плачу, даже если 1 человек и под расчет.

За участие в политической массовке студенту пообещали 50-100 грн. Он рад и надеется в конце дня получить свою сотню. Но вечером куратор дает ему 50, а на удивленные распросы отвечает: «я же тебе говорил, 50-100 грн, всё по-честному». — И он прав.

Лучше примера для украинского сегмента интернета и не подобрать.

Диалог можно, конечно, значительно упростить:

— Слушай, а какой у нас вызывается метод, когда приходит уведомление об отправке сообщения?
— Какой отправки?
— А поцчему Ви отвечаете вопгосом на вопгос?
— Слушай, а какой у нас вызывается метод, когда приходит уведомление об отправке сообщения?
— Какой отправки?
— Успешной отправки сообщения.
— Какое уведомление?
— О том, что все хорошо. С кодом “200”.
— Что значит “все хорошо”?
— Ну, когда приходит уведомление с кодом “200” и сообщение доставлено получателю.
— Почему ты думаешь, что должен вызываться какой-либо метод?

— Потому что две недели назад бьіло принято решение, что какой-то метод должен вьізьіваться в єтом случае. Потому что неделю назад тебе бьіла поставлена задача написать єтот метод и тьі ету задачу сдал. Потому что он уже вьізьівается и я просто хочу знать его название.
— Ааааааа.... тьі про ЄТОТ метод. А я как всегда подумал про что-то не связанное с твоим вопросом и все время думал о другой теме, надеялся что тьі устанешь и отцепишься.

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

www.youtube.com/...h?v=q1hmPfFDEu8

have individuals with weapons.
he has got a weapon, too.
hotel two-six, crazy horse one-eight.
have 5 to 6 individuals with ak47’s
request permission to engage.
R O G E R that !
Uh, we have no personnel east of our position.
So. uh, you are free to engage. Over.
Goddamn it!
Uh, negative. he was, uh, he was right in front of the Brad.
Uh, ’bout , there, one, o’clock.
haven’t seen anything since then.
just fuckin’. once you get on ’em, just open ’em up.
all right.
i see your element, uh, got about four humbvees, uh, out along ...
you are clear. alright firing.
let me know when you have them them.
let’s shoot.
light ’em all up. come on, fire!
keep shoot’n! keep shoot’n! keep shoot’n!
hey, you shoot, i will talk.
hotel two-six, crazy horse one-eight.
crazy horse one-eight, this is hotel two-six. over.
can i shoot?
Roger. Break!
crazy horse one-eight request to engage.
this bushmaster seven. roger. this bushmaster seven. roger. engage
one-eight. engage. clear.
c o m e o n!
clear.
clear. we are engaging
coming around. clear. Roger. trying to uh ...

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

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

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

Борисполь-Руление, AUI001, предполетная проверка.
AUI001, Борисполь-Руление, слышимость 5.
AUI001, слышимость 5, до связи.
В реальной жизни это было бы похоже на:
Жена, Муж, предужинная проверка.
Муж, Жена, борщ 5.
Жена, борщ 5, до связи.

Это достойно места в постоянной памяти

Почитайте про Задачу византийских генералов

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

Цель такого диалога зачастую не в передаче информации (поэтому вся остальная фигня про военных и пилотов имеет мало отношения к действительности). В основном такие диалоги это «не заставляй меня думать над твоей проблемой, по крайней мере раньше чем надо». Стандартные концовки:
1) — АААА я все понял, спасиба! (Убегает с той же скоростью как прибегал)
— Пожалуйста
2) На очередной итерации:
— (Какой-то ответ)
— (Срабатывает триггер на бред) Чо? (Заинтересованно) А теперь все тоже самое с самого начала.
3) На очередной итерации приходим к вопросу на который можно дать ответ не приходя в сознание :)

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

Ціль такого діалога максимально відфільтрувати вплив оточення кліента на інформацію. Тоб-то максимально KISS запитання. В той час коли джуніор відштовхується від свого оточення (враження, логіки предметів).

Жена, Муж, предужинная проверка.
Муж, Жена, борщ 5.
Жена, борщ 5, до связи.
— Приборы?
— 200!
— Что «200»?
— Что «приборы»?

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

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

Далее тоже можно разобрать чисто технически.
Почему каждый из участников повторяет «ритуальную фразу» — называя каждый раз себя и своего собеседника? Потому что разговор идёт в эфире и его могут принимать и другие «точки», в разговоре не участвующие, но по указанию отправителя и получателя понимающие, что это обращение к ним не относится. Ба! Да это же сетевой пакет с указанием адресов «откуда» и «куда»!

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

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

Вместе с тем есть и другая сторона. Уже упопянутый в этом топике «кодер» — он чаще всего а) ограничено способен к оптимальному и просто разумному общению чисто человеческому в т.ч. и профессиональному; б) он чаще всего неспособен понимать и тем более создавать оптимальные и просто разумные и иногда даже просто функционирующие системы уже компьютерные. «Кодить» — наверное, да. Мне уже трудно судить на этом уровне — видимо, «хорошо кодить» — это, по крайней мере, следовать code conventions. А вот понять и создать или модифицировать даже простой протокол вроде описанного со всеми необходимыми атрибутами — уже нет.

Вот вам и

В первом прочтении интерпретировалось как

Протоколов и так хватает в работе. А вот общаться предпочитаю по-человечески. Касательно интерпретации — она была дана в контексте. В контексте общения с женой:
class Echo(protocol.Protocol):
def dataReceived(self, data):
if u’борщ 5′ == data:
self.transport.write(u’Половник вылетел; конец секса. Повторяю: половник вылетел; конец секса’)

А потом люди, привыкшие общаться с машинами и как машины, на доу интересуются «где и как найди девушку».

Прошу считать это безличностным примером :-D

Не знала про повторение инфы — очень хороший принцип.

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

В случае с телефонными номерами действительно работает. А вот с имейлами иногда путаницы ещё больше... особенно когда диктуешь тому, кто не сильно шарит в латинских буквах :) «С как доллар» и вечная путаница в «e» и «i»...

Тут надо им как военные говорить — зулу, браво, или смотришь на инглишь клаву а диктуешь им русские буквы — Жать то русские могут, вот там и выйдет что-то на инглише))

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

когда я слышу «сэ как доллар» или подобное — я говорю, что пришлите СМС или я пришлю иначе это надолго

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

Ещё с детьми работает хорошо))) Не зря ж мамы повторяют всё как минимум два раза)))) Они что-то знают))))))))

Юрий, так вы правда новый главред доу или просто графоман?

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

Да, встречались. Как раз сейчас общаюсь с HR из ... ммм, запамятовал. Ах да, из Wargaming. Вполне адекватная девушка. Но лично не знакомы.

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

Хорошая попытка, но слишком толсто, что засчитать(:

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

— Примите инвойс!
— Кого?
— По буквам: Инна, Николай, Вова, Олег, Йосип, Сергей!
— Б**дь, кто все эти люди?

По буквам: Инкуб, Носферату, Вервольф, Один, Ибикус краткий, Сатанаил!

— Здесь дают премию? Моя фамилия Итого.
— Нет, здесь начисляются налоги. То как говорите ваша фамилия?

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

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

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

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

Нет. «Выражать в коде» — это не «разработчик», это именно «кодер». Которые роли могут быть совмещены в одном человеке, но это не значит что «разработчику» достаточно одного только кода для общения.

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

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

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

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

Жена, Муж, предужинная проверка.
Муж, Жена, борщ 5.
Жена, борщ 5, до связи.
Не дай Бог такие диалоги в жизни...Особенно в более интимные моменты...

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

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

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

Ты не прав. Есть у меня несколько знакомых... которые так мягко подводят к тому, что ты совершенно не прав. Может воспитание им не позволяет сразу сказать «ты ошибся», может они заранее хотят провести собеседника по всем пунктам, которые дадут понять где ошибка — я не знаю. Но со временем привыкаешь к такому общению )))

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

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

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

Могут побить, а могут и зауважать. Зависит от уровня собеседника;)

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

И это хорошо =)
це сумнівно :)

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

Согласен, на кухне правила этикета требуют бить яйца.

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

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

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

Аналогично в разработке. Например, в продукте есть действие связанное с окончанием некоего события, и оно называется finishEvent, это значит оно везде и должно так называться. Не closeEvent, не endEvent, не terminateEvent и так далее. Аналогично все URLы, связанные с ним и все переменные должны содержать именно слово finish. Код-бьютифаеры пока не умеют это отслеживать, увы. Если вы это сами как тимлид не проконтролируете, то количество хаоса, который случайно нагенерят девелоперы будет огромным. Испытано на своей шкуре, больше не хочу.

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

TL;DR
Придерживайтесь code conventions, чтобы на выходных не подавиться пивом.

Есть случаи, когда даже от самых строгих code conventions надо отходить ради удобства чтения. Очень очень редко, чтобы выровнять специфичный код типа сложного SQL удобнее использовать нечётное число пробелов, а не стандартные 2 или 4. Проблема в том, что для этого нужно знать, когда именно это делать можно :)

Це повинно бути описане в

code conventions
:-Ъ

Можно конечно было так сделать, но превращать code conventions в большой талмуд, в котором описано всё и вся, мне не очень хотелось. Чем большего размера документ, и чем скучнее там информация, тем меньше вероятности, что его прочтут и выучат. Люди — не роботы. Я больше фанат подхода в духе PHPTheRightWay — вот вам общие принципы хорошего стиля, а от них можете отклоняться если вы уверены, что отклонение идёт во благо.

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

У вас тим лид одновременно в QC департаменте работает?

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

Но у нас не супер business-critical product, так что копировать такую схему повсюду не советую. Если вы пишете софт для высокочастотного трейдинга, например, тогда вам обязательно нужно дофига QA и дофига юнит-тестов. Это само собой разумеется.

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

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

Я знаю довольно неплохо PHP (модерирую PHP-квизы на Quizful), чуть-чуть JS и jQuery (см. мой предпоследний пост у меня на сайте на /devblog/), могу что-то на CSS подсказать дизайнеру, типа правил суммирования мощности селекторов, могу потрепаться с DBA на тему как правильно моделировать данные для проекта и какие триггеры или хранимки использовать, если надо — написать или отдебажить что-то простое в PL-SQL или повкуривать EXPLAIN тормозящего запроса (или что там в Оракле аналогичное, не помню). Могу написать простенькие тесты на SoapUI, Selenium или PHPUnit, могу пойти к сисадминам, попросить их на линуксе чё-то проверить с правами, или попросить их logrotate врубить на лог к примеру. Сам себе я на дев-машине Vagrant-виртуалку поставил и настроил — доволен, как слон :). Могу посраться с начальником на тему дурацких требований в спеке, которые по итогу никому в реальности оказываются не нужны, ибо неудобны, в последнее время всё больше угадываю. Могу подумать с дизайнером на тему хорошего UI и выбрать то, что интересно было бы сделать (Джоэла Сполски, Психбольницу в руках пациентов и Илью Бирмана начитался, так что про UI я немного соображаю), могу набросать API вебсервисов для разработчика мобильного приложения и согласовать с ним форматы, названия и так далее.

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

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

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

Хороший вопрос, вы меня подловили на формулировке, спасибо :). Разумеется, с сеньорами так делать было бы совсем неэффективно.

Я никогда не работал в аутсорсе, поэтому не очень в курсе, кого там называют Senior dev, кого middle и так далее, ориентируюсь на Австрию. В моём понимании Senior dev обычно целиком отвечает за какой-то кусок проекта, например, за мобильное приложение к моему веб-проекту. В таком случае я, как правило, не лезу в его код, а лишь согласовываю API взаимодействия. Там он — царь и бог, всё понятно. Второй вариант — senior отвечает за модуль внутри проекта, подчиняющегося общим стандартам и имеющем единую базу кода. Тут как правило я тоже не лезу в детали, если стреляет что-то, то это его задача. Максимум, я могу пробежаться по его коду и исправить / попросить исправить косяки с именованием, стилем кода, копипастой или структурой, если мне кажется, что можно было сделать лучше. Самая частая проблема по моему опыту — тотальное незнание английского, выражающееся в появлении переменных типа $qualiti или вообще каких-нить странных $q, которые через 15 строк кода вообще непонятно к чему. Такое я стараюсь убирать сразу, чтобы сохранить читабельность кода.

1. Однозначность терминов. Когда кто-то из солдат видит противника, он сообщает по рации “контакт”. Не “там кто-то есть”, не “враг”, не “о, ля смотри побежал кто-то”. “Контакт” — это метафора, обозначающая, что сообщающий не знает пока, это друг или враг, но увидел движение.
Аналогично в разработке. Например, в продукте есть действие связанное с окончанием некоего события, и оно называется finishEvent, это значит оно везде и должно так называться. Не closeEvent, не endEvent, не terminateEvent и так далее. Аналогично все URLы, связанные с ним и все переменные должны содержать именно слово finish. Код-бьютифаеры пока не умеют это отслеживать, увы. Если вы это сами как тимлид не проконтролируете, то количество хаоса, который случайно нагенерят девелоперы будет огромным. Испытано на своей шкуре, больше не хочу.
Воєнщіна накручена. Contact — просто узагальнення, як Event. А в цьому випадку це більше схоже на нормальну стандартизацію (або регламент).

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

это значит оно везде и должно так называться
Подмечено верно. У военных это называется «однообразие». «В армии всё безобразно, но однообразно». И это часто разумно, хотя лучше бы безобразия поменьше. Если в коде по факту оказались где-то finishEvent, а где-то closeEvent, то есть смысл уединообразить.

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

Отличная статья, спасибо.
Но есть некоторые люди, особенно тролли, которые задают уточняющие вопросы с умным видом специально, чтобы позлить позлить собеседника, особенно если тот менее компетентен. И после 5 минут беседы с 40-50 вопросами резюмируют: «Нууу, надо разбираться», что подразумевает «Отвали от меня и сам разберись». Считаю такой подход неконструктивным на работе.

ну если переспрашивают уже то что 100 раз слышали то тут пора воздействовать уже другими методами.

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

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

здоровая атмосфера — наше все )
если принцип ЧЧВ то ниче хорошего не будет

если не ччв, то и вопросов не возникает :) мы же разбиралди вариант когда все плохо

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

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

Хмм, а я всегда думал, что когда приходит новый человек, то команда сама заинтересована поскорее ввести его в курс дела и «поставить на ноги».

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

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

кому-то нравится учить, кому-то нет, но тех кому нет — больше, а если это не их задача, то они и не обязаны

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

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

Хм-хм. Я вот такой человек, который с трудом объясняет и мне это не очень нравится. С другой стороны, когда к нам приходили новые люди, часто подходили и спрашивали, всё было ОК. Если это не праздный интерес, человеку в кайф поделиться чем-то (касается любой области). При условии, что нет жёсткой загрузки в данный момент, конечно.

мне вообще сложно объективно об этом рассуждать, т.к. я как раз тот, кто учит с удовольствием

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

Зависит от проекта, команды и самого новенького. Ситуации могут быть очень разные. Если не хватает тасков или субкультура не совпала, то может быть очень печально. Если новенький не на своей позиции, если команда хочет почесать ЧСВ. Если все в мыле, а тут вам нате: 3 махровых джуна. В общем с моей точки зрения благоприятных ситуаций гораздо меньше

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

когда он уже 100 раз спрашивал это, то пора подумать в какой клинике этого человека нашли и почему он здесь

Например, в той же гражданской авиации США есть список слов, призванных улучшить голосовую связь:
Вместо короткого «Yes» употребляется более различимое «Affirmative». Вместо бубнящего «No» используется более четкое «Negative».

Блин, 8 лет меня мучал вопрос — почему в counter-strike используются ’Affirmative’, ’Negative’, ’Roger That’ вместо простых yes, no.

Спасибо =).

А меня они заставили в словарь заглянуть )
А есси что-то на голову летит то надо кричать «Incoming!» )

подобная петрушка и в алфавите «для военных».
типа «Foxtrot, Uniform, Charlie, Kilo».

OMG! Вы что не служили в армии!?

IMHO лучше іспользовать ’Roger’ <> ’Negative’, бо ’Affirmative’ закінченням схоже тому легко може створити сумнівну ситуацію. До того ж воно коротше :)

А у меня Affirmative из старых Command&Conquer ещё отложилось :-)

Звукосочетания «Roger that» весьма распознаваемы по радиопередаче, даже если толпы вьетнамцев собрались вокруг радиста, стреляют и кричат «Американ, сдавайсо!»...

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

Зато я видел пару случаев, когда тёртые HR’ши приноровились к таким беседам и не обижались на сухие диалоги с проггерами. Что касается ПМов, то все-таки лучше, когда человек побывал в разработке и знает, что такой стиль общения — не пурга, а насущная необходимость.

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

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

Жена, Муж, предужинная проверка.
Муж, Жена, борщ 5.
Жена, борщ 5, до связи.
Вот и поговорили. Сухо, без эмоций, зато передает всю суть и не оставляет места двусмысленным толкованиям.
5 чего? минут, часов, литров?
У пилотов и вояк немного другая история, там контекст — это «плохая слишимость» и в вашем примере про «Борисполь-Руление» как раз слышимость и проверяли, скорее всего. Но мог быть и другой контекст.
Молча передавая водителю маршрутки 20 гривен, вы заставляете его думать, нарушая одну из краеугольных заповедей юзабилити — «Don’t make me think». Теперь ему нужно считать пассажиров и проводить вычисления.
В общем есть такое понятие «общеизвестно» и «общепринято». Так вот если количство не названо, то деньги за одного человека.
В общем есть такое понятие «общеизвестно» и «общепринято»
Угайте что. У каждого человека «общеизвестно» и «общепринято» может отличаться.
Как-то провожал свою девушку на маршрутку домой. Попрощались. Через некоторое время написал ей СМС — «Нормально доехала?». После чего она мне позвонила и сказала, что вообще-то принято звонить и спрашивать нормально ли девушка доехала, а не слать СМС. Вот вам и пример бытового недоразумения на почве вашего «общепринято». Добавить к этой ситуации немного плохого настроения и чуток обиды — получится отличный рецепт ссоры на ровном месте.
После чего она мне позвонила и сказала, что вообще-то принято звонить и спрашивать нормально ли девушка доехала, а не слать СМС.
Пример, мимо кассы. Ваша девушка просто решила вам вынести мозг (такое бывает).
У каждого человека «общеизвестно» и «общепринято» может отличаться.
У людей которые находятся в одной группе, обычно, формируются такие вот «общеизвестно и общепринято», что позволяет им экономить время на передачу информации.
.
Когда-то мне такие диалоги казались форменным издевательством
Вот скажите как ваша статья проясняет, тот диалог который вам казался издевательством, а сейчас уже вам понятен (Такой вывод я делаю из того что нет смысла употрелять фразу «Когда-то мне ... казались», если нет изменения ситуации).

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

(Такой вывод я делаю из того что нет смысла употрелять фразу «Когда-то мне ... казались», если нет изменения ситуации)
Напротив, изменение в ситуации есть. Раньше мне такие диалоги казались издевательством, а теперь я и сам так говорю в те моменты, когда требуется ясность для разрешения вопроса.
Диалог между разработчиками, который я привел вначале, проясняется последующими примерами общения летчиков и военных. Речь идет о «протоколе», если хотите.
Какой нафик протокол?
— Успешной отправки сообщения.
— Какое уведомление?
— О том, что все хорошо. С кодом «200».
— Что значит «все хорошо»?
— Ну, когда приходит уведомление с кодом «200» и сообщение доставлено получателю.
Человек который начал диалог просто не смог обяснить чего он хочет. Если чесно, то я так и не понял чего хотел первый. Может вы проясните, раз речь идет о «протоколе», а не просто о «ну это то ну ты понял».

Матчасть собственно. Нолэн показал рукой, причём вроде бы на позиции в дальнем конце долины. Сам Нолэн погибнет во время атаки и суть его жеста останется неизвестной. ru.wikipedia.org/...wiki/Атака_лёгкой_бригады

У пилотов и вояк немного другая история, там контекст — это «плохая слишимость» и в вашем примере про «Борисполь-Руление» как раз слышимость и проверяли, скорее всего.
Это протокол общения диспетчер — пилот. Такое же и на ЖД. Да это все пишется регистратором, а сейчас внедряется в РФ еще и дополнительная проверка движком рапознавания речи требования соблюдения протокола — это на РЖД.
Причины: предотвратить плохую слышимость, непонимание и последующие аварии.
Молча передавая водителю маршрутки 20 гривен, вы заставляете его думать...
В общем есть такое понятие «общеизвестно» и «общепринято». Так вот если количство не названо, то деньги за одного человека.

Реальность: если я молча передаю, у меня еще могут уточнить «это водителю?»

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

Пожалуй, покажу эту статью своей девушке.

Но будь готов к тому, что у неё есть мощный контраргумент из 2 слов: «Ой, всё!»

Для освоения инструментов конкретизации рецепта борща? ;-)

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