Se pare că articolul acesta e #1 pe site-ul portocaliu:
easy to start hard to do well
1 Like
Stai sa inceapa cineva un topic cu salarii de 8000 de euro pe luna… 
1 Like
Păi dăm si link, că sunt comentarii interesante și acolo 
5 Likes
Are dreptate primul comentariu. Un js+css+html uneori poate să fie satisfăcător pentru un începător și poate să producă suficienți bani.
Bă, ma bucur la orice oră pt Dorin … da articulul e cam în genul Captain Hindsight
în afară de faptul că e de-al nostru din blog-o-sfera … I got nothing
Ca sahul. Sa inveti regulile e usor. Sa-l stapanesti …
La programare dificultatea e IMO arhitectura. Cand ai zeci/sute de module si zeci/sute/mii de interactiuni intre ele … creierul uman nu poate sa tina atatea lucruri concomitent in memorie (cica max 7-8).
De-aia exista bug-uri in ABSOLUT orice pachet software. Nu poti sa prezici cu exactitate ce face codul tau ptr. ca nu poti sa tii toate output-urile posibile in minte.
In mare cred ca are dreptate. E vorba despre faptul ca f.multi intra usor si devin “experti” prea repede fara experienta, plus li se urca si la cap. Si sa vezi distractie cand “expertul” da de om cu experienta adevarata si incepe sa si argumenteze cu el.
E ca si cum ai termina constructii si te-ai apuca sa ridici un bloc. Cat timp nu exista reglementari legale, ridici o constructie vai de capu ei, care a adus banii, a fost “lansata”, dar la primul cutremur crapa si trebuie “refactoring”.
Pana acum n-am auzit sa existe la scara larga echipe de audit pe cod. Poate dupa ce vor mai cadea cateva avioane Boeing se vor implementa niste legi legate de cum sa scrii cod safe si se va face code review de echipe autorizate.
Luati de exemplu sistemele de siguranta din masini, uneori dau rateuri masive si pun frane aiurea. La Honda Civic multi se plang ca masina le franeaza instant cand intra pe o bretea de iesire de pe autostrada. E din cauza unui cod prost sau limitarilor tehnologice?
Toate chestiile astea trebuiesc cuantificate in bani si timp. Valabil si pentru design. Degeaba mergem la stakeholderi sa le spunem ca trebuie refactoring “ca sa fie bine mai tarziu”.
Niste grafice cu “expected costs” sau un grafic de “ai fi economisit x timp si bani daca porneai bine de la inceput” vor cantari cel mai mult. Intrebarea e cum masori.
1 Like
Depinde de ce anume e programat.
Programarea poate fi de la foarte usora la foarte grea. Din nou, depinde.
Primesti ca ‘tema’ sa implementezi asa ceva (nu neaparat exact asta, dar ca idee…).
Ai nevoie de ceva cunostinte. Daca le ai, beton, dar daca nu… te pui pe lecturat…
De exemplu, o carte care trateaza domeniul, introductiv (posibil aici e nevoie de ghilimele, functie de pozitia de start), are catre 500 pagini:
Modern Quantum Chemistry, Introduction to Advanced Electronic Structure Theory, Szabo & Ostlund.
Necesita tot felul de cunostinte anterioare, algebra liniara, sa nu te sperii de integrale multiple sau spatii vectoriale unde vectorii nu sunt vectori de-aia obisnuiti, ci functii sau spinori etc.
Si nici macar nu trateaza - doar atinge cu exemple pentru orbitali s - integralele care trebuie rezolvate. E adevarat, in cazul asta se gasesc ceva biblioteci pentru rezolvarea lor, dar nu ai luxul asta in orice proiect.
Daca excluzi toata teoria asta din ‘programare’, programarea devine destul de usoara. Problema e ca fara partea asta, nu faci mai nimic. Nu te poti pune sa scrii cod din neant chiar daca stii beton tot ce tine de programare.
Codul trebuie sa faca ceva si acel ceva uneori poate fi complicat prin el insusi. Cu cod sau fara cod.
2 Likes
Exista reguli de codare dar trebuie sa sti ceva carte sa fi auzit de ele, si ai dreptate amatorii se contrazic mereu cu profesionistii … Nu trebuie sa cada Boeing-uri pentru a se afla de reguli trebuie sa citeasca “amatorii” mai mult sa se documenteze dar asta necesita timp pentru a te rupe de la alte activitati … asa e mai simplu sa comentezi ca ce nu stii nu exista … :)) Iti aduci aminte de ultima carte citita acum ca era beletristica sau de specialitate nu amai are relevanta … 
exista bune practici. acele bune practici nu-ti garanteaza rezultatul corect. daca te duce capul 1 + 1 = 2. daca nu, 1 + 1 o sa fie 1, 3 sau 5. indiferent ce carti de “reguli de codare” ai citit.
2 Likes
Văd in comentarii o părere destul de confuza, programarea in sine nu e dificila, sa scrii cod după ce ai ceva exercitiu / experiența e foarte ușor , dar cum îmi place sa le spun și juniorilor, a scrie cod e ultima problema. E o diferența între sa scrie cod și a trata o problema, care mai întâi trebuie înțeleasă , modelată , rezolvată , iar apoi începi sa scrii și codul. Acum normal, in funcție de problema o sa ai nevoie de un volum diferit de cod, cu cât mai mult cu atât devine mai complicat sa îl menții și sa îl orchestrezi.
Parca citisem undeva o comparație drăguța între a scrie cod și a face aplicații (software), ar fi de la a știi sa scrii și a știi sa scrii un roman.
Și da, cum a fost menționat mai sus, cred ca la noi mulți oameni ajung mult prea repede la “senior”. Chiar săptămâna trecută am avut un interviu cu un senior cu experiența de 3 ani jumătate …
2 Likes
Idei bune prin raspunsuri 
Si oarecum pe subiect
programarea nu inseamna doar scris de cod. implica cam tot ce-ai spus tu acolo.
Nu e vorba de usor sau greu, e vorba de ce faci, daca e in limitele tale de inteligenta, daca e in sfera ta de cunostiinte, daca te pasioneaza sau motiveaza solutia.
Daca te depaseste totul si nimic nu te motiveaza inafara de salariu o sa fie foarte greu sa intrii la un nivel la care chiar sa stii ce faci si sa simti ca ai ales solutia corecta.
Am vazut mai sus si ca nu poti fi senior cu 3 ani experienta. De cele mai multe ori nu experienta conteaza ci inteligenta omului, nu e ca si cum poti sa faci mai multe daca esti prost si ai lucrat mult.
Problema e ca la job-urile pe care le facem majoritatea lucrurilor se fac schematic, nu iti trebuie chiar o solutie de la 0 unde inteligenta isi spune cuvantul.
La corporatie conteaza foarte mult comunicarea, asta e cel mai greu. Altfel daca nu comunici si te apuci direct de solutii tehnice o sa iasa poate ceva urat (poate o echipa face de 2 ani acelasi lucru la care lucrezi si tu si iti dai seama abia dupa un an ca ai lucrat degeaba).
1 Like
Eu observ că programatorul mai nou trebuie sa fie și business consultant. Nu se știe ce se dorește, vin cerințe vagi și apoi tot programatorul e prea leneș, nu știe ce face, trebuie să găsim pe altul care știe, et caetera.
2 Likes
si cu toate astea sunt tratati ca niste mucosi imbecili de niste impinge foaie. ca nah, programatorii-s de fapt niste copii mari si nu prea pot fi seriosi. au preferat sa-si piarda timpul pe calculator in loc sa invete lucruri importante.
3 Likes
Experienta mea e asa:
Avem nevoie de un site nou. Dar n-avem layout-uri. Dar trebuie sa lansam pana pe 1 ianuarie. Dar dupa ce faceti voi paginile, ne vin layout-urile si schimbam tot. Dupa ce site-ul e gata, nu e bine, ca ne vine un consultant si face el ca stie, ca am mai lucrat cu el.
De fapt consultantul asta a facut vechiul site, care e tot spaghetti si multe lucruri nu mergeau. De aia am hotarat sa facem unul nou.
Rinse. Repeat.
3 Likes
Am si eu o nemultumire cu programatorii tineri: considera ca totul trebuie sa li se dea mura-n gura, ei doar sa scrie cod. Pana acolo ca decat sa citeasca protocolul X mai bine intreaba mai sus sau pierde timp testand pana iese (sau nu)
De cand lucrez eu nu era cazul de citit protocol anume, in ziua de azi nu se mai face documentatie fiindca logica e ca documentatia o sa te incurce mai mult daca nu o sa fie actualizat cu codul. Iar ce livrezi e codul si produsul, nu documentatia. Cu mici exceptii, dar de exemplu cu Angular am avut situatii in care documentatia era atat de stufoasa incat mi-a luat zile sa inteleg ce trebuia sa fac ca sa pot testa ceva.
Am mai incercat sa citesc si formate de CAD, dar dupa colegii cu experienta mi-au zis clar ca lipsesc intentionat lucruri din specificatii ca sa nu il poti implementa fara suport din partea celui care a scris specificatia open-source. (de exemplu Siemens si o ora de suport costa 2-3 mii de dolari)
1 Like