Joel on Software

Joel on Software   Програм Джоеля

 

Інші статті "Joel on Software" українською

Інші статті "Joel on Software" англійською

Напишіть e-mail авторові (тільки англійською)

 

Вогонь та рух


Джоеля Сполскі
Перекладено Olexiy Oryeshko Олексій Орєшко
Відредаговано Maxym Mykhalchuk Максим Михальчук
6 січня 2002 року

Іноді я просто не можу нічого зробити.

Звичайно, я приходжу до офісу, вештаюсь навколо, щохвилини перевіряю пошту, лажу по Мережі, навіть можу вирішити кілька “проблем” на зразок оплати рахунків American Express. Але повернутися до написання коду ніяк не вдається.

Tetris

 Зазвичай подібні напади непродуктивності тривають день чи два. Проте в моїй кар’єрі розробника бували також і випадки, коли я тижнями поспіль ходив на роботу і не міг нічого зробити. Як-то кажуть, я не в потоці. Я не в зоні. Я ніде.

У кожного бувають зміни настрою, в одних людей ці зміни ледь помітні, в інших – сильніші, а декого вони просто виводять з ладу. Й, здається, між періодами непродуктивності та поганим настроєм існує деякий взаємозв’язок.

Ось тут я пригадую тих вчених, які стверджують, що люди принципово не здатні контролювати того, що вони їдять, а отже після тимчасової дієти людина завжди повернеться до своєї природньої ваги. Можливо я, як розробник, так само не можу контролювати свою ефективність, і потрібно лише спокійно сприймати чергування чорних смуг з білими й сподіватись на те, що моя підсумкова продуктивність задовольнить роботодавця.

 

Go read The Onion for a while.

 

Вже на першій роботі я зрозумів, що в середньому я продуктивно кодую дві чи три години на день, і цей факт досі не дає мені спокою. За часів моєї літньої практики в Microsoft один приятель сказав мені, що насправді він працює лише з дванадцятої до п’ятої вечора. П'ять годин, відніміть обід – і команда щиро кохала його, оскільки він все одно робив набагато більше за інших. Я дійшов того ж висновку. Я відчуваю себе трішки винним, коли дивлюсь на своїх колег. Здається, що вони викладаються на 100 відсотків, а я працюю протягом двох-трьох годин на день, і все ж я один з найпродуктивніших членів команди. Ймовірно саме через це, коли Peopleware та екстремальне програмування наполягають на забороні будь-якої понаднормової праці, та обмеженні робочого тижня рівно 40 годинами, вони цілком впевнені, що підсумковий результат не зменшиться.

Але насправді мене турбують зовсім не ті дні, коли я ефективно працюю “лише” дві години. Мене турбують ті дні, коли я не можу зробити зовсім нічого.

Я довго думав над цією проблемою. Я згадав часи, коли я працював найбільше в житті. Гадаю, це було тоді, коли Microsoft переселив мене в чудовий, розкішний офіс з величезними вікнами, що виходили на чарівне подвір'я, повне квітучих вишень. Все йшло, як по маслу! Я місяцями безупинно працював, перемелюючи специфікацію для Excel Basic – монументальний стос паперу, що перетворювався на неймовірні подробиці, окреслюючи гігантську об'єктну модель та середовище програмування. Я не зупинявся ні на мить. Коли я був змушений поїхати на виставку MacWorld до Бостона, я взяв з собою свій портативний комп’ютер, і документував клас Window, сидячи на мальовничій терасі Гарвардської школи бізнесу.

Якщо ти вже став до роботи, то зовсім не важко підтримувати цей стан. Чимало моїх днів проходять за приблизно наступною схемою: (1) прийти на роботу, (2) перевірити пошту, полазити Мережею, (3) вирішити, що не завадить спочатку пообідати, (4) повернутись з обіду, (5) перевірити пошту, полазити Мережею, (6) остаточно вирішити попрацювати, (7) перевірити пошту, полазити Мережею, (8) вирішити, що час працювати дійсно!!! настав, (9) запустити клятий редактор, та (10) неперервно кодувати, доки я не помічу, що вже пів-на-восьму.

Мені здається, що між пунктами 8 та 9 закралася помилка, тому що мені далеко не кожного разу вдається зробити цей крок. bike trip Моєю єдиною проблемою є лише почати працювати. Як відомо, нерухомий об’єкт намагається зберігати стан спокою. Є дещо неймовірно важке всередині моєї голови, річ, яку майже неможливо прискорити до бажаної швидкості, але якщо процес вже пішов, то підтримання руху не потребує жодних зусиль. Досить схоже на велосипед, облаштований для автономної подорожі через усю країну – неможливо повірити, наскільки важко зрушити з місця з цим причандаллям, але якщо ти таки рушив, то ніякого зайвого навантаження не відчуваєш.

Можливо, це і є ключ до продуктивності: просто почніть працювати. Можливо, в тих випадках, коли парне програмування працює, воно працює саме завдяки тому, що ви з товаришем просто примушуєте один одного починати кодувати.

Joel in the Army

