De multe ori, in facultate sau in lumea olimpicilor la informatica apare intrebarea daca folosesc la ceva cursurile avansate de algoritmi si structuri de date de la facultate, sau daca premiile la olimpiada au vreo valoare. Recent vorbeam cu Cosmin despre asta, iar mai demult vorbeam cu Calin Fusu despre daca intr-adevar este nevoie ca, la nivel de dezvoltator/programator, sa ai oameni ultra calificati sau este ok si cu programatori medii.
La vremea respectiva nu am reusit sa ii raspund convingator lui Calin insa, intre timp, am ajuns la niste concluzii organizate si ceva mai argumentate. 🙂
Programatorii rezolva probleme. Cel mai bun exemplu recent de probleme vizibile sunt problemele de scalabilitate pe care le-a avut trilulilu.ro. Cum nu stiu care au fost cauzele, as imparti problemele lor in mai multe categorii posibile.
1. Limitare de resurse fizice. Spatiu pe disc, banda de internet, timp de acces la disc.
Daca ai ramas fara spatiu pe disc (exemplu simplist) nici un algoritm nu te poate ajuta (cel mai probabil), asa ca un programator foarte algoritmic nu se va diferentia probabil semnificativ de un programator mai putin olimpic. Singura solutie este cumpararea de mai multe resurse.
2. Limitare de putere de procesare. Query-uri care dureaza prea mult, procesoare care stau la 100% sau RAM insuficient.
Puterea de procesare si memoria sunt consumate de cod, cod care este scris de programatori. De obicei exista tentatia subestimarii pragului de complexitate unde cunoasterea algoritmilor face diferenta, asa ca simt nevoia sa dau un exemplu pe care l-am dat recent la o intalnire FlashCodersNY: determinarea duplicatelor intr-o lista de elemente.
Sa zicem de exemplu ca, in cazul trilulilu, vor ca dintr-o lista de clipuri sa determine titlurile duplicate. Un ne-olimpic cel mai probabil va ordona lista si va vedea daca titlurile de pe pozitii consecutive sunt egale. Un olimpic iti va spune ca asta se poate face mult mai rapid cu un hash. Diferenta intre cei doi algoritmi va fi probabil de cel putin cateva ordine de marime (sper sa nu deschid o cutie a pandorei cu ce stiu si ce nu stiu ne-olimpicii, exemplul este simplist, you get the point 🙂 ).
Desigur, si in cazul asta ineficienta programatorului poate fi suplimentata prin cumparare de resurse. Pragmatic vorbind, costul unui programator care scrie cod (sa zicem) de doua ori mai ineficient decat ideal va fi salariul plus costul resurselor care trebuiesc cumparate pentru a suplimenta ineficienta codului. Daca programul ideal ar fi consumat resursele a 2 calculatoare, costul adaugat de dezvoltatorul slab va fi de 2 calculatoare. Daca ideal ar fi consumat 10, adaugi 10 calculatoare.
Am facut un grafic cu evolutia costurilor in functie de nevoia de scalabilitate, in contextul unui algoritm de (sa zicem) doua ori mai ineficient. In punctul A un programator slab ajunge sa coste compania la fel de mult ca un programator bun, in timp ce acesta din urma poate sa ajunga, cu aceleasi costuri, la un trafic de cateva ori mai mare.
3. Limitari date de solvabilitate. Exista anume probleme pe care pur si simplu doar oameni care stiu algoritmi le pot rezolva eficient, unde diferenta de performanta este prohibitiva inca de la dimensiuni foarte mici ale problemei.
De exemplu, drumul minim intre doua noduri ale unui graf. Un programator ne-algoritmic cel mai probabil nu va sti sa rezolve astfel de probleme si va decide ca ar dura ani si ani pentru un calculator sa gaseasca solutia. Un dezvoltator algoritmic iti va spune rapid ca asta se poate face chiar foarte usor si foarte repede.
Cand apar astfel de probleme? E drept, probabil nu in cazul trilulilu. Dar ganditi-va de exemplu la jocurile de strategie, in care trupele se muta pe harta dintr-un loc in altul printre castele, munti, dealuri si paduri.
Categoria asta de probleme nu mai poate fi rezolvata prin costuri de resurse fizice si cel mai probabil pot fi rezolvate prin schimbarea problemei. In acest caz compromisul inseamna feature-uri lipsa, specificatii diferite, comportamente diferite si asta nu mai este un compromis acceptabil atunci cand succesul business-ului tau sta in implementarea unui anumit produs intr-un anumit fel.
In loc de concluzie
Da, cel mai probabil exista categorii de produse si probleme care pot fi rezolvate fara olimpici si fara algoritmi. Mai mult, pana la un anumit nivel cunostintele unui olimpic pot fi inlocuite prin a cumpara mai multe resurse si costuri mai ridicate.
Insa de aici si pana la a afirma ca algoritmii nu sunt folositori sau ca olimpiadele nu au prea mare valoare este cale lunga.
Eu as zice ca pana si prima categorie pe care o enumeri tu are nevoie de developeri buni care stiu algoritmi, structuri de date, running time analysis si chestii similare.
Un inginer bun o sa gaseasca mai usor bottleneck-urile din sistem, o sa-si dea seama ce componenta ia mult timp, si de ce de exemplu, nu te-ar ajuta mai mult RAM, dar te-ar ajuta mai mult throughput pe conexiunea la retea.
Bineinteles, cunostintele teoretice trebuie suplinite si de cunostinte solide de sisteme si de programare in general (si s-ar putea ca unii oameni sa le reproseze unora dintre olimpici ca sunt deficienti la capitolele din urma). Dar cineva cu un background bun teoretic cauta instinctiv sa programeze eficient, e mai dispus sa se gandeasca la costul fiecarei operatii si ca atare e mai capabil sa puna degetul pe rana.
Vivi, imi da senzatia ca bagi in oala aceea numita generic “programatori” si pe cel care butoneaza cod dupa specificatii sau dupa ureche (numit traditional programator), si pe cei care sunt deasupra domniei sale, care fac design, care fac arhitecturi, care fac consultanta.
Intr-adevar, acestia din urma au trecut si ei la un moment dat prin butonaj (daca sint adevarati designeri, arhitecti, consultanti, si nu sunt doar din cauza ca au impresia ca daca si-au luat o certificare microsoft, sint ei buricul pamantului), pentru ca altfel nu au experienta suficienta ca sa inteleaga ce e aceea dezvoltare de solutii informatice.
@Marian, mesajul meu se refera la programatori care gandesc. Nu fac diferenta intre cel care scrie cod si cel care scrie specificatii.
Cand cel care scrie specificatii le va scrie atat de detaliat pana la a explica algoritmul de gasire duplicate, inseamna ca celalalt e masina de scris, nu programator.
Pentru toti cei care nu sunt masini de scris se aplica cele de mai sus.
@Tudor, sunt de acord cu tine. Cred insa ca exista si anumite situatii, mai ales la nivel mediu si mic, in care punctul 1 se aplica textual. Tot ceea ce este nevoie sunt bani, cumperi mai multe servere, se rezolva problema.
Mesajul meu este pur despre skill-urile algoritmice (care, discutabil, e doar una din calitatile necesare unui inginer bun, alaturi de putere de analiza, getting things done, munca sub presiune, teamwork, etc).
Vivi cred ca ai scos la iveala un fapt interesant. Intr-un alt context ma gandeam la ceva similar zilele trecute, citind diverse insemnari de la Netcamp. Oare lipsa de stralucire a produselor online din Romania nu se datoreaza cumva si faptului ca olimpicii tari o taie imediat dupa ce termina liceul, poate chiar mai devreme? E poate doar impresia mea, dar parca la nivel de realizare, totul pare facut de mantuiala, fara un sistem sau structura, cu un puternic iz de mediocritate.
Si ca sa revin la context, cred ca adevarul e undeva la mijloc. Un programator talentat e un programator talentat si va invata sau descoperi algoritmi si structuri informandu-se pe cont propriu si lucrand chiar daca nu are patalama. La polul celalat, un programator mediocru dar toba de carte e in final tot un programator mediocru.
Vivi, exista in industria asta acel principiu numit 80-20. Astfel ca cineva care face design de calitate poate prezice incapacitatea programatorului mediocru de a gasi solutia optima la portiunea de cod (destul de mica) care are impactul cel mai mare la performanta. Astfel ca poate sa mentioneze codorului “foloseste hash, ca este O(n) in loc de O(n log n) sau mai rau”.
In fond, oamenii din I.T. destepti sint foarte scumpi. Oamenii mediocrii sunt mai putin scumpi. Majoritatea echipelor/companiilor folosesc un amestec de oameni foarte buni si oameni mai putin buni, pentru a maximiza raportul rezultat/costuri. Putini sunt cei care isi permit doar oameni foarte buni, si vai de cei care nu-si permit nici macar unul…
In plus, populatia foarte competenta din I.T. este foarte limitata. Daca toti cei care lucreaza la Adobe, Apple, Google, IBM, Microsoft, Yahoo sunt asa (“olimpici”), atunci aceste companii ar face mult mai putine lucruri – ar fi mult mai sarace in angajati.
(Ovidiu) “Oare lipsa de stralucire a produselor online din Romania nu se datoreaza cumva si faptului ca olimpicii tari o taie imediat dupa ce termina liceul, poate chiar mai devreme?”
Poate. Dar din cate stiu eu, inca mai gasesti oameni foarte buni in Romania. Problema cea mai mare acolo (in Romania) este calitatea managerilor – recunoscuti pentru incompetenta. Eu personal dau vina pe comunism pentru calitatea managementului romanesc. Dar pana una alta, acesta este crudul adevar – managerii romani sunt un dezastru.
Ca sa vezi un exemplu de ce inseamna management bun si management prost, uita-te la Microsoft vs. Apple. Microsoft este obsedat in angajarea oamenilor cei mai buni (cauta de exemplu cartea “How would you move mount Fuji”, o gasesti gratis pe internet). Dar si ce daca? Uita-te ce produse reusesc sa scoata… Prin contrast, Apple, cu capital uman la nivelul de codori cel mult egal cu al lui Microsoft, reuseste sa faca produse extrem de bune.
Punctele 1 si 2 cu probleme tipice de scalabilitate sunt mai usor rezolvabile prin arhitectura decat prin cod “destept” (cum zicea si Marian). O aplicatie inteligent scrisa dar slab arhitecturata are mari sanse sa se comporte mai prost decat una mediocra dar cu o arhitectura gandita sa fie scalabila.
Un “olimpic” (imi place mai mult termenul de “programator talentat”) nu este valoros pentru ca stie pe dinafara niste algoritmi, ci pentru ca poate sa propuna solutii la probleme reale, concrete (tehnice sau de business). Am vazut cazuri cu programatori sa zicem “ne-olimpici” pur si simplu paralizati in fata unei specificatii pe care nu stiau cum sa o traduca in cod sau mai rau apucandu-se de codat fara a intelege de fapt ce trebuie sa faca.
Netul romanesc este varza din cauza banilor. Proiectele pentru afara sunt mult mai bine platite. Blogurile in engleza aduc bani si nu doar de seminte. Pana si spamul este rasplatit mai bine daca il faci in engleza. Sper pentru 2008 sa mai apara niste buyers seriosi si poate ca o sa existe ceva efort si pe piata noastra. Pe de alta parte, stiu ca proiecte cu potential pe piata romaneasca sunt in derulare, ca nu s-au expus la netcamp asta e o cu totul alta poveste …
Vivi, problema noastra nu a fost legata neaparat de cat de buni sunt programatorii. Problema noastra a fost legata de refuzul furnizorului de a ne livra la timp echipamentele.
Revenind la ce ai zis tu, un programator olimpic face intr-adevar diferenta. Nu cred ca un programator bun, cu cunostinte acumulate intr-un ritm normal ar putea rezolva anumite probleme de o anumita dificultate. Cel putin nu le-ar rezolva optim sau in timp util sub presiunea care i se impune.
cred ca realitatea e putin alta. nu exista foarte multi olimpici. daca o companie care ar avea nevoie de un programator foarte bun, si ar oferi un salariu e 2-3 ori mai mare decat a unui programator neolimpic, nu e garantat ca il va si gasi. dintr-o promotie de programatori (absolventi de automatica, info etc), cati au fost olimpici? 1%? poate 2%? si cati dintre acestia nu pleaca la o facultate straina?
sunt de acord cu tine: un olimpic va face diferenta. dar nu poti spune “las’ ca maine angajez un olimpic”, pentru ca pur si simplu nu sunt destui. lucrand la google, unde probabil fiecare al 3-lea sau al 4-lea programator a fost olimpic (sau e la nivelul unui olimpic) cred ca esti un pic biased 😛
Nu trebuie sa fi neaparat olimpic, ca sa fi un foarte bun programator algoritmic. Nu cred ca este corecta formularea olimpic/neolimpic. Stiu oameni extraordinar de buni si calificati care nu au participat in viata lor la o olimpiada. Este singura observatie pe o am de facut 🙂 . In rest sunt de acord cu tine Vivi!
@Sergiu: nevoia de echipamente totusi, de ce a fost generata? De ce ati avut nevoie de acele doua servere in plus?
Vivi, intreaba orice american si o sa-ti spuna ca “hardware is cheap”. Cea mai simpla solutie aproape intotdeauna este sa arunci hardware mai puternic. Asta e prima solutie la care se gindesc, nicidecum sa angajeze un olimpic sau cineva care stie algoritmica pe de rost. Sigur, exista si exceptii, insa aici incercam sa vorbim despre reguli, nu despre exceptii.
Eu mai degraba merg pe varianta arhitecti / manageri destepti, nu neaparat programatori. Doar la G. e o ierarhie relativ plata in care programatorul e rege, insa in foarte multe alte locuri deciziile proiectului nu se iau la nivel de programator ci mai sus un pic. Asa ca nu el decide daca foloseste algortmul X sau Y, daca foloseste hash sau ordoneaza lista sau nu s.a.m.d. De cele mai multe ori mi se pare ca programatorii trebuie sa fie ca si soldatii: sa execute un ordin fara sa cricneasca.
Iar cu exemple de aplicatii scrise prost mi se pare ca e vine tot a PM / arhitecti / manageri care ar trebui sa revizuiasca codul, sa stie cum functioneaza, sa ceara sa fie testat complet, etc.
Oricum bravo olimpicilor, pt. ca nu-i putin lucru realizari de-alea.
ITist,
Am auzit de multe ori ca “hardware is cheap”. Am auzit de multe ori de firme unde programatorii buni sunt considerati cei care fac “fitze” in cele mai exotice limbaje. Am vorbit cu oameni de genul asta si de multe ori am vazut ca din pacate nu aveau idei fundamentale despre ce e underneath it all. Eu inteleg layerele de abstractizare, dar din pacate pentru ei functioneaza pana la un punct, si anume, punctul in care ai nevoie de scalabilitate. In care O(time), O(memory), O(bandwidth), in general O(resurse) conteaza. Si al naibii daca se scaleaza liniar… 🙂
Programatorii ca si soldati? Arhitectii ca si generali? (presumably). Nope, sorry. Aia nu sunt programatori, sunt code-monkeys. Trebuie sa le scrii specs atat de detaliate incat le-ai facut practic tu cam tot. Si apoi arhitectul pleaca in alta companie, si you’re screwed, era singurul care stia cum e gandita aplicatia… Modelul e flawed pentru ca nu promoveaza, err, promovarea: un om are cativa oameni dedesubt, si speranta e ca in 2-3 ani cel mai tare om de sub el sa-i ia locul, in timp ce el se muta mai sus.
Poate sunt eu norocos, dar cel putin la noi la firma (see my webpage for details) algoritmica conteaza imens. Multe din problemele noastre sunt NP-complete, si o euristica buna ajuta mult. Daca underneath ai niste module scrise cu cap, cu structuri de date care “zboara”, reusesti sa mai impingi un pic spatiul problemei, si cu putin noroc Intel reuseste sa-si routeze chip-ul pe 45nm in loc de 65nm.
Algoritmii rock, dude… e un motiv pentru care la noi, la GOOG/ MSFT/ YHOO/ firme tari o mare parte din interviu se focuseaza pe asta. Si la nivel de (senior) engineer, nu de architect.
Lastly, nu cred ca non-olimpic => nu stie algoritmi. Se pot invata si gandi multe intr-o scoala buna, de catre un om motivat. Disclaimer: sunt unul din fostii olimpici.
Nu cred ca este corect termenul de “olimpic”. Ci mai degraba de hmm.. nu stiu “educat in algoritmica”?, nu imi vine nici un termen. As da ca exemplu (pozitiv :D) pe Cosmin, care in liceu nu a participat la olimpiade, dar s-a tinut de algoritmica si Acm-uri, topcoder etc.. Toata lumea stie ca e foarte meserias, si ca a ajuns la google, datorita faptului ca stie algoritmi si s-a implicat in comunitati de algoritmi, dar nu a participat la olimpiade.
E adevarat ca multa lume incepe cu olimpiade, insa nu cred ca se poate generaliza : “Algoritmica stiu doar olimpicii”. Asa cum nu toti care participa la olimpiade stiu algoritmica de nivel mediu-inalt, si cei care nu participa nu stiu deloc, sau de nivel scazut.
As vedea olimpiadele ca un inceput, sunt doar un tip de concursuri algoritmice.
Sunt de parere ca firmele care vor sa dezvolte soft de calitate au nevoie de oameni determinati care au o gandire specifica rezolvarii de probleme, au intuitie, s-au dovedit a fi determinati si capabili de invatare si studiu greu.
In alte cuvinte omul perfect, care are o baza solida si intelegere deplina si capacitate de a vedea dincolo de cod, ce inseamna el, ce abstractizeaza el.
Algortmistul e adaptabil la orice situatie, cod etc.., v-a putea fi antrenat , are “something to build upon”, v-a constitui un asset mai tarziu. Nu ai avea ce sa construiesti pe un programator obisnuit doar sa implemnteze boring stuff, si sa faca call-uri la librari care implemnteaza greul.
De aceea nu orice companie isi permite o astfel de investitie pe termen lung.
Mai short mi-as exprima parerea : cineva care stie algoritmica are mindset-ul perfect pentru un programator de succes, de aceea nu m-as limita sa spun ca doar “olimpici” constituie aceasta categorie de oameni. Exceptiile foarte sunt putine ce este drept.
Just my 2 cents :)) , eh ce stiu eu inca nici nu mi-am dat BAC-ul lol, de parca ar conta 🙂
sorry offtopic : ar fi ok daca ai putea include si o functie de editare a comenturilor
Primul paragraf e exagerat … si la olimpiade am participat, dar rezultatele nu au fost extraordinare.
Vroiam sa zic ca e importanta partea cu cunostintele de algoritmi si nu neaparat cu participatul la olimpiade. Din cate vad la scolile bune in state se face algoritmica ceva mai bine decat la noi. Poate asta e un motiv pentru care in tara cunostintele de algoritmica sunt puternic corelate cu participarea la olimpiade in liceu.
Cel putin eu nu stiu oameni ce s-au apucat sa invete algoritmica de nebuni si nu au participat la nici un concurs de programare.
Foarte mi?to postul ?i comentariile. Eu a? mai ad?uga un lucru: faptul c? am început cu to?ii programarea cândva prin ?coala general?. E un lucru uria? s? intri în facultate având deja o experien?? în programare de 6-7-8 ani. Pentru c? se formeaz? ni?te reflexe. Aduce?i-v? aminte c? a fost o vreme în via?a noastr? când trebuia s? judec?m orice proceduric?, cum ar fi aflarea maximului dintr-un vector. Acum de toate m?run?i?urile se ocup? direct arcul reflex dintre ochi ?i degete, creierul se poate gândi la probleme mai grele 🙂
Spun asta pentru c? e lumea plin? de fo?ti ingineri mecanici / chimi?ti / biologi care ?i-au luat ?i ei o diplom? de informatic? într-un an sau doi ?i se angajeaz? ca programatori. ?i nu zic, am v?zut ?i cazuri fericite, dar cei mai mul?i sunt slabi, atât de slabi încât nu ai cu cât hardware s? arunci în problem? ca s? o rezolvi (cazul mediu pe care l-am intervievat nu ?tia s? inverseze o list? simplu înl?n?uit? sau s? interclaseze doi vectori ordona?i).
Cred c?, pe lâng? participarea la olimpiad?, trebuie s? ne consider?m noroco?i pentru pasiunea care ne-a f?cut s? scriem acele prime progr?mele ?i jocule?e. E un lucru foarte rar s?-?i g?se?ti voca?ia atât de repede în via?? (omul mediu este colegul vostru din clasa a XII-a care nu se hot?râse înc? dac? s? dea la Medicin?, la Drept sau la Arhitectur?).
(1) Prin algoritmi iti dezvolti o gandire matematica ce te ajuta la rezolvarea problemelor in general, nu doar cele de programare.
(2) De mai bine de zece ani a devenit viabila practica pe care o descrii aici: in f multe situatii, datorita pretului scazut al hardware-ului, e mai RENTABIL sa maresti memoria sau viteza de procesare, decat sa platesti un programator bun sau sa aloci timp de dezvoltare suficient pt algoritmi software sofisticati.
(3) Am observat ca de fiece data cand am lucrat pt un client sau manager ne-tehnic, nu merita sa te investesti prea mult cu algoritmi sofisticati. In prima faza, mai toti vor ca sistemul sa le indeplineasca o anumita functionalitate de baza. Foarte putini prevad sau vor sa asculte de problemele de SCALABILITATE (putini stiu ce-s alea). Abia apoi, cand isi dau seama de time-consuming-ul datorat incarcarii (useri mai multi, bandwidth etc), pot in sfarsit sa plece urechea si sa aloce bani si pt …OPTIMIZARE.
Daca sunteti curiosi ce s-a intamplat cu olimpicii internationali la informatica din Romania aveti aici cateva informatii: http://infoarena.ro/olimpici
Vivi, trecand peste ideea de all mighty programmer, programatorul care face si drege, programatorul care ia deciziile cele mai importante din proiect (probabil esti influentat de mediul de lucru), as compara in mare ideea pe care o promovezi cu afirmatia ca “Lotus Elise este o masina extraordinara, prin urmare toti ar trebui sa conducem doar Lotus Elise sau ceva mai sus.” Da, Lotus Elise este o masina care arata foarte bine, finisata de mana, 0-100km/h in mai putin de 5 secunde, handling foarte bun, etc, etc. O afirmatie de genul “Lotus Elise este o masina extraordinara” este un truism.
Dar partea cealalta a afirmatiei (prin urmare toti ar trebui sa conducem doar Lotus Elise sau ceva in aceeasi clasa) este absurda in societatea actuala. Pentru ca oamenii au nevoie de mult mai multe masini decat este capabil Lotus Cars (si Ferrari, si Porsche, etc) sa produca. Si mult mai ieftine decat costa aceste masini. Asa ca multi oameni se multumesc si cu cate o Honda Civic sau o Toyota Corolla.
In aceeasi idee, Dumi, se pare ca tu lucrezi la o firma care face numai Porsche-uri (cel putin asta se intelege din cum vorbesti despre jobul respectiv). Dar nu toti cei care lucreaza in industria de masini lucreaza la Porsche-uri sau la Lamborgini-uri sau la BMW seria 5…
Marian, de aceea mesajul meu prezinta probleme care POT aparea atunci cand un proiect are succes si rezolvari posibile (atat prin solutii banesti cat si prin solutii calitative).
Daca vrei in analogia ta cu masini, nu toata lumea trebuie sa conduca un Lotus Elise. Dar daca iti cumperi o Honda Civic nu vei putea concura cu cineva care are un Lotus. Vei putea sa ii faci poate upgrade la motor si sa il faci sa mearga mai repede. Vei putea sa cumperi ulei si benzina mai de calitate, poate sa angajezi un super sofer. Dar cat timp nu iti iei un Lotus, tot el va castiga cursa.
Si mai mult, sunt de acord ca nu toata lumea participa la curse. Dar toti pasionatii de masini se uita la curse cu fascinatie, nu? 🙂
Va propun sa va ganditi la urmatoarea intrebare: Cum se vad pe ei insisi programatorii numiti “code-monkey”? 🙂
Mi se pare ca problema de la trilulilu e una de management mai degraba decat una de programare. Sigur, programatorii pot sa optimize cate ceva, dar in cel mai bun caz pana la o anumita limitare instrinseca. Daca managerii nu sunt in stare sa cumpere hardware-ul la timp, asta-i piesa.
Oricum, stiti ce se zice: nu exista publicitate negativa 😉
Cat despre olimpici :D, olimpicii sunt olimpici. Dar parerea mea este partinitoare 😀
Ce imi plac oamenii care emit afirmatii sigure si autoritare despre lucruri cu care n-au nici un fel de legaturi directe. 🙂
Sergiu (Biris): Ne poti spune totusi de ce anume ati avut nevoie de noi servere? Limitare de resurse fizice sau de capacitate de procesare?
Foarte interesanta ideea postului dar pare cam trasa de par aruncand in fata olimpici. Aruncare datorata probabil dintr-o superioritate olimpica ca sa zic asa. Trebuie inteles ca olimpicii cu medalii sunt fenomene, nu sunt varsati din cer cu sacul si nu orice firma are acces la ei.
Un proiect de tipul Trilulilu nu necesita foarte mult knowledge, cel putin pe partea de programare. Trilulilu are nevoie de scalabilitate, conectivitate si resurse hardware puternice – un bun specialist in retele + un buget corespunzator cred ca ar rezolva problema.
Bogdan, am dat un exemplu cum o operatie atat de simpla precum gasirea de duplicate intr-o lista are nevoie de oameni cu gandire algoritmica si cunostinte de structuri de date.
Se pot gasi multe multe alte probleme la fel de simple, la fel de aparent triviale unde solutiile ideale sunt mai greu de gasit decat par.
Cred ca subestimezi numarul de cazuri in care astfel de lucruri fac diferenta si faci gresala pe care o fac cei mai multi manageri care au impresia ca stiu ei mai bine. Isi zic ei probabil “mare lucru, ai o gramada de fisiere video, dai bani pe multe servere, ce poate fi asa complicat, pana si eu inteleg asta”. 🙂
vivi, exagerezi. Sunt de acord cu Bogdan: cine n-a rumegat CURSUL de “Data Structures & Algorithms” nu-i …programator. Nu trebuie sa fii olimpic. Si n-o spun din …invidie (am fost al 3lea pe tara inainte de 90 si-am ani de zile la …competitorul lui Vivi :)).
Cei care (inca) lucrati pe la firme ce creaza sisteme, software from-ground-up, ganditi mai mult out-of-the-box. 90% din celelate firme nu stau sa mai reinventeze searching/sorting/shortest path, ci aplica librariile definite de voi. De multe ori …astea “suck”.
Mai intai de toate, identifica genul problemei: scalabilitate, optimizare, arhitectura? Si ce-i atat de greu de inteles ca scalabilitatea se rezolva azi frecvent prin complementare hardware? De-atatea ori e mai RENTABILA, salveaza bani. Si spun asta chiar daca-s softist. Ganditi mai mult business, puneti-va in pielea clientilor. Solutiile “puriste” se-aplica doar in facultate. Ah da, si la …olimpiade 😉
ah, si inca ceva. In “the outside world”, programatorii trebuie frecvent sa se descurce pe structura impusa de cate-un system architect. Nu managerii, ci arhitectii vin cu limitarile cele mai mari. Exemplele cu eliminarea duplicatelor sunt banale. Problemele cele mai frecvente vin de la arhitectura, nu algoritmi.
Cristi, oare ai citit mesajul initial cu atentie? Am admis ca exista tipuri de probleme in care solutia unica este aruncarea de bani, am admis si ca pana la un nivel poti compensa lipsa algoritmilor prin aruncare de bani, deci nu asta este lucrul pe care discutam.
Am incercat insa, cred eu, sa argumentez concret si sa dau un exemplu de algoritm banal care nu are o solutie in nici o librarie (determinarea de duplicate intr-o lista). Nu este nicaieri implementata standard (din cate stiu eu). In cazul ala ceea ce tu spui nu se aplica.
Contra argumentele tale sunt mai mult pareri personale, da-ne niste exemple sau incearca sa combati argumentul pe care l-am dat eu daca nu esti de acord cu concluzia.
Vivi, l-am citit (scuze ca am fost mai polemic). Scrii insa iar de “aruncarea de bani”, cand nu-s singurul care ti-a zis ca sunt intr-adevar multe solutii in care “hardware is cheap”, deci exact contrariul :). Ca ne place sau nu (noua, softistilor).
OK, exemplu concret: chiar Trilulilu. Ai atins doar chestii simple, de OPTIMIZARI (queries, eliminarea duplicatelor). Am dezvoltat destule sisteme similare, sa-mi dau seama ca si acesta e un OLTP (n-as crede ca folosesc OLAP) la care lipsa scalabilitatii venea cert din limitarea de bandwidth si de resurse (preponderent hardware). Chiar daca putea cere si ceva optimizare, sunt convins ca rezolvarea NU ERA la nivel algoritmic. Cel mult puteai sa mentionezi reconfigurare (clustering, splitare baze de date, redistribuire a procesarii etc). Am scris iar de arhitectura (care e mult diferita de algoritmica), dar aici nu putem decat sa speculam :).
In modul cum ai pus initial problema, sunt cateva alegeri fortate si irealiste:
– determinare de duplicate intr-o lista de titluri. La Trilulilu? din ce, din cache? La marimea bazei lor de date? Mira-m-as. Ar folosi mai degraba queries si unicitate pe index (keys).
– problema cu olimpicii care trec direct din facultate sa lucreze la Google sau Microsoft e ca multi programatori – fie si geniali – nu s-au lovit vreodata de problemele reale din mediul business, unde se cere eficienta, pe constrangeri bugetare adesea severe. Putini au intr-adevar nevoie de algoritmi noi, majoritatea sistemelor (gen Trilulilu) sunt mai degraba standard: baza de date, multi-user/multi-procesare, tranzactii.
– se tine prea putin cont de aspectul business. Mi-ar placea sa plonjam intr-adevar si-n cazuri foarte concrete, dar desigur ne-am intinde mult prea mult.
[…] Vivi pledeaza pentru “olimpici” si pana la un punct ii dau dreptate. Sunt categoric pentru recunoasterea competentelor si mi-as dori ca toti sa inteleaga ca un programator de calitate (nu neaparat olimpic) le poate aduce mai mult decat unul de duzina. Sunt insa cateva aspecte problema, foarte viabile, pe care softistii dealtfel capabili, ce trec direct de pe bancile facultatilor la companii ca Google sau Microsoft, nu le vad […]
Raspund aici la postul lui Cristi pt ca pe blogul lui ii trebuie tot felul de id-uri cu care sa ma loghez. Ar trebui sa cititi postul lui ca sa vedeti contextul.
1) Cred ca oameni care au reusit performanta in un domeniu vor sa o atinga si in altele si vor sa evolueze si sa invete, de aceea cred ca un “olimpic” ar vrea sa invete tehnici bune de software development si nu isi va bate joc de munca lui facand spaghetti code.
2) Imaginea globala a gestionarii unui proiect sau modelelor de business nu poti sa o ai decat daca treci prin cateva proiecte reale, deci daca iei doi programatori iesiti de pe bancile facultatii unul olimpic si altul neolimpic nu cred ca vreunu dintre ei va avea viziunea care se cere in “prin vest”.
Conceptul keep it simple stupid cred ca olimpicii stiu destul de bine pentru ca in acelasi concurs ei trebuie sa rezolve mai multe probleme si le e mai usor daca scriu cod scurt curat si simplu. Ei trebuie sa isi maximizeze punctajul si de aici apare si putin pragmatism. Cum zicea Mircea Pasoi in un interviu pe blogul meu, cei mai tari la concursuri sunt mai buni prin faptul ca gandesc simplu si rezolva probleme dure prin cod curat.
3) Nu vad legatura cu programatorii geniali aici, e vorba de intreaga industrie.
4) Din nou ce am zis la 2. Nu le poti avea pe toate, si treaba cu privirea de ansamblu e destul de tricky, dar dupa ce un om trece prin un proiect mare ajunge si el la o privire de ansamblu.
Chestia cu scalabilitatea cred ca e putin exagerata, de multe ori am vazut proiecte unde se poate injumatati spatiul de memorie folosit sau se poate optimiza viteza aplicatiei de 5 ori daca stii unde sa te uiti, fara a complica codul, ci pur si simplu sa mai folosesti cate un hash in loc sa parcurgi structura de date pe ici pe colo, ceva cacheing si merge treaba.
Se pot imbina cele doua chestii: cumparatul de hardware si eficientizarea/curatarea codului si atunci obtii cele mai mari avantaje.
5) E normal sa nu estimeze bine programatorii, de aia nu sunt econimisti 🙂 de aceea e bine sa ai echipe cu cunostinte variate, astfel invata unii de la altii si ai cativa buni pe fiecare domeniu.
Eu cred ca e bine sa incerci challengeuri si sa te autodepasesti, si cred ca majoritatea suntem mai eficienti cand lucram sub presiune, deci e ok, dar managerii ce depind de asta toti invata ca e foarte greu sa estimezi durata unui proiect si unii dintre manageri chiar au buffere de timp programate.
6) Hmm la partea asta nu stiu ce sa zic, probabil fiecare ar trebui sa fie responsabil pana la capat de un proiect ce l-a facut, sau cel putin pana cand proiectul e foarte stabil.
Nu stiu ce geniali stii tu 🙂 dar dupa cum ii descrii nu sunt geniali deloc.
Cosmin – pe blogul meu se poate posta si total anonim, sau cu un simplu nick name 🙂
In rest, multumesc de comentariu. Si m-am referit intr-adevar la softisti capabili (olimpici, “geniali” daca vrem :)), insa maturitatea (asta e) se obtine in timp 🙂
Cateva comentarii spun ca separarea olimpic/neolimpic e artificiala. Sa presupunem ca e. Atunci discutia care ramane este daca e mai rentabil sa angajezi programatori buni sau prosti. Toti programatorii pe care ii stiu au aceeasi definitie pentru ce inseamna programator bun si ce inseamna programator prost. Pe scurt, e cam asa ceva: “Daca se pricepe la lucrurile care-mi plac mie atunci e bun; daca isi pierde timpul crezand ca alte lucruri sunt mai importante atunci e prost.” Unde “lucruri” ia valori din multimea {algoritmi, arhitectura, Java, stil de cod, interfata cu utilizatorul, …}
Daca vrei programatori care pot lucra pe proiecte variate angajezi programatori care au lucrat pe proiecte variate. Daca vrei programatori care sa faca situri angajezi programatori care au facut situri. In general, daca vrei programatori care sunt buni la X angajezi programatori a caror istorie arata ca sunt buni la X.
Daca nu ai luxul sa poti face asta atunci trebuie sa angajezi programatori a caror istorie arata ca sunt buni la Y si sa speri ca performanta la Y e corelata cu performanta la X. De exemplu, daca toti cei care aplica sunt abia iesiti de pe bancile scolii, atunci are sens sa preferi unul care a participat la olimpiade, tot restul fiind egal.
Pe scurt, sunt multe axe pe care se masoara bun/prost si nu e deloc clar cum sunt corelate intre ele. (Ar fi interesant daca ar exista niste studii experimentale.)
Asta fiind zis, intebarea cu daca e preferabil sa angajezi programatori buni fata de programatori prosti mie imi pare ca nu poate avea decat un raspuns. Singurele motive pe care mi le imaginez acum ca ar putea sa le aiba un manager ca sa angajeze un programator prost sunt ca (a) programatorii prosti sunt _mult_ mai ieftini sau ca (b) managerul e prost. Sunt tare curios daca (a) poate fi adevarat si in ce scenariu.
Ca veni vorba de scalabilitate:
– http://www.baselinemag.com/article2/0,1540,2082921,00.asp (despre Myspace si problemele intalnite de ei dea-lungul scurtului timp de la lansare – majoritatea probleme de scalare)
– http://www.highscalability.com/ (despre scalabilittate…si detalii despre cum sunt arhitecturate marile website-uri gen Youtube, Flickr, etc)
Cateva observatii:
1) Exemplu cu hash-ul este intr-adevar destul de simplist pentru ca marea majoritate a programatorilor vor folosi hash-uri si nu vor ordona lista: as vrea sa am un dolar pentru fiecare if(hashMap.get(object.getKey()) != null) {//.. handle duplicate} pe care l-am vazut pana acum. Exemplu pe care tu-l consideri “exotic” este de fapt comun si exemplul pe care-l consideri “comun” este destul de rar si exotic.
2) E o eroare sa departajezi forta de munca in IT dupa criteriul: olimpici/ne-olimpici. Ce au de oferit olimpicii (cunoastere exceptionala a unei multimi de algoritmi, solide cunostinte in combinatorica, etc…) este necesar unei foarte mici parti din piata IT care de regula se ocupa cu optimizarea a diverselor lucruri (baze de date, produse de replicare de date, sisteme de tranzactii distribuite, etc…).
Ce se cere cu mult mai mult pe piata IT sunt cunostinte in modelarea unui domeniu si eventual cunoasterea acelui domeniu. Aceste 2 lucruri te vor ajuta sa creezi arhitectura unui sistem informatic care se poate adapta eficient domeniului si schimbarilor domeniului. Sa-i dai seama rapid ca o problema este NP-complete sau nu nu te va ajuta sa creezi un sistem de asigurari (de exemplu) care sa poata acomoda cerinte noi repede si bine.
3) Dupa cum f. bine remarca Stefan Ciobaca problemele descrise in postul de blogul lui Sergiu Biris sunt probleme de management: 2 servere erau pe drum, n-au mai venit, o sa vina altele, etc…, o problema tipica de gestiune de resurse.
4) Este curios de ce trilulilu nu a cautat sa rezolve problema temporar cautand ceva ieftin pe piata romaneasca care sa le rezolve problema temporar si au asteptat/asteapta sa le vina serverele puternice din Franta. Am impresia ca 10-20 de calculatoare tipice de 600$ ar fi putut sa rezolve o parte din problemele generate de cresterea temporara a traficului (10-20 de calculatoare ar fi putut sa faca streaming la acelasi video clip care era cerut foarte mult cat 2 servere high-end). Singurul lucru la care ma pot gandi este cu trilulilu prefera sa scaleze vertical iar nu orizontal si ca isi mareste numarul nodurilor cu greutate.
Trilulilu ar trebui sa gaseasca un mod de a gestiona cresteri anormale ale traficului, cresteri care sunt greu de anticipat. Iri&Moni se poate intampla oricand din nou (si ar fi in interesul lor sa se produca cat mai des), ei ar trebui sa fie pregatiti pentru aceste cresteri anormale ale traficului. A bare-back post from Sergiu va face treaba odata, dar a doua oara va trece mai greu…
5) Postul lui Sergiu despre problemele de hardware spune multe lucruri despre piata de hard din Romania. E penibil sa te duci pana in Franta pentru niste servere mai puternice…
6) E curios de ce trilulilu scaleaza vertical (folosind Xeoane scumpe) si nu orizontal (folosind servere ieftine) cum se practica in industrie. Singurul lucru la care ma pot gandi este ca incearca sa mentina numarul nodurilor sub control, probabil pentru trilulilu costurile operarii unui nod sunt mai mari decat diferenta de pret dintre un nod scump (Xeon) si un nod ieftin (white box built in-house).
7) Altfel trilulilu este un sit destul de simpatic pe care voi continua sa-l folosesc fiind principala mea sursa de video/audio din Romania. Melodia asta (http://www.trilulilu.ro/runa_/d7ab43ab334dab) o ascult deja de cateva zile.
Mi se pare fortata elogiereea glorioasa a olimpicilor.
Sincer ma mir cine naiba a avut rabdare sa scrie asa ceva ?
Titlul e genial “Cine are nevoie de olimpici ?” , adica chiar nimeni nu are nevoie de ei ?????chiar asa de inutile sunt temele lor teoretico-filozofice ?
Sunt olimpic dar oare va veni NASA sa ma angajeze ? oricum eu stau zi de zi sa astept
[…] Vivi pledeaza pentru “olimpici“ si pana la un punct ii dau dreptate. Sunt categoric pentru recunoasterea competentelor si mi-as dori ca toti sa inteleaga ca un programator de calitate (nu neaparat olimpic) le poate aduce mai mult decat unul de duzina. Sunt insa cateva aspecte problema, foarte viabile, pe care softistii dealtfel capabili, ce trec direct de pe bancile facultatilor la companii ca Google sau Microsoft, nu le vad: […]