Навчання бути хорошим розробником: які частини можна пропустити? [зачинено]

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

Я не починаю з нуля. Я написав багато html / css, SQL, javascript, python та VB.net, а також вивчав інші мови, такі як C та Java. Я знаю про такі речі, як OOP, структури дизайну, TDD, складність, обчислювальна лінгвістика, покажчики / посилання, функціональне програмування та інші наукові / теоретичні питання. Просто я не можу сказати, що я ще справді робив ці речі.

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

Я програміст з основними здібностями - які навички слід зосередити на розвитку?

(також мої навички Unix дуже слабкі, а також знання конфігурації Windows ... не впевнений, скільки часу я повинен витратити на це)

Це пропозиції, засновані не на тому, що я зробив, а на тому, що, на мою думку, мав би зробити заднім числом:

1. Пропустіть нові розкручені технології, оскільки більшість з них вийде з ладу. Створіть винятки для тих, у кого є ставка чи бізнес-план, але завжди маєте стратегію відмови (технології заміни).
2. Пропустіть, щоб стати експертом з кожної мови програмування та бібліотеки. Спробуйте стати експертом щодо порівняно небагатьох (семи) мов програмування та бібліотек, які платять за те, що ви хочете робити. З цього приводу ніколи не пропустіть можливість спробувати зрозуміти нюанси іншої мови програмування. Стати компетентним новою мовою та її стандартними бібліотеками потрібно близько двох місяців.
3. Пропускайте технології на одній платформі, коли є рішення.
4. Пропустити MS Windows. У ньому занадто багато пороків.
5. Пропустіть, щоб стати фахівцем, але вибірково дозвольте іншим думати, що це ви.
6. Пропустіть корпоративну вуду ("орієнтована на користувачів, архітектура компонентів підприємства"), якщо можете. Це нікуди не веде.
7. Пропустіть C ++ (дозвольте іншим займатися цим) і чекайте прив'язки Python.

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

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

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

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

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

Завантажте git, mercurial або базар і дізнайтеся, як створити сховище з ними (це просто мертво).

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

Після того, як ви закінчите писати додаток, позначте його. Це ваш V1. Отримайте ефективну роботу Майкла Пір’я зі спадщинним кодексом , принципами, моделями та практикою розробки програмного забезпечення Боба Мартіна та чистим кодексом , а також Ендрю Ханта та Прагматичного програміста Девіда Томаса . Не соромтеся читати їх у будь-якому порядку, навіть стрибати між ними. Багато ідей повторюється, але вони також зміцнять ваше розуміння, оскільки вони представлені з різних точок зору. (Ви, ймовірно, захочете взяти для довідки книгу шаблонів дизайну GoF )

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

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

В ідеалі, ви б мали наставника, який допоможе вам оцінити свій прогрес. Якщо ви зацікавлені, ви можете зв’язатися зі мною (firstinitiallastname у kharasoft dot net), і я допоможу вам скласти план та надати огляд.

Вітаємо з ініціативою для просування вашої кар’єри! Від цього виграє багато нагород.

Ви знаєте секрет хорошого розробника?

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

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

Намагання досягти неможливого призведе лише до тривоги, безсоння та втрати впевненості в собі.

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

1. Виберіть простий проект, який використовує навичку, яку ви хочете вивчити.

2. Виконайте це, орієнтуючись на цю навичку.

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

4. Що стосується того, що вам подобається, як вийшов проект, запитайте себе: "Це я думаю, що я міг би спеціалізуватися на тому, що мені б сподобалося, чи це пов'язано з чимось, на чому я міг би спеціалізуватися і сподобався б?"
   а. Якщо так, подумайте про інші навички, пов’язані з цією спеціалізацією, і запишіть їх.
   б. Якщо ні, погладьте себе по спині, відзначте це як щось, у чому ви хороші, і рухайтеся далі.

5. Щодо того, що вам не сподобалось у тому, як вийшов проект, запитайте себе: «Це я повинен знати, як це робити (або хочу знати, як це зробити), чи це аспект розвитку, який я міг би і хотів би залишати іншим взагалі? "
   а. Якщо ви вважаєте, що хочете чи знаєте, як це зробити, додайте його до списку, розпочатого на кроці 4a. б. Якщо ви думаєте, що можете залишити цей аспект іншим, зітхніть меланхолійно за свої межі як людської істоти, відзначте це як слабкість і рухайтеся далі.

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

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

8. Поверніться до кроку 2, використовуючи цей проект.

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

Я спеціалізувався на тестуванні та n-ярусних веб-додатках. Наступним моїм проектом буде практика TDD і, можливо, ASP .NET MVC 2. TDD - це посилити свої сили в тестуванні (я SDET, тому TDD просто дасть мені уявити про тестування одиниць, чим я зазвичай не займаюся, крім на моїх тестових інструментах), а також допомогти зі слабкою стороною хорошого дизайну (я сподіваюся), а MVC - це допомогти з моєю слабкістю в передньому дизайні. Мій список включає такі речі, як тестування продуктивності, веб-безпека та робота з веб-дизайнером для створення хорошого (і гарного) веб-сайту.

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

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

Я програмував протягом декількох років (з 7 років - зараз у мене в кінці 30-х).

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

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

