Вдъхновен от бивш технически ръководител на Google
Софтуерните инженери прекарват много време в придобиване на умения за „интервюта чрез практикуване на проблеми с leet code“ и усъвършенстване на автобиографии.
След като най-накрая получат тази работа в стартиращ бизнес, Google, Amazon или друга корпорация, те може да открият, че уменията, които са използвали, за да получат работата, не съвпадат с тези, от които се нуждаят в ежедневната си работа.
Нашият екип беше вдъхновен от седемте умения на високоефективни програмисти, създадени от TechLead. Искахме да предоставим собствен поглед върху темата.
Ето нашите седем умения на ефективни програмисти.
1. Научете как да четете кода на други хора
Всички освен теб пишат ужасен код.
Ето защо страхотно умение, което има множество предимства, е да можеш да следваш кода на други хора.
Без значение колко объркан или зле обмислен е кодът на предишен инженер, все пак трябва да можете да преминете през него. В крайна сметка това е ваша работа. Дори когато този инженер беше ти една година преди това.
Това умение ви носи полза по два начина. Първо, възможността да четете кода на други хора е чудесен шанс да научите какво е лош дизайн. Докато преглеждате кода на други хора, научавате какво работи и какво не. По-важното е, че научавате какъв тип код е лесен за следване от друг инженер и кой е труден за следване.
Трябва да се уверите, че се хващате колкото е възможно повече, докато четете кода на други хора. По този начин другите инженери разбират колко превъзходен инженер сте.
Уверете се, че сте повдигнали точки относно важността на поддържаемия код и доброто коментиране. Това допълнително показва вашето господство в областта на програмирането.
Вашият код трябва да е толкова добре проектиран, че да не изисква документация. Всъщност не трябва да документирате нищо от кода си, ако сте добър програмист. Това е просто загуба на време и трябва да прекарвате времето си в кодиране и в срещи.
Възможността да четете объркания код на други хора също улеснява извършването на актуализации, когато е необходимо. Това от време на време означава актуализиране на код, в който нямате опит. Например, веднъж последвахме скрипт от Powershell до Python до Perl. Имахме ограничен опит в Perl, но все пак имахме достатъчно контекст, за да разберем какво се случва и да направим необходимите промени.
Това идва от прилично разбиране на целия код, както и от способността да четете Perl скриптовете.
Четенето на кода на други хора ви прави ценни, защото можете да следвате дори прекалено проектирани системи, които могат да спънат другите.
2. Чувство за лоши проекти
Има много умения, които отнемат време за усвояване. Едно от уменията, които смятаме, че си струва да знаем, е да разберем кои проекти не си струва да се правят и кои проекти очевидно са маршове на смъртта.
Големите компании винаги имат много повече проекти, отколкото вероятно някога ще бъдат завършени или въздействащи. Има някои проекти, които може да нямат бизнес смисъл (поне не и за вас), а има и други, които просто се управляват зле. Това не означава, че трябва да отрежете идея точно когато не сте съгласни с проекта. Въпреки това, ако заинтересованите страни не могат правилно да обяснят какво ще правят с крайния резултат, тогава може би проектът не си струва да се прави.
Освен това някои проекти може да са толкова фокусирани върху технологията вместо върху решението, че може да е ясно от самото начало, че няма да има голямо въздействие. Това умение изисква правенето на много лоши проекти, преди да имате представа какво всъщност е лош проект. Така че не отделяйте твърде много време рано, опитвайки се да различите всеки проект.
В даден момент от кариерата ви просто ще имате добър усет.
3. Избягване на срещи
Независимо дали сте софтуерен инженер или учен по данни, срещите са необходимост, защото трябва да можете да общувате с вашите ръководители на проекти, крайни потребители и клиенти. Съществува обаче и тенденция срещите внезапно да заемат целия ви график. Ето защо е важно да се научите как да избягвате ненужни срещи. Може би по-добрата дума за използване е управлявама не избягвам. Целта тук е да се уверите, че прекарвате времето си в срещи, които водят до решения и помагат на вашия екип да върви напред.
Най-често срещаният метод е просто да блокирате двучасов блок всеки ден, което е постоянна среща. Обикновено повечето хора ще организират повтаряща се среща във време, което намират за полезно. Те ще използват това като време, за да наваксат работата си по развитие.
Друг начин да избегнете срещите, за да можете да свършите работата, е да се появите преди някой друг. Лично ние обичаме да се появяваме рано, защото като цяло офисът е по-тих. Повечето хора, които се появяват рано, са като вас, просто искат да свършат работа, така че никой да не ви тормози.
Това е важно за индивидуалните сътрудници, защото нашата работа изисква моменти, в които се съсредоточаваме и не говорим с други хора. Да, има моменти, когато може да решавате проблеми, когато може да искате да работите с други хора. Но след като преодолеете проблемите с блокирането, просто трябва да кодирате. Става дума за навлизане в тази зона, в която постоянно държите много сложни идеи в главата си за работата, която вършите. Ако постоянно ви спират, може да ви е трудно да продължите оттам, откъдето сте спрели.
4. Github… Чакай, не Git?
Някои специалности по CS започнаха да използват Git в деня, в който се родиха. Те разбират всяка команда и параметър и могат да обикалят професионалисти.
Други получават първия си вкус от Git на първата си работа. За тях Git е адски пейзаж от объркващи команди и процеси. Те никога не са 100% сигурни какво правят (има причина измамните листове да са популярни).
Без значение каква система от хранилища използва вашата компания, системата е както полезна, ако я използвате правилно, така и пречка, ако се използва неправилно. Не е нужно много за просто натискане или ангажиране, за да се превърне в прекарване на часове в опити да разплетете някаква смесица от множество клони и разклонения. Освен това, ако постоянно забравяте да изтеглите най-новата версия на хранилището, вие също ще имате работа с конфликти на сливане, които никога не са забавни.
Ако трябва да запазите лист за измама на Git команда, направете го. Каквото и да прави живота ви по-лесен.
5. Писане на прост поддържаем код
Една тенденция, която може да имат по-младите инженери, е да се опитат да приложат всичко, което знаят, в едно решение. Съществува това желание да вземете вашето разбиране за обектно-ориентирано програмиране, структури от данни, модели на проектиране и нови технологии и да използвате всичко това във всеки код, който пишете. Вие създавате ненужна сложност, защото е толкова лесно да бъдете прекалено привързани към решение или модел на дизайн, който сте използвали в миналото.
Има баланс със сложни дизайнерски концепции и прост код. Моделите на проектиране и обектно-ориентираният дизайн трябва да опростят кода в голямата схема на нещата. Въпреки това, колкото повече и повече един процес е абстрахиран, капсулиран и поставен в черна кутия, толкова по-трудно може да бъде отстраняването на грешки.
6. Научете се да казвате „не“ и да давате приоритети
Това важи за всяка длъжност, независимо дали сте финансов анализатор или софтуерен инженер. Но по-специално, технологичните роли изглежда карат всеки да се нуждае от нещо от тях. Ако сте инженер по данни, вероятно ще бъдете помолен да направите нещо повече от просто разработване на тръбопроводи. Някои екипи ще се нуждаят от извлечения от данни, други ще се нуждаят от табла за управление, а трети ще се нуждаят от нови канали за своите специалисти по данни.
Даването на приоритет и казването „не“ може наистина да са две различни умения, но те са тясно преплетени. Приоритизирането означава, че отделяте само време, което има голямо въздействие върху компанията. Докато казването „не“ понякога просто означава избягване на работа, която трябва да се извършва от друг екип. Те често се случват в тандем за всички роли.
Това може да бъде трудно умение за придобиване, тъй като е изкушаващо да поемете всяка молба, която ви бъде отправена. Особено ако сте направо завършили колежа. Искате да избегнете разочарованието на никого и винаги са ви осигурявали изпълнимо количество работа.
В големите компании винаги има безкрайно много работа. Ключът е да се поеме само това, което може да се направи.
Има много умения, които не се тестват на интервюта или дори винаги се преподават в колежите. Често това е по-скоро ограничение на средата, отколкото липса на желание да се излагат учениците на проблеми, които съществуват в реални среди за разработка.
7. Оперативно дизайнерско мислене
Едно умение, което е трудно да се тества на интервю и трудно да се повтори, когато посещавате курсове в колежа, е да обмислите как краен потребител може да използва вашия софтуер неправилно. Обикновено наричаме това като обмисляне на оперативни сценарии.
Това обаче е просто учтив начин да кажете, че се опитвате да направите фиктивен код за доказване.
Например, тъй като голяма част от програмирането е поддръжка, това често означава промяна на код, който е силно заплетен с друг код. Дори една проста промяна изисква проследяване на всяка възможна препратка към обект, метод и/или API. В противен случай може да бъде лесно случайно да счупите модули, които не осъзнавате, че са прикачени. Дори ако просто променяте тип данни в база данни.
Също така включва обмисляне на крайни случаи и обмисляне на цялостен дизайн на високо ниво, преди да преминете към разработка.
Що се отнася до по-сложните случаи, когато разработвате нови модули или микроуслуги, важно е да отделите време и да обмислите оперативните сценарии на това, което изграждате. Помислете как може да се наложи бъдещите потребители да използват вашия нов модул, как биха могли да го използват неправилно, какви параметри може да са необходими и дали има различни начини, по които един бъдещ програмист може да се нуждае от вашия код.
Простото кодиране и програмиране е само част от проблема. Лесно е да създадете софтуер, който работи добре на вашия компютър. Но има много начини, по които внедряването на код може да се обърка. Веднъж в производство, е трудно да се каже как ще се използва кодът и какъв друг код ще бъде прикачен към вашия оригинален код. След пет години един бъдещ програмист може да се разочарова от ограниченията на вашия код.
Нашето вдъхновение
„Чудя се откъде получава всички тези различни напитки?“
Присъединете се към моя бюлетин
Преди да превъртате по-нататък, защо не се присъедините към моя бюлетин, за да сте в крак с новостите относно науката за данните, инженерството на данни и технологиите! „Научете повече тук“.
