Практическое пособие «Как вывести из себя программиста»

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

Такие вопросы, помимо нервного тика, приводят и к другим последствиям: у программистов не остается другого выхода кроме как соврать. Потому что дать человеку, далекому от программирования, экспресс-курс «Как писать код» за несколько минут, задача не из легких.

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

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

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

Конечно, это не так плохо, все учатся на своих ошибках. Например, описывая в интервью свой опыт работы junior-разработчиком, Джонатан Барронвиль (Jonathan Barronville) говорит, что ошибаться и не знать чего-то на начальных этапах работы нормально. Но чтобы не услышать ложь в ответ на невыполнимую просьбу или некорректно поставленную задачу, менеджерам стоит обсуждать условия и прислушиваться к мнению специалистов.

«Ты так долго писал код, в нем же больше нет ошибок?»
Даже если код, сайт или программа отлично работают, имеют удобный интерфейс (то, что видят пользователи), за всем этим может скрываться такое количество ошибок, что остается загадкой, как это все работает. Да и вообще, как сказал известный нидерландский ученый-информатик Эдсгер Дейкстра (Edsger Dijkstra), если отладка кода — это процесс устранения багов, то программирование — это процесс внедрения багов.

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

«Ты должен мыслить как клиент»
Общение с людьми, далекими от программирования, иногда доставляют разработчикам, ну вы сами понимаете, «боль». А когда менеджер просит мыслить как эти люди, становится еще хуже. Поэтому когда разработчик говорит, что понял, чего хочет клиент, это не всегда так. Разработчик знает только то, что сказал клиент, а что он думает, и уж тем более как он мыслит, часто непостижимо.

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

Мыслить как такой пользователь программист точно не сможет, так как он сам знает о коде все, а пользователь — ничего. (Подробнее о работе отдела контроля качества читайте тут «How the QA Process Works» и «QA Teams Are Responsible For Keeping the Site From Breaking»).

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

«Ты не должен отвлекаться — иначе ничего не получится»
Клиенты и начальники хотят сразу видеть, что программист начал работать. Точнее, что он сел перед экраном и начал писать код, уверен всемирно известный эксперт в области ИТ Дэвид Штром (David Strom). Он составил список 10 вещей, которые непрограммисты любят говорить программистам, где в седьмом пункте объясняет, что такие люди не понимают важности предварительной работы.

Написание кода — вообще последний этап работы, подготовительная часть до этого состоит из совсем других вещей, которые посторонним могут казаться бездельем, объясняет Маклауд Сойер в 4 пункте своей статьи. Чтобы продумать выполнение определенных задач и требований, иногда нужно расслабиться, посмотреть в окно, послоняться вокруг, поспать или даже поиграть в Halo — никогда не знаешь, в какой именно момент придет решение.

Харлан Миллс (Harlan Mills), основатель Software Engineering Technology однажды сказал: «Программирование напоминает игру в гольф. Цель не загнать шарик в лунку, а сделать это за наименьшее количество ударов». Чтобы достичь цели быстрее, необходимо как можно лучше продумать все шаги и «удары». Осталось только объяснить это менеджеру.

«Я плачу за код, а не за комментарии»
Конечно, у вашего босса есть право считать так, но ему не приходилось работать с кодом без комментариев. В то время как их наличие сильно экономит время, если с этим кодом придется работать кому-то другому и даже вам самим спустя несколько месяцев или лет, пишет блоггер Джейк Рошело (Jake Rocheleau) (см. пункты 20 и 25). Иногда программиста вынуждают согласиться работать без комментариев (в виду, например, сжатых сроков), что осложняет и последующее устранение ошибок в коде.

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

Другая проблема комментариев заключается в том, что они редко обновляются вместе с исправлением кода. В этом случае они даже могут стать опасными и завести разработчика совсем не туда, объясняет автор книг и основатель Simple Programmer Джон Сонмнез (John Sonmez) в 4 правиле программистов (из 11 существующих). Но писать или не писать комментарии должен решать программист, а не менеджер или клиент.

