Hvad er forskellen mellem en dårlig, middelmådig, stor og top softwareudvikler?


Svar 1:

Det er mere eller mindre det samme som forskellen mellem en dårlig / middelmådig / stor / top svejser eller murer… med et par undtagelser.

  • Omfanget af ydeevne forskellig. Mængden af ​​tid, det tager at skrive og fejlsøge et komplet bibliotek / program, kan variere med en faktor på måske så meget som 100 mellem de bedste og de værste programmerere, jeg nogensinde har mødt. Jeg kan ikke tænke på en anden menneskelig aktivitet, hvor dette forhold er lige så stort. De bedste programmører kommer med smarte forbedringer - gå ud over specifikationens blotte knogler - find huller i selve specifikationen og skub for at få dem sorteret, inden de skriver kode. Press den sidste dråbe ydeevne ud af koden, længe forbi det punkt, hvor en mindre programmør ville have givet op og sagt “Meh! Godt nok."

De værste programmører efterlader generelt et subtilt spor af ødelæggelse bag dem, der kan ødelægge en lille virksomhed ved at producere software, der er dårligt designet, upålidelig og ineffektiv.

Det er måske det samme for murere og svejsere - men enhver kan se på en mur og mærke til, at det ikke er lige eller lod, eller at mørtelen ikke er jævnt udført. I tilfælde af en svejser kan du røntgenstråle svejsningen og måle ufuldkommenhederne på en noget automatiseret måde.

Men når et program har en masse subtile bugs - eller et dybt mangelfuldt kernedesign - eller endda hvis det er meget mindre effektivt, end det kunne være - så er disse dybe og vanskelige problemer muligvis ikke tydelige i nogen tid, efter at den dårlige programmerer er flyttet videre til et andet job.

Hvis virksomheden også har en god programmør om bord, vil den person spilde mere tid på at finde og løse disse problemer, end de ville have taget for at skrive softwaren selv fra bunden ... men det er sandsynligvis det samme for murere og svejsere.

Når det er sagt, er nogle af de bedste programmører prima-donna - de kan være svære at arbejde med, have forfærdelige mellempersonlige færdigheder - den slags. Dette er det samme i andre brancher. Når en musiker eller en skuespiller er i de nederste trin i deres erhverv - vil de være fornuftige og imødekommende - men når stjernestatus bliver presset på dem, kan de begynde at stille urimelige krav og tænke sig selv ”over resten af ​​menneskeheden”.

(Van Halen krævede i deres kontrakt, at der blev leveret en skål med M & M'er til dem med alle de brune fjernet!)

Det er langt fra at være universelt sandt - men det sker bestemt.


Svar 2:

Det hele kommer ned på valg. De bedste udviklere ved, hvornår de skal gå store, og hvornår ikke, hvornår de skal lave deres egen løsning, og hvornår de skal bruge et eksisterende bibliotek. Når vi tester udviklere, der bruger Devskiller, finder vi ud af, at ikke kun deres kode er elegant, men at den også leveres rettidigt, men det færdige produkt behøver ikke omfattende omarbejdning.

Software er som ethvert teknisk produkt. De bedste udviklere leverer projekter, der ligner en Toyota Corolla:

Kilde: Fil: Toyota Corolla Style (europæisk version 2016) .jpg

Den bedst sælgende bilmodel på verdensplan med over 40 millioner producerede, den er elegant i sin enkelhed, anvendelighed og pålidelighed. Det er billigt at masseproduktion og gør nøjagtigt hvad det skal, uden at tage for mange ressourcer op.

Hvis en Carola er som de produkter, der er skabt af en stor udvikler, ville en middelmådig udviklers output svare til en Juicero:

kilde: http: //antyweb.pl/juicero-zawies ...

Sig nu, hvad du vil om Juicero, det gør, hvad der skal, nemlig presse juice. Problemet er, at det er overkonstrueret inden for en tomme af sin levetid. Resultatet er et dyrt produkt, der kun har lidt mere brugbarhed end dine hænder. Med andre ord, det gør, hvad det skulle, men det var så ineffektivt, at det mistede sin værdi for de fleste mennesker.

Men i det mindste fungerer Juicero. En dårlig udviklerkode kommer ud som noget om Tacoma Narrows-broen i en stiv brise:

Med andre ord kan en dårlig dev være ansvarlig for potentielt katastrofale bugs, som andre er nødt til at løse, før hele applikationen går ned, omdirigerer tid og ressourcer til resten af ​​projektet ..

Som du kan se, hvad der gør en dev god eller ej ikke er deres medfødte viden, men hvordan de kan anvende deres færdigheder og beslutningstagning til praktiske anvendelser. Den bedste måde at se, hvor gode de er, er at give dem en praktisk test som dem, som Devskiller administrerer for at se, om deres evner er praktiske eller rent abstrakte.