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

Моє запитання: що найефективніше, що ви зробили, щоб покращити свої навички програмування? Що б ти порадив іншим, хто хоче вдосконалитись?

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

Без конкретного порядку ...

• Робота з людьми набагато розумнішою, ніж я

• Завжди слухайте, що мають сказати інші, незалежно від того, чи є вони молодшими, середніми, старшими чи гуру. назва роботи нічого не означає.

• Вивчайте інші рамки / мови та бачите, як вони роблять справи, і порівнюйте це з речами, які я вже знаю

• Читання про шаблони, кращі практики, а потім вивчення моїх старих речей та застосування цих моделей, де це необхідно

• Парне програмування

• Не погоджуючись з усім, що говорить Джоел. ;)

Вирішивши, щоб ТО був "торгом все торгів"

Досить на початку своєї кар’єри я був експертом з певною базою даних та мовою програмування. На жаль, саме ця база даних втратила "війни за бази даних", і я виявив, що варіанти кар'єри були ... обмеженими. Після цього я свідомо вирішив, що більше ніколи не дозволю собі стати таким боком. Тож я вивчив усе, на що я міг потрапити: Windows, Unix, C, C ++, Java, C #, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL та ін. Які б інструменти та технології не були новими чи незвичайними, я став "ідучи до хлопця" - "Запитайте Крейга, якщо він цього не знає, він дізнається це". У результаті я працював над різними проектами, від вбудованих систем екологічної телеметрії до систем управління та управління протиракетної оборони.

Єдина проблема, з якою я коли-небудь стикався, - це з компаніями, які наполягають на тому, щоб Підждон перетворив мене на спеціальність, коли моя спеціальність - це загальний професіонал. [РЕДАКТ: Також відомий як людина- полімат чи ренесанс або багатоспеціаліст. ]

Щось слід пам’ятати… який період напіввиведення знань у галузі високих технологій? Це відповідає Закону Мура: половина всього, що ви знаєте, буде застарілим через 18-24 місяці. Експерт, який вибирає неправильну дисципліну, може легко підірвати пресу технологій; генералісту залишається лише додати ще трохи навичок і запам'ятати уроки минулого в застосуванні цих навичок.

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

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

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

Найголовніше, що я дізнався від Аарона, - це ніколи не припиняти навчання.

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

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

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

Дві речі:

1. Прочитайте код, написаний різними людьми.
2. Напишіть документацію на код, написаний іншими людьми.

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

Регулярно відвідуйте спортзал.

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

Програмування. Робота над цікавими проектами. НІЧЕ НЕ, як зайти і працювати над речами. Особливо під тиском. Я завжди кажу всім, хто запитує мене, як програмувати - просто знайдіть класний проект (навіть якщо вам доведеться його скласти) і працюйте над ним.

Зайнята неповна робота з репетитором студентів у моєму університеті. Це дійсно змушує вас зрозуміти щось на зовсім іншому рівні, коли вам доведеться пояснити це комусь іншому.

1. Я великий прихильник системи "вивчайте одну мову програмування щороку". Один рік дає вам достатньо часу, щоб подолати "добре, я знаю синтаксис, тому тепер я знаю мову" упередження, і змушує вас піти трохи далі і зрозуміти, що вигідне в цій мові, і програмуйте в стилі, рідному для ця мова (під якою я маю на увазі, ви не закінчуєте писати програми Java, використовуючи синтаксис Ruby). Кожна мова змінить те, як ви думаєте про програмування - я знав, як використовувати рекурсію, але мислення в рекурсії не відбулося, поки я не взяв клас по прологу (я думаю, функціональна мова, як ML, мала б такий же ефект).

2. Почніть проект для домашніх тварин. Моє особисте рівняння для хорошого проекту з домашніми тваринами - це те, що у вас є досвід роботи з чимось, що ви не знаєте = додаток, яке ви вважаєте корисним. Наприклад, Migratr (мій власний проект, який триває з кофеїном, який триває) розпочався як "Я знаю c #, але я ніколи не кодував веб-API. І я хочу перенести всі свої фотографії в Zooomr". Це так само легко могло бути "Я кодувався проти веб-API раніше, але я не знаю C #"

