Не ставте програмістом "теоретика"

Я знайшов цю статтю в кількох дописах на SO. Я потрапляю в 6-й архетип; "Теоретик".

Він визначає "теоретика" як:

Теоретик знає все, що потрібно знати про програмування. Він або вона можуть провести чотири години, читаючи лекції про історію неясної мови програмування або надаючи доказ того, як написаний вами код є менш ніж ідеально оптимальним і може зайняти додаткові три наносекунди. Проблема в тому, що Теоретик нічого не знає про розробку програмного забезпечення. Коли Теоретик пише код, він настільки "елегантний", що прості смертні не можуть його зрозуміти. Його або її улюблена техніка - рекурсія, і кожен блок коду підганяється до максимуму, за рахунок своєчасності та читабельності.

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

Навіть працюючи над тим, що має бути простим проектом, я схильний заграти дону, намагаючись переробити все з нуля (це, мабуть, пояснює, чому я витрачав близько 2 років, намагаючись зробити операційну систему з нуля. Але навіть я бачив, що це зрештою було безглуздо).

Що може допомогти мені уникнути цього? І дотримуватися принципів KISS?

Спасибі

Будучи природою теоретиком, я можу сказати вам, що робота в магазині Agile швидко і рішуче вилікує всі подібні тенденції. Зокрема, операція програмування eXtreme з програмуванням пар (ідеально часто обертається), розробкою на основі тестування, боксу часу та обмеженими спринтами одразу відкладає вашу роботу для всіх колег і вимагає від вас відкрити та співпрацювати щохвилинна хвилина. Це величезний зсув від окремих завдань в ізольованих кабінетах, в яких процвітає робота в теоретичному стилі. Він вимагає повної чесності та повної доброчесності, оскільки всі постійно залежать від усіх інших.

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

1. Майте цілі на те, що ви маєте розвивати.

2. Звучіть ці цілі до чогось доставного найближчим часом.

3. Потім зосередьтеся на цих цілях, усуваючи всі інші міркування. Немає фону. Немає історії. Немає розширень. Нічого загального чи абстрактного.

4. Тоді звузити їх ще до того, що ти можеш зробити, що буде корисним. Не добре. Не гнучка. Не піддається ремонту. Просто прийнятний.

5. Тоді поставте пріоритет до абсолютного мінімуму, необхідного для досягнення найменшого, що ви можете зробити. Сенс полягає в тому, щоб вибрати дату приблизно за тиждень і побудувати до цієї дати. Якщо ви не можете щось доставити за тиждень. Вузький. Фокус. Обрізка. Зменшити.

6. Потім усуньте пух. У вас є лише тиждень. Продовжуйте різати.

7. Тоді зосередьтеся лише на скороченій реалізації, яка буде зроблена якомога раніше. В ідеалі менше тижня, тож у вас є час написати документацію.

Я працював з теоретиками. Я вважаю «додаткові» виправданням, щоб уникнути насправді робити щось, що може бути позначено як провал.

Робити - і не вдається - важко. Говорити про те, щоб зробити щось простіше, ніж щось робити. Багато досліджень і роздумів - це спосіб уникнути неправильної справи, а потім переробити її, дізнавшись, що користувачі брехали.

Просто поставте код перед ними. Вони назвуть код невдачею. Це буває. Але в процесі відмови ви дізнаєтесь, які реальні вимоги. І ти дізнаєшся, що брехали.

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

Я б грав на ваші сили, шукав можливості, де ваш стиль та уподобання є перевагою.

Для того, щоб ви залишалися продуктивними, хоч і балуєтесь написанням рамки MVC в Ерланге (або що вам здається цікавим), вам, можливо, слід приділити час вашій більш есстеричній роботі, скажімо, годину на день. Решту дня просто зосередьтеся на бурхливій роботі і виконайте роботу. Коли ви побачите щось цікаве, яке б відволікало вас на закладку або робило примітку, але рухаєтесь далі, тоді поверніться до неї у своєму виділеному часовому інтервалі.

