Как да отглеждаме младши разработчици

Изминаха две години, откакто завърших Lighthouse Labs като младши разработчик на софтуер. В 8-седмичен интензивен участък ни казаха какво е програмиране, научихме Ruby и JavaScript езици, въведени в 3 или 4 рамки и настояхме да разработим собствен проект.

След това всички бяхме готови да започнем кариерата си. Щастливите за нас разработчици умения са с голямо търсене. За съжаление за нас, от този момент трябваше да възприемем проактивното обучение, как да се справим със синдрома на самодива и да се научим как да плуваме в морето на завършилите компютърни науки.

Миналия месец участвах в конференцията на Полиглот без конференция. Имаше поне две сесии, посветени на отглеждането на младши разработчици. Затова смятам, че е подходящо да споделя няколко неща, които са ми помогнали.

# 1 Специално време за настаняване

Като нов наем ме насърчиха да задавам въпроси. Но след месец-два да задавам въпроси, най-накрая почувствах, че трябва да знам. Да, мислех, че трябва да мога сам да намирам решения. Не исках вече да бъда бреме. Не исках да изглеждам глупаво, неинтелигентно или направо глупаво. В крайна сметка колко време може да отнеме да се научи ... А ?! Грешен.

Отнема толкова време, колкото е необходимо, за да се научите. А някои задачи са по-сложни от други.

В крайна сметка се озовах в кръг - вярвам, че мога да разреша проблема. Отнема ми завинаги. Стресиран съм. Старшите разработчици от друга страна не искат да управляват микроуправление, те знаят, че съм самостоятелно учащ се. И всички ние приключваме седмици с малък или никакъв напредък. (Или съм само аз?) Във всеки случай.

Решение: Ежеседмично (първоначално дори два пъти седмично) 30 минути проверка на проектите, за да обсъдим посоката, напредъка и затрудненията.

Вместо да тичам, за да задавам въпрос на всеки 30 минути, мога да отделя време за проучване и разбиране на проблема по-добре и събиране на моите въпроси. Получаването на 30 минути неразделно внимание е безценно. Отговарям на въпросите ми и научавам повече за организацията, свързвам се с ментора си. И всеки оставя среща, усещайки, че постигнахме напредък.

# 2 Рецензии на код

Кредит за изображение: Unsplash | @tirzavandijk

Едно е да кодирам функция, да поправя грешка и да я пускам на моята локална машина. Съвсем различно е да се ангажира нов код в производството.

Повечето компании използват преглед на код като инструмент за трансфер на знания, но колко от тях го използват като възможност за преподаване?

Винаги ще бъда благодарен на един от първите ми ментори, който ме накара да премина през процеса на преглед на кода на всеки парче код, който подадох като молба за изтегляне.

  1. Представете проблема - поставете всички на една и съща страница.
  2. Пуснете кода - покажете на всички, че работи.
  3. Преминете през решение с думи на миряни - демонстрирайте, че разбирате решението.
  4. Преминете през кода - покажете го в кода.

Този процес ме научи да мисля, преди да кодирам. Направи ме по-уверено да изразявам решенията си в техническо отношение. Обръщам повече внимание на четливостта на кода.

Принципите, изложени в Чистия кодекс, могат да бъдат установени и научени с тази практика. Ако има повече млади разработчици в екипа, предлагам да ги включите и в този процес.

# 3 Сесии за проектиране на решения

Едно от най-големите оплаквания, изразено на конференцията, беше неспособността на младшите разработчици да видят голямата картина. И честно казано никой не трябва да бъде много изненадан. Повечето от нас в началото са просто претоварени с проблема. Спомням си, че работех по първия проект, като се ужасявах дори да пипна кода, който някой друг написа.

Решение: Обсъдете потенциалното решение и архитектурата, преди да напишете кода. Бяла дъска. Какъв съществуващ код може да бъде адаптиран, какво мога да изградя, който може да се използва в бъдеще.

Това, което наистина работи за мен, беше, когато имах малко време да прототипирам решението и да изляза с предложението си, дори и по-късно да бъде изхвърлено. Това ми позволи да науча къде трябва да се подобря мисловния ми процес.

Намирам тази техника за изключително ценна. Чувствах, че не само пиша код и коригирам нечии грешки, но проектирам и създавам нещо ново и полезно за бъдещето. Изложи ме, за да видя по-голяма картина. Това е една от основните причини да вляза в разработката на софтуер - да проектирам решения.

# 4 Излагане на повече код

Първото нещо с всеки код е да се види как е направено преди и как е реализиран за решаване на подобни проблеми. Така че излагането на код изглежда е естествено предложение.

Но най-много ми помогна работа върху странични проекти. Пренаписване на код, който някой е написал и всъщност вижда как е разработен стъпка по стъпка.

В работна среда се опитвам да намеря функция в привидно различни части на платформата, само за да видя как мислят и кодират други разработчици.

# 5 Всеки се приковава на глупави грешки

Това е само напомняне, че никой от нас не може да спре да учи и само сътрудничеството и споделянето на знания могат да донесат развитие още повече.

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

Да искаме помощ е начинът да се разрастваме и никога не трябва да се срамуваме да потърсим помощ и да предложим помощ. И как баща ми го казва:

„Когато сте прекарали в проблем два часа (дни, седмици, месеци), не се разочаровайте, че не сте го направили за час (ден, седмица, месец). Бъдете щастливи, че не ви отне четири часа (дни, седмици, месеци) “
Благодаря на баща ми, който ми помогна неимоверно да направя първите си стъпки и ми показа колко интересно и полезно може да бъде развитието. Благодаря на Voleo, че взе шанс за мен като чисто нов завършил Lighthouse Labs. И всички бивши, настоящи и бъдещи учители. Вашето време и усилия не остават неоценени.