Da ai dreptate, in general am problema asta pe UI AngularJS, in rest am impus test unitare, dar aici nu avem.
Nu sustin ca trebuie sa implementezi numai algoritmi naivi, sau ca nu trebuie sa cunosti algoritmica ci doar ca nu cunoasterea algoritmilor este scopul informaticii si programarii ci rezolvarea unor probleme concrete.
Din pacate mi-a luat foarte mult timp sa descopar si mai ales sa accept ca partea de business este mai importanta decat partea de inginerie care nu face decat sa implementeze nevoile business-ului.
3 Likes
Răspund din perspectiva unei persoane care plătește și a plătit programatori pentru dezvoltarea de soluții software. Sper că am înțeles corect întrebarea.
Sînt medic. În chirurgie circulă o glumă profesională: operație reușită, pacientul mort. Din punctul meu de vedere măiestria tehnică este o condiție necesară dar nu suficientă pentru a avea succes. Poți programa un website corect d.p.d.v. informatic dar care să fie perfect inutil d.p.d.v. al sustenabilității financiare. Tocmai explicam astăzi unui programator cu care lucrez că trebuie să ne poziționăm față de potențialii clienți astfel încât să creștem probabilitatea ca proiectul nostru să devină sustenabil financiar. Programatorii cu care am lucrat eu au tendința de a dezvolta features care sînt cool dar ?uită complet aspecte plictisitoare dar importante cum ar fi GDPR-ul sau implementarea unui flux de marketing; mai mult, consideră că este sub demnitatea lor/nu este treaba lor să implementeze aceste lucruri. În timp am descoperit că de fapt nu știu să lucreze cu adevărat cu tools-uri de marketing sau că nu cunosc legislația care afectează funcționarea unui business online. Pentru mine nu este suficient să faci copy/paste în head la scriptul de Google Analytics sau Facebook Pixel - ar fi de mare ajutor să mă educi cum să le folosesc; sau măcar îndrumă-mă către un tutorial decent pe subiect.
O eroare majoră pe care o poate face un programator este ca în loc să se uite la potențiala piață ca și sursă de venit să se concentreze pe buzunarul finanțatorului deși ar trebui să fie evident că acest buzunar va seca în lipsa aportului de capital de la clienți. Dacă eu ca finanțator ajung să știu ce este un framework, un flow într-un site, un câmp într-un formular și o validare, un div, o consolă într-un browser etc. etc. cred că și un programator trebuie să vorbească mai mult decât Programming Speak. Eu consider că skills-urile orientate către business sunt esențiale și pe termen lung un programator care înțelege aspectele de business va avea mai mult de câștigat decât un simplu tehnician și am încercat să ilustrez mai sus cum și de ce. Happy to discuss și chiar sînt curios ce veți avea de spus. 
5 Likes
de acord pana la un punct.
problema cu skillurile astea suplimentare e ca trebuie invatate, exersate si rafinate.
asta inseamna timp (pe langa cel necesar de a fi un programator bun).
asta inseamna ca programatorul respectiv e deja avansat in cariera + are de recuperat o investitie destul de mare => tarif mare.
sau pur si simplu in loc sa fie programator cu skilluri de business o sa fie antreprenor cu skilluri de programare.
in oricare dintre situatii… oamenii astia (care exista) nu sunt chiar pentru proiectul (si mai ales buzunarul) oricui.
apoi mai e si alt aspect aici: poate nu esti doar un finantator, ci si un project manager.
in ziua de astazi exista joburi destul de specializate (si oameni care sa le ocupe) si se pot acoperi toate aspectele necesare dezvoltarii si vanzarii corecte a unui proiect software.
faptul ca exista oameni cu pregatire multidisciplinara e ok atata timp cand exista o disciplina de baza in care exceleaza si pe care o practica in majoritatea timpului. altfel… e despre eficienta si mai ales ineficienta.
ps. exista si schimbari de cariera si asta e foarte ok, dar nu despre asta era topicul.
ps2. eu cred ca principalul skill secundar pe care trebuie sa il invete orice freelancer (indiferent de domeniu) e despre project management.
trebuie sa stie sa isi gestioneze foarte bine bucata lui si sa o execute cat mai eficient si in specificatiile angajate (timp, cost, tehnic, etc).
alte skilluri sunt mai mult pentru dezvoltare personala sau cel mult conexe jobului.
un client normal ar trebui sa isi ia un consultant pentru a isi intelege si traduce ideea si un arhitect pentru a ii dezvolta planul tehnic.
sincer, un exemplu mai prost nu am putut vedea vrodata scris si aici in ideea ca te-ai referit la soldati ca fiind programatorii care sunt foarte buni tehnici si doar executa(daca am inteles eu prost te rog sa ma corectezi). Am mai avut discutii cu altii la fel de inversunati pe subiectul ca un programator foarte bun tehnic este mai bine vazut decat unul mai putin bun tehnic dar cu alte skilluri precum cele de business.
Eu (programator) m-am gandit asa - un client multumit este cel pe care-l ‘educi’ in timp ce-i dezvolti produsul si nu doar ii executi comenzile. Un client nu stie ca tu ai scris o bucata de cod din 2 linii inloc de 4 ( dese ori performanta dintre cele 2 solutii este insesizabila). Am ajuns la gandirea asta vazand cum merg lucrurile in firma unde lucrez acum, unde se pune foarte mult accent pe skill-urile dinafara programarii, in special cele ce tin de ‘educarea’ clientului.
L.E. - a sters @RedGuard si probabil nu se mai intelege exact ce-am vrut sa zic
poate confunzi putin rolurile.
cand educi clientul si ii dezvolti produsul se cheama ca esti consultant si eventual arhitect.
cand implementezi ce ai educat mai devreme… abia atunci esti programator.
later edit: a nu se intelege ca e ceva gresit in a fi antreprenor / freelancer / multi-rol, etc.
fiecare isi alege ce i se potriveste mai bine, doar ca in exemplul tau nu mai vorbim exclusiv de un programator si atat.
de ce nu? de ce nu poti dezvolta produsul si pe parcurs sa-l educi? Ce vreau sa zic e ca la inceput clientul vine cu o idee, cu niste indicatii, pe parcurs ce dezvolti produsul - sa zicem - tu ca programator poti veni cu imbunatatiri legate de ceea ce doreste el sa faca sau chiar cu feature-uri noi ce il ajuta in dezvoltarea business-ului.
eu nu am spus ca nu poti sau ca nu e bine.
am spus doar ca atunci cand faci asta depasesti atributiile programatorului si iti asumi alt rol / alte atributii.
adica nu asta e normalul unui programator, ci e o situatie putin extinsa spre one man show.
daca ai angaja o firma mare pentru implementarea acelui software… ai toate sansele sa nu discuti ever cu un programator, ci cu alti oameni care fac ce spui tu si apoi traduc astea in niste specificatii exacte care sunt pur si simplu implementate de programator (care nu are nici voie si nici motiv sa intervina pe specificatii in faza de implementare - presupunand ca arhitectul si-a facut treaba bine).
daca vrei, e similar cu a angaja un om sa iti contruiasca o casa.
nu ai arhitect, nu ai inginer, nimic.
si te bazezi pe zidar si pe experienta lui sa te invete despre rezistenta la cutrebur, despre ergonomia locuirii in viitoarea casa, despre instalatii termice / electrice, eventual vine si cu o propunere despre niste automatizari si tot asa.
eventual, la final il intrebi si despre mobila si decoratiuni interioare.
si el e pur si simplu zidar.
e bine sa aiba is alte skilluri?
probabil ca da (in special pentru el si pentru dezvoltarea lui personala - si eventual provesionala daca vrea sa isi schimbe cariera sau sa se multicalifice).
e bine sa te bazezi pe skillurile lui pentru a lua decizii despre viata ta viitoare in casa respectiva?
probabil ca nu (cel putin nu pentru altceva decat zidarie).
si acum inapoi la programator.
daca inlocuim zidar cu programator si casa cu software… ti se mai pare o idee buna ca un programator sa faca de toate?
3 Likes
din punctul meu de vedere e trasa de par comparatia maxim. Nu trebuie sa fii arhitect sa vii cu idei de business. Si sa luam exemplul unui frontend dev - daca are ceva cunostinte si de ui/ux poate da un sfat in directia asta. Daca are ceva cunostinte business sau in timp ce dezvolta produsul isi da seama de un feature ce ar putea ajuta afacerea, din nou poate da un sfat in directia asta.
Din exemplul tau se intelege ca si cum daca un programator se apuca sa dezvolte un software inseamna ca va arata la final fix cum vrea programatorul(sau cel putin asa am inteles). Pe cand eu ma refer la faptul ca poti ‘educa’ clientul in anumite parti ale software-ului, sa-i aduci imbunatatiri, sa-i aduci valoare. Pentru asta nu tre sa fii nici arhitect nici manager nici inginer etc. Toate astea nu se afla in viziunea mea legata de programatori ci chiar este implementata unde lucrez acum. Noi ca programatori avem legatura directa cu clientul in fiecare zi, iar legat de feature-uri, avem meetinguri special pentru discutii legate de cum putem ajuta clientul mai mult si ce sfaturi ii putem da.
ca sa dea un sfat trebuie sa cunoasca foarte multe informatii despre proiect, in special imaginea de ansamblu.
pentru ca sfatul lui sa fie util… e nevoie sa cunoasca scopul proiectul, audienta proiectului si comportamentul acesteia, impactul in consumul de resurse al proiectului (atat hardware, cat si la nivel de mentenanta, posibilitate de extindere), implicatii legale, etc.
ti se pare plauzibil ca “sfatul” unui programator sa fie mai bun decat raportul asumat al unui specialist care integreaza / cantareste toate aspectele astea?
apoi, presupui ca e nevoie de acel sfat.
daca in proiectele de freelancing se intampla sa lipseaca alti specialisti, deci ramane loc pentru astfel de sfaturi… nu asta e situatia unui proiect facut corect.
intr-un proiect serios… orice modificare aparuta la faza de implementare are implicatii destul de mari si chiar daca aduce un beneficiu e posibil sa nu merite efortul de a fi inclusa rezultatul final.
cine decide care “sfaturi” merg la clienti si care care nu?
programatorul?
sau project managerul?
sfaturile astea sunt tehnice sau despre cum sa isi organizeze businessul?
repet, nu am spus ca nu e ok sa contribui cu feedback (tehnic si non-tehnic), am spus doar ca un programator e programator cand se ocupa de programare si isi asuma alt rol atunci cand se apuca sa dea sfaturi de business.
si da, o singura persoana poate sa aiba mai multe roluri (si chiar isi poate scrie pe cartea de vizita rolul principal sau pe cel pe care il gaseste mai interesant), dar asta nu inseamna ca ramane programator cand ofera consultanta de business.
2 Likes
Nu sunt deacord cu ceea ce zici tu, dar nici nu vreau sa lungim subiectul pentru ca e evident ca nici tu nu esti deacord cu ceea ce zic eu. Avem 2 concepte diferite la ceea ce face un programator, sau ce ar trebui sa faca, sau ce mai poate sa faca pe langa programare. O zi faina !
Parerea mea in cazurile de outsourcing nu o sa intelegi niciodata piata mai bine decat clientul din simplu motiv ca sunteti in tari diferite, poate pe continente diferite, poate culturi diferite, etc.
Aș avea cîteva observațII după ce am citit ce s-a mai scris pe pagină.
- Constat că progamatorii între ei nu pot cădea de acord despre ce înseamnă a fi programator (no pun intended). Există așadar o lipsă de standardizare. Standardizarea profesiei poate că n-ar fi un lucru rău. Cred că ar fi util pentru clientul nespecialist IT ca atunci când contractează un programator să știe cam pe ce treaptă a scării profesionale se află acea persoană.
- @John_Jhon Vorbești despre arhitecți de sistem, project manageri, antreprenori cu aptitudini IT și sună foarte complicat totul. Mie îmi place să țin lucrurile simple și clare. Într-o multinațională sau într-o echipă mare care lucrează poate remote și pe mai multe proiecte în paralel poate că aceste roluri au o justificare. La nivel de freelancer sau mic consumator de servicii IT cred că aceste roluri sînt/pot fi îndeplinite de aceeași persoană și că persoanele care pot oferi o gamă cât mai largă de asemenea servicii la un nivel bun de calitate vor avea de cîștigat pe termen lung.
- Nu știu câtă supraspecializare aveți în IT. Eu îți pot spune că am văzut multă supraspecializare în chirurgie și my take on the subject este că supraspecializarea nu este un răspuns adecvat în orice circumstanță. Modelul programatorului soldățel care face extraordinar de bine o chestie mică și-o avea utilitatea lui la un anumit nivel - într-o intereacțiune client programator- furnizor de servicii programator dar nu într-o interacțiune de tipul client nespecialist IT - progamator. Dacă însă IT-ul ca industrie seamănă vreun pic cu medicina ca mod de organizarea a industriei, aveți și voi nevoie de mulți și foarte buni generaliști.
- Închei cu un element nou pe care probabi că ar fi fost mai bine să îl menționez anterior dar mi-a scăpat. Îl includ aici. Am întâlnit de mai multe ori la unii programatori (vorbesc de freelanceri) atitudinea de tipul “conținătorul (partea software) este mai importantă decât conținutul (filmul, textul și ce-o mai conținte produsul respectiv - să ne imaginăm un website)”. Acest mod de a vedea lucrurile menit să scoată în evidență importanța muncii programatorului cred că trebuie abandonat. Pentru mine partea software este un mijloc de atinge un scop și nu un scop în sine și în tot ceea ce am realizat pînă acum am considerat conținutul mai important și mai greu de realizat decât conținătorul. Pot să fac un compromis și să accept că softul este la fel de important ca și conținutul; dar nu mai mult.
3 Likes
exact ce am spus si eu: sunt mai multe roluri, chiar daca sunt asumate de o singura persoana.
ca referinta, exista si situatia cand un client angajeaza un designer sa ii deseneze un site si designerul isi asuma si rolul de programator si il si pune in opera dupa ce il deseneaza.
clientul il va numi in continuare designer (pentru ca asa s-au pozitionat de prima data), chiar si atunci cand face munca de programare.
asta nu inseamna ca atributiile unui designer includ taskuri de programare.
cam asa si cu programatorul si “sfaturile” de business.
depinde de unde o privesti.
programarea este o chestie aflata in transformare rapida.
pana ajungi sa standardiezi ceva… deja o sa fie obsolete (da, sunt si programator).
in plus, standardizarea aduce si ceva limitari de creativitate, iar programarea e si despre “think out of the box”.
dpmdv programarea nu are nevoie de standarde impuse.
contextul economic impinge programarea sa adopte proceduri / frameworkuri / etc pentru eficienta si predictibilitate.
clientul nespecialist are responsabilitatea (pentru buzunarul si proiectul sau) sa se educe cat de putin in domeniu (si nu ma refer la educatie tehnica) inainte de a alege un programator cu care sa lucreze.
la fel se intampla si cu un client in constructii, sau cu unul care are nevoie de un avocat / dentist / psiholog / etc.
si poate daca e chiar important… clientul nu se va mai baza pe programator sa ii ofere sfaturi de business (ci o sa isi angajeze un consultant de business) sau sa ii implementeze solutii de marketing sau ergonomie (ci va angaja specialistii necesari).
ma opresc din dezvoltat ideea pentru ca am spus-o de suficiente ori deja (dar am fost taguit in raspunsul anterior si m-am simtit vizat).
ps. da, e ok daca alti programatori nu sunt de acord cu mine, dar asta nu face situatia mai putin reala.
evident, oricine se poate afla in eroare (deci si eu), dar am suficienta experienta in suficiente roluri sa fiu convins de ce spun.
–
later edit:
unii ar spune ca mai important decat continutul (care e mai important decat softul) e chiar clientul respectivului continut.
cat de bun e un text foarte bun pe care nu il citeste nimeni?
2 Likes
In acesta situatie, mai mult business