Топ 5 урока от работата ми като (Junior) софтуерен инженер
Реших да споделя най-важните уроци, които научих през първите ми 2 години работа като софтуерен инженер. Не са подредени по важност, а са в хронологичен ред (започвайки от първите ми дни на работа и стигайки до ден днешен).
Аз самият съм Java Web Developer (като в последно време повече ползвам Kotlin), но всъщност уроците тук не са чак толкова технически, а са по-скоро свързани с това как да мислиш и да се държиш, ако искаш на работа да максимизираш положителните емоции и да минимизираш отрицателните. 😅
Защо си заслужава прочитането? Ами, ако си Junior, мисля, че малко ще улесниш началото в кариерата ти. Ако си Mid/Senior, ще си спомниш някои от основите, които е лесно да забравиш, когато вече си напреднал и фокусът ти е насочен към други неща. А ако въобще не си developer, може да забележиш, че голяма част от написаното всъщност може да бъде приложено и в твоята собствена сфера на работа (тъй като голяма част от тези уроци според мен са универсално полезни). 👀
И така, ето уроците….
—
1. Очаквай да си объркан в началото и се довери на процеса (няма как да се провалиш, ако просто продължаваш да ОПИТВАШ).
В началото ще си объркан и уплашен, но това е НОРМАЛНО и е важно да не го забравяш!
Общо взето в началото всичко ще ти е ново, неизвестно, плашещо, объркващо и всичките нови неща може да ти дойдат твърде много наведнъж. Освен това вероятно ще те е страх от това да не допуснеш някоя тъпа грешка, заради която да те уволнят (😅), ще си твърде учтив и внимателен за всичко, няма да можеш да бъдеш напълно себе си (ще си притеснен и ще се филтрираш), няма да искаш да поемаш рискове и т.н.
Това е нормално. Ключът е да третираш всичко това като нещо временно, което скоро ще отмине и е просто част от процеса. Може да звучи просто, но ако просто разбираш, че всичко това е нормално и че много хора се сблъскват със същото, ще си по-спокоен и ще ти е по-лесно да изтърпиш този труден период в началото.
Ако просто продължаваш да се ОПИТВАШ, с времето ще свикнеш и нещата ще започнат да се подреждат в главата ти. Замисли се за следното: ако се упражняваш в нещо отново и отново, ден след ден, какъв е шансът да се провалиш (при условие, че се учиш от грешките си)? Почти невъзможно е (рано или късно ще схванеш каквото трябва да схванеш). Рано или късно всичко започва да придобива смисъл в главата ти (представи си го като Рубик кубче, което с времето се подрежда). Рано или късно свикваш с работата и не изпитваш силни емоции от това, което правиш (работата се превръща в навик за теб).
Ако гледаш на нещата по този начин, ще минимизираш страха и напрежението, които изпитваш при започване на първата ти работа. Ще знаеш, че успехът ти е въпрос на ВРЕМЕ и ФОКУСИРАН ТРУД (а не на нещо произволно, което е извън твоя контрол), а затова ще се чувстваш по-спокоен и няма да се чувстваш сякаш не правиш нещо както трябва или сякаш има нещо сбъркано с теб.
—
Обаче е важно да не се хващаш с ТВЪРДЕ МНОГО НАВЕДНЪЖ, защото това ще те парализира психически! В оптималния случай ще навлезеш в нещата ПОСТЕПЕННО (и ако си в добра фирма, хората там ще са се погрижили процесът ти на “onboarding” да протече точно така).
Например в началото аз минах през подготвителен проект, който ми показа какво бих правил в истински проект, а това значително намали напрежението, което изпитвах, когато започнах работа по истинския. Освен това имах колеги, които ми помагаха, когато се чувствах загубен в огромния code base, в който трябваше да се потопя след подготовката, и когато не знаех кое какво е и ме беше страх да не допусна някоя сериозна грешка. Това беше МНОГО полезно. Не елиминира напрежението напълно, но значително го намали.
Все пак ако нямаш такова нещо на разположение, според мен трябва в началото сам да си поставиш за ОСНОВНА ЗАДАЧА това да разделиш проекта, по който работиш, на малки смилаеми части. Например си казваш “ОК, днес ще прочета ей тази част от кода и документацията. След това ще продължа по ей тази част…” и повтаряш този процес отново и отново, докато не придобиеш някаква обща представа за това, с което се бориш.
—
Мисля, че тези идеи могат да бъдат приложени в който и да е стадий от кариерата ти (а не само в началото й).
Да, може да свикнеш с която и да е технология, който и да е инструмент, процес на работа и т.н. Просто продължавай да използваш нещото и имай сляпа вяра, че мозъкът ти ще се справи с задачата, която си му поставил: рано или късно ще разбереш нещата.
Всъщност аз сега прилагам същите принципи и за други неща свързани с програмирането, които преди ми се струваха невъзможни (например разбирането на някои по-сложни алгоритми). Просто продължавай да се опитваш и постепенно ще схванеш каквото трябва.
2. Работата в екип не е толковa лоша. Можеш да се научиш да работиш в екип и дори да ти харесва (а това всъщност ще те направи по-добър както в работата ти, така и в живота като цяло).
Отново, в началото всичко ти идва много наведнъж и е леко плашещо. Защо? Поради редица причини…
Първо се запознаваш с много хора наведнъж (например на първия ми работен ден в “истински проект” трябваше да се запозная с 15–20 човека на Daily-то, защото тогава бяхме голям екип 😅). Трябва да запомниш имената на всички и по възможност да запомниш всеки с какво се занимава. Трябва и да се представиш пред всички. За някои хора това не е кой знае какво, но за мен беше доста стресиращо.
Освен това се чувстваш сякаш всеки друг знае повече от теб и e по-добър програмист от теб. Усещането е все едно всеки е там от години и е наясно с всичко, а ти си паднал от друга планета и просто не си за това място. До голяма степен това е илюзия, но все пак вътрешно пак няма да ти е комфортно в началото.
Също така най-вероятно ще те е страх да попиташ за помощ, защото не искаш да изглеждаш некомпетентен и не искаш да губиш времето на другите. Понякога пък не знаеш КОГО да питаш. Понякога ти отговарят бавно или неясно. Понякога пък въобще НЯМА кого да питаш в момента.
Отделно изпитваш напрежение и да започнеш да допринасяш стойност към проекта, защото не искаш да изглеждаш като мързеливец, който не прави нищо, или сякаш си някой, който се учи супер бавно и му трябват месеци само за onboarding. Още повече напрежение изпитваш, ако някой те чака да завършиш някоя задача (най-вече ако му е нужно да я приключиш, за да може да продължи напред със своята задача).
—
Обаче, отново, с времето свикваш с работата в екип и ти става по-спокойно отвътре (а и ти харесва повече да работиш така). Защо?
Първо научаваш, че като цяло повечето хора са толерантни и търпеливи, когато става дума за някой, който тепърва започва работа. Това е така, защото всеки един е бил в твоята позиция в миналото и знае, че началото е трудно.
Научаваш също, че дори и по-опитните хора не знаят всичко (в проекта, а и в софтуерното инженерство като цяло). В “реалните” проекти обикновено всичко е доста динамично и нещата постоянно се променят. Дори и да си опитен, няма как да знаеш всичко.
Постепенно научаваш, че да питаш за помощ не е толкова лошо и често може да ти спести много време и главоболия (вместо 5 дена да си блъскаш главата в стената и да се чудиш “Как да направя това, мамка му!?”, можеш да отделиш 5 минути, за да попиташ “Как да направя това?”, а след това да получиш отговор и да продължиш напред. Във връзка с това, един често срещан въпрос е “КОГА да попитам за помощ?”. Моето правило е следното: първо влагам някакви усилия, за да се справя сам, а когато отвътре се почувствам сякаш НАИСТИНА съм се опитал (т.е. отнесъл съм се сериозно към задачата и съм направил каквото мога), но все още не се получава, то тогава отивам да търся помощ (без значение за какъв проблем става въпрос). Като една леко странична бележка, това мисля, че е и най-добрият подход, ако искаш да получиш помощ от хора по форуми за програмиране и сайтове като StackOverflow (хората ще са много по-склонни да ти помогнат, ако видят, че вече си вложил някакви усилия преди това, а не просто чакаш някой да ти свърши работата, защото си мързел).
Също започваш да се приспособяваш към начина на работа на екипа ти. Свикваш с методологията, различните срещи (team meetings), стилът на комуникация, темпото на работа, постигането на синхрон (особено важно, когато заедно с някого работите по една и съща функционалност) и така нататък.
Става ти и по-комфортно да изразяваш мнение, да поемаш повече рискове в работата и др.
Справянето с работата в екип е непрекъснат процес. Ще продължиш да допускаш грешки в това, но с времето и практиката ще станеш по-добър.
—
Какво трябва да направиш от практическа гледна точка? Отново просто трябва да се довериш на процеса (да имаш сляпа вяра, че с времето работата в екип ще ти стане по-лесна).
Освен това може да пробваш да добавиш и “социални предизвикателства”. Това може да звучи тъпо или странно, но за мен беше доста полезно. Тъй като ми беше трудно да изразявам мнение в различни срещи, да искам помощ и като цяло да съм този, който се свърза с друг колега, за да иска нещо от него, започнах да си поставям малки предизвикателства, чрез които да свикна с тази част от процеса на работа. Например си поставих предизвикателството поне 1 път да изразя мнение по някакъв въпрос в дадена среща. Или пък да питам поне 1 път за нещо, което не ми е ясно. Така, малко по малко и стъпка по стъпка, стана по-естествено да се свързвам с колеги за различни неща (тъй като си доказах, че не е чак толкова лошо).
—
Работата в екип ти помага да развиеш някои умения, които намират приложение както в работата, така и в живота като цяло.
Първо: научаваш се да се сближаваш с хората. Особено ако си интроверт като мен (доста често срещано при програмистите като цяло), е доста вероятно да си свикнал да си правиш всичко сам. Може би това не е задължително лошо нещо, но все пак след известно време става малко скучно и самотно, ако правиш абсолютно ВСИЧКО сам. Работейки с други хора, правиш работата и живота си малко по-забавни и вълнуващи, а дори и по-лесни (ако познаваш и харесваш хората от екипа ти, очевидно работата с тях става по-лесна и приятна). Да, разбира се, че понякога не е точно така (понякога просто не се разбираш с хората от екипа ти), но дори и в този случай поне имаш възможността да се упражняваш в комуникацията с такива “трудни” хора.
А как става това сближаване на практика? Мисля, че неформалните срещи са добър начин. Например периодично имахме някои срещи като “team lunch” или “coffee break”, в които просто си говорехме за произволни неща. Тези срещи не бяха задължителни, но аз исках да присъствам, защото ми дадоха възможност да опозная другите от екипа като ХОРА (а не само като програмисти, product owner-и и така нататък). Също се стараех да присъствам и на всички team buildings, поради същата причина. А ако имаш тази възможност, мисля, че най-добрият начин всъщност е да ходиш до офиса по-често. Аз лично не съм го правил много (твърде много ми харесва да работя от вкъщи 😅), но все пак забелязвам, че хората, които го правят, получават някои ползи, които аз не: по-популярни са, имат повече приятели на работа и т.н.
Второ: научаваш се да не се привързваш твърде много към хората, с които работиш (и свикваш с промяната като цяло). В живота всичко е временно (включително и самият живот 😅), а работата с други хора ти напомня този факт отново и отново. Не знам защо, но когато започнах работа, си мислех, че с хората, с които работя тогава, ще бъдат същите хора, с които ще работя и години по-късно. Обаче всъщност какво става? Хората идват и си отиват: сменят проекти, работа… като цяло просто следват собствените си интереси (а така и трябва, разбира се). Промяната е неизбежна и трябва да свикнеш с това (и да можеш да се адаптираш), а чрез работата в екип научаваш този урок отново и отново.
Трето: ставаш по-добър професионалист. По-конкретно:
- Научаваш се да правиш компромиси и да разбираш гледната точка на другите (както гласи книгата “The 7 Habits of Highly Effective People” на Stephen Covey -> “Seek first to understand, then to be understood.”)
- Научаваш се да бъдеш по-добър учител и лидер (например поемайки ролята на ментор, вземайки решения в проекта и т.н.)
- Научаваш се да се справяш с кода на другите (например в pair programming сесии; когато правиш pull request ревюта и т.н.)
3. Стреми се да правиш всичко максимално КАЧЕСТВЕНО!
Може и да ти се размине това да правиш само минимума на работа, но НЕ Е В ТВОЙ ИНТЕРЕС! Има един цитат, който гласи “Начинът, по който правиш едно нещо, е начинът, по който правиш ВСИЧКО!”. Тоест ако свикнеш “да си оставяш ръцете” на работа, ще започнеш да го правиш и във всичко друго, с което се захванеш. Важно е да осъзнаеш, че влагането на минимални усилия е рецепта за посредственост (и ако искаш повече от посредствени резултати, ще трябва да вложиш повече усилия от посредствения човек). Това като цяло е моята “философия за успех” (която научих от света на личностното развитие).
Дори и не всеки път хората да оценяват труда ти, пак се стреми да дадеш най-доброто от себе си, защото в дългосрочен план това е в твоя полза! С времето ще се превърнеш в един от най-ценните разработчици в екипа ти, без значение къде допринасяш (без значение в кой проект и в коя фирма). Защо? Защото повечето хора са мързеливи и правят само минимума (това е в човешката природа), така че ако ти вложиш само малко повечко усилия от другите, ще ти е лесно да изпъкнеш по положителен начин.
Каквото и да правиш, опитай се да го направиш ДОБРЕ.
Например от гледна точка на КОДА, който пишеш, това означава да пишеш КАЧЕСТВЕН код: прост, четим (разбираем), лесен за поддръжка, добре документиран и така нататък (общо взето код, който следва принципите от книги като “Clean Code” и “Code Complete”). Не прави само минимума (например да оставиш неформатиран код, да използваш неясни имена на променливите ти, да няма документация, няма тестове и т.н.).
Ако пък правиш ПРЕЗЕНТАЦИЯ (или пишеш блог пост 😅), прави я като на първо място мислиш за АУДИТОРИЯТА си (това, което ще е полезно на хората, които ще те слушат). Например направи презентацията проста, забавна, разбираема, релевантна, накрая дай линкове към самата презентация или записа й. Не прави само минимума (например да представяш по скучен начин; да говориш с предположението, че всички разбират терминологията, която използваш; слайдовете ти да са само стени от текст и т.н.).
А ако пък пишеш ДОКУМЕНТАЦИЯ (на кода, който пишеш; при създаване на Jira ticket; при описване на нещо в Confluence и др.), недей да пишеш само нещо “колкото да има там” и което е твърде неясно и само ти си го разбираш. Напиши го достатъчно ясно и подробно (все едно ще го чете някой, който все още няма никакво понятие за това, което документираш).
Когато създаваш PULL REQUESTS: не го прави набързичко, колкото да ти се махне от главата. Първо бъди сигурен, че build-ът на проекта минава успешно; няма оставен кофти форматиран код; няма останали парченца код, които си сложил само за debug-ване, но си забравил да махнеш накрая; няма закоментирани парчета код, които си забравил изтриеш (или за които е трябвало да добавиш допълнителен коментар, който описва защо този код временно не се ползва); ясно е какво точно добавя или променя твоят PR (написано е в описанието му и е изразено чрез имената на твоите commits през git).
Ако пък правиш ревю на чужд PR, недей да го правиш набързичко (освен ако промените не са съвсем малки), т.е. да хвърлиш един бърз поглед, да кажеш “Изглежда добре! и да го одобриш. Недей и да го игнорираш, защото не ти се занимава да разбереш какви точно са промените по кода. Вместо това пробвай кода на твоята машина, виж кое как е, а накрая остави полезен коментар с обратна връзка под PR-а (сега тази обратна връзка ще е много по-полезна, защото си вложил усилия НАИСТИНА да разбереш PR-a и логиката зад промените направени от автора му).
Както се казва: “Дяволът е в детайлите.” Обръщай внимание на малките неща, които повечето хора игнорират или не забелязват.
—
Разбира се, работата НИКОГА няма да е свършена перфектно, но ВСЕ ПАК се стреми за отличие! Направи най-доброто, което можеш, с ресурсите (време, енергия, hardware, software и т.н.), които имаш на разположение. Целта тук е да си изградиш навика да правиш нещата ОТЛИЧНО (като истински майстор в занаята си), без значение с какво си се захванал. Освен това, така ще изградиш РЕПУТАЦИЯТА на някой, който винаги прави нещата добре (качествено). Каквато и роля да играеш в определен етап от кариерата ти (програмист, оратор, ментор и т.н.), опитай се да бъдеш възможно най-добър в нея. Така ще станеш истински шампион (на работа, а и в живота като цяло).
4. В същото време пък (парадоксално) НЕ СЕ ТРЕВОЖИ ЧАК ТОЛКОВА МНОГО! Това е ПРОСТО код!
Да, стреми се за качество, но в същото време не приемай всичко чак толкова на сериозно! Това е просто работа и не е целия ти живот (надявам се 😅)! В края на деня не забравяй, че това е просто работа, просто код и дори нещо да се обърка, най-често не е краят на света.
Лесно е да се вкараш във филма и да започнеш да мислиш, че софтуерното инженерство е голяма работа и е най-важното нещо на света. Да, в известен смисъл наистина е важно, но в повечето случаи не е чак на ниво “живот и смърт” по важност.
Например може да започнеш да мислиш “Олеле, АРХИТЕКТУРАТА на приложението! Толкова е важна и ако приложението не е перфектно проектирано, всичко е прецакано!” Обективно погледнато най-вероятно разработваш просто поредното неоригинално CRUD приложение, а не нещо революционно и невиждано досега. Да, естествено, че е хубаво да помислиш за архитектурата, но самото ти приложение не е ЧАК толкова важно и затова дори и да не е перфектно проектирано, планетата няма да експлодира.
Или пък “Кодът ТРЯБВА да бъде оптимизиран, за да може приложението ни да е 0.01% по-бързо!” Няма нужда кодът да е перфектно оптимизиран, за да изпълни задачата, която ти е поставена (важното е да е ДОСТАТЪЧНО добър). В много случаи може да оптимизираш кода и в по-късен етап, така че не е чак толкова важно, ако не всичко е напълно изгладено от самото начало на разработката.
Или “На ей тази важна позиция съм на работа и всичко, което правя по проекта, е изключително важно!” Дали НАИСТИНА е изключително важно? Дали планетата ще експлодира, ако например напуснеш работата си? Не, ще бъдеш заместен и екипът ти ще измисли как да продължи и без теб. Не се вземай твърде на сериозно.
Като едно допълнение, хареса ми и един съвет, който чух от Alex Yochev на една конференция. Той беше казал просто “Don’t overthink things!” и мисля, че контекстът беше вземането на технически решения в проекта, по който работиш. Тоест недей да вземаш нещата чак толкова на сериозно или да търсиш перфектното решение за всеки технически проблем. Не е нужно всичко да е перфектно, важното е просто да вземеш решение, което ти се струва “достатъчно добро”, а по-нататък може да смениш подхода, ако има нужда.
—
Също така е важно да не се привързваш емоционално към кода, който пишеш! Кодът ти не определя стойността ти като човек.
Например ти правят ревю на PR-а и ти почваш да спориш “Ама ако използваме generics тук ще е много по-добре и ще избегнем повтаряне на код! Няма да позволя моето име да бъде свързано с по-нисша имплементация!” На кой му пука? Просто направи компромис и продължи напред. Не е краят на света, а и можеш просто да рефакторираш по-късно. В много случаи просто не си заслужава да спориш относно неща свързани с кода ти. Не се впрягай за дреболии и просто продължи напред.
Все пак, разбира се, използвай здравия си разум. Ако вярваш, че дадена промяна е наистина важна, сподели аргументите си с екипа и направи каквото можеш, за да бъде въведена в проекта. Въпросът е, че дори да не стане на твоето и точно както си искал, адаптирай се и продължи напред, вместо да плачеш и да мрънкаш.
5. Трябва сам да поддържаш мотивацията си жива, за да продължиш да харесваш работата си.
В началото всичко е вълнуващо. Нов проект, технологии, хора, методология, предизвикателства, научаване на нови неща и т.н. Обаче след известно време става малко монотонно: “ОК, имплементирай тази функционалност, която е почти същата като онази, която имплементира преди месец, а след това напиши тестовете, рефакторирай кода и направи същото, което правиш всеки път.”. Споменах, че с времето свикваш с неприятните и трудните части от работата, но за жалост свикваш и с готините и интересните, а в резултат изпитваш все по-слаби емоции от тях (това важи за всичко в живота).
Затова трябва сам да поддържаш жива страстта си за софтуерното инженерство чрез добавяне на РАЗНООБРАЗИЕ и НОВИ ПРЕДИЗВИКАТЕЛСТВА! Мисля, че има 2 начина да постигнеш това: чрез “breadth” (широчина) и “depth” (дълбочина), като двете думички може да са ви познати (от алгоритмите BFS и DFS).
“Breadth” в този контекст е например да смениш проекта, по който работиш, или изцяло да смениш работата си. “Depth” би било да работиш по различни части от сегашния ти проект (например ако си backend developer, би означавало да работиш по нещо свързано с frontend, DevOps, непознати части от backend-а на проекта и т.н.) или да поемеш по-голяма отговорност на сегашната ти работа.
Досега съм използвал предимно вторият подход (“depth”), защото ми харесва проектът, в който съм, и харесвам работата си като цяло. Все пак ето някои примери за това как въвеждам “breadth” и “depth” на работа.
За “breadth”:
- 1) Карам online курсове за различни технологии и инструменти в програмирането, а дори и за soft skills теми (за технически курсове харесвам Udemy, а за нетехнически Pluralsight, но и в YouTube има доста добри курсове и от двата типа).
- 2) Чета технически книги. Сега гледам да изчета класиките, но мисля, че дори и някои книги, които НЕ СА директно за програмиране (но по някакъв начин са свързани със софтуерното инженерство), могат да са полезни (например наскоро завърших една свързана с формирането на софтуерните изисквания — готиното е, че ти дава поглед върху някаква най-вероятно непозната за теб част от процеса на разработката, ако си developer и си свикнал в по-голямата част от времето да си фокусиран върху реализацията на вече оформените изисквания).
- 3) Слушам речи на експерти в областта на софтуерното инженерство. Например периодично гледам презентации от различни Java/Spring конференции, а понякога просто си пускам Uncle Bob, за да си припомня някои основни принципи.
Ползата от тези неща е, че ти помагат да разшириш повърхностните си знания за различни части от софтуерното инженерство (и така е по-лесно да поддържаш интереса си жив). Може и да не ползваш всяка една технология или идея, за която си научил от горните източници, но поне ще знаеш, че съществува и когато се чудиш как да решиш някой проблем, в главата ти по-често ще изплува идеята “Хм, може да пробвам онова, за което прочетох онзи ден!”.
За “depth”:
- 1) Опитвам да работя върху непознати за мен части от проекта ни. Например понякога пробвам някои малки frontend задачи (или поне пробвам да задълбая във frontend кода, за да свърша backend задачата си по-добре). Също така се опитах да понауча малко и за deployment инструменти, DevOps и др. Предизвиквам се като се опитвам да разбера на по-дълбоко ниво различните части от проекта, по който работя (дори и частите, които не съм ЗАДЪЛЖЕН да познавам). Така поддържам интереса си към проекта жив.
- 2) Опитвам се да поема повече отговорност в работата ми. Например периодично правя презентации за различни неща, които съм научил в кариерата си (дори този пост първоначално беше под формата на презентация). Не съм задължен да ги правя, но ми харесва, а и вкарва разнообразие в работата ми. Поех и ролята на ментор, което беше интересно и ново за мен изживяване.
Като цяло такива разнообразни предизвикателства поддържат работата интересна за мен. Формулата мисля, че общо взето е следната: ако няма никакво предизвикателство, изпитваш СКУКА; ако предизвикателството е твърде голямо, изпитваш ТРЕВОЖНОСТ (или се ядосваш); ако е постепенно увеличаващо се предизвикателство (което отговаря на сегашните ти умения), изпитваш ВЪЛНЕНИЕ (зараден си с ентусиазъм да продължиш напред).
—
Имай предвид, че тази “depth” идея може да бъде приложена и в КОНКРЕТНИ ЗАДАЧИ.
Например наскоро се наложи да презентирам за 2-ри път същото нещо (т.е. една и съща тема, презентирана 2 пъти за различни събития). На мен лично ми става скучно, ако трябва да повтарям нещо, което вече съм споделял, та затова реших да се предизвикам. Презентирах същата тема, но този път разширих презентацията като добавих още малко информация към нея. Освен това поправих някои грешки от първото представяне. Идеята е винаги да търсиш начини да подобриш нещата, а не просто да повтаряш едно и също нещо по 100 пъти.
Друг пример: понякога се налага да имплементираш някаква функционалност, която е доста сходна на нещо, което вече си имплементирал в миналото. Вместо да направиш нещата точно както си ги направил последния път, може да пробваш и да експериментираш с някакъв алтернативен и потенциално по-добър подход за имплементация. Или пък може и просто да откриеш начини да подобриш кода, който си писал последния път.
Схващаш идеята: винаги търси начини да се предизвикваш.
—
И последно: като страничен ефект от правенето на тези неща на работа, получаваш повече НАГРАДИ: повече уважение от колегите ти, повече повишения и възможности. Освен това поддържаш уменията си и винаги растеш като софтуерен инженер. Като цяло според мен ще спечелиш много, ако започнеш да използваш този начин на мислене на работа, а и в живота като цяло.
БОНУС: Ето още един последен урок, който научих сравнително наскоро. Все още e “work in progress”, тъй като аз самият се опитвам да го приложа и да го разбера на по-дълбоко ниво. 😅
6) Стреми се да се превърнеш в ЛИДЕР (ако искаш да стигнеш елитно ниво)
В един момент ще стигнеш точка, в която имаш малко повече знания от някои от колегите ти (тоест няма ти да си най-неопитния). Може да използваш тези насъбрани знания и опит като начална точка за това да се превърнеш в ЛИДЕР!
Защо това е важно? Защото ако през цялото време се фокусираш върху “микро задачи” (например да имплементираш дадена функционалност, да оправиш някакъв бъг, да изпълниш някакъв произволен Jira ticket тихичко и самостоятелно), ще си “ОК” софтуерен инженер, но няма да стигнеш елитно ниво и няма да си сред най-ценните разработчици в екипа ти.
Най-ценните софтуерни инженери са именно ЛИДЕРИТЕ. Това са хората, които вършат “макро задачите” (например да направят проекта по-бърз, да разрешат критично важни проблеми на PROD и т.н.), т.е. те поемат повече отговорност и също така помагат на колегите си да станат по-добри.
Да, очевидно отнема известно време да стигнеш това ниво (няма как от днес за утре да преминеш от Junior към Senior), но все пак мисля, че можеш да започнеш да се придвижваш в правилната посока още от сега! Ето някои идеи за започване (дори и сега да си Junior):
- помагай на другите (помагай с техния onboarding, бъди ментор, помагай за свършването на задачите на другите, кажи им къде могат да намерят помощ за разрешаването на проблемите им и т.н.)
- сподели идея/мнение за важни решения в проекта ти (технически решения, решения свързани с процеса на работа и др.) [btw, важното не е дали другите ще приемат идеите ти, а просто да свикнеш да участваш във важните решения и да започнеш да мислиш на “макро” ниво]
- направи малко повече от това, което другите очакват от теб (например напиши някакъв guide за да улесниш колегите си с нещо, оправи някакъв забравен и игнориран от всички bug, предложи да представиш нещо полезно за другите: някаква имплементирана функционалност или нещо полезно, които си намерил и може да улесни работата на другите).
По този начин ще свикнеш ПОСТЕПЕННО да поемаш повече отговорност (тоест няма да ти се струпа всичко наведнъж, защото още преди нещо да е станало част от задълженията ти, ти вече си го правил поне до известна степен) и ще се подготвиш за това да си лидер (тъй като си свикнал да работиш с другите, да им помагаш и да ги водиш към по-добро положение от сегашното им), а стойността ти във фирмата и в проекта ти ще се увеличи драстично (колегите ти ще знаят името ти, ще те свързват с положителни неща и ще си добър кандидат за по-високи позиции).
Обобщение:
- Очаквай да си объркан в началото и се довери на процеса (няма как да се провалиш, ако просто продължаваш да ОПИТВАШ).
- Работата в екип не е толковa лоша. Можеш да се научиш да работиш в екип и дори да ти харесва (а това всъщност ще те направи по-добър както в работата ти, така и в живота като цяло).
- Стреми се да правиш всичко максимално КАЧЕСТВЕНО!
- В същото време пък (парадоксално) НЕ СЕ ТРЕВОЖИ ЧАК ТОЛКОВА МНОГО! Това е ПРОСТО код!
- Трябва сам да поддържаш мотивацията си жива, за да продължиш да харесваш работата си.
- Стреми се да се превърнеш в ЛИДЕР (ако искаш да стигнеш елитно ниво)
Това е засега. Успех! 😎
