Algoritmi sau business-oriented problem-solving? Care skill-uri sunt mai importante?

@Work Carieră & Soft Skills
1

O intrebare foarte interesanta pe Quora.

Cateva din opiniile exprimate cu care rezonez personal:

[…] two different cognitive styles in software engineering. The person who is good at designing and writing new algorithms is talented at the most abstract topics like math but less good at dealing with large amounts of detail. The other cognitive style is demonstrated by what I call “integraters”. Those people are good at mastering the huge amout of detail necessary to put together many different pieces of software using a variety of programming tools - less abstract much more detail.

Good software developers are for the most part expert consumers of data structures and algorithms rather than expert producers of data structures and algorithms.

Good software developers aren’t “weak” on algorithms. They’ve just gotten over it. They don’t think it’s important. Because it isn’t. Algorithms are the kind of thing implemented by one person. Good developers know that very little real work is done by one person.

Entry-level developers tend to get quizzed more on the fundamentals because that’s all they probably know. It’s not actually very important to the job, but it’s the only experience they have to draw on.

De partea cealalta,

If someone is weak at data structures and algorithms, they can hardly qualify as a good software developer. […] You shouldn’t trust the opinion of anyone who downplays the importance of being strong in data structures and algorithms.

Great software developers are, by and large, great with algorithms—even if they don’t know a lot of the famous ones. Developing algorithms is so fundamental to what a software developer does that it’s difficult to be great at writing software in general without being great at figuring out the steps to solve a problem.

4 Likes
2

old-el-paso-taco-girl.jpg800×450 37.1 KB

E ontopic !

3 Likes
3

Depinde de domeniu. :slight_smile:

1 Like
4

Te rog elaboreaza, exact de asta am ridicat “la fileu”.

Eu consider ca programatorii buni sunt cei care stiu sa livreze functionalitatea dorita de business, fara sa scrie cod criptic pe care doar ei il inteleg, si fara sa faca overengineering.

Din experienta mea, cei care sunt pasionati de algoritmica nu intotdeauna scriu cod usor de mentinut si de asemenea nu intotdeauna lucreaza bine in echipa.

7 Likes
5

intrebi din prisma angajatorului sau a angajatului?

6

Aplicația aia Google de pe mobil care îți sugerează știri de când am telefoanele îmi tot recomandă articole de genul:

  • Cele 5 top caracteristici ale unui programator bun
  • Cele 10 chestii pe care angajatorii le caută la un programator
  • Ce am învățat după x ani ca programator (tocmai fugit din Bangalore și lucrând în SUA la ceva firmă obscură)

După vreo 500 de astfel de articole citite de-a lungul anilor am ajuns la concluzia că tot ce zic astfel de discuții e: scrie cod bun, nu scrie cod prost. Adică nimica. Toată blogosfera din industrie vorbește despre concepte vagi de genul: un programator bun e atent la detalii. Bleah.

Pentru mine e foarte simplu. Un programator bun scoate cod care:

  1. Funcționează. Banal dar cam tot ce scot colegii mei e marginal funcțional. De genul dacă îi dai o anumită valoare inițială merge. Pentru orice altceva crapă undeva. Și nu e vina lor, tu ai dat ceva valoare proastă.
  2. Funcționează suficient de rapid. Criteriul ăsta nu îmi aduc aminte să-l fi respectat cineva. Că pentru un import dintr-un fișier CSV de 50.000 de linii chestia durează 7 ore, not my problem.
  3. Scrie codul în cât timp e necesar. Nu 50 de linii de cod în 6 luni, cod marginal funcțional taxat cu vreo $10.000.
  4. Scrie cod ușor de citit și urmărit. N-are rost să spun că toată lumea se kk în asta. Merge pentru valoarea 1. Că nu poți citi tu codul, că nu poți urmări execuția că am băgat acolo o funcție recursivă de chichi, că nu merge pentru orice înafară de valoarea 1, treaba ta. Noi ne-am cărat, hai, papapapapapa.
7 Likes
7

Problem solving, dar sa nu implice business.

1 Like
8

Raspunsul a fost foarte clar. Reformulat, ‘depinde de functionalitate’. Daca businessul doreste un sant, probabil ca niste sapaturi de santuri sunt de ajuns.

