Як я можу стати більш автономним і самодостатнім програмістом? [зачинено]

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

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

Сприйняття часу
Розумні хлопці звикли вирішувати проблеми відносно швидко. Я пам’ятаю, як був пристрасний, коли мені довелося витратити годину на одну проблему з численням. Витратити 60 хвилин на проблему - це вже нічого. Ті дні закінчилися ... поховають їх і попрощаються. Складність та розмір більшості програмного забезпечення сьогодні надзвичайні. Люди не розуміють усіх інструментів, якими вони мають скористатися, щоб зробити справи довше. Дуглас Крокфорд, один із ключових людей мови JavaScript, сказав:

"Misapplication of standard tools...is the new standard."

У світі просто не вистачає часу, щоб вивчити всі інструменти розробки.

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

Так, це нормально. Я все ще вигадую з деякими речами, які мені кидають дорогу.

Що можна зробити?

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

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

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

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

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

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

Напевно, найкраща тактика була б:

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

Не бійтеся задавати питання "великої картини"

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

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

Дайте собі період очікування

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

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

Викиньте кілька чернеток

Сядь і відклади все, що тобі в голову, і тоді ти письменник. Але автор - той, хто може судити про власні речі, не жаліючи, і знищити більшість.
—Сідоні Габріель Колетт

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

Самодостатність прийшла б із собою

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

Часто задаючи питання, ви ризикуєте показати, що вам не вистачає обох цих питань.

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

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

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

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

1. Це щось, що ви можете з'ясувати за допомогою google / forums або довше працюючи над ним
2. Це щось, з чим ви можете піти чи виправити без особливих витрат, якщо зіпсуєте?

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

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

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

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

Отримавши технічні знання, решта - це мудрість та впевненість, і ті, хто має досвід.

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

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