The language ultimately doesn’t matter much 
&& Programming languages are simpler than the human ones!
Programming is really about solving problems.
Comments are code
Cel putin asta am aflat dimineata, si pot spune ca dupa 6+ de programare simt ca e cam adevarat.
Ce credeti?
Ba nu, conteaza destul de mult, language si mai ales ecosistemul, altfel de ce nu am programa toti in virtual basic, pascal, pearl, cold fusion etc. Sau python, unele lucruri le poti face in python pt altele trebuie sa apelezi C din python.
Am aflat și eu asta lucrând cu clienții și observând că ei au probleme de rezolvat, nu dau doi bani pe clean code, extensibilitate, bune practici, teste, coverage, că-i react, că-i python, că-i laravel sau altceva.
Majoritatea clienților vor următoarele lucruri de la o soluție software (indiferent că-i site, aplicație, script, îi zicem software, da?):
De aia mi se pare ciudat că se pun probleme „cum faci clientul să plătească pentru teste?”. Nu-l faci, îl pui să plătească pentru o soluție care-i rezolvă problema rapid, în buget. Că soluția aia include sau nu teste, include sau nu principii SOLID sau mai știu eu ce? E treaba ta, nu a clientului.
Comments are code
Majoritatea comentariilor mi se par redundante/inutile, so there is that…
The language ultimately doesn’t matter much >> ce inteleg eu prin aceasta afirmatia, si validez ca find adevarat, e ca intelegerea unei probleme si rezolvarea ei folosing algoritmi logici, este prima etapa ce prevaleaza invatarea si folosirea unui limbaj de programare.
In esenta, limbajele curente de programare par a fi similare, folosesc aceleasi pattern-uri:
defineste variabila, loops, functii, clase, etc.
Bineinteles ca e decisiv intr-un punct al proiectului ce limbaj de programare se va folosi.
iamntz, uite ceva interesant:
“comments explain code to other programmers? > NO! > Code explains the comments to the computer”,
si da, si eu sunt adeptul comment-ului inline simplificat, si focusul sa fie pe naming vars, classes and fn.
Uncle Bob are un utube f bun (clean code) in care detaliaza contextul general al folosirii comentariilor inline.
Nu-și amintește nimeni de pseudocodul din facultate? De ce îi zice pseudocod?
Și eu sunt de părere că programarea este despre rezolvarea unor probleme/nevoi. Ca să vă spun o fază amuzantă, am rezolvat o problemă de mecanică cu un principiu din programare.
Este drept că fiecare limbaj are particularitățile lui de nivel de detaliu (eficiență, performanță, etc), însă la nivel general, toate sunt cod care rezolvă ceva. Tot felul de abordări pe care le întâlnim și în jur dacă suntem bine atenți.
O să vă las aici un banc despre programatori:
Soția îl trimite pe programator la cumpărături, “ia o sticlă de lapte, dacă au ouă ia 10”. Programatorul se întoarce cu zece sticle de lapte. Soția îl întrebă: “de ce ai luat zece sticle de lapte?” El: “Păi avea ouă”.
Cum faci un chat sau o aplicație mobilă în PHP?
Cu cat inveti mai multe (limbaje) cu atat restul devin mai usoare.
Prima data cand stii doar un limbaj si auzi de chestii complicate in altul…wtf. Ti se pare ca-i Everest.
Dar cu cat experimentezi cu mai mullte limbaje cu atat pare mai simplu sa faci switch la altul. Chiar daca nu-l stii bine.
You just stop worrying and learn to love the variety. 
Corect, Alex. Bine punctat. Sunt foarte placut surprins sa citesc comment-uri ce denota o intelegere a fundamentului programarii, dat fiind ca in grupurile de IT de pe fb, am intalnit foarte multi care “codeaza dupa ureche”.
Eu mai ajut dierite persoane pe grupurile de it de pe facebook si am observat urmatoarele:
Aceste tipuri de pesoane sunt si pe forum.
Acum ceva timp, cand nu erau prea multe limbaje, erau reviste care aveau ceva cod in basic pe care il incercai si iti faceai jocuri si altele. Si lumea vedea programarea chiar ca un lucru cu care sa isi rezolve problemele.
Asta e genul de epifanie ce apare dupa multi ani de programare. Intr-adevar, daca stii sa programezi nu conteaza limbajul pentru ca stii ce sa cauti cand implementezi o cerinta. Nu doar pseudocodul e important ci si structura proiectului, best practice-ul (suna mai bine in engleza), pattern-urile, arhitectura aplicatiei, un pic de DevOp, un pic de UX si, vorba cuiva, “sa nu mirosi” (asta e pentru colegii de echipa).
Totusi, ca sa fiu obiectiv: cand ajungi bun in limbajul X vei trece pe limbajul Y unde esti mediu. Capacitate sa inveti sa ai si esti ok in orice.
You’re proving the point. Alegi alt limbaj? JavaScript maybe?
Știm foarte bine că nu primești același salariu pe un alt limbaj față de cel pe care îl știi cel mai bine, dar asta este altă problemă. Ideal este să îl “iei ușor la bord” în paralel cu limbajul principal. Dar când ajungi să te descurci în 2 sau mai multe limbaje este deja alt nivel de maturitate și ajungi să înveți tot felul de paradigme cross-language sau cross-technology.
Alex, cred ca capacitatea de a invata e direct proportionala cu calitatea materialelor si/sau a mentorului. Din pacate, ca si in fotbal, un foarte bun programator nu va sti neaparat sa predea. Personal am intalnit cursanti ce dupa 4-5 luni de curs Java, nu intelegeau inca mai nimic si nu erau doar ei de vina.
Cred ca ne putem aduce aminte cum un profesor ne facea sa ne placa materia, de multe ori. Eu am inceput anul trecut sa predau web dev (FE oriented), si realizez ca studentii isi modeleaza capacitatea si pasiunea in functie de cum si ce explic, si ce sentiment le transmit in relatia cu idea de “viitor programator”.
Imi place ca iti faci un pic de “mea culpa” spunand ca ai studenti care nu pot invata si e vina profesorului, iar tu predai… 
Da, sunt de acord cu capacitatile limitate ale unora in a intelege programarea, sau viata in general, dar au si ei un loc si un nivel salarial in lumea asta.
Alex, se pare ca nu m-am exprimat foarte clar :)) Eu vorbeam despre capacitatile studentilor ce nu erau stimulate. Limitele sunt alt subiect - unul destul de subiectiv deci nu l-as aduce in discutie.
De asemenea, dupa cum scriam eu am predat web dev, si la clasa unde s-a predat JAVA studentii erau destul de nemultumiti si de debusolati legat de profesorii anteriori. Bine’nteles ca nici eu nu am fost un fel de “guru”, dar am avut acest imbold de a-i intreba daca au inteles ce li s-a predat pana acum, si daca dupa aceste luni de invatare, au primit ceea ce se asteptau de la bun inceput.
Alex.io, crezi ca salariul e in functie de cat de bine stii un limbaj? Btw, voi lucrati fulltime sau remote (freelancing)?
aici pot sa ma bag si eu in discutie 
mie mi se pare ca sunt 2 cazuri:
ca experienta proprie, eu am schimbat limbajul, dar in acelasi timp mi-a crescut si salariul la noua companie. Acum, cand mai accept discutii pentru interviuri, in unele situatii ne oprim la faptul ca nu am X ani in limbajul Y, am inceput sa accept refuzurile astea cu mai multa usurinta, ma gandesc ca un angajator pentru care conteaza mai mult numarul de ani fata de capacitatile angajatului nu e o alegere foarte buna pentru cel din urma pe termen lung. Dar, am discutat si cu altii care, chiar daca eu stiu limbajele X si Y, datorita experientei acumulate pe proiecte, ei avand nevoie de dezvoltari in limbajul Z, am dus discutiile mai departe.
Pe scurt, sunt angajatori care se uita fix la numarul anilor de lucru (nici macar nu-i poti spune experienta) intr-un anumit limbaj, si angajatori care stiu sa-si dea seama de capacitatea angajatului din proiectele avute, fara sa puna in prim plan durata intr-un anumit limbaj.
Tl;Dr: „even if you can, doesn’t mean you should”.
Posibil să cazi în capcana „PHP+Apache+Server Shared” și să crezi că dacă nu e instalat de firma de hosting, nu se poate.
Pentru chat există soluții (e.g. asta). Pentru mobile există câteva „compilatoare”. Nu pentru toate platformele, dar … să zicem că reușești (cu destulă încăpățânare).
Eu am lucrat doar antreprenor si remote freelancing (upwork), si din pacate nu stiu cum e situatia angajarilor fulltime. Dar totusi sunt dezamagit de faptul ca uneori evaluarea unui developer se face de catre un HR, un PM sau mai stiu eu cine din firma ce nu cunoaste notiunile de baza…
Se pare ca in crearea unei oferte de lucru (gen cele pe Linkedin), se procedeaza cam asa: PM-ul discuta cu developerii si realizeaza ca mai trebuie adusi devs (de cele mai multe ori nu trebuie, dar na), apoi fiecare echipa de dev listeaza cerintele ce trebuie sa aiba candidatul (fiecare baga cat poate de mult), iar apoi HR-ul insumeaza cererea si o posteaza online.
De cealalta parte tu ca si candidat, esti stupefiat de cerinte si daca nu ai experienta in domeniul ofertelor de angajare, o sa ai senzatia ca niciodata nu vei putea acumula specificatiile cerute in oferta.
Si ce e cel mai neplacut, e ca dupa ce reusesti sa iei jobul, realizezi dezordinea si haosul din acea companie/echipa si ca de fapt de la ce visai ai ajuns la un simplu muncitor care reuseste sa scrie cateva linii de cod de care sa fie mandru, pe saptamana.
La momentul acesta asta imi e senzatia: cu cat aplic la mai multe interviuri si oferte pe upwork, realizez lacunele angajatorului in domeniul IT. Fara sa mai zic ca la momentul actual lucrez in parteneriat cu o companie suedeza exclusiv de IT, al carui CEO e total nepregatit in domeniu, iar CTO-ul ce incearca din rasputeri sa introduca toate practicile de BE in FE…
Si nici nu am mentionat topicul UX :)) topic ce e complet neinteles de “senior PM”, CTO’s, etc