E adevarat ca functionalitatea e cel mai important aspect. Mentatilitatea cu ‘very little real work is done by one person’ e foarte paguboasa, e clar mentalitate de manager care se uita in stil comunistoid la ‘muncitori’. Pentru manager, important e sa aiba softul functional la termen, sa iasa banul. Respectivul vede toata padurea, ignora copacii, si mai ales ignora faptul ca un programator a facut un sfert de padure pe cand altii au facut cate o frunzulita (iar unii poate au avut contributii negative, poate chiar masive, incendiind padurea de cateva ori :slight_smile: ). Mai mult decat atat, copacii aia nu sunt egali in cazul softului. Poti sa ai doar vreo cativa extrem de importanti, din diverse motive. Lasand analogiile la o parte, studiu de cazuri:

  1. ‘Business’-ul e de fapt cercetare stiintifica. Program functional, folosind simetrii pentru a face rezolvarea problemei abordabila. Problema: Ai de-a face cu Clebsch–Gordan coefficients - Wikipedia Calcule tensoriale cu asa ceva. Bineinteles, structuri de date si algoritmi, ca doar n-o sa rezolvi problema ne-algoritmic sau anti-algoritmic, ‘business oriented’. Intr-o prima faza, implementarea lasa de dorit, in sensul ca o buna parte din eficienta teoretica ramanea doar pe hartie datorita unei implementari lente. O abordare ‘business-oriented’ desi livra functionalitatea, o facea aproape inutilizabila. Prima faza: implementarea de ‘sparse tensors’ cu std::map. Simplu, muncitoresc, structuri de date si algoritmi standard, doar cateva ore de lucru pentru a adapta programul la asa ceva. Salt spectaculos in performanta, pe ceva simplu de test s-a trecut de la ore la minute timp de executie. Binisor, dar nu suficient. Pasul urmator: focus pe calcule. Implementarea ‘sparse tensor’ care sa fie eficient nu numai pe accesul la coeficienti, dar si la calcule. Timp de lucru: vreo doua ore de comunicare a detaliilor problemei, ceva mai multe ore de scris cod si testare decat in prima faza, algoritm mai complicat, inca vreo doua ore pentru integrare in program - asta fiind munca in echipa, doua persoane. Reducere timp de executie la secunde.

  2. Lasand chestiile astea sofisticate care nu sunt ‘business oriented’, sa trecem la ceva cu adevarat ‘business oriented’. M-am lovit recent de ceva scris cu picioarele de vestitii programatori rusi, tari in algoritmica (sau asa se zice). Suficient de tari ca sa livreze functionalitatea. Cod C++ scris in stil C de catre niste programatori C extrem de slabi. Adica foloseau librarii C++ dar programul era scris in stil C ca porcu’. Nu stiu cum altfel sa numesc ceva care foloseste un milion de variabile globale cu nume criptice. Eventual poate purta denumirea de ‘job security’. Dar problema reala nu e acolo. Problema reala a indicat-o un tester: domnilor, avem o problema, programul si in idle foloseste 100% din procesor. Problema era chiar mai grava, programul ar fi folosit 100% chiar si la un procesor cu viteza infinita. Serios, analizand codul puteai sa-ti dai seama ca indivizii erau extrem de ‘business-oriented’, au ales pentru video streaming o librarie care era usor de folosit, pentru OpenGL au folosit Fixed Function Pipeline - OpenGL Wiki pentru ca le era lor mult mai usor (si aparent suficient), au ales pentru codec ceva destul de avnsat pentru ca acolo s-a simtit nevoia, etc. Multe dintre alegeri pareau rezonabile, programul dadea in acel moment iluzia de functionalitate (chiar putea fi folosit, doar ca avea unele probleme)… doar ca necesitatile pe termen mai lung erau mult mai mari… foarte multe cadre pe secunda, imagini cu rezolutie foarte mare, analizare ‘computer vision’ si AI, chestii care necesita putere de calcul. Daca o ocupi cu prostii inutile, nu o mai ai pentru altceva.
    Ok, acestea fiind prezentate, a urmat sa ma bag eu in cod un pic, profiling pentru a identifica locurile unde se intamplau tampeniile business-oriented, apoi rezolvarea problemelor. Nu neaparat cu chestii sofisticate de algoritmica, ci cu cunoastere ceva mai detaliata a librariilor folosite. De la timp de calcul infinit ‘necesar’ am redus la o fractiune din puterea de calcul a procesorului (extrem de slabut comparativ cu ce intra in productie). Nu am lucrat foarte mult pe asta, cam zero din perspectiva ‘very little real work is done by one person’. Dar beneficiul din punct de vedere al puterii de calcul ‘necesare’ se poate zice ca a fost infinit :slight_smile:

3 Likes
9

Dacă este vorba o problemă de business gen bancă, logistică depozit, etc. pentru care se dorește o implementare software, trebuie mai întâi să înțelegem acel business împreună cu ei care înțeleg acel business, să punem întrebări, să vizualizăm exemplele, știi tu: ddd,bdd și arhitecturi software. Se poate de exemplu să constatăm că unele probleme de business sunt chiar probleme de grafuri, dar probabil aici fie folosești o librărie care îți oferă acei algoritmi sau să folosim o bază de date de tip graph de exemplu neo4j.
Dar dacă prin business este ceva mai tehnic, poate un kernel de sistem de operare, un compilator, un nou limbaj de programare, poate ceva de gen piped piper unde nu există deja care să îți ofere o anumită funcționalitate, atunci ar trebui să ne reamintim cursurile de algoritmică și structuri de date, eventual să găsim moduri noi și mai bune pentru probleme cunocute sau necunoscute.

10

Seriously tho’, why not both? Vorba lui @Cosmin_Popescu

Eu am o analogie și chiar zic că-i buna wrt cunoștințe strict tehnice vs cele de business. Sa zicem că un programator e un sportiv de performanță. Atunci cunoștințele de “computer science” ar fi forma lui fizică, iar cele de business ar fi skill-ul la sportul respectiv. Ai nevoie in general sa poti sa alergi mult fără să obosești, sa ridici greutăți mari, sa faci salturi și tumbe. Dar astea sunt mizele de intrare în joc și nu-ți garantează că vei fi un sportiv bun. Trebuie sa suplimentezi cu antrenament specific jocului, studiatul de tactici, de istoric al adversarului, să ai și o doza buna de noroc și în final să-ți placă jocul și să vrei sa faci asta câți ani de activitate oi avea. Sigur, de la sport la sport contează mai mult sau mai puțin forma fizica vs structura sportului. Golf sau dart sunt mult mai puțin demanding decât tenis sau fotbal. Ditto, structura sportului in sine poate fi complicată sau nu - maratonul e destul de simplu fata de fotbal sau formula 1.

La fel cum există IOI sau concursuri ACM, exists și concursuri de strong man sau de atletism pur. Dar nimeni nu ar consideră că îl putem pune pe Usain Bolt atacant din prima. Ditto nu am vrea sa punem un jurnalist de fotbal (cineva doar cu “business side”) acolo.

E altă discuție daca dihotomia asta CS vs business e buna. Pentru o companie precum Mongo, ce înseamnă munca strict tehnică și ce inseamna ce business?

4 Likes
11

Care skill-uri sunt mai importante?

pentru ce sau pentru cine?
cred ca asta e prima eroare in toata dezbaterea asta si e prima eroare in alegerea programatorilor sau a specialistilor /resurselor / solutiilor in general.

nu exista cel mai bun orice… ci exista oriceul potrivit pentru situatia mea

daca am nevoie de un programator care sa ii livreze o aplicatie care fucntioneaza conform cerintelor si o mai si livreaza in termenul stabilit… atunci nici nu conteaza cum o face, e bun daca o face.

da, aici putem dezbare problema “cerintelor”.
in cate cazuri se elaboreaza srs / sds / etc… corect si cmplet?
e vina programatorului daca specificatiile nu sunt corecte / complete?
oare structurile de date si algoritmica sunt mai mult la programator sau mai mult la arhitect?

eu cred ca problema are multe straturi, dar mai cred ca un specialist bun e cel care e capabil sa livreze ce i se cere.

1 Like
12

As alege intotdeauna un “business solver” in locul unui “algoritmer”.
Intamplarea face ca la un moment dat cineava sa-mi spuna ca nu-i merge “importerul de CSV” ceva similar cu cel de la @RedGuard. M-am gandit ca nu-i mare lucru, insa acolo am gasit un pattern Singleton chinuit ca a trebuit refacut complet codul.

1 Like
13

Mie imi place si acest raspuns de pe Quora

As mai adauga si cunoasterea particularitatilor limbajelor de programare, tool-urile cu care se lucreaza etc. Acum ceva timp am postat pe forum un link unde se prezenta un mod eficient de a citi un csv de mari dimensiuni

https://medium.com/@indy_singh/strings-are-evil-a803d05e5ce3

Cred ca putem spune ca a fost o combinatie de algoritmica + cunosterea unor particularitati ale limbajului.

  • An algorithm is just a process or set of rules that a computer takes to do something.
  • A data structure is a way of organizing data.

Acest raspuns poate fi o completare la acesta

Totusi, nu avem timp sa stam 7 ore pt un import ce csv :troll:

1 Like
14

Până la urmă îmi e dificil să înțeleg diferențierea. Fie că e software developer vs software engineer. Fie că e developer vs. arhitect, fie asta, algorithm stuff vs. business whatever.

În calitate de om care a vrut să scrie software mă ocup și de partea unde le zic clienților să lăsăm schimbările de text și culori până după lansarea de săptămâna viitoare. Mai întâi să meargă tot, pe urmă ne ocupăm de plantat panseluțe.

Ah, mai era o chestie în lista de lucruri banale de făcut: Nu te kk pe alți programatori. Am făcut un canal pe Skype unde notific când actualizez un pachet. Ca ceilalți care lucrează cu el să știe că sunt modificări. Cine mă notifică pe mine? Exact. Paula.

