Profit center vs cost center e mai degraba o chestie de “mentalitate” daca vrei, decât de profitabilitatea companiei in sine.
In general startup-urile încearcă să ajungă cât mai mari cât mai repede. Asta e definiția până la urmă. Că și într-o investiție cheltui niste bani acum (astfel “profitul” este negativ) în speranța că vei avea un return mare in viitor. Nu știu dacă trebuie neapărat să dai o dimensiune morala aici.
Dar sa presupunem că angajați un programator (sa zicem că are 5 ani pe java cu spring) average de la o firma de outsourcing. Sa zicem că stă 1-2 ani și după vrea sa plece că nu-i mai place sau că e PIP-uit*. Acum daca vrea sa se întoarcă înapoi la o firma de outsourcing (pentru că numeri pe degete firmele de produs in care e și gândirea că bazele contează nu frameworkul) ce face, îi folosește la ceva experiență de 2 ani pe node și frameworkul vostru, cel puțin din punct de vedere al interviului?
*La companii de produs unde e competiția mare, leafa peste piata, se mai dau oamenii afara. Spre exemplu la Amazon e URA policy, unde bottom 10% e fire-uit in fiecare an.
Si eu m-as baga in categoria jack of all trades, si sincer ma ajutat articolul lui @horia141 putin pentru moralul meu, dar ma ajuta si ce a zis acum ca in multe cazuri jack of all trades este exact ce este nevoie. Logic inteleg de ce este asa si mi se pare normal, dar in realitate m-am descurajat la unele interviuri, chiar daca stiu ca am tintit pt pozitii puternice, unde se intra foarte greu.
Ah, nu mi-a fost intentia, cred ca mai mult te-ai simtit tu, sau m-am exprimat eu gresit. Oricum e foarte discutabil ce este moral/immoral in lumea companiilor, pentru ca nu este vorba despre un individ, ci despre o eticheta mai abstracta.
Cum zicea si Stalin, o moarte e tragedie, 1000 de morti e o statistica.
Thin line.
Poate te superi pe mine, dar afirmatia ta e evident ca e complet gresita.
Cum sa spui ca experienta cu un limbaj, tehnologia sau framework nu conteaza pentru un developer?
Poate nu conteaza pentru un project manager, dar pentru un developer, care lucreaza zi de zi cu mizeriile low level, trebuie sa fie foarte apropiat de cum merge dracia.
Daca nu trebuie sa stie detallile, atunci cum stie sa aleaga o librarie sau alta, un API sau altul, etc. E un non sens. Ce face, le alege palea cu numarul cel mai mare de stele de pe github?
Poate tu vrei sa spui ceva, si poate ai dreptate in ce vrei sa afirmi, dar poate ar trebui sa-ti alegi alt argument pentru ce vrei sa afirmi.
Conteaza si nu conteaza.
Pentru o companie de outsourcing coneteaza foarte mult, vrea sa te vanda din prima zi. Pentru Bolt nu conteaza, pentru ca are capital sa investeasca in tine 3-6 luni pana ce inveti necesarul pentru a putea sa-ti faci jobul de zi cu zi, bine inteles ca nu o sa devii expert, dar nici nu e o cerinta.
Idea de mai sus devine mai logica cand te gandesti la o cerinta mai complexa. Sa zicem hai sa facem un server de stocare a fisierelor, care iti sunt primele intrebari la care te gandesti auzind cerintele?
etc.etc.etc.etc
Pornind de la cele enumerate sus, suntem foarte departe de o implementare exacta, care sa mai fie si constrans de un limbaj/framework anume. Majoritatea pieselor de care ai nevoie, o sa fiu prezente in fiecare limbaj general, (daca nu ai nevoie de ceva domain specific, dar pentru joburile alea sunt si alte cerinte).
90% poate e exagerat, poate sa depinda si de context, dar nu cifra a fost esenta gandului.
Pai de-aia ajungi sa vezi cod de 2 bani pe o groaza de proiecte, de la mentalitatea asta ca “nu conteaza tool-ul” si ca “dupa o saptamana scrie cod de productie, fiindca stie fundamente”.
Am vazut destul cod JS scris de java-devi care incearca sa implementeze toate patternurile din Java pe front-end. Probabil ca si ei aveau impresia dupa o saptamana ca scriu cod calumea. Cand am preluat un proiect de la niste “consultanti top-class” si am vazut ce era in el, echipa in care eram atunci (toti aveam >3 ani exp in JS), am ramas masca.
Dar hei, technically you don’t write crap code, decat daca si altii isi dau seama. In cazul unor echipe din astea, nimeni in echipa nu cunoaste bine limbajul, asa ca they’re all winging it. Apoi dupa 3 ani lucreaza altundeva si PO-s nu inteleg de ce proiectul a devenit so hard to maintain.
Da, am obs, si dau vina pe echipa curenta, nu pe ei ca au angajat echipa initiala, de ex eu am in proiectul cu lucrezele multe chestii facut doar pe CV, cam tot ce a fost la moda sa bagat de-a lungul timpul, kotlin, mongodb, graphQl, python, etc. multe nici nu se folosesc pt ca nu le-a iesit, dar trebuie totusi mentinute
Strict părerea mea - e un punct de vedere extrem de pesimist. Întradevăr e o grija corecta. Așa ceva se poate întâmpla.
Dar riscul mi se pare infim - sa fi deajuns de bun sa treci de un interviu, dar nu deajuns sa te descurci in companie, dar acest lucru sa fie vizibil de-abia după 1-2 ani și nu în timpul perioadei de proba, și în acest timp skillurile cu Java sa se fi atrofiat iremediabil, și piata de outsourcing din Romania sa se fi schimbat intr-asa fel încât caută doar oameni cu 7+ ani experiență în Java și întorc spatele la oameni cu 5 ani de experiență plus ceva extra dintr-o companie demanding de produs, si drept urmare sa nu te mai poți angaja chiar niciunde in industrie sub nicio forma, etc …
Una dintre ideile implicite din articol este că e un moment foarte bun pentru riscuri in plus. Piata este atât de hot, încât după orice problema profesionala se poate ateriza in picioare. Nu a fost mereu așa, și e foarte probabil sa nu dureze indefinit. Dar acolo unde e risc, sunt și șanse de creștere profesionala, extra compensation, etc.
De adăugat că un codebase clean e ceva foarte rar. Majoritatea dau YOLO prin proiecte după cum îi tăie capu, indiferent că au ani de experiență în stackul respectiv.
Nu ma supar. Ma bucur ca avem o discutie aici. It beats “no reaction”. Dar chiar ma gandeam ca o sa fie o chestie de genul “preaching to the choir” pe partea de limbaje. In schimb văd că nu-i o credință universala
Să fac o gluma. Avem:
Make up your mind! 
In orice caz nu am zis că cunoașterea limbajului și ecosistemului nu sunt importante sau că nu contează pentru un developer. Sunt și contează. Până la urmă sunt modul în care toate celelalte se materializează.
Claim-ul meu e că relativ la toate lucurile pe care trebuie sa le știe un dev, cu precădere unul experimentat, sunt minoritare. Și că odată stăpânit un “ecosistem”, este relativ ușor de tranzițional într-un altul. Pentru că nu trebuie să pornești de la 0. Ci ai deja 90% din ce-ți trebuie acoperit, sub forma acestor skill-uri independente de ecosistem. E foarte probabil.ca niciun alt skill luat separat sa nu constituie mai mult 10%, dar luate împreună …
Mă gândesc că e o chestie de “blestem al cunoașterii”, in care nici nu mai ști cate lucruri cunoști pe care un novice nu. Ditto, prima oara când înveți programare, înveți mult mai multe despre cum funcționează un calculator. Nu doar limbajul de programare. Și poate e riscul de asociere prea strânsă între acestea.
Mă gândesc așa la o lista neexhaustiva dar aplicabilă orarui dev de “lucruri mai importante decât limbajul in sine” după mintea mea: gândire sistematică, abilitatea de a exprima soluții/legi/principii/etc in cod, cum funcționează un calculator, algoritmi, structuri de date, sisteme de operare (+ particularități a la Linux vs Windows), rețele și protocoale specifice (TCP, IP), HTTP, baze de date, sisteme distribuite, design patterns, limbaje&compilatoare, statistica, ceva matematica, software engineering practices (clean code, clean architecture, DDD, and friends), hardware mai serios, OOP, etc. Clar nu trebuie sa fi toba de ele, și clar nu ai ce sa faci cu ele daca nu le poti exprima in cod in vreun fel. Apoi mai sunt cunoștințe de “background”, și apoi de domeniu de business care cântăresc și ele ceva, dat care sunt portabile. Dar odată ce ai un toolkit format într-un ecosistem, este relativ ușor să le portezi într-un nou ecosistem (ie statistica rămâne la fel, modul de interacțiune cu SO-ul se schimbă ceva, etc). Mai ales că tranziția asta este de multe ori între Java, C#, Python, PHP, Go, Ruby, JavaScript, etc. Câteodată C++, câteodată Perl, câteodată Scala. E așa de multă cross-pollination între limbajele astea …
Pe partea de hiring multe companii au ales să țină seama de treabă asta, și să nu mai aibă că requirement strict experiență fix pe tehnologia pe care o folosesc. Iarăși multe nu fac asta. Cred că sunt companii faine de ambele tabere, dar empatizez mai degrabă că și construcție cu cele din prima tabără. Așadar lor le cânt odele 
Dar problema nu e la developers, eu am lucrat cu nodejs, si nu mi-a fost greu sa ma obisnuiesc, conceptele sunt la fel, am mai citit o carte, documentatie etc. dar problema e la angajatori, se uita cu asa… weird daca tu vrei sa te angajezi pe java dar nu ai facut java de 2 ani de exemplu, bolt e o exceptie, dar multe firme nu se complica cu “ii invatam noi”, “le dam timp sa se accomodeze”, nu risca, la interviuri te intreaba de librarii pe care ei le folosesc, pe mine nu m-am angajat de exemplu la luxoft pt ca veneam duoa un gap de 1 an, cand am vurut sa tranzitionez spre alceva, non-IT, de fapt veto-ul nu a fost de la luxoft, ci de la client-ul luxoft.
Desi sunt de partea cum ca un dev trebuie neaparat sa stapaneasca fundamentele, iar un angajator are mult mai multe de castigat daca are procesul de selectie orientat catre fundamente(si nu catre limbaje, frameworks si tool-uri), a stapani minim 1 limbaj din astea mai populare e de bun simt.
Acuma…eu de exemplu sunt de parere ca un om care stie bine java, poate invata go relativ repede. Doar sa isi doreasca asta 
In compania unde lucrez acum avem foarte multi go devs care inainte au facut php sau java. Si se descurca foarte bine. Daca am fi cautat exclusiv go devs, va asigur ca am fi avut cel putin 2 proiecte maricele neimplementate in ultimul an.
Ca si companie, e bine sa faci si un calcul de cost de oportunitate. Cat de mare este acel cost in cazul proiectelor nedezvoltate in comparatie cu angajarea unor devi care au lucrat inainte pe alte tehnologii si probabil learning curve-ul initial ar fi maricel.
For sure. E un alt articol pe care-l scriu despre anti-pattern-uri la companii.
Dar ca totusi nu mai e atat de rau cat era pe vremuri. Am asa o lista de 20+ de companii faine de produs din Romania, unde conteaza mult mai putin “sa sti fix libraria pe care o folosim azi”, si mai mult capabilitatile de inginer.
@horia141 Horia, am urmarit o prezentare de-a ta anul trecut la devtalks daca nu ma insel si mi s-a parut extrem de interesanta. Ma bucur ca avem oameni ca tine la noi in comunitate!
Ma mira foarte mult sa aud asa ceva.
Un developer investeste extraordinar de mult timp invatand o groaza de lucruri de detaliu, care nu se transpun absolut deloc. in alte limbaje/frameworkuri/tehnologii. Daca se transpun intr-atat incat sa fie aproape identice, te poti considera foarte norocos.
Am spus deja asta, e vorba de sintaxa, API-uri dar si tooling. Exista intr-adevar niste pattern-uri, cum sunt design patterns, dar sunt destul de putine.
Iar in ceea ce priveste comonalitatea dintre toate limbajele/frameworkurile/librariile: aceastea au lucruri in comun, dar care sunt mai mult bazate pe lucruri de baza din computer arhitecture, deci sunt destul putine. De exemplu, te astepti sa existe variabile, operatori, functii, callstack, acces la storage (scriere/citire), etc. Dar fiecare va avea caracteristicile lui, API-ul lor propriu, optimizarile sale, etc. Sa le stapanesti si sa le alegi corect, necesita foarte mult timp.
N-am inteles gluma/cele 2 bullet point-uri. Care este logica de “ori” dintre ele?
Cele 2 bullet point-uri sunt complementare mai degraba.
Va dau un exemplu foarte simplu de ce nu se transpune:
Dacă pui un Java dev pe React o să fie ca un pește in desert.
Nici un pattern din Java nu e o idee bună pe front-end.
La fel și pe Go, un Java dev o să fie foarte frustrat când trebuie să dea copy paste în loc să facă overloading.
Este vorba (și) despre cât de repede se adaptează peștele ăla în deșert.
Pe Arrakis erau păstrăvi de nisip, soooooooooo… 
Tin sa va reamintesc ca prin unele licee se face C/C++ ca prim limbaj de programare. La facultate algoritmica se facea in C++ de asemenea in primul an. Aveam colegi care nu au mai facut programare pana la facultate (weird, I know) si care au inceput cu C/C++. Si apoi treceai prin restul (Java, C#, Lisp, ASM, etc.)
Exact, doar ca daca nici ceilalti colegi nu stiu (ca si ei au venit de pe Java si au bagat cod React de 2 bani in productie, din prima saptamana), iar managementul habar n-are, o sa creada ca fac o treaba buna.
Partea nasoala e dupa 2-5 ani, cand vin altii si trebuie sa-l mentina. Aia de la inceput vor fi de mult plecati.
Am patit pe 2 proiecte diferite, firme diferite. Cel mai rau cod de JS/React pe care l-am vazut, scris de catre devi veniti de pe Java. Mai era nasol si sa le dai feedback - la unii - , ca aveau 10 ani de experienta (overall) si “stiu ei mai bine” decat unul cu 3-5 ani exp.