Пользователь
0,0
рейтинг
17 февраля 2013 в 23:47

Разработка → Как стать ведущим разработчиком. Часть 1 из песочницы

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

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

Я совершенно согласен в определении значения „ведущего“ с моим другом Тео. В своей главе в книге Web Operations издательства O'Reilly он пишет:
Поколение X (и в ещё большей степени поколение Y) — это культура немедленного удовлетворения. Я работал с поразительным количеством инженеров, рассчитывающих, что их „карьерный путь“ до высших инженерных должностей займёт не более пяти лет только потому, что они умные. Но это просто невозможно. Их слишком много. Не каждый может быть ведущим. Неужели, если через пять лет вы ведущий, значит вы на пике своего развития? Разве ещё через пять лет вы не получите ещё более ценный опыт? Что тогда? „Супер инженер“? А ещё через пять лет? „Супер-пупер инженер“. Думаю, проблема заключается в молодости нашей отрасли. И в самом деле, мало кто занимался веб-администрированием (web operations) на протяжении пятнадцати лет. Учитывая динамику развития индустрии, многие предпочитают управленческие позиции или риск предпринимательской гонки.
Он прав, сфера веб-администрирования пока ещё очень молода. И поэтому не стоит удивляться, когда люди со званием „ведущих“ демонстрируют незрелое поведение, как с технической, так и с человеческой точек зрения. Если вы не читали главу Тео целиком, я рекомендую вам это сделать.

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

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

Я предполагаю, что „ведущий“ инженер — это зрелый инженер.

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

Мне задавали вопрос на Quora: «Какие отличительные черты (кроме технических умений и опыта) присущи лучшим управляющим технических отделов?». Ответив на вопрос, я понял, что и сам постоянно стремлюсь к обладанию упомянутыми в ответе качествами. Этот пост похож на тот ответ.

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

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

Обязательные качества зрелых инженеров


Все статьи с попытками описать необходимые качества будут переполнены пунктами в своих перечислениях: в инженерии есть о чём поговорить. Я опишу только некоторые качества: до каких-то я дошёл сам, некоторые взял из разных источников, многие — из «Неписаных законов», упомянутых выше.

Зрелые разработчики рады конструктивной критике их идей


Все успешные инженеры, которых я встречал, по окончании разработки и планирования проекта постоянно задают коллегам подобные вопросы:
  • Что я мог упустить?
  • Почему это может не сработать?
  • В чём я могу быть неправ?
  • Если даже с технической точки зрения это звучит верно, будет ли это понятно всей организации настолько, чтобы управлять, поддерживать и расширять это?
Они знают, ничто, ими сделанное, не останется только в их руках, и хорошая проверка от коллег — это то, что сделает их продукт лучше. Как было где-то сказано, они „рады плохим новостям“.

Зрелые разработчики осознают, как их воспринимают в личностном плане


Недостаточно одного умения написать во сне фильтр Блума на Erlang или многопоточную программу на C. Всё это не имеет значения, если никто не хочет с вами работать. Зрелый инженер знает, что законченность, элегантность и превосходство его идей ничего не значат, если никто не хочет с ним работать из-за того, что он придурок. Снисходительность, недооценивание, самолюбование и самореклама отталкивают от вас (может только и на подсознании) других инженеров. Но радость от разработки в некотором смысле заключается как раз в наслаждении той компанией людей, с которыми вы проектируете и создаёте что-то новое. Инженер, который запросто называет другого дебилом, обречён на остановку в своём развитии.

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

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

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

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

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

Я всегда обращаю внимание на подобного рода публичные заявления, когда сталкиваюсь с ними, и если такой человек придёт на собеседование к нам в Etsy, я хорошенько подумаю, прежде чем взять его на работу (Кристофер Браун говорил об этом же в своём докладе на Velocity London).

Зрелые разработчики не избегают прогнозов, а постоянно совершенствуются в них


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

Зрелые разработчики обладают развитой интуицией, даже если не знают об этом


Этот код выглядит неплохо, я горжусь собой. Я попросил других людей проверить его и записал все отзывы. И как долго теперь у меня займёт переписывание и исправление? Как мой код повлияет на работу сервера, когда он там окажется? Как и насколько изменится использование ЦПУ/памяти/диска/сети? Смогут ли другие понять этот код? Достаточно ли прост мой код, чтобы другие смогли в него вникнуть и расширить?

Зрелые разработчики понимают, что не в каждом проекте будут хватать звёзды с небес