Коли я служив Ізраїльським десантником, один генерал зупинився неподалік нас і прочитав невелику промову про стратегію. Для піхоти в бою, казав він, існує тільки один шлях – “Вогонь та Рух”. Ви постійно ведете вогонь, наближаючись до ворога. Ваш вогонь змушує його лежати долі, отже він не може стріляти у відповідь. (Саме це мають на увазі солдати, коли кричать “прикрий мене”. Це означає “давай, стріляй по ворогу так, щоб він лежав і не міг стріляти в мене, поки я буду перебігати цю вулицю”. Працює.) Просуваючись, ви захоплюєте територію й наближаєтесь до ворога, отже ваші постріли будуть частіше влучати в ціль. Якщо ви не будете рухатись, то ваш ворог почне контролювати перебіг подій, і це погано. Якщо ви не будете стріляти, то ворог притисне вас додолу своїм вогнем.

Я надовго запам’ятав ці слова. Я помітив, що всі різноманітні військові стратегії, від повітряних сутичок до маневрів цілих флотилій, базуються на принципі “Вогонь та Рух”. Наступні п’ятнадцять років я витратив на те, щоб усвідомити, що принцип “Вогонь та Рух” так само працює і в реальному житті. Ти маєш просуватись вперед потроху, але щоденно. Несуттєво, якщо твій код буде ламерським, з багатьма помилками та нікому не потрібним. Коли ти рухаєшся вперед, постійно виправляєш помилки й пишеш новий код – час працює на тебе. Стережись, якщо конкуренти ведуть вогонь в твоєму напрямку. Можливо, вони просто бажають примусити тебе гаяти час на прийом їх подач, та не давати рухатись вперед?

Згадаємо історію стратегій доступу до даних від Microsoft. ODBC, RDO, DAO, ADO, OLEDB, тепер ще й ADO.NET – Все Нове! Технологічна необхідність? Або наслідок дій некомпетентної команди проектування, якій необхідно щороку з нуля винаходити доступ до даних? (Дійсно, мабуть так воно і є). Але кінцевим результатом є звичайний вогонь для прикриття. Конкуренти не мають інших альтернатив, окрім як витрачати весь свій час на підтримку та переписування існуючого коду, замість того, щоб розширювати можливості своїх продуктів. Придивіться уважніше до ринку програмного забезпечення. Найкраще себе почувають фірми, які найменше залежать від великих компаній, і котрі ніколи не зациклюються на знаходженні та виправленні тих помилок, які з’являються тільки в Windows XP. Проблеми ж виникають саме у тих компаній, котрі ворожать на кавовій гущі, намагаючись передбачити щонайменший подих Microsoft. Таких людей турбує поява .NET, тому вони вважають за потрібне переписати всю свою архітектуру під .NEТ. Microsoft веде по вас вогонь, і це звичайний вогонь для прикриття, й вони можуть просуватись вперед, а ви – ні, такі правила гри, синку. Чи збираєтесь ви підтримувати Hailstorm? SOAP? RDF? Ви підтримуєте це тому, що ваші клієнти дійсно цього потребують, чи тому, що дехто веде по вас вогонь, і ви відчуваєте, що повинні відповідати? Відділи продаж великих компаній чудово розуміють тактику вогню для прикриття. Вони приходять до свого клієнта та кажуть: “Добре, ви не зобов’язані купувати цей продукт саме в нас. Купуйте в найкращого виробника. Але спершу переконайтеся, що їх продукт підтримує (XML / SOAP / CDE / J2EE), оскільки інакше ви будете “Замкнені в багажнику”. Коли ж невеликі компанії намагаються продати свій продукт подібному клієнту, єдине, що вони бачать – це зомбований керівник технічного відділу, який відмінно імітує папугу своїм “Чи підтримуєте ви J2EE?”. І ця невелика компанія витратить весь свій час, вбудовуючи підтримку для J2EE, навіть якщо це не додасть їм ані жодного клієнта, ані жодної можливості відзначитися. Просто для галочки – ви робите це виключно тому, що вам необхідна галочка навпроти цього пункту, але ніхто й ніколи не буде використовувати цю можливість. Саме так і працює вогонь для прикриття.

Вогонь та Рух для таких невеликих компаній, як моя, означає дві речі. Вам необхідно мати час на своєму боці і просуватися вперед щодня. Врешті решт ви переможете. Все, що я зробив вчора – це трішки поліпшив палітру кольорів у FogBUGZ. Нормально. Кожний день вона стає ще кращою. Щодня наші продукти стають дедалі кращими, й ми маємо все більше клієнтів. Допоки наша компанія не сягла розмірів Oracle, нас не цікавлять грандіозні стратегії. Ми повинні лише приходити на роботу кожного ранку та, якимось чином, запускати редактор.

It's getting better all the time... o/~


Ця стаття є перекладом з англійської статті Fire and Motion  

Джоель Сполскі є засновником Fog Creek Software, невеликої компанії у місті Нью-Йорку. Він закінчив Йєльський університет і працював програмістом та менеджером у Майкрософт(Microsoft), Віаком(Viacom) та Джуно(Juno).


Вміст цих сторінок відображає думки окремої людини.
Всі права захищені Copyright ©1999-2005 Joel Spolsky.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky