Hur är det att jobba som en programmerare?

Jag tar kanske en aningen hårdare ställning än swehunter2000 och säger att om man som programmerar jämt och ständigt sträcker sig efter exempel, då är man nog inte särskilt bra på det man gör. När man först börjar lära sig ett nytt språk/ramverk/bibliotek kan exempel vara guld värt, men man bör så snabbt som möjligt bilda sig en uppfattning kring dess koncept/design-principer. Då kan man istället vända sig till referens-dokumentationen hellre än att googla och hålla tummarna för att någon gjort något liknande som man kan modifiera till sina behov. Kan man å andra sidan bara skriva flytande så kanske det är ett tecken på att man varit fast vid ett ställe lite för längre och bör vidga sina vyer lite.

Konkret för din situation, har du svårt för att använda dokumentationen så beror det nog på att du saknar förståelse för ramverket. Istället för att nöja dig med att klippa och klistra och hoppa vidare till nästa problem, försök förstå varför något görs på ett särskilt vis, och hur allt hänger ihop ur ett större perspektiv.

Skulle hävda att duktiga programmerare har många standard algoritmer memoriserade och behöver i mindre utsträckning googla sig till svar. Detta kommer oftast med erfarenhet men även övning på att lösa kodproblem. Du kan kolla in https://open.kattis.com för att träna upp dig själv.

google-fu är det inget fel på och finns oerhört många bloggar, m.m där ute. Handlar inte bara om att inte återuppfinna hjulet men även att vara uppdaterad och se om det har kommit nya lösningar till tidigare problem så att man inte sitter memoriserad med ett arbetsätt lämpad för år 2000.

Men i det stora hela beror det på vad för sorts arbetsuppgifter man har, förut var det vanlig med webbutvecklare som knackade ihop statiska hemsidor dag efter dag och för dessa monotona arbetsuppgifter är det lätt att bara upprepa det man redan kan. Medan om du är en ensam utvecklare på ett företag som vill att du skall skapa allt möjligt så lär du behöva googla en del.

Men duktiga programmerare kommer att kunna tolka kod exempel bättre, göra förbättringar och integrera i sina system.

Jag skulle säga att steg ett är att veta VAD du ska göra. Om någon kommer till dig med ett problem ska du veta på ett ungefär hur du skulle gå tillväga för att lösa det problemet i någon form av pseudokod. Om du inte vet vad du ska göra blir det i princip omöjligt att lista ut hur du ska göra det också.

Jag jobbar som programmerare och googlar saker hela tiden, för precis som har skrivits innan finns det alltid andra som haft samma problem och frågeställningar som en själv. Gör kundadaptioner av mitt företags mjukvara, så beroende på vad jag behöver lösa kan jag också använda funktionalitet från den existerande kodbasen, samt leta information från andra projekt (som kodmässigt är branchade från samma eller tidigare versioner av grundkoden). Därför blir en viktig del i mitt arbete att hitta rätt information.

Ovanstående leder mig till att jag borde leta under javafx.graphics för att hitta sådant som rör t.ex. Scene.

Exempel är lysande till att ge en vink om vilken typ av problem ett bibliotek eller något ramverk har för avsikt att hjälpa dig med. Däremot så skrapar exemplen ofta bara lite på ytan och förutsatt att du inte löser ett problem helt i onödan lär inget exempel beskriva exakt det du behöver.

Så för dagligt jobb har jag det som används väldigt frekvent memorerat (går inte att vara effektiv annars) samt allt annat referarar jag till referensmanualen (normalt enda stället alla finesser finns dokumenterade) alt. läser källkoden till den externa kod jag använder (rätt mycket som tyvärr har usel dokumentation men där koden ändå är så pass bra att det inte finns någon anledning att uppfinna hjulet själv).

Men man måste zooma ut en nivå till. Att kunna detaljerna kring specifika bibliotek är viktigt när man först förstått sin problemdomän och har ett grepp om bästa sätt att ta sig an problemet. Om problemet man försöker lösa är någorlunda komplext blir då kravet här att läsa "papers" (forskningsrapporter) samt litteratur som behandlar långt mer abstrakta koncept (algoritmer och olika högnivåsätt att strukturera program).

Det skrivet: du har helt fel om C++
Det var sant när man jämför C++03 med Java, C++11/14/17 är i praktiken ett nytt språk och man kan nu göra saker rätt mycket som man kan göra det i Java/C#.

Ovanpå det kan man i C++17 väldigt göra saker som inte ens är teknisk möjligt i dagens Java/C#, t.ex. om du har ett data-parallellt problem (t.ex. summera alla tal i en väldigt stor lista). Ett väldigt simpel exempel

// seriell version
int sum(std::vector<int> v) { 
    return std::reduce (v.begin(), v.end(), [] (int sum, int n) { return sum + n; });
}
// data-parallell version (fyra till >10 gånger snabbare på moderna x86 givet tillräckligt stor längd på v)
int sum(std::vector<int> v) { 
    return std::reduce (std::execution::par_unseq, v.begin(), v.end(), [] (int sum, int n) { return sum + n; });
}

Det andra exemplet ser förföriskt enkelt, men det kan faktiskt inte implementeras i Java/C# med mindre än att man gör ändringar på byte-kod nivå vilket skulle paja bakåtkompatibiliteten. Att C++ har ett turingfullständigt språk i form av templates meta-programmering som körs vid kompilering är orsaken till att man lyckats löst det där! (Är väldigt mycket magi bakom kulluserna som man som användare kan ignorera).

Då kan du ju testa att köra lite "reverse-engineering", d.v.s. jämför exemplet med vad som står i dokumentationen och försök förstå den utifrån exemplet.

Du får alltså plocka isär lösningen och titta på varje bit individuellt och försöka förstå hur den fungerar och hur den kan pusslas ihop med övriga bitar. Testa att modifiera utifrån vad som står i dokumentationen och observera hur resultatet förändras osv.