Dec 16, 2020 · 10 min citire
programatori noi, Bine ați venit în industria dezvoltării de software, fără trebuie să investești o carieră de un deceniu pentru a învăța aceste lecții pe calea cea grea.acum, unele lucruri pot fi învățate doar prin experiență. Pot să vă spun că aceste lucruri sunt importante sau că se întâmplă cu adevărat în industrie, dar este posibil să nu mă credeți până nu le urmăriți în propria carieră. Decizia este de până la tine, dar aici sunt sfaturi pentru beneficiul dumneavoastră, ar trebui să alegeți să le învețe calea ușoară.
1. Abilitățile oamenilor sunt importante și pentru programatori
Ești proaspăt terminat de facultate. Capul tău este o grădină în care plantezi o mulțime de lucruri interesante și creative — la urma urmei, vei locui acolo pentru tot restul vieții, așa că de ce nu? Ești reticent să lași oamenii să intre pentru că s-ar putea să-ți distrugă toată munca grea cu propriile lor moduri diferite de a gândi și de a face lucrurile. Te pricepi să asimilezi-să găsești idei noi, să le descompui și să le analizezi, și apoi să le plantezi în vastul depozit de date al creierului tău programator. Acest lucru descrie majoritatea programatorilor destul de bine și cu siguranță m-a descris. Dacă este așa, sunteți în pentru destul de o ajustare.
a fost nevoie de aproape jumătate din cariera mea de zece ani în calculatoare pentru a realiza că oamenii pot fi greu de lucrat uneori și că munca unui programator include mult mai mult decât lucrul cu computerele. Înainte de a lucra cu computerele, cineva trebuie să — și dea seama pe ce vor să-și cheltuiască banii-banii cu care ești plătit. Odată ce își dau seama, va fi mult timp petrecut în întâlniri discutând orice și totul despre el — cât timp va dura, care este modul corect de proiectare și cine trebuie să fie implicat. Aceste discuții sunt rareori rapide sau ușoare și, dacă deja te străduiești să comunici eficient și să convingi oamenii de convingerile tale, nu va fi mai ușor atunci când trebuie să folosești termeni tehnici pe care nu toată lumea îi va înțelege. Dacă, la fel ca programatorul tipic descris mai devreme, ești timid sau rezervat și eviți să vorbești în întâlniri, acesta este încă un obstacol în calea ta.
apoi aruncați în amestec faptul că nu toată lumea este ușor de înțeles și aveți o rețetă pentru probleme. Majoritatea programatorilor le lipsesc deja abilitățile oamenilor, așa că își imaginează fiorul de a lucra doar cu computerele, lucru pe care îl înțeleg mult mai bine decât oamenii. După cum explică paragraful anterior, este invers. Îți place sau nu, vei petrece mult mai mult timp lucrând cu oamenii decât cu computerele. Până când veți ajunge în cele din urmă să vă suflecați mânecile și să începeți să „codificați ca vântul”, probabil că veți fi sătui de întâlniri și obosiți să fiți tratați ca o resursă, mai degrabă decât apreciați pentru expertiza dvs. În timp ce fiecare companie este diferită, companiile cu o cultură corporativă prietenoasă și confortabilă sunt greu de găsit. Nu numai asta, dar lucrurile se schimbă chiar și de la o zi la alta.
2. Expertiză fără autoritate
foarte des, ideile dvs. despre ceea ce va fi o soluție software utilă intră în conflict dramatic cu ideile oamenilor care iau efectiv aceste decizii. Trebuie să poți trăi cu asta, să lucrezi la proiecte temute/plictisitoare și să-ți iei bucățile ca un adult. Fred Brooks în mitic om-luna numit această expertiză fără autoritate.
este mult mai probabil să sfârșești prin a menține codul prost scris al altcuiva de acum 10 ani, trezit de un pager care bâzâie la 3 dimineața în schimbul de asistență, decât să fii ales să scrii o nouă aplicație web fantezistă de la zero, cu toate instrumentele noi suculente despre care ai citit și salivezi. La urma urmei, noile instrumente pot fi costisitoare și, de obicei, nu sunteți cel care ia deciziile.
sigur, este o idee stupidă să cosi o peluză întreagă cu un consumator de buruieni. Dar când ceri o mașină de tuns iarba și ți se spune „Nu”, poți fie să arunci prosopul, fie să te descurci cu mâncătorul de buruieni.
3. Curiozitatea naturală de a experimenta este o necesitate
a avea o bună înțelegere a sintaxei, semanticii și limbajului — cum ar fi s — ar putea câștiga de la a fi un englez, matematică sau inginerie majoră-merge un drum lung pentru a vă face un programator bun, dar nu este totul.
mai mare decât atât este să nu — ți fie frică să încerci lucruri — să apeși butoane — să faci greșeli-să vezi ce se întâmplă. Scormonește puțin. Scrieți un cod rău și urmăriți-l cum cade pe față. Acesta este principalul și cel mai bun mod de a învăța despre computere. Dacă te bazezi pe alții pentru a-ți da seama, te limitezi doar pe tine. Trebuie să fii dispus să încerci singur și să înveți din rezultate, bune sau rele.
4. Compilatorul / computerul cere perfecțiune absolută
Imaginați-vă că nu puteți trimite un e-mail până când nu ați corectat fiecare greșeală gramaticală, cuvânt scris greșit și virgulă lipsă. Sună ridicol? Cu un computer ca șef, acest lucru descrie fiecare e-mail. Cu excepția faptului că în loc de un e-mail, vorbim despre scrierea unui program de calculator.atingerea perfecțiunii necesită mult angajament, motivație și persistență — mai mult decât au mulți oameni. Programatorul ar putea să nu fie suficient de motivat sau persistent pentru a trece prin bariere, erori, erori, specificații tehnice de 100 de pagini și provocări de depanare pentru a ajunge în cele din urmă la ultimul pas al perfecțiunii absolute. Este un drum lung de parcurs, mai ales fără curiozitate naturală și aptitudini lingvistice.
5. Ideile sunt simple; programele de calculator sunt complexe
când programați, instruiți computerul să facă ceva. Computerul poate fi făcut să facă aproape orice vă puteți gândi. Lucrezi cu chestii abstracte de gândire-idei pure. Acest lucru poate suna ca cerul și există cu siguranță lucruri bune despre el; dar, ca orice altceva, are dezavantajele sale.
adesea, ideile par foarte simple. O singură idee nouă pare destul de simplă pentru ființele umane care posedă un intelect inerent despre conceptele lumii reale. Calculatoarele nu au acest intelect inerent, astfel încât chiar și cea mai simplă idee, tradusă în limbajul computerului, devine rapid complicată. Găsirea instrucțiunilor potrivite este o sarcină dificilă chiar și pentru programatorii experți, veterani — în special pentru ceva care nu a fost făcut înainte. Și dacă a fost făcut înainte, de ce nu cumpărați doar acel program, în loc să scrieți unul nou? Timpul unui programator este scump — de obicei 30 USD/oră sau mai mult. Dacă un program costă 30 USD pe utilizator, acel program poate fi achiziționat de obicei permanent. Chiar dacă costă 300 USD pe utilizator, este încă mult mai ieftin decât 30 USD/oră.
6. Nu orice eroare este un bug
mulți programatori noi sunt descurajați prima dată când construiesc sau compilează ceva, doar pentru a avea 50 de semne roșii, linii ciudate sau erori și avertismente pop-up. Pentru a înrăutăți lucrurile, fiecare eroare este o prostie criptică, cum ar fi „membrul non-static nu poate fi accesat dintr-un context static.”
sfatul meu pentru tine: relaxați-vă! Calmează-te o secundă. Nu orice eroare este un bug. Nu orice eroare este vina ta. Nu orice eroare trebuie chiar remediată imediat. În plus, erorile pot fi reparate.
majoritatea editorilor de coduri moderne vor fi atât de ocupați cu găsirea erorilor, chiar înainte de a termina de tastat codul, încât poate părea rapid o sarcină imposibilă de a pune parantezele în locurile potrivite. Din nou-calmează-te, fă un pas înapoi și realizează că nu este atât de rău pe cât pare.
programez de mai bine de un deceniu și nu cred că am scris odată un program care a funcționat perfect prima dată când l-am încercat. Vor fi erori în codul tău! Obișnuiește-te cu ideea de a vedea acele semne enervante, roșii, ciudate peste tot.
apoi, o eroare nu este neapărat un bug. Da, erorile trebuie să fie stabilite în cele din urmă, înainte de a putea rula programul. Cu toate acestea, efortul de a elimina erorile este secundar lângă sarcina de a scrie codul. Și așa cum am menționat mai devreme, majoritatea editorilor de astăzi vor găsi toate erorile posibile cu mult înainte de a termina scrierea codului. Asta nu face aceste erori mai importante decât ceea ce făceai deja. Nu-i lăsați să vă împiedice; se vor întâmpla, așa că fiți pregătiți și învățați să le puneți în așteptare până când veți obține lucrurile. Pe măsură ce înveți să gândești ca un computer, vei începe să înțelegi ce erori sunt importante și care lipsesc doar biți din programul tău pe care nu i-ai finalizat încă.
pentru a rezuma: roșu, ciudat și enervant (o eroare) nu se traduce automat în important.
7. Nu există erori nu înseamnă nici bug-uri
Imaginați-vă stând pe spate, după o mulțime de muncă grea, mulțumit că ați stabilit în cele din urmă toate aceste erori enervante. Acum poți fi pe drumul tău vesel, nu? Greșit.
nu orice eroare este un bug, iar inversul este, de asemenea, adevărat: lipsa erorilor nu este neapărat o lipsă de bug-uri. Doar pentru că codul dvs. nu are erori nu înseamnă că va funcționa corect. În general, trebuie să presupuneți că codul dvs. nu va funcționa corect, chiar și după ce ați remediat toate erorile.
există două tipuri generale de erori: erori de compilare (tipul roșu, squiggly) și erori de execuție sau logice. Acesta din urmă este ceea ce vorbim acum.
spune codul rulează de fapt. Aceasta înseamnă că computerul îl înțelege și îl poate executa, dar asta nu înseamnă că instrucțiunile în sine nu sunt eronate. Ceea ce creierul tău vine cu prima dată are sens pentru tine, dar un computer are de obicei nevoie de mai multe detalii decât un creier uman pentru a înțelege un proces sau un algoritm.
un exemplu perfect este împărțirea la zero. Această expresie matematică este nedefinită, dar problema nu este evidentă dacă doar împărțiți x la y. fie x, fie y ar putea fi orice. Numai atunci când programul rulează, y are o valoare reală, care ar putea sau nu să fie zero.
8. Rezolva problema, nu doar o problemă
este incredibil de ușor atunci când depanare sau depanare pentru a deveni confuz cu privire la ceea ce problema reală este de fapt — pentru a obține firele încrucișate și petrece ore neproductive, urmarind o gâscă care nu are nimic de-a face cu problema reală la îndemână.
a deveni un programator mai bun are mult de — a face cu posibilitatea de a identifica rapid cauza principală a unei probleme-și apoi de a remedia asta. Așa cum îmi place să spun, rezolva problema.
în acest proces, de multe ori executați peste probleme minore, legate de care ar putea avea nevoie, de asemenea, Fix — o problemă, dar nu problema. Nu da înapoi doar pentru că ai rezolvat ceva. Este nevoie de multă concentrare pentru a rezolva o problemă până la sfârșit.
depanarea este adesea considerată ca fiind făcută în proporție de 99%, pentru majoritatea timpului necesar depanării. Acest lucru se datorează faptului că, până când cauza principală este de fapt cunoscută, știind cât timp va dura pentru a o remedia este o discuție discutabilă. Găsirea cauzei principale poate dura adesea mult timp în sine.
astfel, amintiți-vă aceste reguli simple pentru depanare și depanare:
a) testați — vă întotdeauna codul
B) Verificați și validați totul-în special lucrurile despre care credeți că nu au nevoie de el
C) încercați să nu faceți modificări „la genunchi”, o presupunere aleatorie pentru a convinge eroarea să dispară; acestea introduc adesea mai multe probleme
D) apoi verificați de două ori
Depanarea de la sine este o dovadă simplă că computerele sau roboții nu vor prelua niciodată lumea. Arătați-mi un computer care se poate depana singur și vă voi arăta o lume care nu are nevoie de programatori.
9. Problema fundamentală de dezvoltare de software nu contează cât de mare programul sau software-ul, cineva va găsi o modalitate de a utiliza greșit, dar va fi complet convins că ar trebui să funcționeze în acest fel. Nu mă crezi? Dezvoltați un software, publicați-l și citiți comentariile și e-mailurile pe care le primiți. Veți găsi în curând că acest lucru este absolut adevărat.
fiecare are propriul mod de lucru. O mărime nu se poate potrivi niciodată tuturor, dar, din păcate, pentru dvs., ca programator, O mărime este mult mai ieftină și mai eficientă decât trei sau patru dimensiuni. Rareori vi se va oferi șansa de a implementa fiecare caracteristică posibilă — toate clopotele și fluierele la care vă puteți gândi. Adesea, este exact opusul pe care conducerea îl cere de la tine. Ei doresc un produs minim viabil (MVP) pentru a testa conceptul și a vedea dacă clienților le place și dacă versiunea completă va merita chiar să fie construită.
10. Tehnologia este o țintă imprevizibilă, în mișcare, ocazional, oamenii nu se pot hotărî cu privire la ceea ce vor — și trebuie să faci față consecințelor sau chiar să cureți mizeria. Edward Berard a spus-o astfel: „mersul pe apă și dezvoltarea de software dintr-o specificație sunt ușoare dacă ambele sunt înghețate.”Uneori, cerințele se vor schimba în mijlocul proiectului și va trebui să vă ajustați și să vă adaptați, ca și cum ați funcționa pe motorul unei mașini în timp ce conduceți pe autostradă. Nebun, dar adevărat.
până când ați finalizat proiectul, s-ar putea să descoperiți că acesta a devenit învechit sau inutil. Poate a bibliotecă sau cadru depinde de nevoile actualizate, iar compania dvs. nu dorește să finanțeze actualizarea. Poate că de fapt îl livrați clienților și nici măcar nu vor să-l folosească (am văzut că acest lucru se întâmplă cu propriul meu proiect).
Tehnologia depinde de interacțiunea de succes dintre oameni și alte persoane, oameni și computere și computere cu alte computere. Atât oamenii, cât și computerele pot fi imprevizibile și toată această imprevizibilitate inerentă nu va dispărea pur și simplu pentru că doriți.
11. Estimarea este dificilă
cele mai interesante și valoroase proiecte sunt în mod normal cele care nu au mai fost făcute până acum. Pentru că nu au fost făcute niciodată, estimarea cât timp vor dura este un anumit punct de frustrare, dificultate și durere. Imprevizibilitatea (punctul 10 de mai sus) este, prin definiție, greu de prezis!
directorii de afaceri nu vor să audă niciodată cât va dura ceva. De obicei, sunt interesați de cum să o facă mai repede și cu un buget minim.
programatorii nu vor niciodată să audă cât de puțin timp sau cât de puține resurse vor avea. Ei au nevoie de timp liber pentru inovare și cercetare. Au nevoie de noi instrumente scumpe pentru a codifica mai repede și mai bine. Programarea este părți egale tehnice și creative, și nu poate fi grăbit fără a strica rezultatul final — dar de multe ori este. O linie de asamblare funcționează doar cu un proces simplu, se schimbă puțin și poate fi repetat la nesfârșit — niciunul dintre acestea nu se aplică dezvoltării de software. Asta nu pare să oprească niciodată managerii să încerce să o transforme într-o linie de asamblare.
efortul de estimare este bătălia nesfârșită pe care urmează să o porniți ca programator. În încheierea acestei prezentări de carieră, nu pot spune decât: nu uitați să râdeți și să vă distrați. S-ar putea să descoperiți într-o zi că umorul este ceea ce v-a adus până la capăt cu sănătatea intactă.
programatorii P. S. sunt acum mai valoroși pentru companii decât banii. Nu fi prea dur cu tine; computerul va avea grijă de asta. Dă-ți un pat pe spate pentru că ești interesat de o profesie atât de dificilă, dar plină de satisfacții.