Toți oamenii cu care lucrez se descriu ca:

I am a SENIOR DEVELOPER & SYSTEM ARCHITECT with more than 14 years of hands-on Intensive Experience in developing large scale/ complex system solutions for any/cross platform with high performance and scalability feature.

sau

I am a Full Stack Web Developer with more than 10yrs of experience. I aim to deliver results according to clients needs, specifications, time & budget. I am fully dedicated to give you quality. Fully approachable and easy to communicate.

Dar nu poate să scrie o frază întreagă corect.

Când îi rog să-mi explice ce au făcut în 10 minute via un voice-call, știi ceva? N-avem noi timp de așa treburi, ia mai lasă-ne-n pace.

Ah, mă tăvălesc pe jos de râs:

Highly motivated Full Stack senior developer of having 7 years of experience in the software industry. I care about producing clean, elegant, maintainable, robust, well-tested code.

Ăsta a scris 3 luni cel mai mare rahat posibil pe care și acum stau să-l repar. Dar faza cea mai tare e că i s-a cerut să facă o modificare și s-a încurcat în propriul lui cod :rofl:

6 Likes
15

La interviurile pt juniori, am vazut ca se pune destul de mult accest pe intrebari de algoritmica. La ultimul interviul intrebarile au fost mai mult de cum as aborda o anumita problema. Proiectul la care lucrez in prezent implica si ceva algoritmica, dar si business.

Cum parsezi eficient fisiere care vin la intervale de 5-15 minute fara sa omori un server. Si vin multe la numar.
Cum calculezi KPI pt a ii pune frumos pe un dashboard si a face un raport pt management ?
Si alte din astea.
Este primul proiect unde am vazut ca se foloseste transformata Fourier rapida pt a calcula o periodigrama (implicatie in business)
Se cer ambele

La un proiect la care lucrez in timpul liber nu este un focus pe algoritmi neaparat, ci mai mult pe concepte de oop, design patterns (cqrs) precum si toolingul pus la dispozitie de limbaj si mediul de dezvoltare.

Pana la urma un algortim este o secventa de pasi pt a rezova o problema.

Scuze de reinvierea discutiei, dar este una interesanta :smiley:

2 Likes
16

O sa pun succint problemele care le am, engleza tehnica o inteleg cea de business nu, am dat bac la engleza, dar fac parte dintro generatie batrana, cei tineri unii sunt peste mine la engleza si apreciez, jobul implica communicare cu client in engleza atat concepte tehnice cat si de business.

Edit: Cred ca de obicei trebuie sa ai un mix de oameni care sa creeze business cat si tehnologie, cand eram mai tanar am incercat si eu sa creez business dar am ales calea usoara si m-am orientat spre open source, eu am crezut in open source inainte ca el sa fie in voga, consider ca e mai greu sa faci business decat tehnologie, trebuie sa intelegi nevoile oamenilor, nu doar sa fi tu cu calculatorul si sa rezolvi probleme, @tekkie a spus la un moment dat ceva similar ca e nevoie de o echipa ca sa creezi business.

2 Likes
17

Corect. Vb lui Knuth: “Premature optimization is the mother of all evil”.
Prima data sa mearga. Asta-i 90%. Dupa aia sa mearga excelent. Ala-i restul de 10%.
(sigur, nu vb de software ptr. rachete unde excelenta face parte din requirements).

Si ca intotdeauna balanta este cheia. AI scris cod criptic pe care doar tu si cateva genii il pot intelege? Nema balanta. AI scris cod labartat si lenes pe care si bunica l-ar fi putut scrie mai bine? Nema balanta.
Ai scris un cod curatel,cu o performanta decenta si usor de intretinut/extins? Bingo.

1 Like
18

Tre sa scrii cod ca si cum colegul de baca este un psihopat si stie unde stai :smiley:

19

@scheffgames asta a fost reperul meu mereu, am incercat sa scriu cod cum am apucat si am ajuns la un proiect nementenabil, dupa aia am mai studiat cum se scrie cod, de aia e bine ca cineva sa iti faca code review asta inseamna ca si altcineva iti intelege codul, si aici sunt proiecte pe care le scrii de la zero unde poti sa zici ca scrii totul clean, dar cand intrii pe un proiect scris de altcineva lucrurile nu sunt chiar ideale, daca ai idee de o abordare pentru acest caz sunt chiar curios care e solutia ideala cand modifici software scris de altcineva.

20

Neapărat să fie ceva teste unitare pe acolo, mai ales când modifici soluția altcuiva.

Am citit cartea asta despre abordare unui codebase de tip legacy → pe scurt : testele sunt cheia. Iți oferă siguranță și certitudine că nu strici ceva. Dacă combini testele cu tehnici precum folosirea interfețelor vei ajunge mai repede la success (sau final, în fine…)

2 Likes