Какими бы бессмысленными или незначительными не казались ваши первые задания, приложите к ним все усилия.
Умение доводить дела до конца, значит делать то, что вам неинтересно. Не важно, насколько привлекателен проект, там всё равно будут скучные и утомительные задачи, задачи, которые новичками считаются ниже их достоинства или должности. Мой приятель, Келлан Эллиот-МакКри (CTO в Etsy), говорит об этом следующее:
Иногда спасение можно найти в простоте скучных задач. Зрелость говорит, что такие задачи нужно выполнять быстро и двигаться дальше. Иногда скучные задачи требуют предельной дисциплины и концентрации внимания. Как ни странно, наиболее скучные задачи, которые выполняются только ведущими инженеры, могут быть в то же время самыми необычными.

Зрелые разработчики прокачивают мастерство и квалификацию окружающих


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

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

Поэтому, вместо того, чтобы говорить «Так, подвинься, давай я сделаю», мы говорим «Ясно, давай разберёмся с этим. Я покажу тебе, как пишу/отлаживаю/и т. п. Затем то же сделаешь ты, чтобы я убедился, что ты понимаешь как и почему мы делаем это именно так».

На этом первая часть перевода закончена. Буду рад конструктивной критике и советам. Я старался, но может быть, что-то понял и перевёл неправильно или коряво — предлагайте свои варианты. Принимаются пул-реквесты на GitHub.

Вторая часть
Сергей @skovorodkin
карма
83,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (76)

  • +11
    Сильная статья, особенно хорошо про «Щедрость ума», спасибо за перевод.
    • +6
      Рад, что понравилось. Вторая часть ещё интереснее, постараюсь на неделе выложить.
      • +1
        Спасибо за первую часть. Так понравилось, что не могу ждать, — уже читаю продолжение :)
    • +2
      Как жаль, что «Щедрость ума» у некоторых травмируется самолюбием и надменностью. В итоге проект не движется и новичку сложно общаться с толстокожым всезнайкой.
      • 0
        Значит это очень тупой и глупый человек, который в первую очередь не жалеет себя. Ибо если уделить сейчас 10 минут на обучение, вместо того чтобы самому за 5 всё исправить. То в будущем не придётся по подобным «проблемам» отвлекаться ещё кучу раз. Что в сумме превысит эти 10 минут обучения.
  • +1
    При чем тут картинка? Мало того, что весь ютьюб забит такими картинками как снапшотами к роликам, так еще и нахабре давайте лепить и к месту и не к месту. Картинка красивая, но какое отношение она имеет к посту? Нафик.
    • +15
      Я неисправим — люблю красивых женщин.

      А на картинке Кейт Мацудайра, которую автор упоминает в первом абзаце.
      • +30
        Картинка тонко предлагает вариант «через постель» в ответ на главный вопрос статьи? :)
        • +4
          В постель к такой просто так не залезть. Эта картинка тонко мотивирует на поиск пути частного решения главного вопроса статьи :)
          • +10
            Для ведущего разработчика нет ничего невозможного :-)
          • +2
            Тогда остаётся через бутылку. Хорошего виски. Судя по картинке.
            • +2
              Судя по картинке, там скорее шампанское… какой же ведущий разработчик будет виски из такого бокала пить? :-)
              • –1
                Русский? :-)
                Заперевшись в серверной с сисадминами, из чего только мы не пили.
    • 0
      Согласен. Надоела эта тема «какую б влепить картинку, чтобы привлечь внимание и отхапать побольше плюсиков за статью?» В оригинальной статье картинки нет. Раз это перевод, то и в переводе быть не должно. Во всяком случае пониманию статьи она никак не способствует, только засоряет информационное пространство. Если кому-то охота посмотреть красивых женщин, для этого есть специальные сайты :-)
      • +3
        Да ладно вам, всё-таки это картинка из блога упомянутой программистки — katemats.com/about/
        Так что нельзя сказать, что переводчик её специально ради плюсиков по всему интернету искал )
    • –1
      imwode — вы женщина? :D
      • +2
        а вы?
        • 0
          нет :)
          уже заглянул в профиль, впрочем. Удивила реакция.
          • +3
            обычная реакция на спам
  • +15
    Однажды, когда в одной мелкой компании (которая вскоре развалилась) стало очень много «ведущих», я спросил у самого старшего ведущего: «Что у вас понимается под словом „Ведущий“?». На что он мне ответил: «Ведущий разработчик — это тот, который ведёт какой-либо проект.».
    • 0
      Я только начинаю свой путь, и мне важно понимать тех, кто знает больше моего. Может быть, после того, как я усвою информацию из этой статьи, моим наставникам и коллегам будет легче и приятнее со мной работать. Думаю, цель статьи именно в этом.
    • +6
      Был такой опыт: была компания А, который занимал определенную долю рынка. Пара руководителей ушла из этой компании и организовала компанию Б. И переманила к себе несколько ведущих разработчиков из компании А. Первые 2-3 года работали только они и подняли весь фундамент этой новой компании. Так как компания Б пошла более продуктивным путем, то она отъела большую часть рынка. Потом уже, когда появились заказчики, клиенты, вариации, вот только тогда начали нанимать разработчиков и все «ведущие» стали начальниками отделов. Так что, вспоминая именно тот коллектив из ведущих разработчиков, я вспоминаю эту команду и работу как рай программиста. Конечно это может быть и связано и с тем, что мы тогда занимались чистым R&D, делали то, что никто до нас не делал еще и у нас получалось. Но без такой команды это бы не получилось или получилось бы намного позже.
      Так вот много «ведущих» для меня — это рай программиста.
      • +5
        +1. Рай — это небольшая команда умных, опытнах и приятных в общении (всмысле, не чересчур самоуверенных, умеющих принимать критику, и просто поговорить по дружески) людей — при этом именно программистов, а не менеджеров, скрам-мастеров и проч.
      • +2
        Вспоминается цитата представителя Стрелки на конференции NextPlace: «Каждого человека мы назначаем директором. Это простой способ сделать людей счастливыми.»
        Действительно, если есть возможность — почему бы и нет?
    • 0
      Справедливости ради, подобная ситуация возможна. Для полноценной ответственности за проект зачастую надо иметь менеджерские навыки, достаточные хотя бы для управления самим собой. Поскольку разработка вещь не всегда тривиальная, это управление должно быть серьезнее, чем управление неквалифицированным персоналом на простых работах.

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

      Это я не про ваш частный случай, а вообще, к слову.
    • 0
      Была обратная ситуация в одной крупной компании у нас развелось много ведущих и главных специалистов. Я спросил почему есть специалист, ведущий специалист и главный специалист, оказалось все проще — по степени сложности проекта и ЗП.
  • –18
    А картинки лучше такие в тему:
  • +8
    Про ответственность за прогнозы — верно. Мне отец рассказывал (он из энергетики, думаю много где также), что в бригаде — мастер самая неблагодарная должность. Он получает немногим больше самого квалифицированного слесаря, зато вся головная боль по поводу составления планов и их выполнения достается именно ему. В то время как слесарь приходит на работу и делает свое дело, не думая о начальстве сверху.
    • +1
      У меня отец тоже из энергетики и тоже часто жаловался, что не раз ему поручали выводить людей в выходные и праздники только лишь для того, чтобы в понедельник отчитаться «Мы сделали все что могли, но законы Кирхгофа, как и предполагалось, нарушить так и не смогли».
  • +1
    Спасибо за статью.

    Смысл раздела «Зрелые разработчики обладают врождённым чутьём, даже если не знают об этом» непонятен.
    • +2
      Скорее всего имеется в виду развитая интуиция.
      • 0
        Спасибо, воспользуюсь вашей формулировкой, если вы не против :)
        • +1
          Как я могу быть против? ;)
  • 0
    Фраза «Ясно, давай разберёмся с этим.» вызывает более негативные эмоции. Почему-то слово «ясно» стало более отталкивающим в разговорах. Более приятно, когда тебе скажут: «Хорошо, давай разберёмся с этим». :)
    Или это только я так на это реагирую?
    • +2
      Спасибо за комментарий!

      Многое зависит от поведения говорящего: интонация, мимика, жесты. Лично я не вижу в самом слове ничего отрицательного.
      • 0
        Видимо имелось в виду это:
        Ясно...

        Upd. Почему-то не отображается картинка :(
    • +2
      У меня есть друг, который говорит/пишет «ясно» тогда, когда ему нечего сказать, но разговор поддержать нужно :) Бесит жутко, но знаю что он не имеет ввиду ничего плохого. Так что это больше от персональной реакции зависит.
    • 0
      «Ясно» в ответ на описание проблемы означает примерно следущее: «Да, я понимаю некоторые из слов, которые ты говоришь, и даже когда-то натыкался на подобную задачку. Так что если ты объяснишь подробнее, то, может быть, я смогу помочь разобраться в проблеме». Не понятно, что в этом такого негативного…
  • 0
    Спасибо, полезная информация. Узнал, что мне еще много нужно над собой работать.
    Специально не пойду читать 2-ю часть в оригинале, дождусь перевода. У вас хорошо получается.
    • 0
      Рад стараться!
  • +3
    «Неужели, если через пять лет вы ведущий, значит вы на пике своего развития? Разве ещё через пять лет вы не получите ещё более ценный опыт? Что тогда? „Супер инженер“? А ещё через пять лет? „Супер-пупер инженер“.»

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

    Если же говорить об аналитических навыках (умение находить алгоритмы для решения задач и создавать новые технологии), то тут развиваться можно бесконечно, хотя для этого возможно потребуется искать новую работу, когда текущие проекты начнут казаться слишком простыми.
    • +1
      Вы слишком утрируете… Много Вы знаете языков и парадигм программирования, которые сильно поменялись или устарели за 5 лет? Понятно, что всё течёт, всё меняется, происходит смещение мейнстрима, но гораздо медленнее.
  • +1
    Интересно, а что делать зрелым разработчикам, когда они слышат от молодежи, которую сами же и обучали, слова «Так, подвинься, давай я сделаю»?..
    • +5
      Радоваться! Хоть что-то получилось удачно делегировать xD
    • +1
      Ответить: «Ну, сделай. А я посмотрю». А если у молодого получилось решение приемлемого для этого проекта качества — действительно, радоваться. Хоть одна веточка потребует меньше возни.
  • 0
    Возраст не значит ничего. Да и незрелый может знать то, чего не знает „ведущий“.

    Ведущие разработчики не могут знать всё. Их технические знания не безукоризненны, но они не переживают из-за этого.
    • 0
      Это в ответ к предыдущему комментарию.
    • 0
      Насколько я понял, там не о возрасте… Просто не совсем точная игра слов при переводе Junior.
  • 0
    Очень интересно было почитать, сразу стало понятно по каким критериям можно расти, чтобы стать действительно ведущим специалистом. Про «щедрость ума» понравилось. К сожалению, в компаниях очень часто присутствует конкуренция и соперничество, особенно в компаниях, где программистов очень мало. Поэтому помимо «щедрость ума», нужно не забывать про пословицу «мал золотник, да дорог». Нет ничего плохого в том, чтобы учить, но иногда это может сработать против вас.
  • 0
    «Так, подвинься, давай я сделаю», мы говорим «Ясно, давай разберёмся с этим. Я покажу тебе, как пишу/отлаживаю/и т. п. Затем то же сделаешь ты, чтобы я убедился, что ты понимаешь как и почему мы делаем это именно так».

    Ох, как же мне иногда хочется услышать эти слова =)
  • +5
    Не помню, где прочитал, но мне очень нравится эта фраза. Она, как мне кажется, покрывает большинство указанных тезисов:
    Профессионализм — это способность оценить меру своей НЕкомпетентности

    Т.е. обычный специалист ищет подтверждения тому что он прав. Профессионал же, всегда считает, что он не прав и пытается найти доказательства обратному.
    • +2
      Да, это при отладке очень ярко проявляется… Профессионалы сначала ищут ошибки в своём коде, а новички засыпают форумы топиками в стиле «язык/фреймворк/библиотека такая-то не работает».
      • +3
        А еще важнее в самом начале задачи.

        После получения задачи.
        Новичок:
        Ок, задание понятно начинаем кодить.
        Профессионал:
        Правильно ли я понял задачу? Есть ли вероятность что автор имел ввиду что-то другое? Есть ли конфликты в постановке?

        Проектирование
        Новичок:
        О! У меня есть классная идея, как сделать это круто и правильно.
        Профессионал:
        Поискать в коде, возможно такая функция уже есть. Осмотреться вокруг, возможно правильнее делать как все а не как лучше. Ок, нам нужно новое решение, возможно задача уже решалась, надо погуглить на тему готовых решений или идей.

        Ну и отладка — это конечно эпично:
        Новичок:
        О! Проверяем сценарии которые я закодил, все работает!
        Профессионал:
        А есть ли сценарии, которые явно не указаны в задаче? А не используется ли измененный мною код еще где-то, что могло упасть?

        И т.д. и т.п.
  • +2
    «Если живешь в европе и тебе за 30, то ты можешь начинать претендовать на место тимлида. Если ты живешь в России, тебе 22 и ты до сих пор не тимлид — то ты неудачник». © кто-то

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

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


    Я всегда по неопытности считал, что неопредленные факторы они на то и неопрделенные, что они только и делают что вносят погрешность в оценку сроков. И как понимать «не должен задреживать»? Игнорировать факторы? Идти к гадалке? Не думать о плохом? Не понимаю. И это ведущие разработчики?
    • +1
      Видимо, имелось ввиду, что зрелый разработчик должен знать о подавляющем числе этих неопределённых факторов, вследствии чего он сможет спрогнозировать сроки достаточно точно (т.е. чем опытнее разработчик, тем меньше форс мажоров).
      • 0
        Обычно оценивается не сам срок выполнения, а вероятность уложиться в разные сроки… Ну и соответственно называется срок с приемлемой вероятностью уложиться в него. Для своих задач это не особо сложно, сложнее когда вам надо оценить срок выполнения набора задач целой командой программистов. Вот там уже неопределённости в разы больше.
        • 0
          Умение планировать наверное один из главных признаков опыта. Заметил, что новички склонны преувеличивать свои силы и занижать сроки исполнения задач. А ведь высокому начальству не объяснишь, что не успел сдать в срок, потому что болел, вызвали в военкомат, свадьба, похороны и т.д и т.п. На планы завязываются слишком много людей, чтобы просто так взять и сорвать срок.
          Сейчас делаю так, спрашиваю оценку времени у новичков, потом увеличиваю это время на 50%. Все задачи сдаются вовремя.
          • +1
            Хм, даже не знаю… Это Вам либо сильно с новичками повезло, либо задачи слишком простые, либо это далеко не новички, если увеличения их оценок на 50% хватает, чтобы они постоянно укладывались в срок.
            • +1
              Не знаю, у меня нормальные ребята. ИМХО, если человек не успевает даже с 50% запасом времени, я бы ему рекомендовал сменить профессию. Хотя ситуации могут быть разные. Студенты, кодеры которые никогда ничего не успевают, пока не скажешь как надо ехать, или же маньяки идеального кода, с последними особенно сложно.
    • 0
      Вы должны уметь как минимум озвучить все эти факторы. И назвать их вероятность. Например:

      — К XX.XX.XXXX нам нужны спецификации от партнёров. Если их не будет, или в них будут ошибки, то время выполнения увеличится.

      — Перед релизом нам нужно заложить N дней на дополнительное тестирование, т.к. возможно большое количество нестыковок.
  • +1
    Очень качественный перевод, спасибо!

    Единственная неточность — вместо «снисхождения», видимо, имелась введу «снисходительность».
    • 0
      Да, вы правы.

      И вам спасибо!
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Ох, как я вам завидую. Вы только учитесь в школе, а уже такие желания. Это очень круто.

      Почитайте, например, про этого парня. Его судьбу, конечно, не стоит повторять, но начал он рано и сделал огромный вклад в наше сообщество. Дерзайте.
      • 0
        Зачем далеко ходить? Вот хороший пример.
  • 0
    Спасибо. Жду продолжения. С удовольствием прочитаю.
  • 0
    Скучно текст звучит, как будто его написал древний морализирующий дядя…
    В целом мысли правильные, но к профессионализму бы еще добавить здоровые амбиции и драйв — вот где энергия к росту
    • +1
      А мне статья показалась женской. Вот как девушки говорят, «если ты настоящий мужчина, то должен <сделать что-то>». И здесь точно так же: «настоящий разработчик обязан браться за самые скучные проекты, никогда не ошибаться со сроками, телепатически предугадывать желания левой пятки заказчика, не использовать job safety driven development и cover-your-ass engineering».
      • 0
        Умная девушка так не скажет, у неё есть приёмчики похитрее :)
  • 0
    Подскажите, не переводилась ли упомянутая книга про неписаные законы инженерии на русский?
    Очень заманчиво звучит, но уровень английского не позволяет…
    • 0
      Я ничего не нашёл. Может быть, существуют отечественные аналоги, сходу не нашёл, но стоит поискать.
  • 0
    Что случилось со второй частью? Автор вдруг стал read-only
    • 0
      аналогичная ситуация, пол статьи прочел дома а вторую половину теперь не найду(
    • +1
      От автора из скайпа:

      «Меня перевели в ридонли за рекламные ссылки, которые я, не подумав, вставил в конце поста.
      Чтобы вернуться и открыть пост, я должен сначала написать что-нибудь в песочницу. Постараюсь это сделать сегодня.
      Прошу прощения за неудобства.»
      • +1
        Я вернул пост, спасибо :) Приятного чтения.
  • 0
    Это было интересное чтение, спасибо автору. Уже во многих источниках встречал мысль, что по-настоящему умные люди не стесняются чего-то не знать, не стесняются спрашивать и искать лучшие решения. Возьму этот критерий на вооружение, для отсеивания тех, кто молод-зелен и считает, что знает всё на свете и всё умеет.

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