І хоча написання вашої власної версії всього може бути інформативним - найкращі розробники, яких я знаю, майстри уникають написання коду ВИКЛЮЧЕНО для речей, які вони абсолютно повинні робити самі - тобто ядро ​​того, що є унікальним у їхньому проекті.

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

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

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

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

У той же час тестування і дотримання вимог бізнесу - і часом тестування покаже, що ви насправді повинні переписати якийсь код або написати його самостійно (часом ви можете зробити свій внесок у покращення проекту).

Це просто питання читання і вивчення матеріалів, коли це потрібно.

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

Спроба знайти біти для пропуску - це не найкраще ставлення.

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

Можливо, дотримуйтесь веб-розробок, на шкоду, наприклад, Windows Dev.

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

За один рік у вас, швидше за все, не буде завершено "кілька хороших додатків / сайтів / веб-сайтів", особливо на крутій кривій навчання. Єдине, чого навчишся, - це вигорання.

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

Наприклад, мене цікавить бейсбол фантазії. Протягом багатьох років я розробив багато речей, пов’язаних із цим, від скріплюючого екрана статтю, яка збирає робот, до веб-сайту, призначеного лише для HTML, до повного веб-додатка із масштабованою базою даних SQL Server, що подає його, до ... Моїм наступним проектом для домашніх тварин може бути додаток Silverlight у режимі реального часу, щоб хлопці могли сидіти за віртуальним столом, щоб робити проект.

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

Пропустіть трохи побоювання, на якій мові розпочати програмування.
Просто виберіть її та перейдіть.
Витратьте свій час, вивчаючи додаткові ресурси API.

Ось чому:

Що краще, XUL, SWT Eclipse або wxWindows? Не знаю. Всі вони такі величезні світи, що я не міг їх оцінити і розповісти. Мало читати навчальні посібники. Вам доведеться потіти і кровоточити річчю рік-два, перш ніж ви дійсно знаєте, що це досить добре або зрозуміти, що як би ви не старалися, ви не зможете зробити свій інтерфейс смаком як справжню їжу.

Джоел Спольський, "Лорд Палмерстон з програмування" http://www.joelonsoftware.com/articles/LordPalmerston.html

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

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

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

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

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

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

Я хотів би поділитися тут двома пунктами:

1. Мислення з точки зору алгоритму завжди допомогло б. Коли я починав роботу, я завжди думаю про реальні сценарії життя та поточні алгоритми, які стоять за ними, і завжди намагаюся їх оптимізувати.
2. Ніколи не кидайте навчання та розуміння нових речей / технологій, у комп’ютерах немає нічого подібного GURU, вам завжди потрібно продовжувати навчання, і вам доведеться сприймати цей факт наперед і продовжувати вчитися.

Не має значення, чим ти займаєшся, доки ти дотримуєшся цього і навчишся робити це добре .

Усі викладені вами ідеї - це добре знати, які допоможуть вам. Хто вас найбільше цікавить? Ви згадали, що ваші навички Unix слабкі. Чи обмірковували ви поставити Linux на комп’ютер? Знання C вже допомогло б, оскільки ви могли змочити ноги в програмуванні Unix-систем, не маючи додаткового стресу щодо вивчення нової мови. Це також може стати можливістю дізнатися про драйвери пристроїв, якщо це вас цікавить.

Я б дуже рекомендував навчальні збори та принципи функціонування в якийсь момент навчання вашого розробника. Обидва виявилися дуже корисними для мене в моїй "нормальній" ролі як програміста Java. Я дізнався Лісп і Пролог. Особисто я віддаю перевагу Ліспу, але це питання думки. Асамблея вчить думати про те, як комп'ютер бачить вашу програму, і я вважаю, що це важливо для кожного програміста. Функціональне програмування вчить думати більш детерміновано, що в моєму випадку допомогло мені написати більш тестований код, і це безпечно для потоків.

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

Перестаньте намагатися навчитися бути гідним розробником через рік. Навчіться бути хорошим розробником через 10 років.

Із пов'язаної статті:

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

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

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

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

Перестаньте хвилюватися і перейдіть до програми. : D

Я просто хотів би дати вам мої кроки натхненних читань та моїх найбільш переломних моментів досі.

У моїй кар'єрі з програмним забезпеченням було кілька моментів "WOW". Вони пішли так:

Head First Design Patterns - Це справді відкрило для мене світ OOP / OOD, абсолютний штапельний продукт.

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

Роберт К. Мартін - Agile Patterns and Practices - я зараз проживаю свою кар'єру кодування, що базується на цих принципах. Слово СОЛІД проходить через мій розум для кожного написаного кодом. Це в поєднанні з «Чистим кодом» на мене так сильно постраждало, що я переконав свого роботодавця в той час, щоб дозволити мені навчити його всій компанії близько 15 розробників. Я навіть не був старшим, хорошим у презентаціях, але мій ентузіазм змусив це відбутися.

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

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

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

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

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

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

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

Як пропонує Джефф О, якщо ви хочете бути хорошим програмістом, ви ніколи не кинете вчитися.

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

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

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

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

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

Зрештою, хороший розробник - це той, хто вміє підібрати те, що потрібно для виконання завдання.

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

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

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