Vad gör ni för att bli bättre programmerare?

Jag ger mig själv ett projekt som kräver att jag lär mig saker jag inte kan förnärvarande.

Som mitt nuvarande projekt, en SSCDisabler till Counter-Strike.

Ska antagligen försöka lära mig lite lisp inom en snar framtid vilket garanterat kommer förbättra mitt tänk lite, samtidigt försöker jag specifiera mig lite inom C++, diverse datasamlare och liknande som bara får gå och gå (t.ex en webcrawler med en viss uppgift) intresserar mig (Ja, C++ kanske inte är det ultimata för uppgiften, det är jag medveten om) så jag försöker jobba lite med det och lösa alla problem som kan tänkas uppstå...

Du ville inte ha svar som "koda mycket" eller liknande, men jag tycker det bästa sättet att lära sig på är att jobba med ett projekt och bara ta hand om problemen som uppstår, inte vara rädd för att testa runt i hela processen.
Man behöver inte alltid göra program som man vet att man kan lösa genom några veckors arbete heller, kommer man på ett riktigt enormt koncept och kan sucka åt hur stort arbetet blir så har man ju gott om problem att lösa i framtiden.

Edit :
(Addition)
Glömde nämna att jag försöker ta del av andras problem mycket också, det gäller i princip allt, inte bara programmering.
En bra kanal att insupa kunskap från är #c++.se på QuakeNet, tycker jag... Dyker upp frågor på alla nivåer där.
(Man kan ha nytta av kanalen oavsett om man kodar C++, men det är förstås ett rätt stort plus)

Jag läser en hel del, kollar the Daily Python några gånger per vecka efter intressanta texter och läser Joel on Software.

Jag lånar också böcker och läser, som The Pragmatic Programmer, Code Complete, "Pickaxe", Dive into Python.

Faktiskt är det det enda nästan, jag har problem med att återuppfinna hjul, så det blir tyvär inte så mycket programmering, jag gillar dessutom inte att programmera själv, och jag känner inga programmerar IRL som jag kan programmera med, och inte så många på nätet heller.

Ah, ja, jag läser ju Sweclockers och Slashdot och IRC:ar en del också, det hjälper väl lite det med.

Men det var ju just vad du inte ville ha som svar, men vad kan man annars göra? Be till gud och meditera?

För närvarande lär jag mig OCaml, dels för att det är ett fint språk men även för att förhoppningsvis kunna ändra mitt tankesätt till det bättre även inom imperativ programmering.

I övrigt så ger jag mig på lite olika projekt, både små och stora, meningslösa och användbara. Dessutom så spenderar jag antagligen inte någon dag utan att programmera eller tänka på programmering åtminstonde en timme. Jag gillar dessutom att diskutera med andra programmerare och utbyta idéer och erfarenheter.

Nu är jag absolut ingen kodare, men jag gör gärna grejer som t.ex. mathschallenge (4%) och liknande uppgifter, skapar gärna egna åt mig själv också (liknande dom på mathschallenge).
Så läser jag gärna på olika sidor tillhörande diverse programspråk, just nu försöker jag lära mig python genom docs.python.org t.ex.

Att ge något mer specifikt förrutom att koda mer och läsa mycket mer känns ganska meningslöst då det ej finns något annat man kan göra för att bli bättre. Det finns ingen magisk lösning som gör dig automatisk till en bättre programmerare, utan man måste ligga i och programmera och verkligen vilja lära sig nya saker.
Det som skiljer en bra programmerare och en dålig programmerare är motivationen, en dålig programmerare nöjer sig med dåliga lösningar, medans en bra programmerare hela tiden försöker skriva bättre lösningar på problemen.

Ta sig an nya utmaningar gör att man blir bättre, eftersom man tvingas lösa problem på andra sätt. Att bara läsa och koda är visst en del i det hela, men jag har svårt att tro att det ger speciellt mycket om man inte kodar något mer verklighetsförankrat - exempelvis något man själv har nytta av. En annan sak kan ju vara att man försöker modifiera en befintlig lösning. "Ok, nu har jag skrivit det här programmet och det fungerar. Kan jag göra det mindre? Eller snabbare?"

Lyssna på proggressiv hårdrock.

Nu blir jag väl bli mobbad igen

