Cei mai mulți dintre noi, mai ales cei care suntem pasionați de asta, vrem să fim mereu la curent cu cele mai noi tehnologii, vârful de lance, să le încercăm proaspăt scoase din cuptor.

Ca la lansarea noilor modele de telefoane.

Dar oare tehnologii vechi mai este relevant să înveți?

Ce înseamnă totuși “vechi”?

Acum dacă specialitatea ta si job-ul pe care îl ai presupune să scrii cod în limbaje mai nou apărute, cum ar fi Kotlin, de exemplu, nu prea ai ce tehnologie veche să înveți, pentru că limbajul e apărut relativ recent.

Da, știu, are cam 10 ani, dar și asta tot recent înseamnă.

Deasemenea dacă ești, să zicem, developer de Angular sau React, evident pentru tine nu există “vechi”, pentru că framework-urile astea au câțiva ani de când au apărut.

Dar dacă ești C# developer sau Java sau PHP developer, vei avea ceva dinozauri de studiat.

De ce ai vrea totuși să cunoști și tehnologii care nu mai sunt de actualitate?

Așa cum ziceam mai devreme, toți ne dorim să folosim doar vârful de lance, pentru că evident cu cât mai nouă versiunea cu atât vei avea o experiență mai plăcută ca developer. Și nu doar plăcută dar și mai ușoară.

Aici e partea interesantă, pentru că deși tehnologiile evoluează foarte repede și în câțiva ani se pot schimba lucrurile destul de semnificativ, firmele cu greu vor ține pasul cu aceste schimbări.

Cu cât aplicația va fi mai mare și cu cât nivelul ei de criticitate într-o companie este mai mare, cu atât mai greu va fi adusă la zi.

Mai ales în momentul în care ajunge la un anume nivel de maturitate și la un număr semnificativ de utilizatori, iar numărul de features noi adăugate într-un interval de timp începe să scadă. Proiectul intră pe un nivel de platou și o bună parte de timp, update-urile la versiunile mai noi de tehnologie vor fi neglijate.

Pentru că dacă nimeni nu se plânge, aplicația merge bine, nu sunt probleme, de ce să investești bani și resurse să faci un upgrade?

Și în felul ăsta, ajung să existe prin companii, proiecte care au fost dezvoltate la jumătatea anilor 2000 și de-atunci fiecare feature nou care a fost adăugat, s-a făcut pe fugă și în silă de fiecare developer care a atins codul.

Nu scrie cod în silă

Sfatul meu e că dacă te găsești vreodată în situația de a fi nevoit să lucrezi pe un proiect mai vechi, să n-o faci pe fugă și să cauți să înțelegi cum funcționau aplicațiile la momentul la care au fost dezvoltate, cu tool-urile existente atunci, pentru că asta ți-ar putea aduce un avantaj enorm.

E foarte bine să fii stăpân pe ultimele versiuni ale tehnologiei cu care lucrezi, dar totodată consider că un asset important e să știi să jonglezi un pic și cu versiunile mai vechi pentru că va conta mult dacă nu ai de gând să lucrezi doar în firme de genul startup.

Prin companiile mari și corporații vei găsi din greu aplicații de genul ăsta, rămase grav în urma tehnologiei și detestate de toți developerii care iau contact cu ele.

Dar în momentul în care va exista un incident pe proiectul respectiv, iar pentru că la ultima dezvoltare făcută de tine, nu te-ai grăbit să arunci acolo codul și să fugi și ai studiat un pic arhitectura și modul în care funcționează aplicația, ai înțeles un pic cum se face comunicarea între layere, ce componente externe are, cum e structura bazei de date șamd, tu vei fi omul de bază în incidentul respectiv.

Ce ai de câștigat

Acum eu nu zic să stai să-ți bați capul zile întregi să înțelegi un codebase care e “full spaghetti”, doar zic să acorzi puțin mai multă atenție și să cauți să înțelegi proiectul pe care lucrezi, chiar dacă nu e .NET 6, sau Java 15.

Îți va lărgi mult plaja de cunoștințe pentru o tehnologie anume și te va ajuta să te descurci cu ușurință indiferent de proiect.

Asta nu numai că te va face un developer mai apreciat și mai bine plătit, dar dacă ești freelancer, de asemenea vei putea face bani rezolvând probleme micuțe pe proiecte vechi.

Și da, poate ai crede că proiectele de genul ăsta sunt niște excepții rare, dar adevărul e că o grămadă de firme de outsourcing angajează oameni pentru proiecte de genul ăsta, pentru clienți din alte țări care nu mai vor să-și bată capul cu ele. Sau există șansa să întâlnești o situație în care firma vrea să facă un upgrade sau o migrare unui proiect de genul, iar faptul că vei avea experiență cu proiecte similare te va ajuta enorm de mult.

Știu că pe la interviuri toți promit că vei lucra cu cele mai noi și mai strălucitoare tehnologii de pe piață și că oportunitate ca aia rar o să mai găsești și bla bla, dar de multe ori după ce bați palma și începi munca, găsești total altceva.

De-asta consider că e bine să stăpânești și tool-uri mai vechi, mai ales dacă vei lucra remote și vei vrea să fii cât mai independent posibil.

Deci mai este relevant să înveți tehnologii vechi?

Da, cu siguranță.

Nu e cazul să faci asta din proprie inițiativă, adică să cauți acum informații despre lucrurile astea dacă nu ai niciun proiect de genul, pentru că sunt slabe șanse să găsești ceva bine documentat în zilele noastre.

Doar dacă ai efectiv un proiect la care lucrezi vei putea dobândi cunoștințe de genul.

Acum poate te întrebi: dar totuși care sunt șansele să lucrez tocmai eu pe un proiect de genul?

Mmmmm…

Aș zice că destul de mari.

Spuneam și pe la început, că dacă nu ai un job pe la vre-un startup, prin firmele care au vechime pe piață sunt foarte mari șanse să găsești proiecte de genul.

Poate nu toate, evident.

De obicei sunt și proiecte mai noi, care încă sunt în faza de development masiv și care nu au parte de cine știe ce incidente de producție sau alte probleme de genul, pentru că sunt încă într-o versiune beta.

Dar printre proiectele astea, sigur sunt și altele mai vechi care vor fi sau nu înlocuite de cele noi.