1. Профессионализм
Непрофессионалы не берут ответственности за свою работу. Они делегируют эту ответственность выше по иерархии: ты начальник, — ты и отвечаешь. Если непрофессионал обкакался, — экскременты приходится убирать работодателю. Профессионал чистит за собой сам. Что ещё делают профессионалы и не делают дилетанты?
- Используют правило «Не навреди». Ваш код должен работать и вы не должны ничего ломать. Конечно, это не каждому под силу, но по мере профессионального роста, количество ошибок в вашем коде будет стремиться к нулю.
- Контроль качества не должен ничего найти. Я неоднократно наблюдал ситуацию, когда в тестирование отправлялась неверно выполненная задача. Причём, то, что она не выполнена было понятно разработчику. Такое отношение никуда не годится. Когда вы отдаёте задачу тестировщикам, вы должны быть полностью уверены в вашем коде. Дефектный код — это любой код, в качестве которого вы не уверены. Если служба контроля качества нашла в вашем коде ошибку, вы должны удивиться, извиниться, понять, почему это произошло и не допустить подобного в дальнейшем.
- Используют автоматизированное тестирование. Невозможно быть уверенным в качестве своего кода, не протестировав его. Протестируйте код вдоль и поперёк, справа налево и сверху вниз. Каждый кусок кода должен быть протестирован для всех возможных ситуаций. Если это делать вручную, — у вас не будет времени на разработку, поэтому тестирование нужно автоматизировать: пускай потеет машина. Код должен быть покрыт тестами на 100%. Об этом чуть подробнее позже в разделе про TDD.
- Пишут гибкий код. Структура кода должна обеспечивать гибкость. Внесение изменений в код не должно приводить к непомерным затратам. Профессионалы знают паттерны проектирования и строят на них программную архитектуру. Проверяется просто: попробуйте внести изменения в ваш код. Если это вызовет боль чуть ниже пояса, — значит с гибкостью у вас всё плохо. Переработайте структуру кода, чтобы следующее изменение вносилось проще. Это называется безжалостным рефакторингом: всегда оставляйте модуль чище, чем до вашего прихода.
- Учатся сами. Работодатель не обязан вас никуда отправлять учиться. Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
- Знают свою область. Вы должны знать, что такое диаграмма Насси—Шнейдермана, алгоритм быстрой сортировки, что означает термин «бесхозные данные» и для чего нужны «таблицы Парнаса». Чтобы быть профессионалом, вам нужно знать фундаментальные основы профессии. Причём, большая часть этих основ была сформулирована несколько десятков лет назад. Паттерны проектирования, SOLID, методологии разработки, анализа и проектирования, TDD, ООП, структурное программирование, непрерывная интеграция, парное программирование, артефакты.
- Не останавливаются в обучении. Наша отрасль постоянно развивается и обновляется. Если вы не следите за тем, что происходит, вы можете за год оказаться в каменном веке. Пример для дизайнеров: вы можете не знать о том, что для фотошопа есть плагин, разбивающий ваш макет на ассеты и заливающий в облако, но заказчик предпочтёт работать с тем дизайнером, который в качестве результата работы даст ему ссылку на сборник ассетов для верстальщика. Это я про sympli.
- Тренируются. Чтобы держать форму, нужно постоянно напрягать мозги. Выполняйте упражнения на разных языках программирования. Пусть это будут несложные задачи, которые занимают не больше 10 минут. Но время на них нужно выделять каждый день.
- Работают совместно. Отличный способ научиться чему-то новому, — это совместная работа. Профессиональные разработчики стараются вместе проектировать, тренироваться, работать, планировать. Они много узнают друг от друга и делают свою работу эффективнее. Очень помогает, когда вы даже просто сидите рядом с товарищем и смотрите, как он пользуется средой разработки. О! Оказывается, есть раскладка Бирмана и Ctrl-Alt-Z в фотошопе.
- Учат других. Лучший способ научиться самому — это научить других. Именно поэтому я пишу статьи и иногда провожу занятия и курсы. Основную пользу от преподавания получает преподаватель. Профессионалы берут на себя ответственность за обучение новеньких сотрудников и не бросают их один на один с огромной медицинской информационной системой, в код которой даже смотреть страшно (это про нас).
- Знают предметную область. Есть порочная практика работать только по спецификации. Это верх непрофессионализма, когда мы всю мыслительную деятельность поручаем аналитикам, а свой собственный мозг используем исключительно для описания алгоритмов. Профессионал знает полезное действие. Он понимает, зачем нужна каждая функция, что она даст пользователям и как она повлияет на бизнес клиента. Он может исправить спецификацию и отправить аналитиков на дополнительное исследование.
- Понимают интересы работодателя и заказчика. Если у вашего работодателя проблемы, — это ваши проблемы. Если вашему работодателю задолжал ДИТ Москвы 30 миллионов и не платит уже который месяц, — это означает, что вы к новогодним праздникам останетесь без премии. Предлагайте решения проблем заказчика и знайте его бизнес. Придумайте для своего заказчика новый проект, идею, улучшение, бизнес-процесс, продукт, посоветуйте сотрудника, поставщика, покупателя. Не жадничайте.
- Скромны. Профессионал — это не непогрешимый царь горы. Я видел примеры, когда даже самые квалифицированные разработчики ошибались. Профессионал не смеётся над ошибками других, не издевается над коллегами, принимает заслуженные и незаслуженные насмешки над собой. Он понимает, что его оценки сроков могут быть неверными, а выбранная технология окажется негодной.
2. Говорите «Нет»
Рабы не могут сказать «Нет», а наёмные работники могут. Если же вы профессионал, — это ваша обязанность. Когда руководитель ставит нереальный срок, ваша обязанность сказать «нет». Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет». Когда вам предлагают работать по ночам, ваша обязанность сказать «нет».
Самое ужасное, что можно сказать — это сказать, что «вы постараетесь». Нет ничего хуже. Отвечая так вы не выполняете свою работу, а ваша работа заключается в том, чтобы сказать: «нет, это невозможно». Вы можете пытаться избежать неприятных переговоров, но это просто малодушие:
— Нужно сделать поиск туров к пятнице.
— Это невозможно, на разработку и отладку поиска нужно две недели.
— Нам нужно показать клиенту в пятницу. Давай постараемся.
— Хорошо, я постараюсь.
Вы избежали конфликтной ситуации сегодня, но спровоцировали взрыв в пятницу. Это может привести к ссоре с клиентом и, в конце концов, к потере заказчика. Стойте на своём: невозможно — значит невозможно.
Фразы «я попробую», «я постараюсь, «я попытаюсь» нужно совсем исключить из своей лексики и не принимать такие ответы ни от кого другого. Если вам говорят такие фразы, — уточняйте и настаивайте на прямом ответе. «Я попытаюсь» — означает, что вы приложите дополнительные усилия для того, чтобы выполнить задачу. А какие это усилия? Неужели вы работали раньше не в полную силу? Или теперь вы готовы работать круглосуточно? Или вы взвалите это на плечи коллектива? Если у вас нет резервов энергии, нового плана и не собираетесь изменять своё поведение, — значит вы просто врёте. Не надо пытаться.
3. Как сказать да. Язык обещаний
Один мой хороший, но неопытный друг встречался с клиентом по сайту и пригласил меня на переговоры. Пришёл мужчина и начал рассказывать о том, какой у него хороший проект, но он уже несколько раз обжигался на непрофессионалах; поэтому нам нужно сделать предварительные макеты. Я знаю о вреде предварительных макетов, а мой друг не знал и как только я собирался открыть рот, — он уже ответил, что «да, хорошо, мы сделаем». Так был сделан первый и единственный шаг к потере клиента. К заданному сроку он не сделал макет, не получил новый заказ и клиент разочаровался.
Обещание можно разделить на три части:
- Вы говорите, что что-то сделаете
- Ответственно относитесь к своим словам
- Выполняете обещанное
Сказать «да» — это значит, что нужно сказать, что вы что-то сделаете без каких-либо модификаторов. Что это за модификаторы? «Нужно» (мне нужно похудеть), «должен» (мы должны найти новых клиентов), «постараюсь» (я постараюсь уговорить инвестора), «хорошо бы» (хорошо бы сходить в кино), «надеюсь» (надеюсь, мы встретимся на следующей неделе), «давайте» (давайте сделаем аутентификацию к четвергу), «если будет время».
Проследите за своей речью и речью других. Обратите внимание, как часто эти слова встречаются вокруг нас и как часто вы пытаетесь снять с себя ответственность.
Серьёзное обещание говорит о том, что вы выполните конкретное действие. Даже если вы не можете сделать всё, что вас просят, вы можете сделать какую-то конкретную часть из предложенного.
— Сделай, пожалуйста, отчёт в Birt. Это нужно сделать к понедельнику.
— К понедельнику не смогу. Но к этому времени я подготовлю веб-сервисы.
В общем виде серьёзное обещание выглядит так: «Я сделаю то-то к такому-то времени». Если вы не справились с обещанным, как можно быстрее сообщите об этом тому, кому вы обещали.
4. Написание кода
Готовность кода — это такое его состояние, когда решено сразу несколько задач:
- Код работает. Он отражает решение поставленной задачи и вы в этом убедились. Решён каждый аспект задачи.
- Вписывается в существующую архитектуру. Система не должна потерять в гибкости, стабильности, прозрачности. Код должен соответствовать принципам проектирования.
- Нормально читается другими разработчиками.
Программистам много платят, потому что это сложная работа. Нужно сконцентрироваться на работе и, если это сделать не удастся, у вас получится плохой код. Если вы устали, — не пишите код, а лучше немного поспите. Если от вас ушла жена, — не пишите код. Если ваша кошка только что родила семерых сыновей, — не пишите код.
Ночное программирование неприемлемо. Ваш ночной код будет словно бумеранг возвращаться к вам снова и снова на исправление и доработки. Почему так любят ночное программирование? Во-первых, оно позволяет выглядеть героем: «а работал всю ночь написал тонну говнокода». Во-вторых, ночью никто не отвлекает. Но ведь и днём можно организовать всё так, чтобы ничего не отвлекало. Пару раз в неделю я перевожу телефон и мессенджеры в самолётный режим, чтобы можно было спокойно подумать над задачей без отвлечений.
Зона потока — зло. Так программисты называют сверхпроизводительное время, когда удаётся писать-писать-писать код и не хочется ни на что не отвлекаться, а всё продолжать и продолжать. В этом состоянии программист считает себя суперменом, а свой код хорошим.
Проблема в том, что быстро написанный в Зоне код чаще становится причиной ошибок. Вы можете потерять часть общей картины и код будет плохо согласован с остальным частями или бизнесом. Если вы чувствуете, что входите в Зону, предпринимайте осознанные усилия, чтобы выйти из неё. Помогает pomodoro, парное программирование и жена.
Верный признак Зоны, — это когда вы невежливо отвечаете на телефонные звонки и не рады даже хорошим людям.
Творческий кризис можно преодолеть. Он обычно происходит от усталости или от однообразия. Вводите в свою жизнь что-то новое и больше отдыхайте. Читайте книги из разных областей: классическую литературу, естествознание, научную фантастику, Дарью Донцову. Творчество порождает творчество.
Сокращайте время отладки. Это время кажется разработчиком неизбежным, но чем меньше вы сидите за дебаггером, тем больше вы сделаете чего-нибудь действительно полезного. Помогает TDD/TLD и контрактное программирование.
Остановитесь. Программирование — это марафон, а не спринт. Не нужно засиживаться, только потому, что не смогли ещё доделать свою задачу. Ощущение, что «это дерьмо вот-вот заработает» может не покидать вас часами. Дайте голове отдохнуть и чаще используйте поговорку «утро вечера мудренее». Решение может прийти к вам позже по дороге домой, в душе или за завтраком. Позвольте этому случиться.
5. Отставание от графика
Есть такой класс людей, которые пытаются уверить до последнего, что всё будет хорошо, хотя, понимают, что к сроку не успеть и это понятно даже ёжику. Из недавней практики: мой друг, фотограф (Ф) и поэт заказал новогоднюю фотозону у парня по имени П. Ф поставил перед П задачу с дэдлайном на три дня раньше реального: 1 декабря. Реально, 4 декабря должны были начаться съёмки в по-новогоднему оформленной студии. Реально, фотозона делалась ещё неделю, в результате чего Ф проклинает П, строит сам, отменяет фотосессии, несчастлив.
Домашнее задание: приведите пример, когда вы облажались со сроками и всех подвели.Мы будем отставать от графика. Вопрос лишь только, как мы будем это делать. Есть два важнейших момента: раннее обнаружение и прозрачность. Постоянно следите за ходом работы, относительно конечной даты. Делайте прогнозы завершения: оптимистичный, нормальный и пессимистичный. Для каждого сценария поставьте предполагаемые даты и ежедневно обновляйте их. Пусть все члены команды понимают, когда вы реально закончите задачу.
Не нужно надеяться, что вы успеете. Надежда убивает проекты и отношения. Спешить тоже не нужно, потому что самые большие косяки рождаются в спешке. Некоторые руководители предлагают сверхурочную работу. Согласиться на неё можно только если у вас есть резерв личного времени, аврал будет длиться недолго и это действительно поможет делу.
Некоторые разработчики пытаются впарить недоделку за готовый продукт. Получается плохая практика, когда смещается определение готовности и вся команда работает из рук вон плохо: потом переделаем.
Готово — это значит, что успешно пройдены все автоматизированные приёмочные тесты.
6. Помогайте и принимайте помощь
Если вы Программист с большой буквы, — помогите другим. Это важная часть профессиональной этики. Ваша работа не настолько важна, чтобы не помогать начинающим. Но это не значит, что вы должны отказаться от личного времени и оказывать помощь всегда и везде. Объявите во всеуслышание, что вы готовы помогать только с 14:00 до 16:00.
Принимать помощь — ещё большее искусство. Если предлагают, будьте признательны и выделите время на это. Если не предлагают, обязательно попросите. Выйдите в общий зал, встаньте на табуреточку, скажите: «мне нужна помощь» и нарисуйте на доске суть вопроса. Не стесняйтесь. Понятно, что многие становятся программистами, потому что им больше нравятся компьютеры, чем люди. Однако, для хорошего разработчика навык общения и приёма-передачи знаний жизненно необходим.
На этом первая часть окончена. Через неделю будет вторая часть, в которой рассмотрим TDD, тренировку, приёмочное тестирование, планирование, уклонение от работы, способы оценки, работу под давлением, работу в группе.
Иллюстрации нарисовал Александр Корнилов.
Вторая часть статьи >
UPD: тут была акция с розыгрышем книги в честь моего дня рождения и она закончилась.Комментарии (200)
KlimovDm
11.12.2016 09:54+1Когда я был студентом, мы писали конспекты работ Ленина. Было немного непонятно — зачем? Возможное объяснение — конспект предполагает то, что произведение где-то как-то прочитано. Может по диагонали, через силу, местами — но прочитано.
Книга Мартина — произведение известное, в рекламе не нуждается. Его часто советуют и будут советовать, его читают и будут читать. Но зачем делать по нему конспект?
woodhead
11.12.2016 10:15-1Видимо, графомания.
Чтобы написать самому такой объём, нужно знать и уметь очень много. Принцип качественной статьи: «Своди страницу в абзац, а абзац — в предложение!». Но знаний не хватает, а писать хочется.
Опять же, можно пообсуждать какие-то тезисы, а в случае чего — сослаться на авторитет.
Да и времени для написания статьи требуется меньше. Сочинение пишется дольше изложения.gaal
11.12.2016 18:22+2Поздравляю автора с днем рождения и спасибо за статью.
Я не стал бы так судить о человеке. Не стоит забывать что вы смотрите на всех через призму своего восприятия людей. А в отношении себя могу сказать что мне было интересно прочитать эту выжимку из книги и мне не понадобилось выделять на это много времени. А с временем у меня уже давно проблемы и насобирался большой список того что нужно прочитать, изучить, попробовать. Теперь я могу судить о книге и понять хочу ли я ее прочитать и какой приоритет.
navff
11.12.2016 19:10+1Спасибо за поддержку. Я пишу так, как мне было бы удобно потом читать: открыл и бегло просмотрел все пункты. Увидел, что я в очередной раз начал говорить «постараюсь» и исправился. Читать книжку заново долго. А кто-то, оказывается, сию книгу не читал: см. комментарии ниже.
hardegor
11.12.2016 10:59+22Зона потока — зло.
Странно, свой лучший код я написал именно в «зоне потока», я его называю состояние драйва или «поймал волну». Видимо, потому что такое состояние появляется, когда у тебя в голове сложился весь пазл, ты имеешь полную картинку и превращаешь её в код и самое главное — никто не отвлекает.Hrodvitnir
11.12.2016 11:19Я думаю, что, в большинстве своем, пункты про зону потока и ночное программирование, это весьма индивидуальные вещи. Это чес всех под одну гребенку.
Но, в целом, статья очень годная.
Автору душевное спасибо, а так же легкой сдачи заказов и проектов, с днем рождения:)
svboobnov
11.12.2016 11:36Хм, а я вот с автором согласен. Пару раз написал «в потоке» код, порядка 2000 строк, а через неделю на него стыдно смотреть было. Хорошо, что это был одноразовый отчёт. То есть, код работал работал без ошибок, но был страшен.
hardegor
11.12.2016 18:39+1Так отрефакторить после никто не мешает, не спеша по уже рабочему коду.
Просто в такие моменты получается находить решения сложных проблем или увязывать между собой кусочки масштабной системы. И тут поток дает отличный результат.
Вообще такое состояние я отношу к «удержанию абстракций повышенной сложности», т.е. в обычном написании программы, программист удерживает в голове одну или несколько абстракций и перекладывает их на пишущийся код. А в моменты просветления сложность удерживаемой абстракции увеличивается. Где-то даже статья была про это, как бы не на хабре…
AndreiChernykh
11.12.2016 14:29Проблема с «Зоной потока» в том, что
1. У вас отсуствует в этот период адекватный фидбек. Программист, можно сказать, становится зашорен и мчится напролом к созданию той картины, которую он нарисовал в своей голове. Это полностью противоречит идее agile разработки, которая предполагает, что вы двигаетесь в работе короткими циклами, постоянно оглядываясь назад и по сторонам чтобы вовремя заметить, что вы свернули где-то не туда.
Опять же, когда человек вдруг вытаскивают из зоны (что обязательно случается рано или поздно) это вызывает у него фрустрацию, а потом еще время на попытки опять в эту зону попасть.
2. Люди, входящие в «зону» становятся трудно достижимыми для их сокомандников. Создание программного продукта это стройка, а не марафон; тут важна возможность быстро обсудить что-то с коллегой, сделать ревью кода, показать прототип и т.п.hardegor
11.12.2016 18:54+61. а причем здесь agile? Вы путаете теплое с мягким, не конечно вы можете программировать во главе с Грефом по agile, но кто сказал что нельзя пользоваться потоком? Меня всегда напрягают проповедники и их последователи своей безапелляционностью и неприятием всего отличающегося от их веры.
2. А зачем мне сокомандники, я спокойно обхожусь без них в течении дня. Поток у меня длится час-два и этого обычно хватает на решение какой-то проблемы. В результате, по вашим словам, у меня складывается ощущение, что вы каждые полчаса устраиваете митинг, чтобы обменяться мнениями. Но это же говорит о слабости членов вашей команды и слабой проработке архитектуры создаваемой системы :)AndreiChernykh
12.12.2016 12:04+1Не спора ради, т.к. каждый волен сам определять комфортный способ работы, а чтобы прояснить мою позицию:
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
По поводу сокомандников тут я вижу проблему в том, что если каждый сидит в зоне потока, то, во-первых, коллеги боятся лишний раз посоветоваться друг с другом, т.к. любой из них может находиться в потоке, а во-вторых, потоки разных людей не синхронизированы, т.е. найти время, когда все члены команды вне потока чтобы провести митинг становится сложно. Имхо, такая ситуация не способствует атмосфере взаимопомощи и командной работы.
kloppspb
12.12.2016 12:09потоки разных людей не синхронизированы, т.е. найти время, когда все члены команды вне потока чтобы провести митинг становится сложно
Никаких проблем у нас с этим не возникает. Время «больших» митингов известно заранее (раз в неделю). А по-мелочи не так уж и часто приходтся друг друга дёргать, чтобы это стало проблемой. Как раз наоборот, слишком частые обращения будут тревожным сигналом: что-то здесь не так и надо принимать меры.
Fesor
12.12.2016 14:03а как у вас обстоят дела с тем, насколько каждый член команды вкурсе кто чем занимается и как оно там примерно работает? Или каждый пилит свой кусочек и в целом все самодостаточны?
kloppspb
12.12.2016 14:33Нормально всё с этим.
В конце концов есть JIRA с подробным описанием коммитов/merge реквестов.
Есть Confluence, где всё расписано подробно. Вплоть до того, что каждый аспект системы рассматривается со всех сторон: внутреннее устройство для разработчика, для саппорта, для партнёров, использующих API, для простых юзеров (на базе чего потом пишутся юзергайды), для сисадминов, обслуживающих систему, и для тестеров.
А тот, кто забывает обновлять там информацию по нетленке, за которую отвечает, может получить по ушам :)
hardegor
12.12.2016 16:06Вы переходите в другую крайность — неужели вы думаете что всегда работаю в потоке? Нет конечно. Но в любом случае, когда отвлекают от программирования или обдумывания — я этого сильно не люблю, а если еще и каждые 5 минут… такое случается только со студентами, но и на них есть управа :)
sand14
19.12.2016 07:17Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
Но при таком подходе вы не увидите/не прогнозируете ни средне-, ни долгосрочную линию работы.
Да и насчет ближней — тоже вопрос.
Давно предполагаю, что фанатичное следование Scrum/Agile зачастую говорит о синдроме дефицита внимания, о неспособности сконцентрироваться хотя бы на пару часов, чтобы рассмотреть задачу в целом.VolCh
19.12.2016 11:32В рамках Scrum долгосрочное планирование осуществляется с помощью бэклога, среднесрочное в рамках спринта, а краткосрочное в рамках ежедневных пятиминуток. В общем и в целом планированию выделяется достаточно времени, на проектах длиною год и более в итоге может получиться даже больше чем на таком проекте по водопаду.
sand14
19.12.2016 12:53На бумаге все хорошо,
но практике программисты не видят ничего кроме пятиминуток.
Получается mushroom management с быстрыми короткими движениями между скрамами.
Даже если и видна стратегическая перспектива, то результат, который можно пощупать, нужно показывать к следующему ежедневному скраму, соответственно, работа на перспективу, даже относительно ближайшую, программистами не ведется.
Ну а если при этом еще и времени на планирование выделяется больше, чем по водопаду…
search
11.12.2016 14:46+2Возможно это индивидуально. Но по опыту вижу что человек работал в потоке, когда коммитет больше 10 файлов за раз (бывает и по 50), а в сообщении коммита не способен нормально описать чем занимался. Обычно такой код проскакиевает код ревью. Но в дальнейшем возникают проблемы с его поддержкой. Так называемая "стрельба дробью". Когда для внесения небольших изменений, в результате неявных зависимостей, нужно перелопачивать все эти файлы.
Ckpyt
11.12.2016 16:23+1За годы работы заметил такой прикол: чем меньше проект, над которым работаешь, тем эффективнее «зона потока». И наоборот, в больших проектах «зона потока» часто создает большое количество трудноуловимых ошибок.
П.с. по крайней мере, со мной так :)
sim31r
11.12.2016 23:11больших проектах «зона потока» часто создает большое количество трудноуловимых ошибок
В статье об этом и говорится «вы можете потерять часть общей картины». Это как-раз про большие проекты. Маленькие проекты даже в зашоренной «зоне потока» вполне удерживаются в памяти.
DistortNeo
11.12.2016 18:08Видимо, это связано с тем, что для того, чтобы поддерживать код, написанный в состоянии волне, нужно снова входить в это состояние.
navff
11.12.2016 19:12и самое главное — никто не отвлекает.
Может, ключевой момент в том, что никто не отвлекает? Получается, что у вас Зона, наверняка, ночью. Верно же?hardegor
11.12.2016 21:16Сложно сказать, я подозреваю что там все моменты ключевые :)
С ночью не угадали. Может быть и утром на свежую голову, бывает и ночером(с 10 до 2) или после прогулки или физической нагрузки, но обязательно должен быть момент когда решение сошлось и надо зафиксировать его в коде.
Jofr
12.12.2016 14:57Дружище, работайте так, как вам нравится. Если в какой-то статье на хабре написано что что-то зло, так это… на заборе тоже много чего написано.
aquamakc
12.12.2016 09:24+1Сам регулярно «ловил волну». Могу сказать, что иногда намного полезнее остановиться и подумать что и зачем я делаю и нет ли способа лучше. Были ситуации, когда «на гребне волны» писались не оптимальные алгоритмы или принятые решения уходили далеко от поставленной задачи.
Jofr
12.12.2016 14:54+1Потому что «зона потока» — не зло. Более того это чуть ли не единственная причина, по которой мы становимся программистами и по-настоящему любим свою работу.
Хороший программист в состоянии потока остается хорошим программистом, плохой — плохим.
В который раз к утверждению про «поток зло» напоминаю про книжку: Михай Чиксентмихайи, «Поток».
sand14
19.12.2016 07:10А у Спольски, тоже широко популярного у узких кругах, можно было прочитать, что зона потока это добро, и что программистов нельзя отвлекать, и им друг друга тоже нельзя отвлекать, т.к. даже самый простой вопрос соседа «как сделать то или это» выбивает того из зоны потока на 15 минут.
И кому верить? — Фаулер вот тоже авторитет.
Я к чему — ну немного… надоели все эти менеджерские техники и фанатичное им следование или их пропагандирование.
Может быть, лучше учить языки, библиотеки, принципы проектирования, учиться разбивать задачи на интересные подзадачи, и весь такой прочий технический олдскул, а не надеяться на некие техники как культ карго.hardegor
19.12.2016 07:36И кому верить?
Себе надо верить. Если вам это помогает с хорошим результатом, то пользуйтесь.
ru_vlad
11.12.2016 12:15Ну во первых с Днем рождения! :)
Желаю счастья, здоровья и всего всего чего душа пожелает :)
Что то многовато программистов в эти дни родилось, особенно если начать с прекрасной Ады ;)
По всем выше перечисленным пунктам можно полностью согласится, хотя в каждом случае бывают исключения.
Например на счет «нет», вроде думаешь что нет, не справишься, а начал схватил «волну» и в срок успел и глазу приятно :)
НО опять все это исключения, жизнь слишком многогранна что бы могла уместится в простые рамки :)
Cromathaar
11.12.2016 12:34Может быть ничего нового статья, как таковая, не несет, и кто-то скажет, что «это все обман, чтобы набрать классы», но на мой взгляд лучше лишний раз напомнить о подобных книгах, пусть это и приводит к дублированию. Лично видел, как труды Мартина переворачивали сознание людей. С днем рождения! :)
perfect_genius
11.12.2016 12:48+5Проверяется просто: попробуйте внести изменения в ваш код. Если это вызовет боль чуть ниже пояса, — значит
Значит стоит попробовать руками :Dс гибкостью у вас всё плохо.
nckma
11.12.2016 12:55+8Если же вы профессионал, — это ваша обязанность. Когда руководитель ставит нереальный срок, ваша обязанность сказать «нет». Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет». Когда вам предлагают работать по ночам, ваша обязанность сказать «нет».
Вы уволены… :-)DFooz
11.12.2016 13:35+2и чего минусанули nckma? Мне руководитель так и сказал: «Нам надо выпускать продукт, а не всякой красотой заниматься». Да, он — быдлокодер и плевал он на C++11, шаблоны проектирования и прочее. Но быстро сменить работу не всегда получается, чтобы с такими особями не общаться
renskiy
11.12.2016 14:44+1он — быдлокодер и плевал он на C++11, шаблоны проектирования и прочее
Костыльный программист :)
Проблема в том, что желание спроектировать красивую архитектуру часто перерастает в оверинжиниринг. Необузданный перфекционизм — вообще бич воодушевленных (passionate) программистов. Вполне естественно в таких случаях желание руководителей не допускать такого развития событий, но почти всегда это приводит к противоположной крайности.
solver
11.12.2016 17:02+9Чаще всего, это не оверинжениринг, а желание сделать просто хорошо. Не идеально, не супероптимально.
Просто хорошо.
Которое другие тут же закидывают лозунгами типа «идеальная архитектура», «оверинжениринг» и т.д. и т.п.
Как результат эти закидыватели выглядят, в глазах руководства, как «прагматичные» разработчики «ориетированные на бизнес». Они попадают в лиды и говноподходы продолжают культивироваться.
Итог — имеем то, что имеем…Fesor
11.12.2016 17:54На эту тему рекомендую этот докладик:
masterspline2
11.12.2016 19:16+4> «Нам надо выпускать продукт, а не всякой красотой заниматься»
А еще не он будет технический долг возвращать, зато премию за своевременное выполнение поставленной задачи получит. Так что такому руководителю скорее плевать на исполнителей. Если было бы не плевать, то он обсудил бы этот вопрос, объяснил, что заказчику нужен продукт к определенному времени, поэтому нужно придумать в каких местах можно схалтурить, чтобы успеть в срок. А также выделить время после сдачи на возврат технического долга (если проект придется и дальше развивать). И самое главное — сдержать обещание и выделить время.
Исполнитель в такой ситуации тоже должен понимать, что ему зарплату платят не за стройную архитектуру, уместное применение шаблонов и 100% покрытие тестами, а за решение задачи заказчика. И между архитектурой приложения и своевременным выполнением задачи нужно находить баланс, потому что без возможности рефакторинга приложение невозможно развивать, а без сдачи проекта вовремя не будет зарплаты.MacIn
13.12.2016 05:27А еще не он будет технический долг возвращать, зато премию за своевременное выполнение поставленной задачи получит.
Это же классика: перевыполнить план, получить премию за 105%, а потом получатель будет исправлять косяки.
Fesor
11.12.2016 17:53+2Тут есть большая разница. "архитектурно слабое решение" нормальное, если у вас не будет необходимости потом бороться с недостатками. Например нам нужно сделать что-то за 2 дня. И мы можем сделать это что-то за два дня, но есть еще нефункциональные требования, нагрузки, безопасность… Мы понимаем что решение, с которым мы можем успеть несет в себе огромные риски. А потому лучше сказать нет, ибо на самом деле эта реализация сродни ложному обещанию: Мы как бы все сделали, но потом придется переделывать. Причем как правило клиент будет больше расстроен тем, что его вовремя не предупредили о рисках.
Другой пример. Попросили вас сделать что-то, что будет использоваться лишь раз. Например — импорт данных из одной системы в другую. Эта операция будет происходить ровно один раз. И объем данных известен. Но разработчик хочет сделать правильно, пишет отдельный компонент, который использует какой-нибудь потоковый парсер, импорт по частям, заботится о производительности решения и т.д. Словом, делает "правильно" и тратит на эту одноразовую штуку в 3 раза больше времени.
То есть по сути, разработчик всегда должен понимать зачем он что делает, и исходя из этого уже оценивать плюсы/минусы принимаемых решений и искать наиболее эффективный вариант.
SamsonovAnton
11.12.2016 18:27+3Ну и слава богу! Валить надо как можно скорее из такой компании, где за выражение экспертного мнения указывают на дверь.
nckma
11.12.2016 18:31+2Возможно в больших городах с этим проще. В маленьком городе просто некуда бежать…
DistortNeo
11.12.2016 21:35-2Сфера IT мобильна, а зарплаты в ней достаточны, чтобы иметь возможность спокойно сменить город.
navff
12.12.2016 06:14В маленьком городе просто некуда бежать
В моём Череповце некуда бежать, но можно работать удалённо на столицы, что мы и делаем. Если квалификации достаточно, можно найти нормальную работу за пару месяцев.
navff
11.12.2016 19:16Вы уволены… :-)
Пожалуй, для каких-то работодателей может случиться и так. Но часто такая позиция вызывает уважение. Чуть подробнее в комменте ниже.
cybd
11.12.2016 12:58+3По-моему, нужно оставаться честным с самим собой. Оставаться честным с командой. Это касается как и сроков, объемов и трудности задач. Сколько было случаев, когда заведомо занижали эстимейты, озвучивали их команде, а в процессе работы чувствовали угрызения совести и в итоге срыв срока сдачи, потеря контроля и ссоры в команде. Научиться не бояться говорить правду, говорить что это займет больше времени, во время работы сообщать что первоначальная оценка оказалась неверной.
Спасибо за статью. С днем рождения!navff
11.12.2016 19:20Да! Очень, прям, точно вы сформулировали мысль. Если мы будем поступать по совести, то всё будет хорошо и у нас, и у заказчика.
nckma
11.12.2016 20:15+1Конкретно у меня очень странная проблема.
Я считаю, что поставленные задачи невозможно выполнить качественно и в срок. Многие коллеги «в курилке» согласны со мной. Однако на совещаниях я остаюсь в одиночестве и только я говорю, что все плохо со сроками и плохо с архитектурой. Остальные продолжают уверять менеджмент, что все отлично и все можно сделать.
Получается, что я один и есть «хромая утка», которая постоянно говорит неприятности.
Не очень весело. Для себя решил, пожалуй лучше больше молчать и больше соглашаться.
sergio_deschino
11.12.2016 13:17С днем рождения)
Вот вопрос с зоной потока мне действительно показался спорным… Я наоборот в таком случае облачаюсь в наушники, ставлю телефон на dnd и пишу, пишу, пишу… А на следующий день или через некоторое время делаю ревью с рефакторингом и переписываю какие-то вещи.
OlegAxenow
11.12.2016 13:59+8Когда читаю очередную статью про полезные советы Мартина (или советы по мотивам его книг), каждый раз хочется прокричать — «Только не забывайте включать критическое мышление!». Сегодня видимо критическая масса накопилась :)
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
— Это невозможно, на разработку и отладку поиска нужно две недели.
— Нам нужно показать клиенту в пятницу. Давай постараемся.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.KlimovDm
11.12.2016 15:51+3P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
Может вы удивитесь, но далеко не все это понимают. Недавно я проводил серию собеседований, так каждый третий соискатель напрямую увязывал тестирование с корректностью кода, а некоторых в этой фразе не смущали слова «должен» и «на 100%»
amakhrov
11.12.2016 22:16Фаулер про покрытие тестами: http://martinfowler.com/bliki/TestCoverage.html
Если вы тестируете осознанно и качественно, можно ожидать покрытия в районе 90%. В то же время, покрытие 100% выглядит подозрительно — выглядит так, будто кто-то специально пишет тесты таким образом, чтобы получить высокий процент покрытия, но не задумываясь о том, что он делает.
(If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% — it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.)
Так в чем же ценность анализа покрытия кода тестами? Это просто помогает определить, какие части вашего кода не протестированы.
So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested
rassol
11.12.2016 14:19Шикарная статья, спасибо! С, с днём рождения :) Многих счастий и малых багов :)
Marwin
11.12.2016 14:45+6Насколько красиво написано, настолько же далеко от суровой реальности, если только ты не работаешь в компании уровня гугла или мс. Больше 10 лет кручусь по фирмам-стартапам, где обычно есть только директор/основатель/маркетолог/гуманитарий, придумывающий как поднять бабла, и понимающий, что это нужно было еще «вчера». А дальше они нанимают «компьютерного грамотея», который делает «всё» (включая даже закупки и установку оборудования на места, если таковое будет использоваться плюс сидение на техподдержке). Работа 24/7/365. Какое ТДД, какой контроль качества? Забилдилось? ура, заливаем в продакшен, а жизнь сама отбракует неудачные решения.
Конечно, я не фанат таких условий, но я и сам не вижу альтернатив, как небольшим компаниям в условиях тотальной экономии бюджета пытаться что-то вывести на рынок, когда они даже не знают примет ли народ их решение.Marwin
11.12.2016 14:54+6я к тому, что в большинстве случаев (согласно принципу, что 20% времени/усилий дают 80% качества) рациональней сделать 5 разных вещей, и, возможно, одна из них стрельнет, чем до посинения доводить до идеала код и отлаживать процесс разработки, думая, что проект не взлетает только из-за багов, а не просто потому что он никому не нужен.
TimsTims
12.12.2016 09:06+1Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге (с) баш
Assargin
11.12.2016 14:58+2Жёсткая правда. Малодушие до сих пор мешает иногда говорить нет.
Зона потока для меня — это спокойная, почти не отвлекающая музыка, либо её отсутствие и почти полная тишина в студии, при этом я сконцентрирован и все получается хорошо.
С днём рождения! :) Интересно будет прочесть эту книгу.
kloppspb
11.12.2016 16:23+3Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
Конечно, рабочие моменты всплывают в голове и в нерабочее время. И что-то новенькое захватить тоже иногда хочется, даже если оно не связано напряую с текущими задачами. Но планировать это именно таким образом — IMHO, признак чего-то нездорового (вспоминается даже «has no life» из ЮП).navff
11.12.2016 18:34А мне кажется, нет ничего здоровее, чем заранее продуманный режим дня. Встал, принял душ, выпил два стакана воды и за книжки. Ну, или в другое запланированное вами заранее время. Важно выделять его ежедневно.
kloppspb
11.12.2016 19:09+3Этот режим хорош во студенчестве или в армии :) Ну или для одиноких людей, не обременённых никаким хозяйством, или просто сильно зависящих от работы во всех смыслах.
Лично я готов планировать рабочее время исключительно по договорённости с работодателем, а как распоряжаться оставшимися от основной работы квантами времени — решается более гибко, исходя из текущих потребностей вне работы (среди которых, кстати, «а не забить ли на всё и не поваляться ли кверху брюхом просто так» — тоже вполне уважаемое желание, которое может настигнуть в любой момент).
DFooz
11.12.2016 21:07+6Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
плохой совет. Хороший должен быть: если работаешь 40 часов в неделю, планируй на работу 30, а оставшиеся 10 на самообразование, в будущем потенциально связанное с тематикой проекта. Ибо твои новые знания втройне окупятся для фирмы.
vedmalex
11.12.2016 16:30+1А вот читаю, и думаю…
Больно принципы описанные в статье, и, очевидно, в книге, похожи на законы Дхармы. Быть хорошим программистом сложно! Но интересно.
Еще раз с днем рождения!
От кришнаита и программиста.
navff
11.12.2016 18:37Спасибо, здорово! Действительно, если следовать регулирующим принципам, то, что описано в книге как-то само начинает работать.
Strain
11.12.2016 16:50С днём рождения бро!
Про говорить «нет» — реально ценно, правда чем больше тебе платят тем сложнее это сказать :)solver
11.12.2016 17:11Собственный опыт говорит об обратном.
Чем больше тебе платят, тем больше прислушиваются к твоему мнению.
Хотя конечно же всегда есть исключения.
navff
11.12.2016 18:41+3Мне платят за то, что я говорю нет. Реально, это работает: я ж не просто посылаю его в зад и не делаю то, что он просит. На всё есть обоснование, и когда работодатель понимает, что каждый отказ обоснован его же интересами, он начинает уважать.
Недавно клиент просить впилить на карту дополнительные виды флажков. Я говорю «нет», объясняю почему, спрашиваю зачем оно надо и предлагаю альтернативное решение. Все счастливы.
А вот донести до человека свою точку зрения — это целое искусство. Бывает, на одно письмо из четырёх строк уходит полчаса.
Firsto
11.12.2016 18:28Не всегда есть возможность сказать "нет", когда заказчик требует необходимый функционал в любом виде, пусть даже с помощью костылей.
P.S.: С днем рождения.
navff
11.12.2016 18:58Если вы сделаете и оно будет работать без косяков, но не красиво, — значит вы сделали. Если же вы знаете заранее, что выполнить задачу нереально, ваша обязанность сказать «нет». Речь именно о честности, а не о тупом отказе работать.
worldmind
11.12.2016 18:28В основном согласен, но, к сожалению, бизнес этого не понимает, практически нереально найти работу без плохокода, все бешено набирают технический долг неведомо на что надеясь, а потом когда развитие бизнеса стопорится обвиняют программистов в том, что они мол нифига не делают, хотя они заняты латанием дыр в тонущем проекте и не имея времени отдавать технический долг продолжают усугублять ситуацию.
navff
11.12.2016 19:02Видимо, речь о компаниях, для которых разработка ПО — не основной вид деятельности? Получается, что менеджмент не закладывает время на тестирование и рефакторинг?
worldmind
11.12.2016 19:08Процесс ни для кого не является основным видом деятельности, все работают на результат, да вот только чаще всего на краткосрочный.
mikemet
11.12.2016 18:41Прекрасная, полезная и интригующая статья.
Думаю, такая книга будет полезна как начинающим программистам ( каковым являюсь я), так и опытным.
Александр, Поздравляю Вас С Днем Рождения! Здоровья и удачи Вам во всем.
И если Ваше предложение по книге в силе, то: mikemet@yandex.ru
rodial
11.12.2016 18:426. Помогайте и принимайте помощь
Может быть поэтому?!
произведение известное, в рекламе не нуждается
Полагаю так и есть, я слышал о ней, но прочитать руки не доходили. После этого конспекта понял, что книгу всё таки стоит прочитать. Ну и точно есть люди услышавшие о ней в первый раз.
navff с днем рождения )
LazyMechanic
11.12.2016 18:42Владимир, спасибо за статью. Я только вхожу в мир программирования и больше половины написанного тут точно отражают мои «проблемы», которые я считал достоинством (как отказ от помощи, в сторону решения своими силами). Поздравляю Вас с днем рождения! Успехов вам!
KEKCoGEN
11.12.2016 18:43Очень не согласен с пенуктом 2
Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет»
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.navff
11.12.2016 18:46А разве нельзя сказать «нет» и предложить альтернативу? Или отложить. Или сделать проще.
Наша задача — сделать клиенту хорошо. Если я быстро нахреначу ему копипаста с стэковерфлоу, не поняв, как оно работает, в будущем это обернётся большими проблемами.
А вообще, в книге более подробно расписано про «нет» и статья не отражает всего, что написано в оригинале.
bad4iz
11.12.2016 18:46Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.
vlentikus
11.12.2016 18:46Отличная статья для начинающих! Спасибо огромное за потраченное время на конспект, с удовольствием буду ждать продолжения. И с Днем Рождения Вас!!! Будьте счастливы, и успеха во всем!
Mernadan
11.12.2016 18:47Спасибо за хорошу статью по правильному распредению времени)Это даже касатеся не только программирования, но и другихотраслей в целом. Картинки доставили? И самое главное~Поздравляю Вас с Днем Рожденья, Счастья, здоровья, творческих успехов, стабильности и процветания! Пустт все у Вас получится
kuftachev
11.12.2016 18:47Я поддерживаю автора статьи, конспекты книг от консультантов очень нужны, так как в них 90% воды, но здравые мысли бывают. Из того, что я читал: "Чистый код", "Рефакторинг", "Шаблоны корпоративных приложений", сейчас больше не вспомню.
KohTlag
11.12.2016 18:48Поздравляю с днем рождения. Желаю, чтобы не убавлялись силы и выносливость, чтобы не исчезали желания и мечты. Чтобы не только день рождения, но и каждый последующий день приносили удовлетворение от жизни, вдохновение к свершениям и желание жить, любить, творить.
alexandzolotarev
11.12.2016 18:48Конечно есть пункты которые не ко всем подходят, но в целом всё не лишено логики и здравого смысла. Нашёл для себя статью полезной.
posts2000
11.12.2016 18:48+1Happy birthday . I'll be happy if you send me the book in electrical version:) P.S. I want the book on DC, 12V, 2A. Thanks.
shakandrew
11.12.2016 18:49Поздравляю с днём рождения, желаю счастью в личной жизни!
ПУХ… shakandrew
Ну по поводу ночного программирования можно поспорить, уже настолько привык к тому, чтобы кодить ночью, что днём просто нет желания… просто руки не хотят браться за дело.
Так что по-моему это сугубо индивидуальный вопрос.navff
11.12.2016 18:51А что вы днём делаете? Ночью работается хорошо потому что никто не отвлекает: телефон не звонит, жена молчит, дети спят. Можно войти в Зону и спокойно писать. Но, согласно восточным наукам о здоровье, такой подход очень плох для психики. Может, есть варианты пересмотреть режим?
flsh
11.12.2016 18:51+4А никого в статье не смущает 40 часов работа + 5 часов обед + 20 часов дорога + 5 часов на сборы на работу + 56 часов сна + 20 часов на обучение в неделю = 146 часов в неделю для работы из 168. И идеальный программист оставляет себе только 22 часа в неделю на дела, спорт(активный отдых), семью. Никого не смущает, что идеальный программист должен жить только работой? А такие статьи уничтожают нашу жизнь.
VolCh
12.12.2016 06:00+1На дорогу как-то многовато. Но вообще можно сильно совмещать дорогу и самообразование.
kloppspb
12.12.2016 10:15О, стандартный аргумент в разговорах об удалённой работе :) И стандартный же ответ: а можно это время потратить так, как захочется. А не так, как это диктует способ его убийства.
VolCh
18.12.2016 19:35Основной аргумент у меня лично против удаленной работы — недостаточная способность технических средств обеспечить максимально эффективные коммуникации.
kloppspb
18.12.2016 22:18Мне тоже так казалось поначалу. Но довольно быстро пришло понимание, что чем больше необходимости в живом общении, тем больше что-то не так. И наоборот, его отсутствие — признак того, что всё правильно, и вообще, очень хорошо сказывается на производительности.
Через почти 10 лет удалёнки могу представить только одну ситуацию, когда плотное общение действительно необходимо: в проект вливается новый человек, который при этом не очень хорошо знаком с предметной областью. Да и то если через пару месяцев он не перестанет доставать окружающих общением и не начнёт работать самостоятельно, то либо его квалификация не соответствует задачам, либо что-то не так с организацией работы.
В обычном режиме JIRA+Confluence или их аналогов вполне достаточно. Текущие вопросы прекрасно решаются в почте/скайпе/jabber, в крайнем случае — голосом.VolCh
19.12.2016 12:07Как по мне, то текстовые методы необходимы, прежде всего, для документирования результатов решения проблем, а вот выработка этих решений наиболее эффективна в голосовом режиме как минимум. То есть текстовое общение в крайнем случае, когда нормально возможности обсудить нет. Одна из проблем текстового общения — очень неэффективная модерация совещаний, нет возможности кого-то перебить, пока он полностью свою мысль не изложит.
kloppspb
19.12.2016 18:32нет возможности кого-то перебить, пока он полностью свою мысль не изложит.
А может это и хорошо :)
Наверное, всё зависит от конкретики. За почти 4 года работы в предыдущем проекте пришлось собираться для обсуждений всего 2 раза. Да и то скорее не «пришлось», а «раз уж все рядом оказались, так почему бы не?». Не так уж и часто практически для любого расстояния.VolCh
19.12.2016 18:54Вероятно. Да, если что, я про разработку не в ИТ-бизнесе, но в бизнесе, для которого ИТ — основа, и принятие многих бизнес-решения зависят от оценок разработчиков на реализацию или адаптацию.
MacIn
19.12.2016 02:26Например?
VolCh
19.12.2016 11:58Например, углы обзора типичных камер и экранов не обеспечивают нормальной возможности видеть одновременно нескольких участников конференций, с одним-то сложно без специального оборудования. Сложно обеспечить трансляцию процесса рисования схем на бумажке или доске, особенно без ущерба для видеоряда самого рисующего. Звуковые тракты (стандартные микрофон-динамик) не обеспечивают естественную звуковую картину.
Не, возможно, где-то в Гугле или МС обеспечивается практически полный эффект присутствия, но наверняка окупается стоимость оборудования для этого хорошо если для топов.MacIn
19.12.2016 15:54Ясно. Везде своя специфика. Мне за 6 лет удаленной работы не потребовалось ничего сложнее обычных VoIP конференций и общих чатов в скайпе. Но у нас и работа сильно распараллелена.
EvilShadow
12.12.2016 13:19А сон тоже сугубо для работы нужен? Иначе можно было бы обойтись без него?
cerberus13
11.12.2016 18:52Только слова благодарности за статью! А что касается критики — то никто не идеален :-)
Уже долгое время хочу стать лучше и никак не могу остановиться на этом пути…
zz2
11.12.2016 18:52Спасибо за статью. Поздравляю с днем рожденья! Желаю большИх финансовых инструментов!
Vadomen
11.12.2016 18:52Пасибо. Норм конспект. Жду продолжения. С днем рождения. Неиссякаемого вдохновения тебе. Моей жене сегодня тоже др.
brooth
11.12.2016 18:53+5Как будто мой ПМ писал. Работай больше, проси меньше. Ошибок в коде быть не должно, тестировщики не для этого там сидят. Учись сам, в свободное время, компания не обязана это оплачивать. Проблемы начальства — твои проблемы, твои проблемы — твои проблемы. Ты должен всем, не, серьезно, всем! Тебе никто и ничего.
Каждый кусок кода должен быть протестирован для всех возможных ситуаций. Если это делать вручную, — у вас не будет времени на разработку
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Вообщем, Вы извините, но статья жуткая «вода». Местами уровня папблика вконтакте.navff
11.12.2016 18:53-1Ваш ПМ — мудрый человек.
brooth
12.12.2016 11:59+1Если бы… И что вообще тут мудрого? То, что программисты должны писать код без ошибок — это вообще наиглупейшая мысль. Человек не может держать в голове все логику среднего+ проекта.
Извиняться перед тестировщиками… Какому мудрецу это вообще могло в голову прийти? Извиняться за то, что нормально? Их профессия, как результат понимания того, что в текущих реалиях без ошибок никак.
Вы же понимаете, что если я до передачи задачи в QA, проверю все возможные тест-кейсы, то после меня эти же кейсы (как минимум) проверят они? Вам не кажется, что это нерационально?
Про стопроцентное покрывание тестами я уже написал, это гиганская работа. По опыту, на написание тестов уходит столько же времения (а то и больше), как на саму фичу.
К тому же, автотесты — не панацея. Как по мне, то они вообще не для этого. Они для того, чтобы программист мог спокойно рефакторить проект. И быстро находить, где и чего он поломал.
Я считаю, мудрый ПМ — это человек, который всегда держит в голове то, что ошибки будут. И выстраивает рабочий процесс, отталкиваясь от этого. Не летает в облаках, не надеется на удачу, не думает, что он сможет заставить программиста писать без ошибок.
Не хочу писать слишком большой комментарий. А так, тут поле не паханное, извините, подобного бреда.KlimovDm
12.12.2016 12:15+1То, что программисты должны писать код без ошибок — это вообще наиглупейшая мысль.
Эх, не удержусь, приведу одну из моих любымых цитат:Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения (с) Дейкстра
VolCh
18.12.2016 19:36Внесение ошибок в код — практически неизбежный побочный эффект его создания или модификации.
Tsimur_S
13.12.2016 06:33+1По-моемому, в статье нигде не говориться что ошибок в коде быть не может. Посыл в том, что не стоит отправлять на QA стадию код в котором, очевидно, есть ошибка, в надежде авось проскочит. Так же не стоит отправлять фичу вообще не протестировав ее. Я имею в виду прогнав тот кусок работы, что вы сделали. Вы удивитесь, но есть люди которые как то запилив очередной компонент, даже не попробуют его в работе хотя бы на заведомо валидных сценариях. А QA он действительно для другого, он должен проверить что компонент не обрушил нигде функционал неочевидным образом и проверить на разные edge cases.
VolCh
18.12.2016 19:40А QA он действительно для другого, он должен проверить что компонент не обрушил нигде функционал неочевидным образом и проверить на разные edge cases.
Не согласен. Грубо говоря, за обрушение части функционала неочевидным образом отвечает Quality часть QA, а вот за то, что реализованная часть функционала работает очевидным (описанным в ТЗ и подобных документах) образом отвечает Acceptance часть.
navff
13.12.2016 06:42Вы бы лучше книжку почитали, чем столько сил на комменты тратить.
Не нравится ПМ — у нас свободное общество, где можно менять работу. Ошибки в коде будут, но это исключительная ситуация, когда ваш код не прошёл ваш собственный контроль качества. А если вы пишете в надежде на тестировщиков, — значит вы поступаете непрофессионально.
100% покрытие тестами окупится, когда вам нужно будет изменить что-то в системе. Прогнал тесты и увидел, где сломалось. Если тестов нет, с ростом системы будет расти неуверенность в успехе изменений. Так система превратится в склад устаревшего кода.VolCh
18.12.2016 19:46100% покрытие тестами хотя бы в эталонном окружении окупается, имхо, только если минуты простоя или некритические ошибки выливаются в суммы, значительно большие чем многие человеко-месяцы работы разработчиков тестов. По крайней мере в области веб-разработки.
HaJIuBauKa
13.12.2016 22:04+2Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Если вы имеете в виду Роберта Мартина (автора книги), то он написал очень много автотестов, в том числе фреймворк для приемочного тестирования, код которого состоит на 30% из кода тестов. Думаю он знает о чем он говорит. С цитатой которую вы привели я согласен на 200%.
Kassady
11.12.2016 18:53Интересно, особенно для начинающего программиста, буду стремиться к тому, чтобы быть хорошим программистом. Большое спасибо! С Днём Рождения!
ferogot
11.12.2016 18:54-1С мнением о зоне потока согласен.
В последний раз при работе в зоне, я казалось поднял с 10% до 80% готовность проекта, а при сборке получил сообщение о неожиданной ошибки и закрытии приложения. Выдвинул и проверил множество теорий, вплоть до ошибки IDE :)
В итоге, на поиск причины ушло непозволительно много времени, а ошибка была весьма глупая, во вложенном цикле делался инкремент к счетчику внешнего цикла, из-за этого данные неверно инициализировались и вообще говорить о дальнейшей работе приложение нет смысла.
Скорей всего этого не случилось, будь я в здравом уме и следил за своими действиями
P.S. С днем рождения (да-да, признаю, этот комментарий здесь только ради этой книги :3 ). Всем добра!navff
11.12.2016 18:56От упомянутой ситуации никто не застрахован и вне Зоны. Сам я своего опыта про Зону уже давно не имею, ибо работаю только днём, а днём множество отвлекающих факторов.
depporter
11.12.2016 19:07+1Спасибо за конспект. Распечатал некоторые моменты крупным текстом и и расклеил возле рабочего места. С днем рождения, всех благ, удачи, счастья.
Ambrose
11.12.2016 19:18Спасибо! Интересная статья, отличные иллюстрации, заставляет задуматься…
С Днём Рождения! ;)
rail-ka
11.12.2016 19:22Спасибо за конспект, ждём следующую часть. И с днём рождения, всех благ и качественного программирования!
BoryaMogila
11.12.2016 19:58Спасибо, за хорошую статью. Поздравляю с днем рождения. Желаю развития и творческого вдохновения.
Isma
11.12.2016 20:20И нормальным людям нужно всегда понимать, что манипуляция, известная у криминальных элементов как «Пацан должен отвечать за базар» не означает, что кто-то «должен рвать энное место до последнего если вдруг что-то не срастается». Это означает все лишь «Никогда не давай невыполнимых обещаний». По-моему в это упирается большинство пунктов.
Erraendil
11.12.2016 20:40Да-да! Во-первых, с Днем Рождения :) Прикольный способ посчитать сколько наверняка дочитало до самого конца.
А так во многом откликается, хотя я бы не был столь безапелляционным в высказываниях.
Понятно, что статья — конспект, но все же для меня было бы ценнее услышать насколько это соответствует личному опыту автора с примерами.
glader
11.12.2016 20:41+2Поставил минус за «Зона потока — зло». По моему опыту это не так.
navff
13.12.2016 06:58Вы — молодец, потому что открыто пишете о том, что поставили минус.
А вы не забыли перед тем, как поставить минус посчитать по одному плюсу за остальные пункты, сложить и вывести результат? Я не для оценок пишу, однако, сообщаю на будущее: на подготовку одной такой статьи уходит не меньше 8 часов времени автора + 4 часа времени иллюстратора. Время на прочтение книги не считаю, потому что всё равно бы прочитал.
А ещё, нужно вспомнить, что это конспект книги, а не личное мнение автора. Хотя по части «зона потока — зло», мнение автора статьи совпадает с мнением автора книги.
Я вижу, вы сами пишете на Хабр и, возможно, не помешает немного уважения к другим авторам.
d2rdkn
11.12.2016 21:16С днем рождения!!! Хороших людей вокруг, здоровья и успехов!
Хороший конспект! Понравился. Со многими вещами абсолютно согласен, остальных просто, наверное, не понял. Нужно углубиться в изучение :)
avatvar
11.12.2016 21:16«Я постараюсь» — это же мое. Пришла пора меняться, спасибо за статью!
С днем)
sim31r
11.12.2016 23:20+1Мне показалось, что 75% статьи подойдет любым специалистам, немного специфическую терминологию изменить:
Используют правило «Не навреди». Ваш
кодтруд должен работать и вы не должны ничего ломать. Конечно, это не каждому под силу, но по мере профессионального роста, количество ошибок в вашемкодетруде будет стремиться к нулю.
Далее про самообучение, работу в коллективе, режим дня, планирование труда, оценка сроков. От врача и математика, до сантехника.
DiEtIm
11.12.2016 23:53С днем рождения))
Что касается статьи то статья крайне интересная, было бы вдвойне интересно (для меня как для аналитика) как это можно применить к стадии работы с Заказчиком и проектирования. Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача (если исключить те случаи когда программист сам себе аналитик).
И было бы крайне интересно прочесть продолжение)Fesor
11.12.2016 23:59как это можно применить к стадии работы с Заказчиком и проектирования
Это тип… пару месяцев выясняем требования, пару месяцев проектируем? потом пару недель это кодим, тестируем и по итогу получаем от клиента "это немного не то"?
Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача
Программисты должны учавствовать в процессе анализа, поскольку они компетентны говорить "вот это решение будет дорого, но если вот так то дешево". А когда это делают только аналитики, обычно получается не самый оптимальный вариант. Да и фидбэк клиенту проще получать по прототипам каким-нибудь.
navff
13.12.2016 07:05Мы закладываем время на вычитку спецификаций программистами. Программист читает труд аналитика в конфлуенсе и ставит лайк, если всё хорошо. Если что-то не так, оставляет заметки на полях. Пока есть заметки, текст к клиенту не идёт. Так вы побуждаете разработчика сказать «нет» на ранней стадии проекта.
tema_sun
12.12.2016 00:59С днем рождения, но книгу не надо ;)
После прочтения статьи создается впечатление, что идеальный програмист — это такой радужный волшебный единорог. Т.е. его тоже не существует.
Мне вот интересно, когда люди пишут такие книги они учитывают вообще, что каждый программист это живой человек. И, в это трудно поверить, но в своей жизни он не только программирует.kloppspb
12.12.2016 02:48IMHO, всё это может иметь смысл в самом начале карьеры, когда жизненно важно «зарабатывать очки».
Но когда за плечами лет 10-15-20 стажа, оброс бытом и появились стойкие интересы в жизни (только не говорите, что они и в 20 лет есть...), всё это воспринимается с недоумением. Описывается даже не единорог, а какая-то сферическая мечта работодателя. Эдакое существо, у которого в жизни кроме работы вообще ничего нет.navff
13.12.2016 07:11Да. Когда оброс бытом, можно смело начинать пушить в репозиторий всякую дрянь в надежде на тестировщиков, перестать учиться и начинать говорить «я постараюсь». Все взрослые так делают.
tema_sun, возможно, автор книги — программист с многолетним стажем и семьёй? Можно проверить.kloppspb
13.12.2016 09:39Когда оброс бытом, можно смело начинать пушить в репозиторий всякую дрянь в надежде на тестировщиков, перестать учиться и начинать говорить «я постараюсь». Все взрослые так делают.
Вы сами это только что придумали. Почему разместили под моим комментарием, и к чему тут «Да» — непонятно.navff
13.12.2016 09:50Вы пишете:
всё это воспринимается с недоумением
Я не понимаю, что именно из вышеперечисленного у взрослого человека должно вызывать недоумение.kloppspb
13.12.2016 10:08Действительно, в комментарии, на который я отвечал, конкретные пункты (конечно, не все из перечисленных в статье) не указаны. Тем не менее, мы поняли друг друга. Простите, что забыли про вас :) Но могу сказать, что о вещах, связанных непосредственно с процессом, там речь не шла (хотя, со многими положениями тут я тоже мог бы поспорить, но смысла не вижу — судя по другим комментариям вы слишком уверены в своей правоте во всём).
HaJIuBauKa
13.12.2016 22:11Поддержу автора.
Уверенности в его правоте во всем, что он говорит и пишет в комментариях можно только радоваться. К сожалению так делают очень мало людей.
Ведь интернет — это не то, что говорить в лицо, монитор все вытерпит, и ложь и оскорбления.
zolern
12.12.2016 06:19+1С днем рождения! Очень интересная статья, читается легко, все сразу улаживается в голову. Респект за стиль!
Вот совсем недавно на собственой шкуре понял, что это милое честное пионерское «Я постараюсь» вообще никому добра не делает, а самое неприятное, что в конце концов сам себе оказываешся злым Буратино.
leonov_artem
12.12.2016 06:20ТС, статья понравилась! С днем рождения, счастья, здоровья, держись там!
TimsTims
12.12.2016 10:47+1Люди, статья статёй, но не забывайте критически мыслить! Я не со всеми пунктами согласен с автором:
> Используют правило «Не навреди»
Какая-то калька с врачебной клятвы Гиппократа. Причём, мало чем на неё похожая. Что значит «не навреди»? «вы не должны ничего ломать» — вот например ты пишешь робота-парсера, который ходит по сайту ЦБ, и скачивает котировки? Вред? Ну, относительный вред — ведь мы напрягаем серверы ЦБ. ЦБ не загнётся, всё вроде норм. А если это не ЦБ, а какой-нибудь маленький сервачок маленького проекта, с интересной нужной информацией? Ему уже будет вред. Второй пример: ты пришёл к выводу, что надо всё переписывать с нуля. При этом часть функционала потеряется. Это вред? -вред. Твой код сломает что-то? -да, сломает. Правило нарушается? -нарушается.
> Контроль качества не должен ничего найти
Совсем за уши притянуто. Можно месяцы искать в коде ошибки, и выдавать красивый законченный код, а можно отдать код сразу по готовности, и исправить маленькие косяки по мере их обнаружения. Когда задач много, сроки поджимают (не горят, но поджимают), то ты просто не можешь позволить себе тратить много времени на вылизывание кода. (про баланс кода-результата).
Про тестирование примерно то же самое — тесты могут покрывать хоть 100% кода, но это не значит, что код выполняет свою задачу как задумывалось.
> Скромны
Тут какой-то бред. В заголовке говорится «скромны», а в тексте под ним говорится про суровость и обязательное отсутствие чувства юмора.
> Знают свою область
Тоже этот штамп «программист должен писать код в ИТ-отделе». Жизнь меняется, и нужно под неё подстраиваться. Сейчас есть стабильная и очень результативная тенденция иметь своих программистов в каждом отделе. Про это пока не пишут, т.к. все привыкли, что всех программистов надо сажать в одном месте, а всех маркетологов в другом. А когда их садят вместе друг с другом, то отдел маркетологов становится вдруг автоматизированным(программисты автоматизировали маркетинг), а отдел ИТ вдруг продуктивным (маркетологи начали нормально пиарить руководству ИТ-шников).
Автору navff :
> кто поздравит с ДР, тот получит электроверсию книжки в ЛС
А что там с лицензиями? Я надеюсь, вы отправляете лицензионные купленные копии каждому вас поздравившего? Если это не так, то вы становитесь нелегальным распространителем цифрового контента. Вы ведь не зря указали ссылку на озон в самом первом предложении. Получается, вы сейчас пишете: я купил книгу на озоне (за 299р), и делюсь бесплатно с вами на хабре!
Можно много говорить про этику, правильно это или плохо, но награждать не принадлежащим вам контентом(читать — украденным) других людей за какие-либо действия (поздравления в данном случае) — не этично с моей точки зрения.
luck4ever
12.12.2016 11:09Владимир, спасибо за конспект, в ожидании 2 части ) С днем рождения, Вселенского счастья Вам!
alexkab
12.12.2016 11:09Некоторые моменты в статье позволили узнать себя, очень интересно было читать. С днём рождения!)))
Alex_Hi
12.12.2016 11:10Ну что ж, спасибо за освещение такой темы. И с днем рождения! Чтоб дела все шли как по маслу — самое главное)
У меня тоже скоро, кстати. Прям под новый год. :D
rasswet
12.12.2016 13:29С днем рождения! Успехов вам в достижении ваших целей! и с наступающим заодно!
Inq
12.12.2016 17:19С «Зоной потока» не согласен. Считаю, что это что-то вроде «поймать волну». В такие моменты продуктивность подскакивает, и ты пишешь много больше, получая вдвое больше удовольствия. Драйв же :)
Правда, в таком состоянии очень просто и легко уйти в over-engineering, но ничего не мешает потом перечитать тонны кода, и поправить, где надо.
Верный признак Зоны, — это когда вы невежливо отвечаете на телефонные звонки и не рады даже хорошим людям.
Вот тут, конечно, надо «включать голову» и держать себя в руках. Так как люди, что ломают твой «поток», конечно, раздражают. Это как любимую кость у собаки начать отнимать — можно остаться покусанным. Или как у наркомана — дозу… В общем, мало кому нравится, когда кайф ломают :) С другой стороны, когда ты отслеживаешь это — бороться с собственным негативом, конечно, легче.
И с днем рождения, да :) Всяческих успехов и роста во всех интересующих сферах :)Cromathaar
12.12.2016 23:23+2Об том и речь, что задолбаетесь читать и править потом. А возможно и не вы, что хуже многократно. Вспомните постулаты Agile-техник: марафон, а не спринт; постоянная скорость; движение маленькими шажками и т.д. Игра в планирование, TDD, парное программирование — все направлено на то, чтобы разработчик семь раз думал, один раз делал и семьдесят семь раз не переделывал. Ведь экстаз — он такой, да.
kvothe
13.12.2016 04:52Насчёт Зоны потока Мартин не говорил, что это исключительно зло. Он так же приводил пример когда состояние потока уместно — например, когда вы изучаете что-то новое и тренируетесь в этом.
Pavel_Paydulov
13.12.2016 07:18Присоединяюсь к флешмобу :) Владимир, с Днем Рождения! Продолжайте радовать добротными конспектами и да пребудет с вами Сила.
dusty_arrow
13.12.2016 07:19Вспомнилось:
Еще немецкий промышленник Крупп писал, что если бы перед ним стояла задача разорить конкурентов, он бы просто предоставил им самых высококвалифицированных специалистов. Потому что они не начинают работать, пока не получают и не обработают 100% информации. А к тому времени, когда они ее получают, решение, которое от них требуется, становится уже не актуальным.
freindly_mind
13.12.2016 07:19Хорошая статья некоторые вещи были знакомы, а вот в некоторых увидел как глупо я поступаю. С днём рождения!
vnovicov
13.12.2016 07:19С Днём рождения, Владимир! Пусть ваш код в конечном итоге всегда будет безупречным:)
mad_nazgul
13.12.2016 07:21Насчет говорить «нет»…
Лучше не просто говорить «нет», а еще объяснить сколько стоить будет «да».
Мы же «профессионалы» и понимаем, что за счет качество можно купить время.
Которым потом расплатимся тем же временем. :-)navff
13.12.2016 07:23— А бывают случаи, когда в срок нельзя уложиться ни за какие деньги?
—Такое впечатление, что да. Заказчик хочет сферического коня, а коня нет. И привезут только в пятнице, а нужно выкатить версию завтра, потому что выставка, на которую приедет Медведев именно завтра. Так что вместо коня вы ставите заглушку: «тут будет сферический конь».
xexew
13.12.2016 07:24С днем рождения. Желаю дальнейшего творческого развития. Будет интересно почитать книгу :)
Minoshczech
13.12.2016 07:24Отличная работа, ждём 2 часть. С днем рождения! И мы не стареем а добавляем + 1 к мудрости. Успехов в начинаниях.
cb_ein
13.12.2016 07:24А как можно уверенно сказать «да» (особенно с точными сроками) или «нет», если я не имею понятия, справлюсь ли с поставленной задачей? Скажем, она для меня новая — в той области, с которой я до сих пор не имел дела. Это надо изучить вопрос, освежить в памяти или почитать что-нибудь из теории по теме, повтыкать в гугл и стек оверфлоу, наметить пару возможных решений и попытаться их реализовать, посмотреть что получилось — отбраковать неудачные и попробовать другие. Тут ну никак язык не поворачивается сказать что-то отличное от «ок, я попробую что-нибудь придумать».
navff
13.12.2016 07:27Про сроки в следующей части. Так и скажите: «Хрен знает, когда я закончу и я вообще не знаю, возможно ли это» и объясните постановщику всё то, что вы написали. Исследовательские задачи на то и исследовательские. Любой нормальный ПМ это понимает.
filkt
13.12.2016 21:28Не согласен со знанием всех там алгоритмов. Я например на вскидку не вспомню алгоритм сортировки, я им последний раз пользовался тыщу лет назад, и если надо будет, я открою книгу и посмотрю. Всегда раздрожает, когда на собеседованиях человек начинает с ухмылкай вас гонять по алгоритмам которыми он пользуется каждый день, а вы до этого работали вообще в другой области и решили сменить сферу деятельности, и про эти алгоритмы последний раз в институте слышали.
OasisInDesert
Спасибо за конспект и поздравляю с днем рождения, всего наилучшего. Глядя на картинки задумался о дополнительном объеме работ для наполнения статьи. Успехов в работе.