Нещодавно цей лист розійшовся нашої технічної команді. Я вирішив поділитися ним без редагування.
вирішення проблем - це головна послуга, яку ми надаємо. за роки я розробив деякі ідеї високого рівня про це, які, як я виявив, постійно призводять до хороших рішень, яких завжди багато. ви можете знайти ці ідеї корисними або ні, але я хочу поділитися ними в будь-якому випадку: - зрозуміти проблему повністю. якщо є хоча б невелика неясність, задавайте питання та копайте глибше. насправді, всі рішення проблем випливають з жорсткого застосування лише цього одного принципу. те одне маленьке слово, яке згадав клієнт або посібник, і ви соромилися запитати про нього - запитайте про це. той маленький рядок у коді, який ви не зовсім зрозуміли, ймовірно, є джерелом вашої проблеми, не ігноруйте його. - говоріть про проблему *вголос* з кимось іншим. дивовижно, як часто формулювання проблеми англійською мовою, поза розумовими конструкціями, автоматично підкаже рішення. - ніколи не налагоджуйте самотужки. купіть комусь каву чи пиво. зателефонуйте члену команди. це майже завжди марнотратство часу налагоджувати самотужки. наслідок: зупиніть те, чим займаєтеся, і допоможіть, якщо здається, що хтось інший застряг у проблемі. - коли є проблема, перевірте ці речі, в порядку, *кожного разу*: прочитайте код, прочитайте посібник, знайдіть у Google. це протилежне тому, що роблять більшість людей. іншими словами, "перевірте найвищі джерела якості першими", тому що низькоякісні джерела призводять до подальшої плутанини. я не можу сильно підкреслити важливість стати релігійним читачем коду. - ніколи не йдіть низькою дорогою. якщо ви думаєте "це хак, але...", зупиніться та запитайте про допомогу. - не боріться з майбутнім. рішення не має бути повним, але воно повинно хоча б зробити один крок до повноти. відстежуйте часткові рішення з #FIXME, #TODO, карткою в redmine або розмовою з колегою. - залишайте сліди. якщо ваша робота не створює артефактів, які люди можуть перевикористовувати або редагувати, це, ймовірно, пластир, а не рішення. створення редагованого коду набагато простіше, ніж створення повторно використовуваного коду. уникайте рішень, які не є ні тим, ні іншим, як чуми. - не сердіться. ваш мозок вимикається, якщо ви сердитесь на проблему. нічого з того, що ми робимо, не залежить від життя, тому розслабтеся. отже, ви викинули дані. посміхніться і поверніться до їх відновлення. - уникайте раннього впровадження, будучи раннім прихильником. спосіб зрозуміти золоту середину між кровоточащим краєм і крихкою стабільністю, іронічно, це безжально досліджувати та розуміти нові рішення. ви повинні бути раннім прихильником, щоб зрозуміти, коли його слід уникати. FUD (страх, невизначеність і сумнів) ніколи не повинен бути мотиватором для уникнення нового та блискучого, але глибоке розуміння технічних вад *повинно бути*.