Programmerare - hur hög kodkvalitet är det på en normal arbetsplats?

Denna kan vara lite tänkvärd ibland.
http://www.bowdoin.edu/~disrael/what...really-needed/

Kan vara kul att hålla koll på vad man ska skriva åxå.

Elefanten i rummet är bristande kompetens.

Det är andelsmässigt väldigt få programmerare som är ordentliga och duktiga, och de sugs upp av företag som Google och Facebook eller stannar kvar inom den akademiska världen. Kvar blir alla mediokra och dåliga utvecklare. Eftersom de mest arbetar med andra utvecklare av samma kaliber så ser de bara usla kodbaser, och kan intala sig själva att det är normaltillståndet för hela industrin.

Jag missade min Google-intervju rätt ordentligt på målsnöret, så jag tänker inte låtsas vara någon stjärna. Jag tror den värsta sitsen man kan vara i inom den här industrin är att vara bra nog att se hur jävla uselt det mesta är, men inte bra nog att få arbeta med det bra folket.

Det låter drygt, men de är den floskelfria sanningen, och TS vet det nog också. Försök komma in på ett bättre företag om du inte redan gjort det.

Jag har jobbat 18 år som IT-konsult. Huvudsakligen som kodare. Jag är nog ganska usel rent tekniskt. Är inte så intresserad heller.

Har nu suttit i 8 år på samma ställe med samma kod. Är ensam förvaltare av ett ENORMT system för tillfället. Måste vara miljontals rader kod. När utvecklingen var som mest intensiv var vi 8 utvecklare. Under årens lopp har säkert över 15 kodare varit inne och skrivit kod. Alla på olika sätt och av olika kvalitet.

Vet ni vilken utvecklare som gjort mest skada? Jo, den mest tekniskt drivne. Han som tröttnade efter 1 år och som skrivit kod som hade fokus på att vara komplex och "vacker" snarare än lättläst och funktionell. Var ett helvete att förstå vissa av hans lösningar.

Skulle jag vara utvecklingschef på ett bolag skulle jag anställa såna som är lagom duktiga. Som skriver habil kod som fungerar, som är lagspelare och som inte tröttnar och byter jobb efter ett år. Alltså lojala lagspelare som kan se saker ur beställarnas synvinkel. En sån som jag.

De bästa programmerarna. De som brinner för hantverket och hela tiden vill lära sig nytt. Vet ni vad problemet med de är? Jo, de jobbar för sig själva och inte för företaget. De skiter i om projektet går ihop för allt handlar om hur roligt de har på jobbet. De skiter i om de andra i utvecklingsteamet förstår vad de gör. Nästan tvärtom. De sätter en ära i att göra saker så komplicerade som det bara går.

Att anställa en "superprogrammerare" och hålla honom nöjd så att han inte slutar kräver mycket av ett företag och stämmer kanske inte alltid mot var verksamheten vill ha gjort.

Tror du har en felaktig uppfattning om vad jag uppfattar som vacker kod. För mig är det just lättläst och funktionell kod, som inte gör problem svårare än de egentligen är . Det förutsätter dock att "funktionell" betyder nåt mer än "kan fås att göra det den ska"...

Överdrivet invecklad kod är dålig kod, oavsett om det beror på att folk överdesignar, på inkompetens, på slarv, eller på att någon försöker ta poäng genom att slänga in en massa grejer de inte förstår men har hört ska vara bra.

Det är något jag tror skiljer dåliga utvecklare från hyfsade utvecklare: Dåliga utvecklare inser inte värdet av enkelhet, eller klarar inte av att göra saker enkla (relativt till hur svårt problemet är).

Hur lite ska man kunna för att få skriva embedded systems på cv?

Din fråga är OT, men jag svarar ändå på den så får en moderator städa om det behövs.
Jag skriver bara saker som jag kan tillräckligt för att jobba med.
Ex: Jag har gjort några småjobb i C och C++ där jag ändrat lite befintlig kod, men jag skulle inte klara mig särskilt långt som en C- eller C++-programmerare. Alltså skriver jag inte att jag kan C eller C++.

Anser du att du kan jobba som embedded-utvecklare på något sätt så kan du skriva det. Sen är ju "Embedded systems" väldigt brett och säger inte särskilt mycket. Vad är det du kan inom embedded systems?

En lösning kan vara att man sätter en siffra på sin kunskap:
1. Har genomgått självstudier och har förståelse för kompetensen.
2. Utbildad och har grundkompetens. Utbildning kan vara en högskolekurs eller en fristående kurs i ämnet.
3. Praktisk erfarenhet. Kan omsätta teoretiska kunskaper i praktiken och har dokumenterad erfarenhet i uppdrag.
4. Förtrogen. Självständigt arbete, stor erfarenhet, över 3 år, och kan leda andra.
5. Auktoritet. Djup förtrogenhet i ämnet och kan också fungera som mentor.

