Azi am o veste nu foarte bună pentru tine, dar s-ar putea să te ajute să-ți conștientizezi poziția și să treci peste asta.

Parcursul tău tehnic nu e obligatoriu să evolueze, nici măcar ca angajat cu normă întreagă în domeniu.

De asta, în cele ce urmează vreau să vedem de ce e important să lucrezi în continuare la proiecte personale, chiar și atunci când ai trecut de etapa de junior sau entry level.

Poate nu știai asta, dar nu ar trebui niciodată să te oprești din a lucra la proiecte personale, chiar și atunci când ai ajuns la nivelul de senior.

Sigur, poate te-ai angajat deja în domeniu, poate ai deja 1-2 ani experiență și deja ai renunțat să mai “șurubărești” și acasă, sau în timpul liber la niște proiecte.

Asta e una din greșelile pe care le-am făcut și eu la început.

Experiența primului proiect în IT

În primele 6 luni după ce m-am angajat, eram destul de obosit de procesul prin care trecusem așa că îmi umpleam tot timpul liber cu total altceva.

Mă gândeam atunci, așa cum probabil te gândești și tu dacă ești în aceeași situație acum, că dacă m-am angajat, o să învăț la job și în felul ăsta pot să-mi petrec timpul liber făcând altceva.

Mă gândeam că o să fie echilibrul perfect, pentru că o să evoluez lucrând cele 8 ore pe zi și aș fi avut și timp liber să fac și alte lucruri.

Consideram că borna pentru care muncisem atât fusese atinsă și că de-acum în colo e doar o chestiune de timp până o să ajung la nivelurile superioare de senioritate.

Ghinionul meu a fost că proiectul pe care intrasem se mișca foarte greu și cam timp de 6 luni până la un an n-am făcut mare lucru.

În schimb timpul liber începusem să mi-l petrec cu ceva jocuri, reîncepusem să mă uit la o grămadă de seriale și să ies în oraș de mai multe ori pe săptămână.

Până și timpii morți de la birou îi petreceam pe YouTube sau făcând orice altceva decât să mai studiez ceva.

Foarte rar mai încercam să aprofundez ceva nou și atunci îmi pierdeam interesul destul de repde.

Poate contribuisera și oboseala și stresul de din-ainte pe care cred că aveam nevoie să le mai diminuez.

Aproape un an mai târziu, mi-am dat seama că tot timpul ăsta a cam fost pierdut.

La job lucrurile nici că se puteau mișca mai lent, nu făcusem mai nimic în afară de câteva analize pe niște exporturi de date, niște sarcini mici pe partea de baze de date și alte lucruri diverse care nici măcar nu aveau mare legătură cu rolul meu.

Atunci mi-am dat seama că dacă nu lucrez în continuare din proprie inițiativă, nici în următorii 1-2 ani n-o să învăț mare lucru.

Așa am și făcut și în următorul an am lucrat la mai multe proiecte care mie mi se păreau interesante, am trecut prin mai multe cursuri de câteva zeci de ore, am citit câteva cărți și nenumărate articole tehnice.

Între timp, în următorul an, lucrurile au început să se mai miște și pe proiect și am avut de lucru mult mai mult decât în primul an, dar chiar și așa, am continuat.

Mai mult de atât, mi-am automatizat unele lucruri chiar și la job.

De exemplu, mi se cerea destul de des să compun un raport ale cărui date le colectam din diferite surse în diferte formate, pe care trebuia să le procesez într-un fișier Excel.

Așa că am scris o unealtă care făcea atât colectarea de date și procesarea cât și exportul raportului în mod automat, la apăsarea unui buton.

Ulterior am legat unealta asta la ceva evenimente de sistem și raportul se genera automat la o locație din rețea, nefiind nevoie ca eu să mai intervin în vreun fel, sau să fiu contactat de cineva pentru a face vreo acțiune.

Sigur, nu te gândi că aplicația asta fusese scrisă bine, dar era funcțională și destul de rezilientă și astea erau lucrurile cele mai importante.

Pe lângă asta lucrasem deja la mai multe proiecte pe diverse tehnologii, atât ca proiecte personale cât și de freelance.

Schimbând radical modul în care am abordat lucrurile am evoluat extrem de mult, iar la momentul în care m-am hotărât să plec din compania respectivă, am obținut 2 oferte diferite, din 2 interviuri avute.

Revenind la ce spuneam anterior, spuneam că nu trebuie să renunți la a lucra la ceva proiect al tău niciodată.

Pentru că și atunci când vei trece la nivelurile superioare de senioritate, vei avea nevoie să experimentezi destul de mult, cu diferite arhitecturi, diferite design patterns sau tehnologii.

În felul ăsta evoluezi extrem de rapid și prinzi experiență cu o gramadă de unelte și tehnologii, pe care poate proiectul la care lucrezi la job nu ți le poate oferi.

Acum că am clarificat asta, hai să vedem ce ar trebui să eviți.

Proiecte fără utilitate reală

Clonele de aplicații celebre au luat foarte mare amploare în ultimii ani.

De la LinkedIn la Facebook, YouYube, WhatsApp, Instagram șamd, pentru toate găsești pe undeva un video în care cineva face o clonă.

Eu îți recomand să eviți genul ăsta de proiecte, DACĂ, e un “dacă” aici, ai de gând să dezvolți doar partea vizuală a aplicației respective.

Adică doar partea de front-end, sau client-side.

Dacă ai făcut o clonă de Facebook să spunem, dar nu e funcțională decât într-un mod foarte simplist, iar partea de back-end e complet lipsă, probabil au mai făcut și alte câteva sute de oameni aceeași clonă, pe care au pus-o ca proiect de portofoliu la CV.

Atunci tu nu te mai deosebești cu nimic de toți ceilalți.

Acum ai putea spune, că ok, dar eu vreau să fiu front-end developer, nu mă interesează momentan partea de back-end.

Și ai avea completă dreptate.

Dar asta nu înseamnă că trebuie să ignori complet back-end-ul aplicației.

Sunt platforme pe care le poți folosi ca Back-end as a service (BAAS) și aici enumăr câteva din cele mai cunoscute platforme de genul ăsta: Firebase, Supabase, AWS Amplify, AppWrite ș.a.

Alege una din platformele astea și integrează un back-end în aplicația ta.

Nu-ți face griji, dacă alegi oricare din platformele enumerate mai devreme, integrarea ar trebui să fie destul de ușoară și să nu-ți dea prea mari bătăi de cap.

Cum să te diferențiezi ca programator junior

Acum după ce ai adăugat și câteva elemente de back-end în aplicația ta și datele sunt salvate în baza de date, utilizatorii își pot crea conturi, se pot loga, le poți trimite notificări pe email șamd. un alt lucru pe care îl poți face e să-ți aduci creativitatea în joc și să personalizezi aplicația respectivă.

Schimbă-i numele, dă-i un nume mai original și adu-ți contribuția în ceea ce privește modul de funcționare al aplicației.

După ce ai făcut toate astea, care sunt doar câteva din ideile care îmi vin mie în minte, tu ar trebui să te gândești cum ți-ar plăcea ție să fie, vei obține o aplicație completă, funcțională și care nu mai e clona nimănui.

Vei avea un proiect cât de cât original care va ieși în evidență, chiar dacă e clar că seamănă cu o anume rețea socială deja existentă.

Sigur că toate astea îți vor lua ceva timp să le implementezi dar valoarea proiectului va crește exponențial față de clona pe care o aveai inițial.

Asta ar fi varianta în care ești front-end developer, dacă ești în schimb back-end developer, nu sunt atât de multe clone pe care le poți face, dar nici nu e atât de important.

Ce poți să faci în schimb e să lucrezi la diferite proiecte cu diferite tipuri de arhitecturi și tehnologii.

Învață de exemplu despre REST APIs, dacă nu ești familiar cu asta, apoi experimentează cu diferite tipuri de design, cum ar fi CQRS (Command Query Responsability Segregation) sau DDD (Domain Driven Design).

Poți folosi arhitecturi diferite în fiecare proiect la care lucrezi, cum ar fi : N-Tier Architecture, Clean Architecture, Onion Style Architecture, Slice Architecture etc.

În felul ăsta poți să înțelegi mai bine avantajele și dezavantajele diferitelor tipuri de design de sisteme sau arhitecturi, chiar dacă nu ai lucrat pe un proiect real.

Iar atunci când vei avea șansa să întâlnești într-un proiect real un tip de arhitectură pe care l-ai folosit și tu într-unul din proiectele tale, îți va fi mult mai ușor să începi să lucrezi pe el.

Îți recomand să te joci tot timpul cu diferite proiecte din astea sandbox pentru că pe proiectul de la job ești limitat de ceea ce există deja acolo.

Și de obicei pe proiectele mari, aportul tău va fi unul destul de izolat și nu vei avea șansa să înveți despre toate conceptele astea.

În felul ăsta nu mai ești limitat de proiectul respectiv și maturitatea ta ca developer va crește exponențial, evitând o potențială plafonare.

De multe ori oamenii îmi cer idei de proiecte la care să lucreze, am dat aici câteva exemple, dar de cele mai multe ori evit să intru în foarte multe detalii, pentru că vreau că tu să-ți aduci aportul, să-ți pui creativitatea la contribuție.

Să poți explica ulterior unui potențial angajator de ce ai implementat ceva anume.

Altfel dacă vei avea proiecte implementate de-a dreptul “sintetic”, nu vei fi foarte convingător.

Și știm cu toții cât de greu e să obții un interviu ca programator junior, așa că dacă ai ajuns până acolo, de ce să nu fii cât mai pregătit posibil și să te diferențiezi de ceilalți?

Cam atât pentru azi și nu uita să lucrezi constat și să-ți dai timp să înțelegi lucrurile în profunzime. Dezvoltarea software nu e un sprint, e un maraton.