Особисто я маю пачки URL-адрес, які вони виглядають цікавими, і купу бібліотечних книг теж. Можливо, я зрештою отримаю приблизно 10% цих URL-адрес, а, можливо, прочитаю 50% книг у підсумку, але я все одно працюю в день.

У мене сама була ця проблема. Дві методики допомогли:

1. Використовуйте техніку Pomodoro або іншу техніку управління часом, де ви встановлюєте послідовність дуже короткотермінових цілей. Коли вам доведеться з’ясувати, що ви можете досягти протягом наступних 25 хвилин, це робить вас зосередженим на корисній роботі.
2. Тест-орієнтований розвиток. Якщо вам доведеться написати конкретний тест, перш ніж писати будь-який код, це мінімізує мріяння. (Немає способу написати тест на "елегантний".) Після того, як ти щось налагодиш, ти можеш витратити більше часу, ніж тобі потрібно переробляти, але принаймні ти будеш працювати над реальним кодом, а не уявним ідеалом.

Не бийте себе занадто сильно. Легше змусити теоретика зосередитись і зробити корисну роботу, ніж зробити так, щоб люди, яким не байдуже, розширювати свій кругозір.

Уникайте stackoverflow.com . Не зрозумійте мене неправильно - я великий фанат - але ТА та інші форуми, орієнтовані на програмування, роблять ідеальним ворогом добра . Через деякий час ви можете почати відчувати, як тисячі розумних людей дивляться через ваше плече, і нічого, що ви пишете, недостатньо добре. Просто заробіть щось робочим і спробуйте зробити це зрозумілим. Ви завжди можете переглянути, якщо це потребує вдосконалення.

Також уникайте таких статей, як ця, яку ви пов’язали. Ви справді вірите, що існує десять типів програмістів? Або те, що хтось, кого ви знаєте, повністю вписується в одну з описаних категорій? Такі статті мають певну привабливість, оскільки містять трохи правди - ви можете побачити себе та / або своїх колег у деяких стереотипах. Але категорії містять стільки ж води, скільки астрологічних знаків. Спробуйте це наступного разу, коли ви потрапите на змішувач після конференції: "Привіт, я ковбой з кодом! Який тип?"

Це не означає, що ваше запитання недійсне - якщо ви передумуєте речі, добре дізнатися, як уникнути цієї тенденції. Але не дозволяйте, щоб ця розпуста наштовхнула вас на себе в голуб'яцтво.

Існує одна проста інструкція, яка, повністю розпакована, повністю пояснює, як уникнути цього сценарію.

Зробіть найпростішу річ, яка могла б спрацювати.

- Кент Бек

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

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

Простий:

1. Будьте прагматичними .

Протилежна сторона теоретика (яка має свої переваги щодо інформаційної / знання в області програмування) - прагматична.

Застосовувати KISS, DRY, SOC та інший спосіб мислення, як описано у цій відповіді , означає бути прагматичним.

Ви також можете навчитися бути прагматичним, прочитавши цю книгу:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Не забувайте, що теорія та практика працюють разом, не поодинці. Без багато практики, ти знання - це нічого. Без багато знань ви не зможете швидко покращити свою практику.

Отже, практикуйте багато. І багато чого вчити. Але не дозволяйте одному перебирати іншого.

У своїх проектах встановіть термін. Дотримуйтесь цього. Тоді подумайте прагматично про те, як закінчити свій проект до цього терміну. (читайте книгу, дійсно) Потім почніть кодування, почніть читати те, що вам потрібно знати, перейдіть від читання до кодування та обмеження чи вашого часу читання.

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

У мене був хлопець, який був настільки ж блискучим, як це може бути, але, як і ви, завжди доводилося видавлювати останній шматочок зі свого коду, навіть коли він працював чудово, навіть до того моменту, коли він почав писати власні елементи керування, які були по суті такі ж, як ті, які надає довкілля. Це все було дуже круто, але така трата часу, коли нам довелося вибирати речі вчасно. Часто ці побічні проекти підтримували команду, і, зрештою, він почав відчувати тиск з боку оточуючих, і він формувався. Я б запропонував почати працювати в командному середовищі з іншими хорошими розробниками, які повинні витіснити продукти. Завжди є час пізніше переробити і переробити речі або написати найзручніший MergeSort коли-небудь; але іноді вам доведеться донести товар до місця, де він працює, і доставити його клієнту.

Немає нічого поганого в тому, щоб бути «теоретиком» у звичному розумінні цього слова. Знання базових знань та вміння зрозуміти найновіші дослідження CS - це велика здатність, оскільки це золота мина хороших та оригінальних ідей.

"Справжнє запитання" тут більш очевидно в пізнішій половині поста. Знайте конкретну мету проекту та працюйте над цією метою, а не будь-якою іншою метою. Це справді лише питання самодисципліни в цьому випадку. Дивіться відповідь С. Лотта для більш детальної інформації про це :).

Переорієнтуйте свій розум на програмування та навіть налагодження речей до доставки робочого програмного забезпечення. Це визначає ваші пріоритети.

Як цього досягти - інша історія. Найкращий спосіб - задумати якийсь проект і пройти всі кроки, щоб запустити його у виробництво. Після цього у вас буде інший спосіб мислення, ніж раніше.

Дякую за цю посаду. Це робить мою роботу ще більше вартістю. Я відчуваю те саме, маючи освіту з інформаційної архітектури, працюючи розробником програмного забезпечення. Часто я опиняюся, що бореться з тим, "де щось змінити", а не "що змінити". Занадто багато стосунків, занадто багато розумних та загальних речей, що потрібно занадто багато часу, щоб дізнатися, як це працює.

Тож я починаю задавати питання, і ще більше запитань, поки не дізнаюся, ЯК і ДЕ це справді побудовано. І дозвольте сказати - це працює. Чим більше питань пожежі, тим менш важливим є збереження оригінальної архітектури та, нарешті, повернення до основ

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Попросіть свого начальника отримати наставника, а потім зробіть так, як каже наставник.

Важкою частиною є стриманість уваги, і визнання того, що "ей, давайте перепишемо операційну систему" не буде суттєво корисно для виконання завдання, яке вам було дано (саме тому менеджер проектів не зробить).

Також наставник перегляне ВСІ ваші конструкції перед кодуванням та фактичний код після кодування. Це допоможе вам зосередитись на тому, що потрібно зробити.

У мене така ж спокуса перестаратися над інженерними речами, і для того, щоб подолати це, потрібна самодисципліна та організація. Коли кодуємо ще когось, ось як це зробити:

1. Приступаючи до дискретного завдання, витратьте кілька хвилин на роздуми про те, що дійсно потрібно , як функціональність, якість, термін доставки тощо.
2. Знайдіть трохи більше часу, щоб спланувати, як це зробити , розбивши його на підзадачі, підзадачі тощо, враховуючи цілі клієнта коду.
3. Оцініть час кожного елемента , додавши до 50% для невідомих. Якщо предмет займе більше чотирьох годин, розбийте його ще трохи. (Якби я займався проектами коледжу, я би використовував електронну таблицю, але як консультант з декількома клієнтами я використовую систему відстеження проблем під назвою Redmine.)
4. Найголовніше: робіть лише ті речі, які я придумав .

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

Чим більше я це роблю, тим краще я отримую це. Самодисципліна - це розумовий м'яз, який зміцнюється вправою, і я також вдосконалююсь, оцінюючи, скільки часу займатимуть справи та робити технічні компроміси. І я вважаю корисним згадати цитату генерала Паттона: "Хороший план, який жорстоко виконується зараз, краще, ніж ідеальний план, виконаний на наступному тижні".

Як самотній розробник, мій робочий процес поєднує це з аспектами Agile, включаючи дошку Kanban. Я інколи виходжу на дотичні, але намагаюся обмежити відхилення кількома годинами на тиждень, і це працює досить добре.

Якщо ви плануєте працювати в приватній галузі, дуже важливо контролювати імпульс "теоретика". Найяскравіший програміст, якого я знаю, живе в Силіконовій долині, але не мав роботи протягом багатьох років, тому що він має таку репутацію за те, що надавати ідеальний код дуже пізно.