Då listar man vad man anser sig kunna och är intresserad av:
För C++ skulle jag nog sätta en 2:a på mig, men jag tar nog inte med det för det är inget jag just nu vill jobba med. Ta bara med sånt du vill jobba med.
För Java som är det jag jobbar med så sätter jag en 4:a. Att nå upp till en 5:a kräver väldigt mycket.

Jag är top 2 % på stackoverflow och kör mest C, Java och python. Arbetsgivare och rekryterare är nästan enbart intresserade av professionell erfarenhet och helst långa projekt flera år som man ska ha fullbordat.

Det finns verktyg som mäter kodkvalité (i JIRA från Atlassian).

Embedded systems är coolt men en mindre marknad och sämre betalt än webbutveckling, affärssystem och spel. Om du vill jobba med embedded systems och inte har mycket erfarenhet så skulle du kunna gå några kurser i embedded och sen jobba som assistent i kurserna eller med universitetsprojekt där embedded används t ex undervisning med FPGA eller liknande.

Mina senaste konsultprojekt har haft pedantisk noggrannhet om koden. Det får inte vara ett tecken fel och allt som kan bli bättre måste bli bättre.

Min programmeringsstil är att först se till att input och output funkar så att en användare kan uppleva funktionalitet. I det läget kan koden se ut som skit och tyckas skit. Sen gör jag refactoring och typiskt bryter ut kod till mindre och mindre funktioner och med tydligare namn.

Det finns en bok som heter "Clean Code" som har bra rykte. Jag har själv inte läst den eftersom jag hellre är nere i träsket där programmet helt enkelt inte funkar och man behöver analys och resonemang och research för att fatta hur man ska angripa problemet.

Uppdatering: Det känns som att företaget jag (fortfarande) jobbar på har lagt om kursen lite. De har tagit till sig av min kritik och börjat med det mesta. Det känns mediokert att jobba där dock. Nu har jag avancerat upp i hierakin och är väldigt central för deras verksamhet.

Jag skriver komplex och svårläst kod när jag är stressad. I normala fall tänker jag faktiskt på min efterträdare, nästa person som behöver läsa och förstå koden, när jag väljer variabelnamn och strukturerar koden. Jag tycker fortfarande att det är bullshit när folk säger att de inte kommenterar sin kod, det skall man göra om man skriver APIer, viktig kod som används vid flera platser, eller om man inte får till det med ett kodstycke så att det blir pedagogiskt och uppenbart eller i övrigt bara får lite tid över och inte har något vettigt att göra.

--------

Embedded systems:

Skillnaden mellan big och small endian?

Har du skrivit avbrottshanterare? Vet du vad en interrupt vector table är? Vad är skillnaden mellan en vanlig retur från en funktion och retur från en avbrottsrutin?

Hur gör man atomiska operationer från grunden i C+asm? Hur kan du veta att det är korrekt? Kan du bygga synkroniseringsprimitiv (mutex, rwmutex, monitor, spinnlock, et.c.) från grunden med hjälp av detta? (Skriv pseudokod eller riktig kod som bevisar att du kan det.) Beskriv metoder att undvika deadlocks.

Beskriv konceptet "privilege inversion".

Beskriv två generella metoder för schemaläggning av processer för realtidssystem i detalj.

Vad har IO-mappat minne med C-språkets nyckelord "volatile" at göra? Vad är kopplingen? Vilken skillnad i output blir det från kompilatorn med och utan volatile? Varför då?

Banked memory?

Kan du skriva en softfloat-drivrutin? Visa att du kan det genom att implementera en avbrottsrutin (t.ex. i pseudokod) som hanterar multiplikation av två flyttal.

Beskriv ytligt hur man dividerar enbart med hjälp av heltalsaddition?

Kan du svara på ovan frågor utan att blinka har du lärt dig grunderna i embedded (2 på skalan ovan), tror jag. De två sista är inte nödvändiga i verkligheten men om man förstår microprocessorer så borde det inte vara något egentligt problem.

Hundra procent detta. Jag skriver min kod så enkelt som möjligt, för jag vet att de flesta programmerare (jag utesluter inte mig själv) är rätt puckade, så minsta lilla tricks kan leda till att de totalt missförstår vad som händer. Måste erkänna att jag har en tendens att överdesigna saker då jag ofta sitter och tänker över varenda rad, men det kommer nog ordna sig med lite mer erfarenhet (har bara programmerat i lite knappt två år).

Har mer och mer börjat dras till funktionell programmering på grund av att det blir så kort och koncis kod. Lite bökigt med I/O bara, iallafall i rent funktionella språk som Haskell. Men shit vad fin koden blir, och det är så härligt att slippa oroa sig för snuskiga side effects.