Firma mare vs firma mica la inceput

21

Asta cu ‘extraordinar de bine’ e rezervata unor foarte putini…

Iar conceptul e gresit. Unii isi imagineaza ca aia foarte buni pe niste domenii inguste nu le au in general, ceea ce e adeseori foarte fals.

Isi imagineaza cineva ca Steven Weinberg, laureat al premiului Nobel pentru ca a revolutionat teoria campului cuantic, nu le are cu cosmologia? Eu zic sa se gandeasca bine inainte de a arunca cu presupusul. Macar sa arunce un ochi pe biografia respectivului.

Sau ca Susskind, expert in teoria superstringurilor, nu le are in general cu fizica? De-aia a predat la Stanford ‘minimul teoretic’ acoperind o particica buna din ea?

Sau ca Feynman, si-ala cu Nobel pe chestii cu camp cuantic, nu le avea cu fizica in general? Are niste carti destul de bune pe tema asta, contrar teoriei ca astia nu se pricep in general.

De ce ar avea ceva special partea asta cu programarea?

2 Likes
22

Vad foarte multe generalizari pe aici vizavi de cum sunt firmele mici sau mari. Ca inveti x colo si y in partea cealalta. Ma abtin sa comentez pentru ca fiecare are experiente diferite, dar va zic ce as face eu daca as luao de la 0 maine: as evita firmele mici. Motive sunt…mai multe.

  • da, intr-o firma mica ajungi sa faci lucrezi pe mai multe proiecte si sa faci frontend, backend si devops. Dar ce te face sa crezi ca le vei invata decent? In majoritatea cazurilor o firma mica se multumeste cu “good enough - pune in productie ca am promis clientului”.

  • eu personal am invatat in companiile mari in 1 an cat in 4 ani in companii mici. Emag fiind una dintre ele. Nu am facut frontend la emag, dar am facut de toate pe partea de backend. Am invatat ce inseamna cu adevarat o baza de date “mare”. Am invatat arhitectura software si system design. M-as mira sa se faca ceva similar la o agentie de cartier.

  • majoritatea firmelor mici(pe care eu le cunosc) nu au auzit de code review. Sau il fac la misto.

  • majoritatea firmelor mici pe care eu le cunosc nu au auzit de unit testing sau il fac la misto.

  • majoritatea firmelor mici nu au auzit de CI/CD!

  • in firmele mari ajungi destul de repede sa te lovesti de scenarii pe care nu le gasesti in tutoriale pe udemy. Atunci vei fii obligat sa iesi din comfort zone si atunci vei invata cel mai mult.

  • daca vrei sa devii freelancer mai tarziu in cariera, probabil o firma mica is the way to go.

  • nu ignora personal branding-ul. Un CV in care ai fost intern la Adobe mi se pare mult peste intern la SC Agentie de cartier SRL

7 Likes
23

Unul arunca o piatra si 10 o cauta, OP pare un cont facut la misto, m-as mira sa citeasca pe aici.

2 Likes
24

Oameni extraordinari se dau exemple doar în conferințe motivaționale. Noi (eu cel puțin) suntem oameni normali.

Eu sunt adeptul assembly-line-ului, l-am studiat și experimentat și, cel puțin în zona germană, e aplicat încă cu succes. Legăturile le face managementul, inexistent în firmele mici.

Eu am lucrat în firme minuscule (eu sau eu și șeful), mici (până în 20 de oameni), imense (peste 100k angajați) și la stat. În firmele mari există multă politică (pupatul șefului în dos) și de cele mai multe ori oamenii nu sunt apreciați corect, dar există regulamente și proceduri care oferă șanse tuturor. Micimea firmelor mici se vede în tot.

Eu nu zic că oamenii habar n-au de altceva în afara specializării cum nu spun să termini facultatea învățând la o singură materie, dar să fii matematician, fizician, chimist, filozof și pictor în același timp nu se mai poate.

25

Ce ți se pare la mișto in subiectu asta? E foame crunta de oameni pe piata, când ești la început nu știi unde sa te duci, poate o alegere naiva să îți ruineze cariera.

