Переклад статті http://antirez.com/news/112
10-и кратний програміст, в міфології програмістів, це інженер, який може робити в 10 разів більше роботи ніж нормальний програміст, де в ролі “нормального” програміста ми уявляємо інженера, який добре робить свою роботу, але без міфічних можливостей які є у 10-и кратного програміста. Насправді, щоб краще охарактеризувати поняття “нормальний програміст” нам треба уявити середню продуктивність програмування із усіх програмістів, які є професіоналами в цьому напрямку.
Спільнота програмістів розділилася на два протилежних табори в питанні існування такого “звіра” в природі: одні говорять що не існує такого поняття як 10-и кратний програміст, інші говорять, що вони не просто існують, а навіть можна знайти 100 кратних програмістів, якщо знати де шукати.
Якщо ви розглядаєте програмування як “прямолінійну” роботу то стає зрозуміло, що існування 10-и кратних програмістів виглядає ірраціональним. Як легкоатлет може бігти в 10 разів швидше ніж інші? Або будівельник, будує в 10-ть разів більше ніж інший може побудувати за той же час? В будь-якому випадку програмування це творча робота і дуже своєрідна. Навіть якщо програміст не бере участі в плануванні основної архітектури програми, йому все одно треба планувати архітектуру реалізації складових частин.
Тож якщо дизайн і реалізація програми це не лінійна величини, то такі речі як досвід, вміння писати код, широкий кругозір, вміння розпізнати слабкі місця, на мою думку, також не можна рахувати лінійними і коли ці вміння працюють разом, вони можуть в декілька разів вплинути на строки створення програми. Звичайно цей феномен частіше трапляється коли програміст може контролювати, як архітектуру всього проекту так і її реалізацію. Більше орієнтовані на результат, 10-и кратні програмісти можуть розраховувати свої можливості для того, щоб досягнути цілі з набагато меншим використанням своїх сил. Коли задача поставлена більш жорстко, із специфічними вимогами про те, які інструменти використовувати і що як робити тоді можливості 10-и кратного програміста зробити багато роботи за малий час дещо слабшають; він все ще може використовувати свої таланти, для того щоб оптимально і якісно робити локальні задачі, але вже не може зробити все по своєму і краще, щоб досягнути мети і йти своїм шляхом, який, можливо відкинув деякі архітектурні рішення із проекту і в результаті ми отримали б те що треба, але зроблене іншим шляхом із витратою набагато менших зусиль.
Працюючи програмістом на протязі 20 років я міг спостерігати за роботою моїх колег, які працювали поряд, яких я направляв на шлях для досягнення цілі, яким пропонував патчі для Redis та працював в інших проектах. В той же час, багато людей говорили мені що вважають мене дуже продуктивним програмістом. Зважаючи на те, що сам я себе не вважаю трудоголіком я примушував себе програмувати речі швидко.
Нижче список якостей, які на мою думку, найбільше впливають на продуктивність програмістів.
Відверта якість програмування: всі підзадачі треба зробити
Однією з очевидних, або сильних сторін програміста – це розібратися із підзадачам при роботі над якоюсь частиною проекту, це може бути функція, алгоритм чи будь яка інша частина. Вміння ефективно використовувати базові конструкції програмування дуже корисне при розробці, але з мого досвіду не так широко розповсюджене, як повинно було. В команді я іноді спостерігав дуже некомпетентних програмістів, які не знали навіть простого алгоритму сортування і які робили багато роботи, з іншого боку програмісти із профільною освітою, дуже добре знали теорію, але не могли використати її на практиці.
Досвід: порівняння шаблонів
Під досвідом я розумію набір вже вивчених рішень для однотипних задач. Досвідчений програміст знає зазвичай, як упоратися із різноманітними підзадачами. Це дозволяє уникнути багато зайвої роботи, але особливо, є надзвичайно потужною зброєю у боротьбі з помилками архітектури, які в свою чергу є великими ворогами простоти.
Концентрація: реальний час проти запланованого часу
Час витрачений на написання коду непоказовий, якщо не дивитися на якість витраченого часу. Втрата фокусу може бути наслідком як внутрішніх так і зовнішніх чинників. Внутрішні фактори: прокрастинація, відсутність інтересу до поточного проекту (ви не можете робити добре те, що ви не любите), відсутність здоров’я чи сімейного благополуччя, відсутній або поганий сон. Зовнішні фактори: часті наради, погані умови в офісі, колеги, які часто відривають від роботи і так далі. Це видається природним якщо збільшити концентрацію і зменшити відволікаючі моменти то це не магічним чином збільшить вашу продуктивність як програміста. Іноді, для того щоб збільшити концентрацію необхідні крайні заходи. Наприклад я читаю листи лише час від часу і не відповідаю на більшість з них.
Принесення в жертву архітектури: вбити 5% щоб отримати 90%
Дуже часто складність в проекті з’являється коли немає бажання розібратися що другорядні задачі в проекті створюють у сумі зайву складність архітектури, або досягнення більш важливих цілей ускладнене неправильною архітектурою проекту, яка спирається як на важливі частини, так і намагається врахувати зайві. Це дуже важливо для архітектора розпізнати всі частини проекту і виділити ті задачі досягнення яких не відповідає витраченим на них зусиллям. Проект, який націлений на результат, зосередиться лише на тих частинах, які найбільш важливі і які принесуть максимальний результат за розумний час. Наприклад розробляючи архітектуру Disque, менеджер черги повідомлень, в якийсь момент я зрозумів, що реалізувавши негарантовану доставку для повідомлень, всі інші аспекти проекту суттєво покращаться: доступність, мова запитів і взаємодія із клієнтами, простота і швидкість.
Простота
Це очевидна думка, яка означає все і нічого одночасно. Щоб зрозуміти, що таке простота, краще за все перевірити як з’являються складні речі. Я впевнений, що є дві головні причини появи складності, по-перше це не бажання розібратися в архітектурі проекту і викинути зайві частини, по-друге це накопичення помилок в реалізації.
Якщо ви думаєте, що створення архітектури ви кожного разу будете вибирати не оптимальне рішення ми кожного разу будемо віддалятися від найкращого рішення. Якщо, при виявленні помилки в архітектурі, ви не будете її змінювати, тоді ви будете створювати “костилі”, щоб обходити ваші помилки. Проект, таким чином, буде ставати складнішим і менш ефективним з кожним неправильним кроком.
Шлях простоти може бути досягнутим, шляхом створення маленьких концептів для перевірки ідей, і тоді велика кількість перевірених простих рішень може бути вивчена і запам’ятована програмістом, і тоді починаючи працювати, програміст вибирає прості і перевірені рішення. Пізніше, досвід і власні архітектурні навички дозволять вдосконалювати будову проектів і їх частин.
В будь-якому разі коли потрібне складне рішення, важливо розуміти причину цього і розглядати в далекій перспективі, як можна позбавитися складного рішення і вибрати кращий спосіб або вибрати інші альтернативні методи.
Перфекціонізм або як убити вашу продуктивність і упередженість вашого дизайну
Перфекціонізм приходить у двох видах: з інженерної культури по досягненню найкращих результатів, які можна виміряти в програмі і як досягнення особистого задоволення від досягнутого результату. У обох випадках, я вважаю це найбільшим бар‘єром для програмістів швидше показувати результати. Перфекціонізм і страх бути осудженим колегами додає в архітектуру проектів зайві частини що у підсумку призведе проект до гіршого результату, тому що страх буде впливати на архітектуру і буде намагатися досягти лише тривіальних числових показників потужності, а такі насправді важливі речі, як: надійність, простота або можливість вирішити задачі вчасно ніколи не будуть досягнуті.
Знання: теорія яка допомагає
Коли маєш справу із складними задачами, то знання про структури даних, фундаментальні обчислювальні обмеження техніки, не тривіальні алгоритми які дуже підходящі для специфічних задач скоріше всього допомагають знайти підходяще рішення архітектурне рішення задачі. Бути експертом з усього не потрібно але бути обізнаним у значній кількості потенційно підходящих варіантів вирішення проблеми все ж потрібно.
Низький рівень: розуміння як працює залізо
Велика кількість помилок, навіть коли ви використовуєте мову програмування високого рівня, з’являється по причині нерозуміння того, як комп’ютер буде виконувати поставлену задачу. Із таких проблем може витікати повна зміна архітектури програми з нуля, тому що фундаментальні проблеми у використаних інструментах або алгоритмах не дозволять досягти цілі проекту. Добре розуміння мови програмування C, знання про те, як працює процесор, як ядро обробляє команди і як працюють системні виклики може зберегти вас від багатьох проблем в кінці.
Вміння дебажити
Дуже просто витратити велику кількість часу у пошуках незначної помилки в коді. Вміння добре розбиратися з багами накопичується поступово із виправленням багів, які ви знаходите проходячи програму крок за кроком і також написання простого коду який не може мати складних багів, все це разом чудово підвищує ефективність програміста.
Дивлячись на всі перераховані якості я легко можу уявити, що на виході результат може відрізнятися в 10-ки разів. Зібрані всі разом ці якості дозволяють реалізувати архітектуру програми, яка побудована на життєздатній моделі і може бути в декілька раз простішим за альтернативні реалізації. Існує спосіб екстремального спрощення, який я називаю “авантюристським програмуванням”. В основному на кожному етапі програмування вибирається функції для реалізації, які найбільше впливають на базу користувачів і з найменьшими зусиллями.