Situația profesiei 2023

1

Clienți

Situația e în continuare dezastruoasă. Aud de la alte business-uri că au nevoie de 6 – 12 luni să-și facă site-ul. O grămadă de timp. Lucrez cu niște aplicații care deservesc un domeniu și e clar de la prima utilizare că oamenii acolo nu înțeleg domeniul. Fiecare complică un concept inutil și îi aruncă niște etichete care n-au nici o logică. O fi și problema că lucrez cu Europa unde engleza e o necunoscută. Am conceptul de „Property” pe care ei îl folosesc cu semnificația de imobil. După aia am o serie de entități care au proprietăți („properties”). Fun!

Toate se mișcă foarte încet aici, contracte ce durează ani de zile să fie negociate, toată lumea e încântată de soluția pe care le-o oferi, nimeni nu vrea să intre în horă cu tine. Că așteaptă să vadă că ai tu alți clienți. În rest laude și urale.

Organizare internă

Dezastru. Clienți care nu înțeleg cum funcționează procesul de dezvoltare software. Nu știu să vină la o discuție și să ceară ce vor. Trebuie alții să-și dea seama. Nimeni nu își cunoaște procesele interne. Ironic, și omul responsabil cu procesele interne nu are nici o documentație. Când e să raporteze ceva nu știe să scrie aplicația, pagina, seria de pași pe care să-i faci ca să ajungi la problemă dar nici ce vrea nu poate descrie coerent.

Trebuie să facem modificări în interfață, avem un designer, dar nu, eu programatorul primesc cererile direct. Avem un reprezentant dar nu, fiecare vorbește unu la unu cu fiecare. Mă trezesc cu lucruri făcute că a vorbit X de la clienți cu Y de la programatori. Fără o discuție, un task definit, ecrane și descriere. S-a făcut ceva. Punct.

Multă muncă inutilă. Că clienții au folosit ceva Google SEO Tools care a zis că dacă facem fundalul la filtre mai negru o să crească rata de conversie. Aia e prioritatea. Dar faptul că toată aplicația crapă când avem 200 de vizitatori simultan nu e o problemă.

Lumea cere micro-management. Știu, toată articolele de pe LinkedIn comentează că trebuie să-ți lași oamenii să lucreze independenți, să nu-i freci la cap toată ziua. Oamenii noștri nu, că le trebuie cineva să-i țină de mână la fiecare task. Că nu înțeleg ce au de făcut. Ok, avem un canal de chat și doi oameni mereu pregătiți să vă îndrume. Ați întrebat acolo? Păi, nu.

Programatori

Oh, Doamne! Atâția ochi dați peste cap că aș putea genera curent electric doar din asta. Că nu lucrează cu PHP că e pentru babalâci. Că nu scriu query-urile în Modele, că le scriu direct în Controller. Că folosesc ei o funcționalitate din framework că e doar o linie de cod când nimeni nu știe ce face framework-ul cu acel proces. Că ei scriu condensat codul ca să avem puține linii de parcă pe mine mă interesează altceva decât un cod ușor de citit.

Cel mai tare e când mi se zice că ei nu implementează ce li s-a cerut. Că ei vor să facă aplicația future-proof și ce am făcut în design nu e bine. Da, au stat cel puțin 7 oameni să facă acele ecrane și vine un oarecare din echipă și zice că suntem șapte tâmpiți. Și când întreb cum vor să o facă future-proof fie nu știu, fie îmi dau exemple care nu se pupă cu realitatea proiectului.

E o foarte mare de problemă cu orgoliile. Toți vor să ajute, dar nu am mai găsit om care efectiv să facă ce îi cer. Toți vor să arate cât de mult pot și îmi bagă pe gât tot felul de soluții de care nu am nevoie.

Toți țin de cod cu dinții. Cum adică să scriem cod care după 2 săptămâni să-l aruncăm la gunoi? Că nu, că trebuie să facem mai multe ședințe, cu mai mulți oameni, să scoatem cod de calitate. Dude, am nevoie de ceva scris repede în 2 zile să văd dacă direcția e bună. În plus rolul programatorului e să scrie cod. Că e bun sau rău decid persoanele cu acea responsabilitate.