O chestie nu o înțeleg, fie firma mică sau mare, in Romania, cel mai probabil faci outsourcing. Adică ești contractor pe un proiect, într-o echipă de la client, cu developers de la client. Nu contează mai mult clientul firmei, decât firma in sine?

Foarte multe firme mari îți asignează un buddy/peer/mentor/God care sa te ghideze, nu ar reprezenta și asta un avantaj?

26

Nu stiam ca vorbim chiar de un domeniu asa de larg.

Dar fie. Uite ca se poate.
Nu se poate excela in toate, dar se poate.

Feynman ala de l-am pomenit mai sus, vedea o matematica dincolo de ce vede omul care termina matematica la o facultate obisnuita de prin Romania. Motivul e ca ai nevoie de matematica serioasa in fizica, nu se poate fara. De fizica nu mai zic, dar suprapunerea cu chimia e destul de mare ca sa nu poti spune ca habar nu avea de chimie (de altfel, exista fizicieni care au luat Nobel in chimie, ba chiar Marie Curie a luat Nobel si in fizica, si in chimie).

Daca ii lecturezi cartile alea mai cu povesti (sau chiar cele de fizica), se poate spune ca si filozofa. Filozofii de meserie ar zice ca slab, el ar zice ca aia aiureaza cu filozofia lor. Avea dreptate :slight_smile:

Mai si picta pe deasupra. Se mai ocupa si de muzica. Se poate argumenta ca era amator. Totusi, cu arta statea mult mai bine decat aia de au vandut cu sume serioase banane lipite cu banda pe perete.
Indivizi care sunt declarati experti.

3 Likes
27

Nu fi chair asa de dramatic.
La 21-22 de ani esti la start

Ai inca timp sa mai schimbi.

1 Like
28

Se simte de la un km daca o firma face ce trebuie sau nu. E posibil sa dai pe un proiect urat, dar daca celelalte sunt in ordine poate esti exceptia.

In 2021 un proiect sanatos ar trebui sa aiba code review obligatoriu, unit teste la fiecare pull request (care sunt rulate automat si conditie obligatorie ca sa treaca la fiecare PR), contract testing daca ai microservicii sau teste e2e/smoke-uri rulate la fiecare build, smoke testing automat la release daca proiectul permite, un sistem de CI/CD care face build-ul si ruleaza automat testele si te anunta pe slack cand ceva cade, toate artefactele (pachetele npm de exemplu) sunt stocate pe un server al firmei cu artifactory/altceva si nu descarci random de pe npm. Pe frontend obligatoriu cat mai mult TypeScript cu prettier/linting la fiecare dev. Pe backend in mod ideal ai diagrame la endpoint-uri in documentatie, nu e doar codul. (asta inseamna ca s-a facut review la backend din punct de vedere al arhitecturii si securitatii) Proiectul cel mai bine e structurat pe trunk-based development, adica monorepo ca sa gasesti tot ce iti trebuie cat mai usor. Pe devops ar trebui sa ai om dedicat pe proiect, nu te bagi ca dev in pipeline de fiecare data cand e o problema. (ca pot fi probleme zilnic) Release-ul nu se face de developer ci de catre un program manager/manager/PO cu ajutorul unui buton care ia din env-ul de QA si pune codul in staging/prod. Orice proiect serios are minim 4 medii de lucru: develop, QA, staging si prod, dev-ul are control doar pana la/doar asupra unui pipeline (buton) de Promote to QA, in rest nu mai e al lui (in mod ideal ai cel putin un QA la fiecare dev care iti face testare de explorare/trece prin test case-uri sau le scrie si le automatizeaza). Pe fiecare env ar trebui sa se ruleze testele de smoke automat inainte si dupa un release. Release-urile obligatoriu trebuie sa poata fi restaurate dintr-un buton daca e o problema. Nu se face release vineri sau la sfarsitul programului. Dev-ul nu are acces la credentialele/log-urile de pe prod si nu are ce sa caute cu ssh pe serverele de prod. Exista un log analysis tool pe proiect in care se centralizeaza toate log-urile. Ca si procese ai un daily care ar trebui sa tina cat mai putin posibil, se face peer programming, ai sprint planning/refinement-uri cu product owner-ul, ai retrospectiva la sprint, ai un sprint de 2 saptamani sau mai mult cu retrospectiva la final. In mod ideal fiecare din echipa stie sa scrie teste end to end si exista o platforma cu test cases/test plan si o suita de teste sau se face cucumber/BDD. In mod ideal ai un one to one cu managerul saptamanal/la doua saptamani. Nu se lucreaza peste program si nu se lucreaza in weekend. Exceptie daca e nevoie de ceva release care se poate face doar in weekend. (dar doar cineva senior ar trebui sa faca release in weekend cu totul pregatit, adica planned maintance) Ai un salary review la 6 luni, ar trebui sa iti poti lua o zi libera oricand in timpul saptamanii si oricat daca anunti din timp. Ca si hardware iti trebuie minim 16Gb RAM cu un Core i7, doua monitoare (preferabil mai bun de 1080p) si 32Gb RAM daca ai kubernetes. La firmele care se respecta toata lumea are mac-uri de ultima generatie sau desktop/cloud server + laptop daca faci game development. O atentie foarte mare legata de scaunul ergonomic si masa, la birou ar trebui sa ai un scaun ergnomic (alea de 1500+ lei cu tetiera, nu chinezarii) si o masa reglabila. Inclusiv acasa unii ofera buget/scaunul de la birou.

La o firma mica serioasa poti intreba pe oricine sa te ajute, ai un intreg etaj care te ajuta daca poate. La o firma mare trebuie sa planifici un meeting despre aproape orice la inceput. Buddy-ul o sa iti explice cum functioneaza bucataria si o sa te ajute sa cauti in ce echipa trebuie sa cauti omul care te poate ajuta. Chiar o sa iti puna tot felul de meeting-uri inutile, one on one-uri care o sa te streseze ca sa vada daca lucrezi. Risti sa te intrebe daca vrei un training despre X fiindca a vazut ca ti-ar prinde bine si dupa stai in meeting-uri la care aproape adormi si iti vine sa iti tai venele. Intr-o firma mare trebuie sa iti faci o strategie personala, sa vezi ce accepti si ce nu ca totul are pro si cons. Trebuie sa ai grija ce faci ca e mare politica in echipa, adica daca apelezi la ajutorul cuiva trebuie sa te ridici la nivelul cerut de el, altfel cand trebuie o aprobare te rogi o saptamana de ei. La peer programming e greu daca unul cunoaste si celalalt nu codul, o sa te ia de prost la aproape fiecare meeting si o sa fie greu de lucrat cu unii oameni, in special cand nu ai alternativa.

Daca poti angajeaza-te din start la o companie foarte cunoscuta, o sa te ajute mult in CV. Daca nu poti la outsourcing conteaza mai mult proiectul si echipa decat firma.

Totusi cum in ziua de azi competitia e extrem de mare la nivelul de entry level, e.g 500 de candidati pe un post, cea mai buna strategie zic eu e sa te angajezi unde gasesti loc si se lucreaza cu ce iti place tie.

9 Likes
29

Cred că se amestecă un pic lucrurile, de fapt sunt mai multe categorii.

  • firmă mare care face outsourcing
  • firmă mare cu produsele lor
  • firmă mică cu produsul ei
  • firmă mică ce face outsourcing
  • firmă mică ce lucrează pentru clienți mici pe proiecte mici

Nu trebuie să lucrezi la emag să ai acces la baze de date cu sute de milioane de înregistrări. E suficient o firmă mică ce are un produs cu mii de clienți. Pentru că acces la proiecte mari probabil nu va avea prin outsourcing.

Eu zic că fiecare are beneficiul și momentul ei. Din experiență eu pot da un singur sfat:

Job-ul care îl faci trebuie să contribuie și el la dezvoltarea ta, nu doar tu la dezvoltarea lui. Adică dacă simți că nu evoluezi sau involuezi, nu ai de ce să simți remușcări dacă vrei mai mult, să pleci.

Peste ani nimeni nu te va plăti în plus pentru fidelitate, ci pentru expertiza acumulată. Iar datoria cea mai mare o ai față de tine și dezvoltarea ta, nu față de firma la care lucrezi. Și asta e valabil în orice domeniu nu doar programare/IT.

E plin de marketing și BS corporatist care să te facă să stai acolo să le faci ce au ei nevoie (normal).
Dar când te dau afară pentru că nu mai au nevoie de tine și rămâi cu niște skill-uri care nu te vor ajuta să te angajezi altundeva, nu o să te ajute la nimic BS-ul ăla corporatist.

10 Likes
30

Bine zici. Dar mai exact ce înțelegi prin a te dezvolta ? Să înveți din arhitectura proiectului și din codul scris de colegi? Sa te uiți la tutoriale de pe contul de pluralsight al firmei?

Acuma din review la pull requesturi nu știu cât înveți, că nu faci 100 de pull requesturi și nici nu e văzut bine de management un pr cu multe revizii. Am pățit sa mi se scoată ochii că aveam vreo 30 de commenturi la un pr mare, și nu erau pentru denumiri de variabile.

31

Cred că faci confuzie între multe revizii vs ce trimiți la PR.

Utilitatea Git este că îți permite sa te întorci la diverse puncte în istoria proiectului, iar într-un repo multi-branch, aceste puncte sunt la merge pe branch-ul de producție (e.g. release, master, prod sau cum s-o numi).

Atunci când ești pe branch-ul de producție vrei să te întorci la ultima revizie funcțională în caz de. Și parcă n-ai vrea să cauți ce revizie a introdus bug-ul ăla la payments printre commits de genul „fixed typo” și „update readme”.

Oricum, rezolvi cu un squash.

32

Era jargonul pe care îl foloseam intern pentru un pr cu multe commenturi.

33

Management-ul nu se uita la PR-uri, de multe ori n-au nici cont de git…
In echipa si proiect ai standarde si conventie pentru git, daca cei seniori zic sa faci doar rebase si ammend la primul commit in PR asa faci. (la un monorepo asta e standardul peste tot)
Daca ai monorepo nu iti faci branch ci faci PR direct din develop cu scriptul pe care il folositi. Daca nu ai iti denumesti branch-ul dupa conventie ca sa apara automat in confluence.

La code review o regula foarte buna e sa faci PR cum ai ceva schimbare, sa ai maxim 5-10 fisiere, sa nu strangi 20 de fisiere ca dupa le faci viata un chin tuturor.

A te dezvolta inseamna sa te dezvolti din punct de vedere tehnic si soft skills, adica sa poti tine prezentari, demo-uri, sa poti vorbi si negocia cu ceilalti colegi ca sa livrezi la timp, sa ii prezinti solutii alternative la client, sa vii cu initiative, sa vorbesti profesional, elegant si politically safe. Din punct de vedere tehnic ca si incepator iti garantez ca n-ai nici o treaba cu testarea, primul pas ar fi sa inveti pe un proiect real cum se testeaza, ce inseamna un test bun, cum se testeaza manual, cum se raporteaza un bug, cum scrii teste end to end, cum poti scrie teste inainte de cod, cum sa testezi cat mai mult cu cat mai putin si fara sa fie flaky.
Pe langa asta ai design patterns, best practices si antipatterns, in programare mai nimic nu e alb cu negru. Trebuie sa intelegi cand un antipattern e o idee buna ca sa livrezi la timp si sa fie clientul multumit si cand e un technical debt. La fel si un best practice poate fi o prostie in unele cazuri. Trebuie sa inveti sa ceri ajutor cand trebuie.

34

În primul și primul rând, evită locurile unde se folosesc chestii custom și non-standard.

Când mai aud că sunt în 2021 firme ce nu folosesc un framework PHP de ex că au ei unul mai bun, mai bine nu. Sau folosesc ceva obscur ce nu e în top (laravel, symphony, eventual zend cu indulgență).

Sau ce nu folosesc una din cele top 3-4 framework-uri javascript (react, angular, vue) ci ceva obscur sau mai rău, ceva custom, la fel, de evitat.

În lumea Java nu știu, dar și acolo aș merge pe același principiu. Cu cât e mai obscur ecosistemul pe care lucrezi, cu atât riști să te plafonezi și să pierzi contactul cu industria și să nu fii angajabil.

Da, știu teoria că ‘un programator adevărat învață orice framework imediat’ dar pe partea ‘business’ altfel arată pe un cv react/laravel/etc - 3 ani față de php/mysql/javascript/ care nu spune multe.

Evident, sunt și excepții de la regulă, gen dacă ești expert pe ceva obscur dar foarte foarte folosit, gen mainframe-uri și sisteme bancare vechi pe fortran, atunci discutăm de altceva, dar mă-ndoiesc că în România avem așa nevoi.

2 Likes
35

management-ul nu se uita la PR dar intreaba team lead-uri, si la mine, s-a dat feedback “prea multe comment-uri pe PR”, tu vb in general foarte idealist, nu iti pui intrebarea cine plateste pt toate chestiile care le zici tu, si ca sa plateasca (prespunem ca are bani) ar trebui ca valoare economica a proiectul sa fie foarte mare, ceea ce e rar, daca nu e proiect critic mai degraba il trimite in india.

2 Likes
36

“Prea multe comment-uri” e mult prea generic, n-as lua in serios nici un team lead/manager care ar spune asta, ar putea la fel spune si ca nu ii place de fata ta…
Un feedback constructiv e ca nu e atent la codul/fisierele pe care le comite, ca nu stie (inca) best practices, ca repeta cod care n-ar trebui repetat, ca nu e consistent, ca refactureaza in acelasi PR cu un feature, ca are prea multe fisiere intr-un singur PR, ca scrie comentarii in loc de cod usor de inteles, ca nu scrie unit teste sau ca testeaza doar minimul necesar…

Poti intoarce feedback-ul si sa zici ca nu intelegi ce vor sa zica prin prea multe comment-uri si ca ar fi bine un meeting despre asta, dar nu stiu daca ajuta cu ceva daca vin cu feedback asa de slab.

Dupa cum am zis, e bine sa alegi un proiect frumos si sanatos indiferent de firma. Mai sunt si proiecte de MVP, minimum viable product (in general la firme mici), la care scopul principal e sa livrezi rapid ce cere clientul, de obicei fara teste si cu mult stres. Nu recomand proiectele de genul, inveti doar cum sa scrii spaghetti cod, cum sa te certi cu colegii si cum sa minti clientul. Iar daca iese ceva iti revine task-ul super enervant de a converti tot ce ai facut intr-o luna intr-un codebase sanatos si sa ii explici clientului ca acum va lua un an ce a luat o luna. (eventual ai noroc de manageri care ii spun clientului ca o sa refacturati tot in cateva luni si dupa un an tot asta faceti, plus feature-uri noi pe codul vechi…)

37

Prea multe commenturi, asta-i buna.

Daca lasi codu sa degenereze o sa-ti fie inclusiv greu sa gasesti oameni care sa lucreze pe proiect.

Totul o sa progreseze foarte incet de la un moment dat pentru ca e un veritabil bol de spaghete si ce ar putea sa fie o implementare de 2 ore devine una de 8. Un bug care s-ar putea rezolva rapid deoarece datele curg frumos in stil waterfall devine o bataie majora de cap pentru ca datele vin si pleaca prin n-spe parti etc.

O sa ai 7 stiluri de facut chestii de la 7 oameni diferiti. Ideal e sa nu iti poti da seama ca un feature a fost facut de o alta persoana.

Am lucrat cu “seniori” care lasau sa treaca orice cacat si cu seniori care imi puneau si 50+ commenturi pe PRuri si veneau cu scaunu la mine la birou sa discutam implementarea. Nu cred ca are rost sa zic de la care am invatat mai mult.

38

Pai fix asa. Folosim lucruri standard de care a auzit toata lumea. Am mai scrie pe forum, ca accentul ar trebui sa fie pe cunostinte transferabile.

La vechea firma am lucrat cu lucruri care erau specifice si nici pe Google nu gaseai mare lucru.

1 Like
39

La noi nu e voie squash, de cativa ani ma lupt.

1 Like
40

Te lupți săăăă… fie voie cu sau să nu fie voie cu?

Dacă nu e voie, de ce nu?

1 Like