A Bunch of Programming Advice I’d Give To Myself 15 Years Ago

  • If you (or your team) are shooting yourselves in the foot constantly, fix the gun
  • Assess the trade-off you’re making between quality and pace, make sure it’s appropriate for your context
  • Spending time sharpening the axe is almost always worth it
  • If you can’t easily explain why something is difficult, then it’s incidental complexity, which is probably worth addressing
  • Try to solve bugs one layer deeper
  • Don’t underestimate the value of digging into history to investigate some bugs
  • Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code
  • Make debugging easier
  • When working on a team, you should usually ask the question
  • Shipping cadence matters a lot. Think hard about what will get you shipping quickly and often

Voi aveți sfaturi pentru versiunea voastră mai tânără? :smiley:

2 Likes

Totul functioneaza intr-un fel pentru ca asta vor clientii. Nu exista ca poporul vrea digitalizare dar conducatorii sunt inepti si nu fac. Pur si simplu nu se vrea digitalizare.

La fel si in mediul privat. Lucrurile merg cum merg pentru ca asa doresc clientii. Am intalnit o gramada de furnizori cu API-ul proaste care faceau bine-mersi sute de milioane de euro pe an.

Nu merita sa te chinui sa faci o implementare buna, 99% din clienti nu vor, nu inteleg si nici nu-i intereseaza sa lucreze cu software excelent. Poti face o gramada de bani cu o aplicatie cu o singura clasa si o mie de metode. Sau cu metode lungi de mii de linii.

Pur si simplu iti cauti clientul care ofera cel mai mult si cere cele mai banale chestii. Nu merita sa te complici cu firme si procese de recrutare complicate. Am facut parte din colective puse pe fapte mari si pana la urma de toate s-a ales praful.

Corolar: costa mai putin sa zici “Asta nu se poate realiza tehnic” decat sa te pui sa implementezi o solutie. Daca te pui sa implementezi ceva, apar comentarii ca nu face exact ce se doreste, ca dureaza prea mult, ca daca tu pleci ceilalti programatori nu vor intelege codul. Am rezolvat o mie de probleme pur si simplu zicand: Ah, e complicat. Si nu s-a mai facut nimic.

Programarea merita doar pentru tine si pentru business-ul tau. Cele mai misto aplicatii sunt facute pentru mine si pentru a-mi simplifica mie viata.

P.S.
Am citit si vazut in o suta de blog-uri si clipuri video ca trebuie sa fii proactiv, sa vii cu solutii, sa fii responsabil si sa te adresezi management-ului. Eu de fiecare data cand am facut asta mi s-a zis ca sunt prea perfectionist si lucrurile nu merg asa. Ba chiar unele idei mi-au fost luate si apoi au fost cerute sa fie facute de alt contractor. Prezentate ca idei complet noi. Si nu vorbesc de firme romanesti unde conteaza sa dai bine.

Am renuntat sa scriu cu diacritice de-a lungul timpului. Nimanui nu-i pasa. Cred ca as putea renunta si la cratime.

6 Likes

:disappointed_relieved:


Și ca să fiu on-topic:

  • Încearcă să faci codul cât mai ușor de înțeles pentru ceilalți din echipă, micro-optimizările și sintaxă avansată sunt greu de depanat/reparat/adaptat. costul de performanță nu merită. Degeaba ai tu ce mai faină idee/structură/implementare dacă nimeni din echipă nu o înțelege sau nu vrea să lucreze pe ea.
  • Încearcă să îmbunătățești codul pe care îl modifici când implementezi ceva nou dacă e posibil și nu e schimbare majoră. Oricum trebuie testate și așa faci și modificări și refactoring și cu o singură sesiune de testare
  • Nu judecat codul existent prea tare. Nu ai de unde să știi cu ce constrângeri au lucrat cei dinainte ta. De multe ori ajungi să faci la fel după ceva timp în același împrejurări.
  • Să fii un om OK cu cei din echipă/firmă e mai valoros decât orice skill tehnic. Cunoștințele se pot dobândi, caracterul jegos nu se schimbă așa ușor.

Din lista de mai sus, rezonează foarte mult cu mine următoarele:

  • Try to solve bugs one layer deeper
    · de obicei rezolvi mai multe probleme care n-au apărut încă dacă reușești asta
  • Don’t underestimate the value of digging into history to investigate some bugs
    · apreciez foarte mult un git history cu cât mai multe referințe/ticket etc. E și mai fain când e cineva vechi în echipă care își mai amintește schimbările
  • Make debugging easier
    · atenția pe care o acorzi mesajelor de log și tratarea excepțiilor spun foarte multe despre tine ca programator în ochii mei
  • Shipping cadence matters a lot. Think hard about what will get you shipping quickly and often
    · Viteza cu care poți livra ceva în producție e cel mai fain indicator de cât de bine merg lucrurile. Să știi că poți livra un bugfix în producție în mai puțin de 15 minute îți dă foarte multă încredere în ceea ce faci și reduce mult stress-ul de a întroduce bugguri. E simplu dacă știi că orice bug se rezolvă în câteva minute după ce este rezolvat. Managerii înțeleg că nu e posibil să nu ai bug-uri, și atâta timp cât le poți rezolva repede e OK. Am ceva contra-exemple aici, dar n-are rost să mă lungesc :smile:

Tranșant și realist. Citind ce ai scris mi-a venit în gând piesa banii vorbesc.

O completare:

  • merita să scrii cod de calitate dacă vrei să te întorci înapoi să înțelegi ce ai făcut și să aduci îmbunătățiri sau funcționalități noi.

Nu știu dacă i-aș da sfaturi la younger self. Fiecare etapă a avut rolul ei. Daca arzi etape, nu-ți mai răspunzi la “de ce”-uri și îți găsești mai greu echilibrul. Am văzut oameni cu multi ani de experiență pe nicăieri. Am văzut studenți care aveau cariera pe care un mid-aged și-ar dori-o, neștiind că o are (studentul) și simțindu-se pe nicăieri.
Trebuie să știi te bucuri de ce ai.

1 Like

Ce aplicatii ai facut pentru tine? Si mie imi plac astfel de “home cooked applications”. Eu mi-am facut un “podcast tracker”.

1 Like

Foarte cinic :slight_smile: Uite iti dau un contra-exemplu: Stripe API e atat de bine scris si de bine documentat incat isi face reclama singur. Sunt companii care l-au adoptat pentru ca developerii sunt incantati de API-ul Stripe.


Cat despre topic, o sa las aici o bucata de text scrisa acu’ mai multa vreme.
Se refera la munca in general, mai putin la programare. Sunt lucruri traite si patite pe spinarea mea.

6 Likes

Exact. Programatorii care cauta sa faca asta, trebuie sa mearga la NASA. Acolo cred ca e singurul loc unde clientul e interesat de asa ceva. :smiley:

Cred ca e doar un mare disconnect intre dezvoltatori, clienti si utilizatori in industria IT. Odata ce apar anumite legaturi intre aceste categorii (clientii, dezvoltatorii folosesc aplicatia sau clientul este si dezvoltatorul) atunci se pune accent pe calitate. Sunt multe exemple de reusita pe partea asta.

In acelasi timp, ma intreb cate proiecte nici nu au reusit sa fie lansate. Si cate din ele au esuat din cauza problemelor tehnice intampinate pe parcurs sau promisiunilor nerealiste facute… Noi vedem doar proiectele care au reusit, nu toata imaginea.

Oricine va folosi o aplicatie care e mai performanta sau mai simplu de folosit in locul uneia prost facute si slab performante daca are aceasta alternativa. Si chiar daca nu are, calitatea reprezinta un avantaj contra viitoarei competitii.

On-topic:

  • Calitatea codului e ceva subiectiv si din punct de vedere al contextului si din punct de vedere al dezvoltatorului.
  • Pana si codul care pare prea complex dar e compact are anumite avantaje, nu totul poate fi inteles usor.
  • Mai mult, nu se merita imbunatatirea calitatii codului daca afecteaza signifiant performanta.

Mi-ar fi placut sa realizez aceste lucruri mai devreme

Sergiu cred ca mai stie de clasa aia din data.php care se voia un fel de ORM si care a devenit prea haotica si a fost nevoie de clasa data_data.php si sa nu uitam de data_data_functions.php.

Chestia e ca implementarea aia absolut atroce mergea ca blitz-ul de la aparatul foto fata de un ORM consacrat.

Mda, ORM-urile, in mare parte, am ajuns sa cred ca sunt inutile. Chiar daca face codul mai simplu, pierzi prea multa performanta si ai prea putin control.

Dar si acel data_data.php mergea in alta extrema. Trebuie la un moment dat putin structurat codul sa nu iti ia saptamani sa intelegi ce se petrece intr-un singur fisier