ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼

Cum am devenit un profesionist Agile - interviu cu Venkat Subramaniam

Lőrinc Pap
Algorist & Software Craftsman



PROGRAMARE


Lőrinc Pap: Salut, Venkat! Am dori să știm care sunt părerile tale despre programare în general și despre programarea funcţională în particular.

Venkat Subramaniam: Vă mulţumesc pentru invitaţie. Este o plăcere să intru în dialog cu dumneavoastră și cititorii dumneavoastră. Programarea înseamnă viaţă pentru mine, în multe feluri. Programez de câteva decenii, iar ceilalţi mă întreabă adesea: "Cum de ești tot programator după atâţia ani?"

Mulţi s-au apucat de programare datorită știinţelor și matematicii. Asta am vrut să fac ca inginer, dar ceea ce m-a determinat să rămân programator este arta de a programa. Iubesc programarea funcţională din acest motiv. Este o formă de expresie diferită și este foarte concisă. Este expresivă și elegantă, iar aceasta presupune că sensul este exprimat fără prea multe detalii.

Venkat Subramaniam și Lőrinc Pap

Programarea imperativă este caracterizată de complexitate accidentală. Așadar, când începem programarea imperativă - așa cum am făcut-o de la bun început -, depunem mai mult efort pentru aceeași activitate comparativ cu ceea ce se întâmplă în programarea funcţională care îndepărtează complexitatea accidentală. Când avem de-a face cu un sistem complex, trebuie să fim de acord că schimbarea este sigurul lucru constant.

Îmi doresc să îmbunătăţesc economia software-lui. Vreau să creez lucruri în mod sustenabil. Din acest motiv, sunt un fan al testelor automate. Primesc feedback rapid: ce a funcţionat ieri, funcţionează și azi.

Când îmi asigur spatele, pot fi mai creativ și să încerc idei noi.

Cum crezi că ar trebui să înceapă această călătorie? Ar trebui să îi învăţăm pe copii programarea? Ar trebui să facem programare funcţională cu TDD și Agile de la bun început?

Pentru mine a fost o experienţă incredibilă să văd cum învaţă copiii. Ca adulţi depunem eforturi pentru a învăţa, pe când acesta este un mod de a fi pentru copii. Este important să îi învăţăm lucrurile bine. Implicarea și pasiunea sunt importante. Odată ce au pasiune, copiii trebuie să o aplice creativ, astfel încât să producă valoare sustenabilă.

Când fiul meu a învăţat să scrie cod, la unul din proiectele la care a lucrat, fiecare bucată de cod pe care a scris-o a fost automatizată și testată - și este singurul mod în care a lucrat. I-am spus "Nu voi sta să scriu codul în locul tău, te voi învăţa lucrurile de bază și voi pleca. Îţi vei construi singur aplicaţia."

Când le predau copiilor, le dau teste automate și le spun să scrie cod ca testele să aibă rezultate bune. Unii părinţi și copii vin și îmi spun că "este incredibil să faci ceva, să vezi că merge și să observi rezultatele atât de repede."

Cred că e important să îi învăţăm ce presupune calitatea și buclele de feedback. Copiii își dau seama repede că ceea ce scriu nu va funcţiona tot timpul: mintea noastră este potentă, dar a greși este omenesc. Nu vom putea să reţinem fiecare ședinţă la care am participat - din acest motiv avem calendare și remindere. Același lucru este valabil și pentru programare: nu ne vom aminti fiecare permutare posibilă, dar avem teste automate. Trebuie să spunem acest lucru copiilor "sunteţi deștepţi și capabili, dar sunt lucruri pe care nu le puteţi face ca oameni. Există însă instrumente, tooluri pe care le puteţi folosi."

Un lucru fascinant pentru mine a fost să îi las pe copii să înveţe, fără a folosi jargon de specialitate. Le-am predat recent copiilor Javascript. Am întrebat": Câţi dintre voi cântaţi la un instrument?" - și toţi au ridicat mâinile. Programarea este tot așa: programul citește scriptul muzical și cântă la pian pentru a face ce spun scritpurile. Copiii au zis: "ok, are sens ce spui."

Trebuie să poziţionăm totul la un nivel la care copiii se pot raporta, pe care îl pot înţelege, astfel încât să realizeze că programarea nu e dificilă, ci e un lucru amuzant cu care se poate lucra.

Ar trebui să îi învăţăm pe copii programare funcţională de la început, ar trebui să îi învăţăm pe copii cum să aranjeze forme în moduri diferite sau direct, într-un limbaj de programare, așa cum fac adulţii?

Programarea este un mijloc, o unealtă: trebuie să îi facem să se simtă confortabil când rezolvă probleme.