Опублікування проекту вашого домашнього улюбленця - саме по собі дивовижний навчальний досвід. Раптом всі речі, практично нікого не вчать, але всі повинні знати (для мене це було налаштування власної системи тестування, отримання максимальної користі від систем контролю версій, як робити темп, коли ніхто інший не встановлює свої терміни, як взаємодіяти зі своїми Користувачі і як знати, коли сказати "ні", щоб подати запити), все, що наповнює бульбашки на поверхні, і змушує вас самоосвічуватися на рівні, на якому ви раніше не були, принаймні, не байдуже читаючи полум'я на dzone про плюси / мінуси способу "foo" vs "bar".

Виконання цих двох речей охоплює обидва кінці спектра. Вивчення нової мови зробить вас кращим кодером. Проект для домашніх тварин зробить вас кращим розробником: P

Навчив себе складання. Це було на старому чіпі 6502, коли мені було 13? 14? Занадто давно. Але я не можу придумати нічого, що поліпшить ваш розвиток більше, ніж опуститися на рівень біт.

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

У мікросхемі 65xx було три регістри (акумулятор, X і Y) і відсутні інструкції на рівні машини для множення або ділення. Я пам’ятаю, що кодував розпорядок обчислення бойової шкоди, переглядаючи книгу і раптом розуміючи, що мені доведеться написати власну математичну бібліотеку. Провів пару тижнів, переписуючи 1 та 0 по всьому моєму зошиту, намагаючись зрозуміти, що насправді означає "поділ" та "десяткові місця".

Я з тих пір вивчав C ++, pascal, .NET, багато інших ... але жоден з них не навчив мене так багато, заінтригував мене чи залишив у мене сенс "ух", що збірка на моєму старому комодорі зробила .

Озираючись на старі речі, я написав і зрозумів, наскільки вони погані.

Прочитайте

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

Просто розвивайте апетит до читання.

Програмування.

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

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

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

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

Багато людей запропонували написати код. Я б сказав, що читання коду інших людей набагато вигідніше.

Пара програмується з дуже різноманітними та самовпевненими людьми

Основні речі, які допомогли мені як програмісту:

• Навчений набір сенсорного тексту.
• Навчився долати сором’язливість і задавати питання.

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

І якщо ви не запитаєте, ніхто вам не скаже.

Внесок / участь у проектах з відкритим кодом був для мене найбільше.

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

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

2. Тест, тест, тест. Багато програмного забезпечення, яке я бачив у великих корпораціях, використовують тестові приклади. Чорт, вони використовують JUnit, xUnit та всі інші мови тестування модулів. Але проблема, яку я бачив, полягає в тому, що більшість програмістів ніколи не бачать, як виглядає їх програмне забезпечення у виробництві. Дізнайтеся, як користувачі (або системи, якщо це пакетні завдання) взаємодіють із вашим додатком, бібліотекою чи інтерфейсом, щоб дізнатися, яку неправдиву інформацію вони кидають на неї. Це допоможе вам створити хороші тестові випадки та перестати припускати, що ваша програма завжди подаватиме правильний набір даних.

Вивчена схема.

Написання коду та багато його.

Навчання регулярних виразів.

Змагається в конкурсах алгоритмів TopCoder .

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

Покиньте останню роботу.

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

Здається, що у мене було 2 або 3 рази, коли я вважав, що мій код ідеальний, то зрозумів, що мені належить пройти довгий шлях.

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

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

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

Тільки хто такі люди "вони" і де живуть "вони"?

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

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

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

Постійно навчайтесь і практикуйте те, що ви дізнаєтесь.

За допомогою:

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

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

Зазвичай це мій хронологічний порядок вивчення будь-якої нової технології:

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

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

3. Розгортайте іграшковий проект або два, використовуючи те, що я навчився. Я не переживаю за корисність проекту. Мій намір - просто використати моє навчання. (наприклад, проект калькулятора для ООП буде непоганий)

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

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

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