Мої найбільші помилки на позиції Junior розробника

Переклад. Оригінал тут

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

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

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

Тим не менш, більшість моїх помилок були пов’язані не з написанням багів і тим, що проект не був завершений вчасно (і те, й інше зі мною, звісно, траплялося). Вони були, в першу чергу, викликані моїм страхом виглядати дурнем. Багато хто називає це “синдромом самозванця” (imposter syndrome). Мені було страшно визнати, що я не розумію ідею і концепт проекту, або ж не можу запам’ятати, як обходити дерево.

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

Я не ставив достатньо запитань

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

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

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

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

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

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

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

Я забагато стверджував

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

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

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

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

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

Я перестав писати код, не пов’язаний із робочим проектом\

Це те, де я втратив, на мою думку, більше всього. Замість того, щоб відточувати старі-добрі шматки коду, я повністю сфокусувався на коді проекту.

Зрозумійте мене правильно. Концентрація на коді і проекті роботодавця була (і досі є) важливою складовою успішного програміста. Тим не менш, я шкодую, що принаймні 2 години на тиждень я не присвячував написанню коду для open-source проекту чи завданням для LeetCode або TopCoder

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

Однак я не працював, до прикладу, з проектами, пов’язаними із graphics engines чи простими текстовими редакторами (і з багато чим іншим). Я не знаю, які складні для вирішення задачі мають подібні проекти, а я впевнений, що вони мають.

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

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

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

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

Сподіваюся, це допоможе вам на старті вашої кар’єру розробника..

… Декілька слів від перекладача:

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

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

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

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