Celălalt lucru important este să îi învăţăm pe copii, timpuriu, că o problemă se poate rezolva în mai multe feluri. Programatorii adulţi se blochează într-un limbaj, într-o singură soluţie, într-un singur mod de a face lucrurile. Dacă e să ne uităm la programatorii care sunt mai buni decât alţii, ce fac aceștia? Sunt deschiși la idei noi, la sugestii și la alte soluţii. Spre acest lucru trebuie să ţintim și când vine vorba de copii, ca ei să conștientizeze că, atunci când ni se dă o problemă, trebuie să fie deschiși la soluţii multiple - indiferent dacă este vorba de programare funcţională sau imperativă, de limbaj dynamically typed sau static. Nu doresc ca programatorii să își sape o groapă și să spună: acesta este singurul mod de a face lucrurile.

Cunoașterea limbajelor diferite îţi extinde capacităţile. Când apare o problemă, trebuie să ai în vedere opţiunile disponibile și să selectezi un limbaj, o librărie sau o unealtă, în funcţie de problema pe care o ai.

Cum i-ai convinge pe programatori să încerce limbaje de programare diferite?

Procesul de învăţare nu este ușor, necesită timp și efort. Cu toate acestea, mi-a luat cam două zile să învăţ Groovy. Acest lucru nu s-a întâmplat pentru că sunt deștept, ci pentru că am programat în Ruby câţiva ani și tot ce a trebuit să fac este să-mi pun întrebarea: Cum este Groovy diferit de Ruby sau Java?

Am mai învăţat Erlang câţiva ani, fără un motiv anume. Apoi, însă, a trebuit să învăţ Scala foarte repede și mi-am spus: Scala are actori, Erlang are actori. În timp ce Erlang este un limbaj dynamically typed, Scala este static, dar acest lucru nu contează. Am reușit să învăţ Scala foarte repede. Nu învăţăm în blocuri mari, ci în elemente delta. Din acest motiv, este foarte important să învăţăm limbaje diferite în permanenţă. Așa cum am scris și în una din postări: "timpul necesar pentru a învăţa un nou limbaj este invers proporţional cu numărul de limbaje pe care le-ai învăţat".

Îţi extinzi competenţele, la fel și abilitatea de a explora - îţi păstrezi "mușchiul" mental activ. Așa cum spun programatorii pragmatici: trebuie să învăţaţi un limbaj diferit în fiecare an. De asemenea, în fiecare companie unde am lucrat, limbajele utilizate și mediul de lucru erau diferite faţă de locul de muncă anterior. În timp ce produc valoare, dau rezultate în companiile unde lucrez, dar îmi și construiesc cariera. Când am lucrat la un proiect care utilizează C++, am constatat că există un nou limbaj, Java. Compania mea nu a abandonat C++ și nu a învăţat Java peste noapte, deci eu am decis să fac acest lucru în dreptul meu: ziua lucram cu C++, deoarece aceasta era slujba mea, dar seara petreceam o oră să învăţ Java. Când faci asta, vei începe să observi oferte de muncă care necesită folosirea acestui limbaj, sau vechea ta companie îţi va spune: avem în vedere un alt limbaj de programare și avem nevoie de oameni. Aici intervine și termenul 'profesionist'. Dorești ca medicul să spună: există niște instrumente noi pe piaţă care te vor ajuta cu această problemă, ar trebui să le încercăm. Vreau ca doctorul să îmi spună ce opţiuni am. În meseria mea, eu sunt un astfel de profesionist. Deci, când compania spune "Vreau să rezolvi următoarea problemă", este datoria mea să răspund: "Iată care sunt soluţiile".

Cât de des renunţă companiile la munca anterioară pentru a trece la o nouă paradigmă?

Nu este ceva comun, dar nici ceva neobișnuit. Este o greșeală să spunem "această tehnologie este cool": Trebuie să vorbim pe limba de interes a afacerilor. Firmele trebuie să se întrebe: cum va fi afectat fondul lucrurilor, putem economisi bani, putem livra mai repede pe piaţă, putem dezvolta produse cu mai puţine buguri - trebuie să ne exprimăm vizavi de valoare de business.

Oamenii mă întreabă adesea despre cum îmi pot convinge șeful că TDD (de exemplu) este important. Eu le răspund printr-o altă întrebare: "Ești sigur de asta? Dacă nu ești complet convins, nu îi poţi convinge pe ceilalţi. Ţi-ai făcut temele? Ai mai lucrat cu această tehnologie? Ai creat vreun prototip? Dacă l-ai creat deja, scoate-l la suprafaţă ca să i se poată vedea valoarea." Firmei nu îi pasă de tehnologie, ci de rezultate, beneficii, deci trebuie să ne exprimăm în acești termeni.

