Заканчивая серию действий, которые сделают нас лучшими разработчиками, сегодня мы сосредоточимся на удовольствии от продвижения проекта и на некоторых предложениях книг и статей для чтения.
В предыдущей статье мы видели, что мы должны сохранять желание добавлять дополнительные вещи, пока работаем над определенной функцией, и избегать кодирования функций только потому, что можем. Что же нам делать со всеми этими великими идеями, когда они приходят? Как вставлять их плавно в процессе?
Это может показаться очевидным, но написание потребностей в бэклоге — лучший способ их рассмотреть и расставить по приоритетам. Самое худшее, что мы могли бы сделать, это иметь интересную идею, выраженную только в устной форме. Не писать их — это гарантия того, что вопросы время от времени будут возвращаться, загромождая наши мысли и загрязняя действительно необходимые обсуждения. Никто не хочет обсуждать новый фреймворк UT на совещании по звуковому дизайну.
Я встречал разработчиков и менеджеров проектов, которые говорили нам, что есть много вещей, которые нужно сделать. "Какие вещи?" спросили бы мы, чтобы слышать каждый раз один и тот же ответ: «Много их, я мог бы дать вам список!». На самом деле мы могли бы использовать список, но никогда его не видели. Проблема заключалась в том, что, поскольку нигде ничего не было написано, эти люди переутомились, пытаясь их запомнить. Если бы мы надавили достаточно сильно, они могли бы назвать одну или две задачи, но не больше. Они знали, что есть и другие вещи, но не могли их вспомнить и не могли сообразить, было ли это уже адресовано или нет.
Наша цель как разработчиков программного обеспечения — превратить идею в полезный продукт. Мы, конечно, не пытаемся превратить пять требований в двадцать открытых вопросов. Поэтому, когда возникает один вопрос, ошибка или потребность, мы должны с этим справиться. Мы должны представить его владельцу продукта, дать подсказку к ответу, если он у нас есть, позволить ему определить его приоритет и следовать его решению. Если идея принята, мы не должны возвращать ее для обсуждения. Если от него отказываются, мы все равно не должны его возвращать.
Дело в том, что мы не должны оставлять вопрос открытым; мы должны что-то с этим делать. В зависимости от времени, когда сделано замечание, может быть более эффективным сделать его немедленно, как правило, для обратной связи при проверке кода или тестировании истории. В общем случае минимум, что нужно сделать, это записать его для дальнейшего наблюдения.
Некоторые вещи все еще сложны или слишком гипотетичны, чтобы обсуждать их эффективно; в таком случае он обязательно упадет в забытые глубины отставания. Хорошо, если функция кажется нам очень важной, — материализовать ее с помощью прототипа, чтобы каждый мог судить о результатах, тем самым продвигая проект вперед. Оставить место в наших расписаниях, чтобы позволить себе некоторые исследования, — это хороший способ поэкспериментировать с нашими идеями, проиллюстрировать нашу точку зрения и провести интересные обсуждения в команде.
Такое активное поведение также ценится за пределами области разработки программного обеспечения. У очень хорошего менеджера, которого я встречал, была склонность делать что-то, когда это было необходимо. Проект застрял, потому что нам нужна была обратная связь от другой компании? Он позвонит им. Адаптер отсутствовал, когда встреча началась? Он будет тем, кто встанет и найдет его. Работать с ним было одно удовольствие, потому что он был деятелем. Мы все должны быть делателями, а не рассказчиками.
Если вы прочитали все статьи этой серии, то теперь вы готовы стать лидером и надежным, точным, дотошным и целеустремленным разработчиком. Я бы посоветовал продолжить чтение некоторых книг и статей ниже, чтобы усовершенствовать свои навыки.
продолжить чтение
Выпуск DOOM под лицензией GPL помог мне понять, что я всегда могу учиться и улучшать свои навыки. Взгляните на его ридми: https://github.com/id-Software/DOOM
Code Complete: Практическое руководство по созданию программного обеспечения, второе издание Стива МакКоннелла, обязательна к прочтению каждым разработчиком программного обеспечения. Он охватывает каждую часть построения программного обеспечения и подкрепляет свои утверждения цифрами и очень хорошими ссылками. Это простой способ повысить уровень наших навыков. Попросите вашу компанию купить его, купите его сами или найдите друга, у которого вы можете его одолжить, а затем прочитайте его.
Чистый код: руководство по Agile-программному мастерству, Роберт С. Мартин. Это отличная книга, на очень хороших примерах объясняющая, как писать код, чтобы наши читатели и мы сами легко его понимали. Он также предоставляет набор запахов кода, чтобы помочь определить, когда что-то идет не так.
Clean Coder: Кодекс поведения для профессиональных программистов, Роберт С. Мартин. Эта книга для человеческого взаимодействия — то же самое, что Чистый код для кода. На хорошо подобранных примерах он объясняет, как работать профессионально, и побуждать наших коллег делать то же самое.
Опасности кодирования будущего, Себастьян Сильван. Умное объяснение пагубных последствий предвосхищения потребностей. Очень хорошо написано.
Как нанимать сотрудников, Генри Уорд. Это очень интересная статья, в которой объясняется, как нанять хороших работников, и сравнивается прибыль от найма исполнителей и кассиров.
Кодеры-ковбои и культура программистов-героев, Ноэль Ллопис. Интересный взгляд на исторический интерес к героям в команде и объяснение, почему они нам больше не нужны.
Как стать лучшим разработчиком, Крис Рейнольдс. Напоминание о том, что мы можем учиться и совершенствовать свои навыки, практикуясь, встречаясь с умными людьми и проявляя скромность.