E foarte greu să progresezi, lumea ascunde munca, în loc să fie făcute commit-uri zilnic, nu se trimite nimic toată săptămâna, apoi dintr-o dată am un mega-merge de 50 de fișiere modificate și alte 50 noi. Cod complicat inutil, neverificat, rulat în condiții optime și când arăt că același query e rulat de 160 de ori în aceeași pagină primesc răspuns: păi trebuie să îți pui baza de date local, nu la 30 de milisecunde distanță. Că 160 x 30 sunt aproape 5 secunde. Pe când la el 160 x 1 ms = 160 ms – nici nu se vede.

Tehnologie

Toți vor cel mai nou. Totul să fie doar Javascript cu tot felul de biblioteci și framework-uri care se schimbă la 6 luni. De când am început proiectul în Angular, au apărut două sau trei versiuni. Că e super-simplu să migrezi de la o versiune la alta îmi zice cineva din echipă și-mi arată un site cu vreo 50 de pași și verificări să trec de la o versiunea la alta. Nu, mersi.

Avem nevoie de o platformă stabilă, care și acum și peste 10 ani să meargă la fel. Nu avem resurse ca la fiecare 6 luni să luăm la puricat toate proiectele și să le modificăm la ultima versiune.

Mi-am băgat picioarele și am început să folosesc ChatGPT. Drăguț dar cam inutil. M-a ajutat să rescriu câteva lucruri, mi-a mai făcut o funcție aici și acolo, mi-a dat niște răspunsuri generice pentru unele probleme complexe, a crăpat de câteva ori. Trebuie să ai o aplicație foarte foarte rudimentară să poată fi folosit. Iar cineva care nu știe programare de la prima cerere o va da în bară. Da, sigur, scoate cod HTML în regulă, dar cam atât. I-am cerut să-mi facă o funcție care să îmi dea dimensiunea în rem pentru un text începând de la 2rem coborând până la ceva vizibil ca textul să îmi rămână citibil și pe o singură linie. Inițial am rămas uimit, dar apoi mi-am dat seama că treaba asta cu font-urile e peste puterile lui, dar mi-a dat mie niște idei cum aș putea-o rezolva.

Concluzii

Suntem într-o perioadă foarte tulbure. Tehnologiile au avansat foarte mult iar oamenii noi care intră în industrie în mare parte au luat varianta ușoară (Javascript + frontend). Probleme de optimizare a bazelor de date (toți vor NoSQL), simplitatea și expresivitate a codului, optimizare de bun gust încă de la scrierea codului, capacitatea de a lucra independent, să sumarizeze și să pună întrebările relevante sau pur și simplu să stea și să nu facă nimic câteva zile, toate astea lipsesc.

Dorința de afirmare și evidențiere e mai mare decât muncitul în echipă și urmărirea structurii de conducere. Nu, noi facem ce credem noi că e bine, indiferent ce se dorește.

Clienții, proprietarii sau finanțatorii sunt și mai în ceață. Pe lângă că nu înțeleg nimic din software-ul care îl cer mai au și o mână de oameni care mereu comentează și sunt nemulțumiți. Iar ei nu au cum să înțeleagă nimic din toate acestea. Proiecte simple durează luni de zile. Clienții se bazează pe designeri să le sugereze cum să arate paginile, apoi programatorii nu pot implementa design-ul că nu se poate în HTML/CSS ca pe urmă la code review se fac refactorizări la HTML/CSS de se schimbă 90% din cod. Patru pagini de imagini și text au generat un du-te-vino de trei luni.

Soluțiile simple nu mai pot fi puse în practică. Când înveți din prima Javascript și React/Angular/Vue, să faci o pagină statică cu text și imagini pur și simplu nu poți să te gândești că tot ce ai de făcut e să scrii un fișier .html.

Pur și simplu programatorii nu pot accepta că unele lucruri sunt simple și tot de ce e nevoie e un tabel cu o singură coloană și ecranele standard de Create, List, Edit și Delete.

11 Likes
2

Ai oameni care merg numai pe shiny new things si doar aprofundeaza la nivel superficial lucrurile.

Ai oameni care merg numai pe lucruri care stiu sigur ca merg si nu vor sa scoata capul sa invete altceva.

Si tot ce e intre.

Asta e situatia. Problema e in lumea asta ca deciziile se iau dupa vot: “Tu cu ce vrei sa lucrezi?” Si toata lumea alege dupa ce le taie capul.