«Скажи точно, когда закончишь»
Фраза, которая способна вывести из себя почти любого разработчика. Объяснить менеджеру, что просчитать все возможные ошибки и проблемы заранее просто невозможно. Отсюда, например, рождаются мифы о том, что две самые великие сказки — это «Властелин колец» Толкиена и расписание любого программиста (такой пример приводит пользователь Quora Скотт Гарднер (Scott Gardner)). Возможно, иногда преуменьшение бывает свойственно разработчикам. На этот случай шведский программист подготовил специальную табличку перевода программерского времени в реальное.

Однако если отбросить все шутки в сторону, дело совсем не в том, что программисты совсем не дружат со временем или живут в параллельной реальности. Отличное объяснение этому явлению дал эксперт Electronic Auction Services Брэд Лэндерс (Brad Landers), который уверен (первый комментарий в источнике), что главная проблема — в формулировке поставленной задачи. Чем более расплывчато менеджер или клиент составляет требования к проекту, тем больше непредвиденных обстоятельств может возникнуть. Поэтому совсем нечестно перекладывать всю ответственность за несоблюдение сроков на плечи программиста.

«Хватит тестировать, пора запускать»
Очень сложно объяснить простым смертным, что тестирование любых изменений (еще лучше поэтапное) — показатель профессионализма и сэкономит кучу времени при выявлении багов. Но менеджеры очень часто уверены, что они просят внести незначительное изменение, которое займет несколько минут. Но небольших изменений не бывает, считает Дес Трэйнор (Des Traynor), сооснователь службы передачи сообщений Intercom. В своей статье он приводит пример такого «маленького» изменения: клиент просить ограничить написание отзыва о продукте 140 символами.

Специалист сразу увидит, что все не так легко и просто, и это изменение повлечет за собой еще десятки других: например, нужно решить, что будет при превышении лимита в 140 знаков? Текст обрежется, или пользователь увидит сообщение об ошибке? Что будет написано в этом сообщении? Как оно будет выглядеть? Кто займется его дизайном? Вопросы, а вместе с ними и новые небольшие изменения, накатываются, словно снежный ком. И каждое из них требует тестирования.

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

©https://habrahabr.ru/company/1cloud/blog/314586/

20 thoughts on “Практическое пособие «Как вывести из себя программиста»”

  1. I simply couldn’t depart your website prior to suggesting
    that I really loved the usual info an individual supply on your visitors?
    Is gonna be back incessantly to inspect new posts

    Feel free to visit my homepage; dispensaries near me (Melina)

  2. It’s hard to come by knowledgeable people about this subject, but you sound like you know what you’re talking about!

    Thanks

    Feel free to surf to my web-site :: delta 8 THC gummies,
    bit.ly,

  3. I don’t even know how I ended up here, but I thought this post
    was great. I don’t know who you are but definitely you’re going to a famous blogger if you aren’t already 😉 Cheers!

    Also visit my web-site buy weed

  4. Hi there would you mind letting me know which web host you’re working with?

    I’ve loaded your blog in 3 different web browsers and I must say this blog loads a lot quicker then most.
    Can you recommend a good hosting provider at a reasonable price?

    Kudos, I appreciate it!

    Have a look at my webpage delta 8 THC gummies

  5. I was recommended this web site by my cousin. I’m not sure whether this post is written by
    him as no one else know such detailed about my problem. You’re amazing!
    Thanks!

    Also visit my web-site :: pain relievers for dogs – bit.ly

  6. Hello! I could have sworn I’ve visited your blog before but after going through a few of the articles
    I realized it’s new to me. Anyhow, I’m definitely pleased I stumbled upon it and I’ll be bookmarking it
    and checking back frequently!

    My website; best kratom

  7. Уведомление: order hydroxychloroquine 200mg

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *