Cele mai cautate limbaje pentru internship

@navistar.

Nu cred ca mi-ai inteles indignarea.
Referitor la LOC, exact asta am ilustrat, am incercat sa evidentiez (vezi citatul pe care l-am scris, si l-am auzit de n ori: ,,Frate, am scris ieri 6000 de linii de cod”). Tocmai ca eficienta nu inseamna numar de linii de cod. Poti scrie 10,100, 500 - nu are relevanță. Nu este o metrică a performanței!!!

Nu vorbim despre principiile de arhitecturare sau design patterns. Ai perfecta dreptate, iar din punct de vedere teoretic, tot ce ai spus se regaseste in literatura de specialitate.

Problema mea este cu acei ,,developeri” care, desi nu trebuie sa cunoasca interfața altui modul, nefiind atributia lui, neavand nevoie, nefiind implicat in interconectarea modulelor, totusi este etic sa cunosti cu ce se "mănâncă" si latura cealalta.

Si voi da un exemplu, ca poate iarasi nu ma fac inteles.

1. Gigel este front-end developer, lucreaza bine mersi HTML,CSS,JS. Mai stie un f-e framework (Angular,ReactJS), iar pe partea de HTML/CSS - Bootstrap. Ma duc la Gigel, si, desi treaba lui este sa invarta galbenul cu negru, rozul cu verde, eventual sa aplice RWD (daca stie): Bai Gigele, ia incearca tu sa legi minunatia ta de proiect, cu:
- un proiect realizat in PHP (+/- frameworkul Laravel): Pai ce-i ala Laravel? Ce e aia <? php>, echo, $ ...
- un proiect realizat in Java care utilizeaza fm. Hibernate care ORM pt. mapare OO-RDB: Stai ca m-ai luat in ceata.

Auzi Gigele, dar tu ai auzit de Hibernate? Dar de Spring ai auzit ? Si nu, nu e vorba de fast-food-ul de vis-a-vis de Universitatea Bucuresti
Hai sa o luam mai usor. Cunosc Gigei, front-end devs, care habar n-au despre OO. Ca nu le trebuie. Sau, f. putin. Si atunci vine maxima mea: Dar Javascript ce este?... ))))))))))))))))))) Ia fa un sondaj printre angajati si vezi cati dintre ei pot sa detalieze (ca tot ai vorbit de DIP) SOLID, GRASP,...

Legat de analfabetism functional si code monkey. Ce spui tu, este analfabetism functional. Nu stiu interpreta un cod. Problema este cand lucrezi, ai o vaga idee despre cod, si fara sa ai un plan (ce faci? de ce faci asta?) incepi sa scrii cod. Si scrii. Si scriiiiiiiii, si dupa 2 saptamani minunatii de la QA iti trimit inapoi mirifica lucrare.
Exact cum incepi sa scrii cod, fara sa faci/sa rezolvi pe hartie - substratul matematic al problemei. Hai, recunoaste ca asa procedeaza 90% dintre programatori....

Baga frateeeeeeee cod pana maine la 10 sa fie gata. E cunoscuta zicala? Este fraza pe care o aud, de la toti colegii/prietenii mei care au lucrat sau lucreaza in ,,corporatii". Tu din prisma angajatorului, este clar ca vei nega ceea ce spun eu. Poate compania ta (observ ca ai o exp. vasta in domeniu) e altfel - m-as bucura! Sincer!

Cert este e ca, pe mine, daca vreau sa dezvolt o aplicatie de la A-Z (eventual in parteneriat cu X,Y,Z), nenea clientul nu ma intreaba daca cunosc Java, sau .NET, sau PHP. Clientul nu stie ce e web dev, ce e desk dev, mobile dev. Nu stie ce e aia "limbaj de programare" sau "limbaj de scripting".

Ca sa ma simt ,,complet" trebuie sa stiu de toate. Si nu cate putin din toate (ca atunci esti varza), ci bine din fiecare. Ca altfel te plafonezi si ,,mori" cu lupa corporatistului legata de gat.

===
Ii las pe colegii mei (pentru ca nu sunt in masura/nu am experienta lor) - au mai scris si pe alte topicuri - , cate % dintre programatori performeaza. Iar a performa, nu inseamna sa lucrezi intr-o multinationala ...

Edited by Rhesus, 27 January 2018 - 17:38.

Rhesus, on 27 ianuarie 2018 - 17:28, said:

Daca ai nevoie de Gigel pe backend il trimiti la specializare /training pe banii corporatiei , ce mare  scofala ?

Quote

Pai nu-i nevoie ca la noi toti stim fiecare ce stim.

Quote

N-ai cum, pentru ca interfata iti spune care este inputul si care este outputul si trebuie sa faci tu.Majoritatea documentatiei o reprezinta insusi structura  interfatei.
si aste pentru ca interfata este realizata de un arhitect software care ti-o redacteaza in code self-explanatory

Quote

N-are cum, ca la QA se trimite versiunea complilata, si o trimite team-leaderul care este si arhitectul software. Pana codul tau sa ajunga complilat la QA i se face
peer-review la 2 zile. Adica un alt coleg se uite peste codul tau constant sa vada ce greseli ai facut.Daca codul trece de peer-review , atunci la review sapatamanal
de catre Team-Leader, care face code-review la acelasi cod si daca el gaseste ceva ce tie ti-a scapat il face observatie celui care ti-a facut peer-review.Exista insa
si unele erori subtile care nu pot detectate dupa primul  peer-review ci la al doilea.

La aceasta se adauga faptul ca zilnic se tine sedinta SCRUM unde fiecare spune unde este si ce probleme are si ce-l impedica  sa mearga mai departe.

Quote

Frate asta este reteta spre dezastru. Acolo nu exista aplicarea metodologiei Agile/Sedinte SCRUM.Parca ar fi oras fara politie, fiecare face ce vrea,

Quote

Normal, clientul nici nu trebuie sa stie aceste lucruri.

Quote

Imi pare rau pentru voi, dar voi va luptati cu mentalitati si nu probleme tehnologice ale proiectului.
In plus dupa o anumita experienta, ajungi sa incepi sa lucrezi in orice limbaj dupa o luna de exercitii(cat dureaza trainingul)

Quote

Nu neaparat, insa daca la acea multinationala  subiectul este performanta atunci sa lucrezi la acea multinationala inseamna sa performezi in fiecare zi.

Poate ca la voi exista sedinte SCRUM. Felicitari pentru asta! Dar in general, e haos. Daca vrei, iti dau niste nume de multi (pe PM).
Nu ma lupt cu mentalitati, tocmai de aceea am ales calea freelancing-ului. Ca sa nu ma frece team-leader-ul sau project manager-ul la icre. Pot lucra liber la ce vreau, proiecte open-source, proiecte proprietary software(closed source), pot invata ce vreau, cand vreau, si cel mai cel mai important aspect: in acelasi timp in care imi creez un portofoliu, pot sa jonglez intre diferite tipologii de arhitecturi

Cert e ca fiecare e liber sa faca ce doreste, daca se complace intr-o stare anume e bine, daca nu, aia e.

Ca tot e vorba de internships, mai amuzante sunt discutiile de pe reddit unde se lauda cu intershipuri de 100k/an.

dani.user, on 27 ianuarie 2018 - 19:28, said:

+ "beneficii"

pe langa "onoarea de a lucra la corporatie", ce alte beneficii mai sunt ?

- onoarea de a lucra peste program. Program flexibil
- onoarea de a lucra sub stress.
- onoarea de a fii pielea p...estelui.
- onoarea de a te "conduce" un team-manager cu 2 clase sub tine, dar care "le stie pe toate" .

Aaa era sa uit. Asigurare privata la Regina Maria, sa nu cumva sa te imbolnavesti inainte de deadline

Domnu' navistar zicea ca dupa 4-5-6 interviuri (pe diferite level-uri, ca la Super Mario), dupa 50 de zile de pratica, recrutare, s.a.m.d se fac angajarile. Vreau sa-l intreb cate proiecte a realizat, pentru firma lui, cu oamenii care au venit de buna voie la "interviuri" pentru ca apoi sa nu li se mai raspunda / sau sa primeasca feedback negativ.

Tehnica asta e buna si la frizerie, la scoli/spitale. Iei in proba femei de serviciu pt. 50 de zile, pe gratis, iar dupa aceea schimbi "voluntarii". Voila!

Edited by MarianG, 27 January 2018 - 21:06.
se poate si fara limbaj plastic

Toate cele mentionate sunt valabile in majoritatea unitatilor de productie; fie ca e software, fie ca e nu.

Edited by MarianG, 27 January 2018 - 21:08.

Rhesus, on 26 ianuarie 2018 - 22:21, said:

Tine efectiv de management. Poate ca in unele corporatii, cei de la conducere nu sunt sariti de pe fix. Dar din cate am auzit, in majoritatea apar tot felul de probleme precum cea enuntata de tine. Si asta survine din simplul fapt ca nu exista comunicare suficienta intre management si tehnic sau din cauza ca multi manageri nu au lucrat niciodata pe partea tehnica. Necunoscand anumite implicatii tehnice, din una in alta se ajunge la tot felul de anomalii. Cel putin din cate am observat pe la noi prin firma, managerii care au fost pe tehnic par sa fie mult mai dezghetati.

Nu sunt familiarizat cu alte domenii. Dar sunt curios daca in proiectele ingineresti mari (construire avioane, masini, roboti etc.), ar fi pe proiect, manageri cu 0 background tehnic(nici macar facultate) / care nu au habar cu ce se mananca domeniul.
Daca singurele chestii pe care le stii sunt: "Vreau acum", "Sa fie gata repede", "De ce nu e multumit clientul?" etc. atunci, e usor sa fii manager.

Edited by crs12decoder, 30 January 2018 - 23:39.

'De ce nu e multumit clientul' e treaba conducerii. (zic si eu)

nu stiu pe unde lucrati voi, dar daca nu e multumit clientul nu e in regula. de fapt asta inseamna sa fii bun la ceea ce faci, sa fie multumit clientul, nu sa faci nu stiu ce arhitectura nemaiauzita.

Nu rareori, dar nici extrem de des, clientul nu știe ce îl face fericit, trebuie să îi spui ce îl face fericit.

Și da, într-o companie serioasă, echipa e protejată de mofturile directe ale clientului. Clientul e în contact cu cineva din management, fie el un programator numit manager doar pentru acel proiect.

sunt de acord cu tine, dar afirmatia mea ramane valabila

Treaba sefului de proiect este sa se asigure ca munca echipei satisface cerintele clientului.
De altfel sa intrebe echipa 'de ce nu e multumit clientul' arata cat de nepotrivit este postul respectiv pentru el.
Eu consider ca toti (clienti, angajati, contractori, furnizori) sunt parteneri pentru firma. Astfel apare mai greu intentia de a sabota pe cineva, ca doar iti este partener.