Cum ar fi sa te intrebe la McDonalds la angajare: “Tu cu ce casa de marcat ai vrea sa lucrezi?” sau “Cum ai vrea sa faci cartofii?”

Decizia pe ce foloseste fiecare trebuie sa fie luata de un FOARTE mic grup de oameni care sunt extrem de experimentati si care tin viziunea pe tehnic. Nu sa fie democratie in acest proces.

Exemple din multinationale de success: toate echipele au de ales intre Java si Java si Spring si Spring. That’s it, acum hai la treaba :man_shrugging:

3

Pare ca descrii lucruri care se intampla in corporatii. Eu unul sunt lecuit de ele si satul pana peste cap, pentru ca regasesc peste tot in mare parte despre ce spui mai sus.

Mai ales ca fiind pe design, uneori nu e nimic mai frustrant sa vad de cat de multa incompetenta sunt inconjurat mai ales din partea oamenilor care se presupune ca sunt pe niste roluri care ar trebui sa aduca mai multa claritate si sa defineasca cerintele.

Chiar si la partea de design te chinui pana cand intelegi ce nevoi are clientul si sunt singur ca nu e nimic mai frustrant sa ajunga la dev niste mockups interpretate, care la implementare se dovedesc ca nu rezolva exact ce dorea clientul.

Problema sunt oamenii acestia intermediari, product/project manageri, scrum master si ce alte denumiri mai sunt. Foarte multi dintre ei habar n-au in ce consta jobul lor, nu stiu sa se integreze in dezvoltare software si au o atitudine complet pasiva fata de intelegere a procesului si de a-l facilita.

Presimt un shift pe viitor in industrie, reintoarcerea expertilor si oamenilor care se pricep, adunandu-se in acelas loc.

Ma uit putin la anumite corporatii, mai ales pe partea de gaming. Oare cum e posibil ca 3000 de devs la Activision sa scoata o gluma de joc, iar acum un deceniu 100 de oameni aveau un produs mult mai finisat si cu features de baza si de bun simt?

Apoi ma uit la un clipulet pe net cu o product managera care se plimba prin office la Google si face tiktoks. Adult daycare.

2 Likes
4

1. Clienti

  • Tu ca programator trebuie sa faci tot posibilul ca sa nu lucrezi direct cu clientii, product ownerul e acolo fiindca stim toti ca nici un client nu stie ce vrea. Nu lasa clientul sa iti dicteze tehnologiile.
  • Designerii sunt in majoritatea cazurilor batuti la cap, fa desene cu paint sau nu fa grooming(refinement) daca nu e 100% clar design-ul.

2. Organizare interna
Eu n-am avut probleme cu clientii o data ce am avut product owneri pusi pe treaba, design-urile de obicei sunt problematice, dar in rest faci un call cu product ownerul inainte sa te apuci.
De ce nu ridici intern problema ? Sunt n firme la care nici nu se pune problema sa vorbesti direct cu clientul fiindca poate pleci cu clientul sau spui ceva politic incorect/te dai la clienta si s-a dus tot proiectul.
Munca nu e inutila, tu vezi din ochii programatorului, ei vad cu ochii investitorului, adica lor le trebuie cat mai multi bani cu cat mai putin efort.
Nu lucra cu oameni care cer micro-management, nu fa micro-management, cei care au nevoie de asta posibil ori nu au cunostiinte suficiente, ori nu cer ajutor, ori sunt burned out si lucreaza doar ca sa aiba bani de pe o luna pe alta. E acceptabil daca ceva trebuie scos foarte rapid si trebuie totul sincronizat, dar ar trebui evitate situatiile de genul.

3. Programatori

  • Ai n moduri de a seta standarde de calitate in cod, faci o pagina de confluence, faci ceva automatizare precum prettier (nu stiu daca ai ceva de genul pe php), sonarqube, hook la git…
  • Code review obligatoriu, code owners si obligatoriu ownership la codul scris. Adica daca ai scris cod de cacao, tu lucrezi pe el, nu altcineva. Daca altcineva lucreaza tu trebuie sa ii faci code review si suport.
  • Mereu cand se propune ceva ce nu ti se pare rational cere un mic studiu, adica pro si cons, un demo, ceva, intreaba “Cine va fi responsabil de implementarea cu X ? Eu garantez ca va functiona cu php in acest mod” Propune un vot dupa prezentare.
  • Cauta coding standards de la alte firme, incearca sa le aplici de la un nivel mai mare, daca vii tu cu sugestii fii pregatit sa faci un intreg curs despre parerile tale. Sa ai articole bune pentru fiecare standard sau pattern pe care vrei sa il aplici.
  • Pur si simplu nu fa code review la ceva ce are foarte multe commit-uri, lasa un comment sa imparta PR-ul pe mai multe PR-uri si sa scrie mai multe teste…
  • Daca vezi ca cineva n-are experienta incearca sa faci pair programming, nu incerca sa ii explici ca n-a facut ceva bine fara sa ii arati ca nu va intelege

4. Tehnologie

  • Daca esti tanar iti garantez ca nu e visul nimanui sa faca ceva cu PHP sau C++ pe web. O sa isi scrie pe CV la angajare: Am facut 5 site-uri cu PHP de la 0, fara wordpress cu template-uri in Bootstrap, MySQL si CRUD in MVC. Ceilalti: Am facut o aplicatie de stocuri in React cu filtre, chart-uri, skeleton loading, optimistic rendering, infinite scroll, backend for front-end cu tRPC, GraphQL, Websockets…
  • Trebuie mereu ceva mai shiny ca sa poti sa treci de la o companie la alta sau de la un rol la altul.
  • Trebuie un arhitect, dupa arhitectul trebuie sa vada ce developeri poate angaja, e total alta nisa crearea de site-uri de prezentare si scrierea de aplicatii. Daca faci un site de prezentare cu app developers e clar ca focusul va fi pe ceva framework de JS ca e tool-ul cu care se misca ei cel mai bine, tie iti este mai usor HTML/CSS cu Bootstrap de exemplu, mie imi este mai usor React cu Tailwind de exemplu. Desigur trebuie identificati app developerii reali si cei care au facut un curs. Majoritatea aplicatiilor sunt foarte complexe, ai optimistic rendering, conteaza performanta, conteaza accesibilitatea, conteaza sa mearga pe mobile cu touch… Poate tie ti se pare ca e simplu fiindca nu te gandesti ca la o aplicatie ci ca la o pagina de prezentare.
2 Likes
5

Cred ca trebuie evitat ceva ce se cheama, hype driven development.

3 Likes
6

Trebuie vazut daca arhitectura si viziunea produsului se potriveste sau nu cu acel hype. Nu orice hype e rau, doar ca posibil implica anumite costuri, pe care si-l permite sau nu clientul.

7

in afara de query in controller restul sunt idei bune, eu ma consider un programator pragmatic dar nu as merge pe php pt ca nu e type safe, nu are multithreading, si e inconsistent, weird behaviours pe alocuri, si da e bine sa folosesti o functionalitate din framework pt ca e battle tested, si codul e o liabilitate, mai putin e mai bine, codul mult e usor de citit local, la prima vedere, cand te uiti la cateva linii, dar pe ansamblu cand tre sa citeste o pagina intreaga e greu.

1 Like
8

Pai cu cat mai multi oameni cu atat merge mai incet treaba. :))
Concluzia - un singur dev e numarul ideal. :sweat_smile: Ce zic eu unul, zero devs o sa faca treaba instant.

Lasand gluma la o parte, mie mi se pare ca si calitatea jocurilor lasa de dorit. Multe din ele sunt cam dumbed down, eye candy in defavoarea gameplay-ului, etc.

The Witcher 3 m-a plictisit dupa cateva ore de joc. Same fucking shit in continuu, o nuvela interactiva mai mult decat un rpg. Si asta e considerat top rpg.

Jocuri bune mai apar cand vin devii aia vechi si reinvie IP-uri iubite (eg; Pillars of Eternity).
Sau concepte noi implementate bine, cum ar fi Kingdom Come Deliverance.

Aproape ca as dona un rinichi sa vad echipa originala Piranha Bytes sa mai scoata ceva gen Gothic 1/2 sau Risen. :grinning:

9

Mie imi place cand cineva vine si, intr-o discutie despre calitatea indoielnica a software-ului, trage linie la framework-uri. Da, soft-ul care exista e prost, da’ framework-urile sunt solide si verificate.

Mai ales cand vine din tabara connoisseur-urilor fini intr-ale npm-ului care stiu ca un pachet de-al lor ultra-testat a scuturat 30% din Internet.

Stiti ce mi se pare tare la Node.js? Ca pentru a folosi mysql ai nevoie de pachetul mysql2 ca prima versiune deja este depasita.

Mai la subiect, am avut azi de modificat ceva folosit dintr-ale framework-ului si… Nimic. Nu e documentata functionalitatea asa ca tot ce a ramas e sa citesc tot codul sursa.

1 Like
10

daca frameworkul nu e solid, nici nu trebuie sa il folosesti, in java sunt framework-uri si librarii solide, atunci se pune probleme de ce folosesti node.js pt backend, unul din motivele majore pt care nu as folosi e platforma in sine, librarii, framework-uri etc, cine a ales node.js sa isi asume.

2 Likes
11

poate pentru ca nevoia de software a fost mai mare decat capacitatea de productie si nu prea a fost timp pentru “dezvoltare durabila”.

tehnologiile software au fost si ele influentate de cele hardware si de cresterea lor rapida (cine isi mai pune acum problema de cati kilo ocupa codul in asm si daca incape sau nu in memorie?)

aici cred ca tine si de impresia pe care vrei sa o lasi clientului.
cum ar fi sa ii livrezi un landing page html scris in 2 ore fata de macar 3 zile full cu librarii si tehnologii moderne? care e afacerea mai buna pentru firma la care lucrezi si cum s-ar uita cfo-ul la tine dupa cateva faze din astea?
\off: asta e ca in bancul cu avocatul junior care ii rezolva problema “cronica” a clientului in o singura sedinta :slight_smile:

oricum, situatia pe care o prezinti eu am intalnit-o (in esenta, nu fix in forma asta) si acum 10 ani si acum 20 de ani si in proiecte in ro si in proiecte in fr/de, doar ca nu generalizata probabil.
dar mai des intalnita la firmele mai mari fata de cele mai mici.

ca idee, in unele dintre cele mai eficiente proiecte ale mele am programat singur (dar am avut ajutor eficient si de la restul celor implicati - adica echipa ok, proiect ok, bani ok, etc), iar in unele dintre cele mai putin eficiente proiecte ale mele am programat tot singur (dar ori echipa, ori clientul, ori subiectul deveneau mai putin ok si cheful / eficienta mea dispareau si ele).
doar ca in ziua de azi nu prea mai e o solutie sa programezi singur.
totusi, ideea de aici cred ca e despre cum iti faci echipa si despre skillurile tale de leader / manager / etc (daca tu esti cel responsabil cu asta) sau despre inspiratia cu care iti alegi echipa in care intri daca doar programezi.

mie mi se pare o eroare de management daca un client ajunge la un dev si ii cere o modificare pe care devul o si face.
la fel, daca ii ceri unui dev sa scrie o chestie si el o face intentionat altfel sau refuza… pare o problema de integrare / autoritate / leadership.

12

O alta problema e ca programatorii iubesc soft-ul. Insa pentru business acesta e doar o metoda de a face profit. Si profitul ne intereseaza cel mai mult.

Daca putem face bani fara sa scriem o linie de cod, asta e metoda preferata. Urmatorul nivel e sa ai cod prost (sau simplu) care genereaza profit si ultimul nivel e sa ai cod bun care genereaza profit. Insa de ce nu ai nevoie e cod bun sau prost care nu genereaza nimic. De ala nimeni n-are nevoie.

Problemele cele mai mari le am cu persoane pentru care “calitatea codului” e cea mai importanta virtute. Inteleg, si eu eram asa la 20 de ani. Dar e mult mai bine sa ai un cod vraiste care face 100.000 de euro pe luna acum decat sa stai un an sa scrii cel mai frumos cod cu jurnalizare, validari, structura solida, etc. ca sa faci probabil tot 100.000.

Business-ul si managerul nu dau doi bani pe cod care nu genereaza bani. Am avut un “technical debt” imens strans in 10 ani. Am rescris aplicatiile in cateva luni. Codul e ieftin. E simplu sa scrii cod, sa scrii query-uri, sa faci clase. In patru ore pe zi scoti 500 de linii de cod. In cateva saptamani faci o aplicatie destul de buna. Ceea ce conteaza e know-how-ul proceselor business-ului. Sa faci o clasa pentru API-ul unui furnizor dureaza vreo 2 - 3 zile. Sa-i intelegi toate limitarile si cum vrea el sa functioneze in realitate (in lipsa unei documentari cum mai toate API-urile europeene vin - ador cand citesc mesaje de eroare in germana), asta dureaza ani.

3 Likes
13

de acord, dar oare problema vine exclusiv de la ei?

acum 15 ani se putea intampla sa fie necesar sa aduc o completare aplicatiei pana la o ora anume din zi, eu fiind in alt oras, iar ziua de weekend (bine, completare dictata de noi contracte / clienti, dar necesarul era ca la ora x… catev sute de vizitatori sa poata face niste chestii in site).
cum netul mobil mergea mai lent pe atunci, iar laptopul nu era suficient de comod pt a fi setupul principal pentru lucru… taskul se rezolva operand direct serverul live, cu minim de testare.
si acum ma mir ca lucrurile alea s-au terminat bine dpdv tehnic.

totusi, lucrurile au crescut intre timp si programatorii nu au mai putut duce singuri / in echipa mica modificarile si expansiunea businessului… si au aparut doua noi situatii: esecul codului (prea mult sa fie gata la timp sau prea netestat sa mearga bine) + nevoia de colaborare cu mai multi programatori pentru aceeasi bucata de aplicatie.

si atunci businessul a avut nevoie de asigurare suplimentara, de redundanta, de modularitate, etc.
deci si nevoie de cod frumos scris si documentat si etc.
si managerii au insistat atat de tare pe chestia asta… incat acum avem ce spui tu: programatori care si-au dezvoltat partea care li s-a cerut - forma codului… si au lasat logica businessului in seama altora (care probabil nu il comunica suficient de clar catre ei).

nu spun ca imi place situatia, dar asta e impresia mea despre ce spui aici.
sunt de acord cu situatia, dar identific problema dincolo de programatori.

2 Likes
14

Acum daca vorbim de clean code si best practices sa nu ne inchipuim ca toti programatorii se preocupa de aceste aspecte. Asa e prin toate meseriile, de exemplu cati constructori ai vazut facand ziduri sau garduri drepte? Daca un om este imprastiat, dezordonat, daca pentru el nu conteaza detaliile, daca nu e perfectionist intr-o oarecare masura, atunci calitatea maxima a muncii lui va fi exact in aceasta directie.

3 Likes
15

Au fost puse de lume salariile pe Salarii 2023 • zoso blog. Jesus! Constant 8000 de euro pe luna ca B2B. Unul angajat la Google cică 570.000 USD pe an.

Asta explica multe. De aia ma lupt cu cele descrise mai sus, unde suntem noi sunt doar amatori, atat pe partea de business cat si la programare.

2 Likes
16

Cei care lucreaza cu Elvetia au salarii de minim 8-10k euro fiindca acolo salariul mai mic e salariu de frizer. (Google e tot Elvetia)

Dupa ai oamenii care chiar sunt buni si au si negociat bine. (sunt destui)

Dupa suntem restul care lucram pentru Germania/Anglia/SUA dar nu la top-level direct, prin intermediari. Eu de exemplu stiu sigur ca intermediarul meu mai ia tot pe atat cat iau eu si nu e chiar mic venitul, dar nu pot lucra fara. Unii mai lucreaza si cu 2-3 companii (bine alese) deodata si asa ajung lejer la 10-15k euro de exemplu.

In Romania firmele mari au linii date de management (care vor sa arate cum pot reduce costurile) si acum omoara toata industria de IT locala. E.g. se angajeaza doar din Bucuresti/Cluj, hybrid work, salariu care trebuie sa intre in limitele companiei, nu limitele din industrie/experienta/rol. (daca ai o companie cu specific non-it cu departament de R&D celelalte salarii vor trage in jos maximul pe care il pot oferi unui developer) Bonusuri anuale cu N conditii daca te angajezi pe CIM. Cei de pe HR sunt disperati ca nu gasesc oameni. (calificati si la salariul dorit, ca oameni sunt…)

Apropo, la stat lucreaza doar cine n-are alternative, nu vrea sa treaca la urmatorul nivel sau are ceva aspiratii politice. E greu sa te angajezi, e complicat si e prost platit.

1 Like
17

Acuma nu chiar te lua dupa ce e la zoso in comentarii. Aia multi cu 1-1.5-2k pe luna nu comenteaza ca nu-s extreme. Plus ca nu te doare tastatura sa zici ca faci ț-șpe mii de euro pe luna doar ca sa vezi reactii.

6 Likes