It is impossible to begin a discussion of psychological principles of
programming language design without recalling the story of ``Levine the
Genious Tailor.'' It seems that a man had gone to Levine to have a suit
made cheaply, but when the suit was finished and he went to try it on, it
didn't fit him at all. ``Look,'' he said, ``the jacket is much too big in
back.''
``No problem,'' replied Levine, showing him how to hunch over his back
to take up the slack in the jacket.
``But then what about the right arm? It's three inches too long.''
``No problem,'' Levine repeated, demonstrating how, by leaning to one
side and stretching out his right arm, the sleeve could be made to fit.
``And what about these pants? The left leg is too short.''
``No problem,'' said Levine for the third time, and proceeded to teach
him how to pull up his leg at the hip so that, though he limped badly, the
suit appeared to fit.
Having no more complaints, the man set off hobbling down the street,
feeling slightly duped by Levine. Before he went two blocks, he was
stopped by a stranger who said, ``I beg your pardon, but is that a new suit
you're wearing?''
The man was a little pleased that someone had noticed his suit, so he
took no offense. ``Yes it is,'' he replied. ``Why do you ask?''
``Well, I'm in the market for a new suit myself. Who's your tailor?''
``It's Levine---right down the street.''
``Well, thanks very much,'' said the stranger, hurrying off. ``I do
believe I'll go to Levine for my suit. Why, he must be a genious to fit a
cripple like you!''
Would it be inappropriate to concot a version of this story called
``Levine the Genius Language Designer''? The first problem in discussing
language design is that we do not know the answer to that question. We do
not know whether the language designers are geniuses, or we ordinary
programmers are cripples. Generally speaking, we only know how bad our
present programming language is when we finally overcome the psychological
barriers and learn a new one. Our standards, in other words, are shifting
ones---a fact that has to be taken into full consideration in programming
language design.

(Psychology of Computer Programming, Gerald Weinberg)

Jag tyckte att detta var det bästa svaret, ungefär detta är vad som gör att jag hela tiden utvecklas, men snarare så får jag nya uppgifter av mitt jobb hela tiden. Men å andra sidan så har jag inte någon underbart genuin målsättning att hela tiden bli en bättre programmerare, för det tycker jag är dumt, om kanske inte till och med lite fånigt, utan jag vill vara bra på det jag gör (så bra som man kan förväntas vara), och kunna leva på det, "enough's enough". Jag menar, det är klart att man vill bli bättre, men i min värld så finns det väldigt mycket som har en högre prioritet. Man lär sig det man behöver i förhållande till vad man måste ådstakomma. Eller så är jag helt enkelt inte en av dem som tråden riktade sig mot.

Annars så är det väl erfarenhet som gäller kanske...

Strunta i att programmera på fritidsprojekt och enbart syssla med sånt som tillhör kurserna jag läser, fast då gå mycket djupare och bredare in i det hela.
För oss normalbegåvade så är det tillräckligt att greja med något/några språk/system i taget, det blir bara kladd av det hela annars. (obs normalbegåvade)
Speciellt när de som hittade på språken har så livlig fantasi när de skrev syntaxen och allt det andra. Lätta exempel: Varför ska elseif heta elsif i vissa språk? Varför betyder inte = samma som i ansi c, utan == i vissa språk.
Det har inget med bättre prestanda eller mer lättläst att göra, det är bara för att jävlas.. (känns så iaf)

Nå det mest aktiva jag ska/planerar göra är att ta ett helt år efter utbildningen och enbart läsa fritt valda rena programmeringskurser, så jag får en mycket bättre grund.

Ett bra tag tyckte jag att jag inte behövde lära mig så mycket mer "språktekniskt". När jag väl insåg att jag faktiskt var rätt halvfisig så bestämde jag mig för att alltid försöka pröva minst en ny grej i varje projekt. Senast var det cppunit och imgui, nästa gång blir det nog boost.

Nya språk är jag dock dålig på att testa. Jag testade lite C#, men har inte petat på python, ruby eller något liknande (och tror inte att jag kan tvinga mig till att göra det).

Jag skulle rekommendera att diskutera programmering och sätta dig in i låg nivåspråk, samt lära dig hur lambdakalkyl etc fungerar. Överhuvudtaget är det att läsa matte som gäller för att inte glömma schack

Jag har aldrig strävat efter att bli bättre programmerare, dock blir jag det varje gång jag sätter tänderna i ett nytt projekt. Detta beror på att jag envisas med att göra grejer som alltid ligger över min kunskapsnivå. Nått som utvecklar mitt högnivåkodande är utan tvekan mitt assemblerprogrammerande, man lär sig tänka lite som en dator och då är det lätt att skriva kod som datorn gillar

Jag har kodat ungefär sen jag gick i fyran och har upptäckt att för varje
nytt språk jag lär mig blir jag också bättre. Så nya språk rekommenderas.
En annan sak jag upptäckte när jag började läsa prorgammering på gymnasiet
var att det faktiskt hjälper att reflektera över vad man gjort, skriva rapport.
Försöker också få in att jag tänker kring varför jag gör som jag gör, och om det
kan göras på andra sätt. Sen är det rätt givande att lösa samma uppgift som
andra och jämföra hur de har gjort.

Jag anser att "optimering av kod" och "kodens komplexitet" spelar en stor roll i ens programmerande. Dessa är ypperliga att använda när man sedan analyserar det man skrivit. Annars att sitta och läsa om olika algoritmer och dylikt är nog ett av de bästa sätten att lära sig.

Det är klart om man tacklar ett nytt problem så lär man sig troligtvis något nytt, men risken är att man använder gamla kunskaper hela tiden som kanske ej är optimala.

Ett exempel: Säg att du i en massa olika program måste dela alla din heltal med modulo 2. När man tar ett tal modulo 2 (för att få fram resten) så kan man istället använda skiftning med 2 för att få samma resultat och mycket snabbare.
Detta är inget man bara inser för att man tacklar ett nytt problem när man fortfarande använder gamla kunskaper för att lösa dem

Jag har klarat av en utbildning och läser nu vidare (och jobbar extra på sidan om på ett programmeringsföretag) och vad jag märker är att folk som är utbildade inom data ofta läser nya kurser bredvid jobbet.

Datorteknik är väldigt annorlunda från andra utbildningarna/arbetsområden. Min bror är utbildad inom byggbranschen och det är inte varje dag som en ny revolutionerande formel för att bygga en bro dyker upp.

Datorbranschen uppdateras kontinuerligt (nya språk med nya tillämpningsområden, tänker på alla inriktningar utav java som inte fanns för några år sedan).

Det är en härlig bransch...

Hur får du ihop det exemplet? Använda skiftning istället för modulo? Mitt spontana sätt att ersätta modulo (om det rör sig modulo med r=2^n) går ut på att maska bort de högre bitarna: Talet AND (r-1). Jag kanske inte bara förstår ditt exempel, och i så fall får du gärna förklara lite tydligare med ett exempel (alltid lika kul att lära sig nått nytt!).

Bli bättre? Jag? Är man på toppen så har man ingenstans att klättra vettu.

Men.. jag läser väl en del böcker om sånt som intresserar mig, då främst spelutveckling, AI, Python och C++. För tillfället läser jag Effective C++ som känns lite som ett måste att läsa om man ska förstå alla vinklar och vrår i det språket.

Sen.. tja, jag programmerar oftast inte med tanken "nu ska jag bli bättre", utan snarare är det "det här är ett projekt jag är intresserad av så det vill jag göra.". Alltså, det är inte ofta jag programmerar nånting bara för att lära mig en ny teknik, utan jag kanske har en idé till ett spel och då vill jag göra det spelet. Sen lär man sig naturligtvis otroligt mycket av att göra ett spel, så det skadar ju inte direkt. Självklart inser jag också detta, och om man är flera i projektet försöker jag ju välja den delen som intresserar mig; som jag vill lära mig mer om. Som t.ex. när jag gjorde ColEdit (texteditor som flera kan ändra i samma dokument samtidigt, i realtid) så valde jag att jobba med just editorbiten, eftersom jag var intresserad av den algoritmiska biten; hur synkroniseringen skulle funka och sådär.

Jag antar att han syftade på heltalsdivision med 2 och få kvoten, medans du pratar om att få resten.. Modulo betyder "rest", men det är lätt att säga fel ord.
*edit* Man kan även göra en högerskiftning och sedan läsa av carryflagan som kan aktiveras av den instruktionen, då får man både kvot och resten på få instruktioner.

Assemblerkod i all ära (eller trix på bitnivå som "motsvarar" det), men när man kodar något smart. Testa och se om kompilatorn gör exakt likadant eller tom smartare? Kompilatorer är bra på att lösa enkla problem, och avr-gcc som jag testade module 2 i gjorde samma lösning som du ovanför, fast blir problemet lite mer avancerat som %3 så blir det lite mer kod. (speciellt på en risk cpu utan någon divisioninstruktion)
Jag är dock medveten om att du Delight bara visade hur man kunde göra, och inte sa att det var meningsfullt att göra.

Nå att koda sin kod och sedan kolla assemblerkoden är väldigt bra för att lära sig grunderna i det språket man håller på med. Problemet är att det tar lite tid att sätta sig in i x86 assembler om man kodar där. (jag har ej orkat ännu)
*edit* min meningsuppbyggnad var/är inte den bästa.

Jag har börjat läsa den här boken http://www.catb.org/~esr/writings/taoup/ och jag tror absolut att det kommer göra mig till en bättre programmerare.