Sunteţi un adept al programării funcţionale și Agile. Care sunt avantajele acestor abordări?

Programarea în Agile este o programare bazată pe feedback. Nu poţi spune "Facem Agile.", iar apoi să spui că am stabilit termenul limită, am stabilit domeniul de definire, dar suntem Agile. Una dintre postările mele cele mai populare spune: "Am stabilit data nunţii, dar nu am invitat-o încă în oraș," - așa se face managementul majorităţii proiectelor.

Trebuie să adaptăm ceea ce facem bazându-ne pe realităţile din jurul nostru, pe schimbările din jur. Planificarea este atât de importantă, încât în programarea Agile nu o facem într-o fază mare, ci facem planificare activă și adaptivă zilnic. Trebuie să ne oprim și să ne adresăm următoarele întrebări: "Fac programare în funcţie de feedbackul primit sau folosesc termenul "Agile" doar ca să mă simt bine?", "Mă adaptez sau mă încăpăţânez?".

Dacă sunt programator într-o companie și sunt singurul care dorește să lucreze în Agile, cum pot eu să declanșez această schimbare?

Primul lucru pe care l-aș spune ar fi să nu fii ameninţător - ceilalţi nu vor dori să lucreze cu tine dacă ești așa. Când ceilalţi văd că încerci să devii mai bun, vor dori să lucreze cu tine. Al doilea lucru pe care îl recomand este să ajuţi cu adevărat oamenii să crească.

Din prima zi, cultura Intel a fost că poţi merge la CEO și să spui: "Nu sunt de acord". Prin asta se distinge o organizaţie grozavă: provoacă-i pe toţi spunând: "Putem face lucrurile mai bine". Trebuie să punem sub semnul întrebării tot ce facem. Aceasta e cultura pe care trebuie să o construim.

Dacă îmi spui că vei fi mai bun, nu voi crede acest lucru, dar, dacă văd că ai succes, că scrii cod de calitate, că pleci acasă la timp, că nu repari buguri seara........

Când ai succes, ceilalţi vor face totul pentru ca tu și ei să aveţi succes.Nu există o metodă mai bună de a convinge oamenii decât propriul succes. Deci, fă lucrurile în care crezi cu adevărat, obţine succesul, ceilalţi vor observa și vor spune: "Hai să facem asta".

Poţi să ne dai exemple despre cum ai devenit un om de succes în aceste domenii?

Primul lucru pe care vreau să îl menţionez este că ar trebui să fim dispuși să eșuăm devreme și des.

Prima oară când aţi mers pe bicicletă, aţi căzut, aţi avut vânătăi pe genunchi. Trebuie să încercăm, să devenim mai buni refăcând lucrurile greșite iar și iar. Cu cât încercăm mai devreme, cu atât eșuăm mai devreme și cu atât devenim buni în ceea ce vrem să facem mai repede.

Cel mai rău mod de a face lucrurile este să cerem permisiunea. A fost o lecţie dură de învăţat. Am mers într-o zi la șeful meu și am spus: "Am o idee grozavă, vreau să fac chestia asta", iar șeful meu a zis: "Stai jos, du-te înapoi la biroul tău, îmi pare rău, dar avem alte lucruri de făcut" și, deși ceea ce eu ziceam era un lucru foarte important de făcut, nu înţelegeam de ce nu vor oamenii să schimbe modul lor de a face lucrurile?

Dar cine ar trebui să îmi spună că trebuie să scriu cod de calitate mai bună? Nimeni. Pot crea nume mai bune de variabile sau de funcţii, pot scrie teste automate pentru codul meu, pot scrie metode mai eficient. Prin urmare, începi să schimbi lucrurile în sfera ta de influenţă. Primul lucru pe care îl poţi face pentru a declanșa schimbarea este să începi să faci acel lucru chiar tu. Este experimentul optim, poţi încerca lucrurile. Nu tot ce încerci va avea succes, dar e perfect așa. Îţi vei da seama cum merg lucrurile încercând lucruri diferite.

Prima mea recomandare este: încearcă, împărtășește lucrurile în grupul tău, du-te la o prezentare, du-te la o conferinţă. Vei auzi lucruri noi, ceva ce n-ai mai auzit până acum. Decizi să încerci acele lucruri. Ar putea fi un proiect mic, un proiect personal sau unul opţional. Ar trebui să dorești să îl încerci, pentru că atunci când îl încerci, eșuezi, apoi înveţi și devii mai bun. Tot ce obţinem vine din încercări.

În aceeaşi ediţie ... (56)

▼ TOATE ARTICOLELE ▼

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects