[Alg] Hoe "groeien" als programmeur?

[Da_maniaC]

Ik zat eigenlijk met een 'kleine' vraag over het groeien als programmeur in zijn algemeenheid.
Zelf ben ik geen programmeur in hart en nieren maar heb vanwege mijn werk wel erg veel ervaring met functioneel ontwerpen en aanvragen hiervoor.
Nu wil ik eigenlijk buiten mijn werk mezelf meer gaan toespitsen als programmeur, wat uiteindelijk ook zal betekenen dat ik een lichte specialisatie zal kijgen voor een bepaalde taal of pakket etc.
In essentie wil ik zelf graag gaan leren om op professioneel niveau te kunnen programmeren voor het Windows platform.

Kan iemand mij misschien vertellen wat voor mij de beste volgende stap zal zijn? Welke taal zou het beste zijn om op te concentreren? En hoe kan ik het beste kennis opdoen en een certificering hiervoor krijgen buiten mijn werk?

[ Voor 12% gewijzigd door BtM909 op 25-05-2012 00:43 ]

[ZaPPZion]

Als je voor het Windows platform gaat, zou ik zeker aanraden om in C# te gaan programmeren, qua syntax lijkt dat het meest op andere talen (zoals bijvoorbeeld C++ of Java) en er is gigantisch veel voor te vinden op internet. Bovendien is Visual Studio echt super relaxt om mee te werken, zeker als beginner. Bovendien worden er best veel mensen gevraagt voor .NET ontwikkeling, dus dat is ook handig. Wat betreft resources om kennis op te doen zijn er veel mogelijkheden, en ook qua certificering kun je goed bij Microsoft terecht, die hebben volgens mij voor elk niveau wel certificaten. Dus mijn advies is: C# leren! Microsoft geeft zelf al een heel 'learn C#' programma op MSDN vrij, dus dat is ideaal: MSDN: Learn Visual C# on MSDN
Succes!

[Solopher]

Ik weet niet in wat voor een taal ze programmeren op je werk? Het lijkt mij voor je zelf een logische stap om met die programmeertaal aan de slag te gaan, want mocht je ergens niet uit komen kun je het altijd nog aan je collega's vragen.

[Anoniem: 241683]

Tutorials... Veel prutsen en proberen. Zo hebben de meeste mensen het geleerd.

[pinna_be]

Ik raad aan om een groot boek te kopen . (voor c++ is dat bvb stroustrup)
en ervoor zorgen dat je een programmeertaal volledig kent.
de overstap naar een andere programmeertaal zal vrij vlot zijn, aangezien je een theoretische basis hebt en die is gelijk voor alle talen, de enige verschillen zijn dan bvb in zekere mate de syntax.

Om een professioneel programma te maken is een belangrijke stap die je moet nemen software engineering. Waar je leert op een slimme manier software te ontwerpen, samen te werken met andere mensen.
(hievoor is zelfs een topic op tweakers.net als ik me niet vergis)

[Gomez12]

Wat is de tijdsspanne waarin je het wilt leren?

Een avondopleiding / cursus is wmb de snelste manier om het enigzins snel te leren.

Anoniem: 241683 schreef op vrijdag 25 mei 2012 @ 09:34:
Tutorials... Veel prutsen en proberen. Zo hebben de meeste mensen het geleerd.

Dat is leuk als je alle tijd van de wereld hebt. Prutsen en proberen maakt je (imho) in 1e instantie een zolderkamerprogrammeur en als je dan genoeg leert van al je fouten dan kan je meer worden dan dat.

Prutsen en proberen leert je perfect de syntax, maar niet de achterliggende methodiek van hoe problemen aan te pakken. Daarvoor is een boek of een cursus een heel stuk handiger.
Met prutsen en proberen zal je vast na 10x vallen en opstaan inzien dat iets handiger kan en dat je maar beter een best-practice kan hanteren. Maar liever heb ik dan de best-practice van te voren gezien zodat ik niet die 10x hoef te vallen en op te staan.

[.oisyn]

Gomez12 schreef op vrijdag 25 mei 2012 @ 10:33:
Dat is leuk als je alle tijd van de wereld hebt.

Eens. Idealiter begin je dus als je nog op de middelbare school zit. Als je eenmaal je studie hebt afgemaakt en gaat werken dan is er weinig tijd meer over.

Prutsen en proberen maakt je (imho) in 1e instantie een zolderkamerprogrammeur en als je dan genoeg leert van al je fouten dan kan je meer worden dan dat.

Prutsen en proberen leert je perfect de syntax, maar niet de achterliggende methodiek van hoe problemen aan te pakken. Daarvoor is een boek of een cursus een heel stuk handiger.
Met prutsen en proberen zal je vast na 10x vallen en opstaan inzien dat iets handiger kan en dat je maar beter een best-practice kan hanteren. Maar liever heb ik dan de best-practice van te voren gezien zodat ik niet die 10x hoef te vallen en op te staan.

Ik zou wel durven stellen dat iemand die zelf geprutst heeft en geleerd van zijn fouten en een goede opleiding heeft gedaan er beter voor staat dan iemand die louter die opleiding heeft gedaan en het in een keer "goed" heeft aangeleerd. Juist door zijn eigen ervaring met vallen en opstaan zal hij in onbekende situaties een betere afweging kunnen maken. Zo werkt het eigenlijk met alles in het leven. Maar goed, daar heeft de TS niet zoveel aan aangezien hij niet zoveel tijd meer heeft om te vallen en op te staan

[ Voor 5% gewijzigd door .oisyn op 25-05-2012 10:46 ]

[brama]

.oisyn schreef op vrijdag 25 mei 2012 @ 10:45:
[...]

Eens. Idealiter begin je dus als je nog op de middelbare school zit. Als je eenmaal je studie hebt afgemaakt en gaat werken dan is er weinig tijd meer over.


[...]

Ik zou wel durven stellen dat iemand die zelf geprutst heeft en geleerd van zijn fouten en een goede opleiding heeft gedaan er beter voor staat dan iemand die louter die opleiding heeft gedaan en het in een keer "goed" heeft aangeleerd. Juist door zijn eigen ervaring met vallen en opstaan zal hij in onbekende situaties een betere afweging kunnen maken. Zo werkt het eigenlijk met alles in het leven. Maar goed, daar heeft de TS niet zoveel aan aangezien hij niet zoveel tijd meer heeft om te vallen en op te staan

+1. Je leert het meest van je fouten. Heb je ze nooit gemaakt, dan weet je ook niet goed waarom je een bepaalde oplossing kiest. Bovendien zijn de 'prutsers' ook meestal degenen die daadwerkelijk passie voor hun werk hebben omdat ze het echt leuk vinden.

[djc]

Ik zou zelf iets bouwen dat je uitdagend/leuk/nuttig vindt. Moet je het jezelf natuurlijk niet te makkelijk maken, maar wel een project kiezen dat enigszins haalbaar is. Een goede manier om te beginnen kan ook zijn om bij te dragen aan een open source project; hangt er vanaf hoeveel ervaring met coden je al hebt of dat handig werkt (maar je kan ook beginnen met bijdragen aan technische documentatie).

Zelf volg ik nu een Compilers class van Stanford via Coursera, maar was een paar maanden geleden zelf al begonnen een compiler te bouwen (voor een taal die ik zelf ontwerp). Kijk zeker ook eens op Udacity, Coursera, Codecademy of een van de andere e-learning platforms naar vakken op jouw niveau.

[mjax]

Ik ga de knuppel in het hoenderhok gooien. Je zegt zelf dat je "geen programmeur in hart en nieren" bent. Dan moet je dit vooral niet willen, want je zult nooit een topper worden.

Nog nooit ben ik een UITMUNTENDE programmeur/developer/ontwikkelaar/hacker tegen gekomen die NIET 24x7 bezig is met zijn vak. Dit is gewoon a-way-of-life, je bent hier altijd mee bezig met inlezen, experimenteren, hobby-en, etc. Dus het is zeker geen 9-5 baantje.

Ter achtergrond: ik ben eigenaar van een softwarehuis en heb in die hoedanigheid honderden kandidaten voor development posities geinterviewd. Degene die nu nog bij ons werken, zijn ook echt die mensen voor wie softwaredevelopment bij hun leven hoort, iets waar je permanent mee bezig bent. Net als ik zelf trouwens.

[EddoH]

In de praktijk is het wel heel zwaar om nog in je vrije tijd te doen als je nog iets van een sociaal leven wilt behouden.
Je staat op, werkt, komt thuis (in mijn geval rond een uur of 7), kookt en eet wat, en dan heb je nog een uurtje of 2-3 voor je naar bed gaat.

Als je niet een compleet sociaal geiosoleerd leven wilt leiden of ook maar enige interesse hebt in andere zaken dan enkel software development dan is het redelijk onmogelijk om in je vrije tijd nog veel met software development bezig te zijn is mijn ervaring.

[Da_maniaC]

Wow.... iedereen bedankt voor alle reacties tot dusver.

Overigens bedoelde ik met "geen programmeur in hart en nieren" dat ik zelf geen opleiding heb gehad waarbij de focus op programmeren lag. Het enige wat ik momenteel kan is zeer eenvoudige Basic/Delphi en wat VBS/VBA.

Ik heb helaas geen mogelijkheid om via mijn werk het programmeren op te pakken. Alles gaat via een leverancier waar we nogal nauw mee samenwerken.

Zou het 'makkelijk' zijn om na het leren van wat basisbeginselen een game of engine te programmeren?
Of wordt dit doorgaans anders gezien dan een uitgebreide applicatie door programmeurs?
(Het audiovisuele werk dan even daargelaten.....).

En ik heb gehoord van een collega dat er ook wat programmeertalen zijn als Python die in verhouding nogal makkelijk te begrijpen en gebruiken zijn vergeleken met andere talen. Is dit een aanrader?
(Hij noemde nog een taal, maar ik kan er niet meer op komen).

[Devilly]

Da_maniaC schreef op vrijdag 25 mei 2012 @ 18:26:
Zou het 'makkelijk' zijn om na het leren van wat basisbeginselen een game of engine te programmeren?

Nee, al heb ik me laten vertellen dat iets als XNA het is een stuk makkelijker maakt, zeker in het begin.

Da_maniaC schreef op vrijdag 25 mei 2012 @ 18:26:
(Hij noemde nog een taal, maar ik kan er niet meer op komen).

Was dat misschien Ruby?

[RobIII]

Da_maniaC schreef op vrijdag 25 mei 2012 @ 18:26:
Zou het 'makkelijk' zijn om na het leren van wat basisbeginselen een game of engine te programmeren?

Als je onder game "boter kaas en eieren", "vier op een rij" of anderszins (relatief simpele) brainteaser: dat moet je relatief vlug onder de knie kunnen krijgen (mits je een beetje aanleg hebt). Een (2D) Mario, Ultima I of zelfs Pacman is al een andere orde van grootte. En forget it dat je "zo effe" een Quake, Doom of Crysis bouwt (noch de "engine"). Je moet wel realistisch blijven. Baby steps en dan kom je er (ooit) vanzelf wel.

Da_maniaC schreef op vrijdag 25 mei 2012 @ 18:26:
Of wordt dit doorgaans anders gezien dan een uitgebreide applicatie door programmeurs?

Het is maar net hoe je 't ziet. In de basis zijn 't allemaal algoritmes, patronen, nullen en enen Maar anderzijds is een game heel iets anders dan een business applicatie of een tool als WinZip of als een browser of een photoshop.

Da_maniaC schreef op vrijdag 25 mei 2012 @ 18:26:
En ik heb gehoord van een collega dat er ook wat programmeertalen zijn als Python die in verhouding nogal makkelijk te begrijpen en gebruiken zijn vergeleken met andere talen. Is dit een aanrader?
(Hij noemde nog een taal, maar ik kan er niet meer op komen).

Quite honestly: lood om oud ijzer (Welke programmeertaal moet ik leren?). Het gaat erom dat je het concept bevat, een probleem in een oplossing (algoritme, programma, whatever) weet om te zetten. Of je dat dan uitwerkt in C#, PHP, Brainfuck, Python of Ruby is veel minder relevant (en iets met right tool for the right job; in PHP ga je geen Windows desktop applicatie bouwen*)

* Ja, alles kan. Of je 't moet willen, of dat 't the-right-tool-for-the-job is, is een tweede.

Devilly schreef op zaterdag 26 mei 2012 @ 00:31:
Nee, al heb ik me laten vertellen dat iets als XNA het is een stuk makkelijker maakt, zeker in het begin.

XNA abstraheert een hele hoop 'boring' werk weg maar dan moet je nog steeds zaken als, ik noem wat, collision detection of tiling of zelfs 't domweg interpreteren van input (keys, muis, whatever) en omzetten in iets zinnigs begrijpen. Of 't uitwerken van bepaalde spelregels in code.

[ Voor 13% gewijzigd door RobIII op 26-05-2012 01:18 ]

[Devilly]

RobIII schreef op zaterdag 26 mei 2012 @ 01:09:

Of je dat dan uitwerkt in C#, PHP, Brainfuck, Python of Ruby is veel minder relevant (en iets met right tool for the right job; in PHP ga je geen Windows desktop applicatie bouwen*)

Brainfuck is bijna per definitie niet de juiste tool voor een willekeurige taak, behalve als de taak is om met een stel hersenen te fucken.

[RobIII]

Devilly schreef op zaterdag 26 mei 2012 @ 01:18:
[...]


Brainfuck is bijna per definitie niet de juiste tool voor een willekeurige taak, behalve als de taak is om met een stel hersenen te fucken.

Als je 't "vloeiend spreekt", waarom niet? De concepten zijn niet anders; de notatie is wat ellendig maar ieder z'n meug _{Maar goed, je snapt ook dat dit allemaal met een knipoog bedoeld was}

[ Voor 10% gewijzigd door RobIII op 26-05-2012 01:20 ]

[Woy]

edit:
Foute topic

[ Voor 106% gewijzigd door Woy op 26-05-2012 09:30 ]

[Cubic X]

mjax schreef op vrijdag 25 mei 2012 @ 17:31:
Ik ga de knuppel in het hoenderhok gooien. Je zegt zelf dat je "geen programmeur in hart en nieren" bent. Dan moet je dit vooral niet willen, want je zult nooit een topper worden.

Nog nooit ben ik een UITMUNTENDE programmeur/developer/ontwikkelaar/hacker tegen gekomen die NIET 24x7 bezig is met zijn vak. Dit is gewoon a-way-of-life, je bent hier altijd mee bezig met inlezen, experimenteren, hobby-en, etc. Dus het is zeker geen 9-5 baantje.

Ter achtergrond: ik ben eigenaar van een softwarehuis en heb in die hoedanigheid honderden kandidaten voor development posities geinterviewd. Degene die nu nog bij ons werken, zijn ook echt die mensen voor wie softwaredevelopment bij hun leven hoort, iets waar je permanent mee bezig bent. Net als ik zelf trouwens.

Dit dus! Als je niet vanaf je 13de 24/7 bezig bent geweest met programmeren dan zul je nooit een topper worden, maar blijf je meer hangen in het onderste gedeelte.

[farlane]

Cubic X schreef op zaterdag 26 mei 2012 @ 09:35:
Dit dus! Als je niet vanaf je 13de 24/7 bezig bent geweest met programmeren dan zul je nooit een topper worden, maar blijf je meer hangen in het onderste gedeelte.

Ligt er helemaal aan hoe snel je leert, hoe snel je de concepten doorziet. Sommige mensen zijn nu eenmaal intelligenter dan anderen en zullen het misschien in een fractie van de tijd die jij of ik er over hebben gedaan onder de knie hebben.

[RayNbow]

Cubic X schreef op zaterdag 26 mei 2012 @ 09:35:
[...]

Dit dus! Als je niet vanaf je 13de 24/7 bezig bent geweest met programmeren dan zul je nooit een topper worden, maar blijf je meer hangen in het onderste gedeelte.

1. Is hier een beetje fatsoenlijk empirisch bewijs voor?
2. Dit is niet wat de TS wilde weten. Hij wil weten hoe hij kan groeien als programmeur, niet hoe hij de beste programmeur van de wereld kan worden.

Advies aan de TS: Naast goed lesmateriaal moet je gewoon veel oefenen. Een beetje prutsen zoals hierboven door een paar al aangegeven is niets mis mee, maar sta wel open voor kritiek en wees bereid om slechte programmeergewoontes af te leren. Dit laatste betekent dus dat je actief moet zijn daar waar andere programmeurs zich ook begeven (dit forum bijv. ).

[H!GHGuY]

Er is geen heilige graal. De reacties op dit soort topic zijn altijd dezelfde:
- zonder goeie opleiding wordt je het nooit
- ervaring is alles
- prutsen tot je het onder de knie hebt
- ...

Maar de realiteit is gewoon een combinatie van alles:
- een opleiding of cursus kan je in relatief korte tijd een degelijke basis geven en wat inzichten in de basis
- prutsen en proberen levert enkel op als je ook feedback krijgt van iemand die al bedreven is in het vak.
Het heeft absoluut geen zin om 3 jaar te lopen aanklooien. Als je niet weet dat je loopt aan te klooien/Als je je eigen fouten niet ziet, kan je niet verbeteren en loop je na 3 jaar nog te klooien.
(edit: ik begon net op het wijde web te lezen waar ik dit tegenkwam: http://arstechnica.com/sc...nts-think-theyre-awesome/ een aanrader... Zie vooral p.2 die hierover gaat)
- ervaring komt maar met proberen en corrigeren.

Ik kan je dus maar aanraden om cursusmateriaal te zoeken (avondles, cursussen op internet, boeken, ...) om je even onder te dompelen. In tussentijd kan je met kleine projectjes het wiel opnieuw uitvinden. Het voordeel van het wiel opnieuw uit te vinden is dat je kan vergelijken met wat in het dagelijkse leven gebruikt wordt om zo, waar mogelijk verbeteringen te spotten. Het nadeel is dat je de helft van de verbeteringen niet zal zien.
Om je echt te verheven naar hogere niveau's zal je het bad in moeten springen: draag code bij aan open-source projecten of zend je code door aan een programmeur binnen het bedrijf met de vraag om feedback en bereid je voor om volledig afgebrand te worden (en natuurlijk vooral veel bij te leren).

All code written before <insert time here> is rubbish

Met andere woorden, leg je code aan de kant en kijk er een maand later (met verse kijk en nieuwe kennis) terug naar en probeer je eigen fouten te spotten. Desnoods herimplementeer je stukken en probeer je een maandje later nogmaals opnieuw.

En vooral: passie interesse passie interesse passie interesse...
Zonder dit laatste hou je het toch niet vol.

[ Voor 6% gewijzigd door H!GHGuY op 26-05-2012 12:12 ]

[Grijze Vos]

Als je niet bereid bent er meer dan 10.000 uur in te stoppen, don't bother.

[G70boX]

Cubic X schreef op zaterdag 26 mei 2012 @ 09:35:
[...]

Dit dus! Als je niet vanaf je 13de 24/7 bezig bent geweest met programmeren dan zul je nooit een topper worden, maar blijf je meer hangen in het onderste gedeelte.

Sorry maar dat is echt complete onzin. Hier een mooie blogpost over het 'I started programming when I was 6'; http://mjohn5ton.com/blog...amming-when-he-was-6.html

[ Voor 5% gewijzigd door G70boX op 26-05-2012 12:35 ]

[harrald]

Wat een dramatische reacties af en toe zeg!

Het komt er gewoon op neer dat je je plezier in programmeren moet vinden. Als je het leuk vind komt de rest van zelf wel. Je hoeft niet tot de top te behoren om een leuke baan te vinden.

Welke taal je het beste kan leren hangt ook gewoon helemaal van jou af. Wat lijkt jou leuk? Programmeren staat los van de taal die je gebruikt, de taal is slechts een tool. De kennis die je opdoet met een taal kan je gebruiken in andere talen/omgevingen.

Je hebt niet perse een opleiding nodig. Je hoeft niet vanaf je 12de begonnen te zijn, en je kan best op nog veel latere leeftijd beginnen. Iedereen is anders.

Mijn advies:
zorg dat je er plezier in hebt.
probeer in teamverband te programmeren (als je ergens veel van leert is het wel andermans kennis)

[Gomez12]

harrald schreef op zaterdag 26 mei 2012 @ 12:31:
Het komt er gewoon op neer dat je je plezier in programmeren moet vinden. Als je het leuk vind komt de rest van zelf wel. Je hoeft niet tot de top te behoren om een leuke baan te vinden.

Het probleem is dat met enkel plezier, je wel mooie resultaten kan krijgen, maar dat hoeven geen goede programmeerstukjes te zijn.

Programmeren staat los van de taal die je gebruikt, de taal is slechts een tool. De kennis die je opdoet met een taal kan je gebruiken in andere talen/omgevingen.

Let er wel op dat dit veelal meer opgaat voor de gevorderden. "Beginnelingen" hebben veelal de neiging tot tunnelvisie. En het beste kan je (imho) een brede taal als java/.net oid pakken. Een web/script-taal als php/python etc leert je vooral iets van die kant en leert je bijv geen winforms etc.

Je hebt niet perse een opleiding nodig. Je hoeft niet vanaf je 12de begonnen te zijn, en je kan best op nog veel latere leeftijd beginnen. Iedereen is anders.

Mijn ervaring is toch wel dat mensen niet perse een opleiding nodig hebben, maar wel een klankbord die hun brouwsels kan checken. Of een goed voorbeeld (boek) wat een leidraad is.
Op het internet zijn er te veel quick-fixes als tutorials etc die je enkel het verkeerde leren als je niet de valkuilen kent.

[Compizfox]

Programmeren in het algemeen moet je gewoon leren. Dit houdt dus in dat je leert hoe je problemen op kunt lossen met algoritmes en systemen, en dit is in feite in alle talen hetzelfde.

De keuze van een programmeertaal hangt vooral af van voor welk platform en doel je wilt gaan ontwikkelen.

Ik zou zeggen (heel kort door de bocht):
Voor Windows only: C#
Voor cross-platform PC-applications: C++ (met Qt, als het grafisch moet)
Voor web: PHP
Voor Linux, vooral scripting (dus geen ingewikkelde grafische desktopapplicaties, al kan het wel met PyQt en dergelijke): Python
Java is ook nog een optie, vooral als het echt heel cross-platform moet zijn. Het nadeel van Java is wel dat je het gewoon niet wilt gebruiken voor performance-gevoelige applicaties, want het kan nogal traag zijn.

Ik kan je afraden om verder te gaan in VB.NET. Voor .NET is C# gewoon het leading platform. C++ met MFC is om dezelfde reden eigenlijk ook niet echt wat. Het is Microsoft's eigen implementatie van C++, maar je hebt er in feite niet echt iets aan.

Het mooie van C++ vind ik zelf dat het heel breed is qua laag. Je kunt het heel high-level gebruiken maar ook enorm low-level. Met geen enkele andere programmeertaal kun je dat nog meer bereiken imho. Daarnaast heb je gewoon geen dingen op de runtime nodig, zoals een JRE bij Java en .NET framework bij .NET-talen.

Verder kies je gewoon een goed boek uit. Dat is, samen met oefenen, gewoon de beste en snelste manier om een programmeertaal te leren.
Ik ben zelf begonnen met VB.NET, omdat dat toch relatief simpel te leren is. Dit heb ik puur gedaan met prutsen en internet, maar op die manier duur het leren toch redelijk lang. Een paar maanden geleden ben ik definitief overgestapt naar C++ met Qt, en ik kan je zeggen dat een goed boek het gewoon 10x simpeler maakt.

[ Voor 17% gewijzigd door Compizfox op 26-05-2012 15:01 ]

[farlane]

Compizfox schreef op zaterdag 26 mei 2012 @ 14:55:
C++ met MFC is om dezelfde reden eigenlijk ook niet echt wat. Het is Microsoft's eigen implementatie van C++, maar je hebt er in feite niet echt iets aan.

Bollox.

[Mavamaarten]

Compizfox schreef op zaterdag 26 mei 2012 @ 14:55:
Ik kan je afraden om verder te gaan in VB.NET. Voor .NET is C# gewoon het leading platform. C++ met MFC is om dezelfde reden eigenlijk ook niet echt wat. Het is Microsoft's eigen implementatie van C++, maar je hebt er in feite niet echt iets aan.

Bullshit. VB.Net en C# compileren beiden naar MSIL en zijn echt aan elkaar gelijk. Het enige wat verschilt is de syntax.

[Caelorum]

Wat dan wel weer is, maar kan ook zijn omdat ik zelf voornamelijk C# doe, is dat er veel meer voorbeelden te vinden zijn in C# dan in VB.net. Wat dat betreft zal het denk ik iets makkelijker zijn in C# te beginnen. Los daarvan als je voor het .Net of Mono platform kiest kan je maar beter zowel C# als VB.net en CIL (MSIL is hernoemd vanwege standaardisatie!) leren. Al is CIL wel een beetje twijfelachtig, maar kwaad kan het niet.

[ Voor 6% gewijzigd door Caelorum op 26-05-2012 15:37 ]

[RayNbow]

Compizfox schreef op zaterdag 26 mei 2012 @ 14:55:
Het mooie van C++ vind ik zelf dat het heel breed is qua laag. Je kunt het heel high-level gebruiken maar ook enorm low-level. Met geen enkele andere programmeertaal kun je dat nog meer bereiken imho.

Een high-level taal als Haskell kun je anders prima gebruiken om software te ontwikkelen voor hard real-time systems.

[Soultaker]

farlane schreef op zaterdag 26 mei 2012 @ 15:23:
Bollox.

Niet helemaal bollox. Het gros van MFC bestond enerzijds uit dunne wrappers om de Win32 API heen (wat weinig zinnig is aangezien je die API al prima vanuit C++ kunt aanroepen) en anderzijds uit Windows-specifieke klassen die functionaliteit uit de C++ standard libraries repliceerden (CArray en CString in plaats van std::vector en std::string enzo) of functionaliteit die ook al in C++ zit/zat maar niet goed gesupport werd (dynamic casts, runtime type information, exception handling).

[Compizfox]

farlane schreef op zaterdag 26 mei 2012 @ 15:23:
[...]

Bollox.

Je mag me best corrigeren als ik verkeerd geïnformeerd ben, maar dan wel graag met onderbouwing

Mavamaarten schreef op zaterdag 26 mei 2012 @ 15:32:
[...]
Bullshit. VB.Net en C# compileren beiden naar MSIL en zijn echt aan elkaar gelijk. Het enige wat verschilt is de syntax.

Dat snap ik, maar wat zijn dan volgens jou de voordelen van VB.NET boven C#?

[ZaPPZion]

VB.NET en C# zijn nagenoeg gelijk, er zijn echter wel degelijk verschillen. Tot voor kort waren er in C# namelijk geen optional parameters, dat is met .NET4.5 pas geintroduceert (correct me if I'm wrong). Daarnaast heb je in VB.NET geen mogelijkheid om unsafe regions te gebruiken. Er zijn nog wel een paar andere kleine dingetjes, maar die zijn niet noemenswaardig.

De keuze tussen VB.NET en C# is dus wat dat betreft puur een op syntax gebaseerde keuze. Wat vind je zelf prettig typen en lezen is dus eigenlijk wat de doorslag kan geven, de minieme verschillen zijn niet iets om de ene over de andere te prefereren, mocht je het ooit nodig hebben, kun je erg gemakkelijk een van beide talen in de andere gebruiken, volgens mij is het zelfs in de nieuwe visual studio mogelijk om meerdere talen in 1 project te gebruiken, maar dat weet ik niet helemaal zeker.

[witeken]

Ik zou zeggen: C#. Ik heb een paar maand (wegenstijdgebrek helaas wel nog niet zoveel C# programmeer skills, lees als nagenoeg geen) geleden ook een paar weken research gedaan naar welke ik zou nemen. C# kwam als beste uit de bus. Kort samengevat (kan het dus wel nog niet beamen ) is het een niet supermoeilijke, zeer krachtige taal waarmee je weinig fout kunt doen (zoals foute registry dingen ofzo).
En de .Net framework vind ik ook heel mooi.

Het boek dat me hierbij (zal) help(t)(en) is Beginning Visual C#. (ik heb pdf formaat)
Alles wordt keurig uitgelegd en op het einde van elk hoofdstuk is er repetitio + exerciti (herhaling wat je zou moeten geleerd hebben en oefeningsskens gedaan van waar of fout naar kleine programaatjes schrijven waarin je de leerstof toepast).

[Caelorum]

ZaPPZion schreef op zaterdag 26 mei 2012 @ 22:57:
[...]Tot voor kort waren er in C# namelijk geen optional parameters, dat is met .NET4.5 pas geintroduceert (correct me if I'm wrong). [...]

C# 4.0 In VS2010 kan je het dus ook gewoon gebruiken in .net 2.0 projecten zo lang die maar de C#4.0 compiler neemt. (.net 1.0 is dan weer een ander verhaal)

[.oisyn]

Soultaker schreef op zaterdag 26 mei 2012 @ 15:49:
[...]

Niet helemaal bolloxcks. Het gros van MFC bestond enerzijds uit dunne wrappers om de Win32 API heen (wat weinig zinnig is aangezien je die API al prima vanuit C++ kunt aanroepen) en anderzijds uit Windows-specifieke klassen die functionaliteit uit de C++ standard libraries repliceerden (CArray en CString in plaats van std::vector en std::string enzo) of functionaliteit die ook al in C++ zit/zat maar niet goed gesupport werd (dynamic casts, runtime type information, exception handling).

Het is wel bollocks, zijn opmerking faalt aan alle kanten. Ten eerste, "Microsoft's eigen implementatie van C++". Ik snap niet wat hij ermee bedoelt, maar de air die eromheen hangt klopt sowieso niet. Ja VC++ is MS' eigen implementatie van C++. Niets mis mee. Ten tweede, waarom zou dat een reden zijn om er ver vandaan te blijven? Wellicht bedoelt ie inderdaad dat MFC haar eigen container classes kent. Als dat de reden is om het niet te gebruiken dan snap ik niet waarom hij zo idolaat is van Qt waarvoor hetzelfde geldt, en waarvoor je zelfs een andere compiler moet gebruiken voor de ondersteuning van slots en signals terwijl dat ook best in standaard C++ te implementeren is.

Dat je MFC beter niet (meer) kan gebruiken is iets waar ik het wel eens kan zijn, maar de argumenten om dat te ondersteunen heb ik nog niet gehoord in deze topic.

Compizfox schreef op zaterdag 26 mei 2012 @ 22:40:
[...]

Je mag me best corrigeren als ik verkeerd geïnformeerd ben, maar dan wel graag met onderbouwing

Misschien is het handig als jij als eerste met een onderbouwing van je eigen opmerking komt?

[ Voor 10% gewijzigd door .oisyn op 27-05-2012 01:29 ]

[Compizfox]

.oisyn schreef op zondag 27 mei 2012 @ 01:24:
[...]

Misschien is het handig als jij als eerste met een onderbouwing van je eigen opmerking komt?

[...]
Het is wel bollocks, zijn opmerking faalt aan alle kanten. Ten eerste, "Microsoft's eigen implementatie van C++". Ik snap niet wat hij ermee bedoelt, maar de air die eromheen hangt klopt sowieso niet. Ja VC++ is MS' eigen implementatie van C++. Niets mis mee. Ten tweede, waarom zou dat een reden zijn om er ver vandaan te blijven?

Even voor de duidelijkheid: Ik heb zelf geen ervaring met VC++ met MFC. Ik heb het wel in overweging genomen om te leren, maar ben uiteindelijk na wat inlezen tot deze conclusie gekomen. Maar het kan zijn dat ik gewoon verkeerd geïnformeerd ben hoor.

Microsoft VC++ met MFC is toch Microsoft's implementatie van C++? Gebruikmakend van de taal C++, maar met WinForms en dergelijke.
Wat ik dus bedoel is dat als je toch .NET/Windows only (dat laatste is natuurlijk niet helemaal waar, want er we hebben Mono) wilt gaan, je imho beter voor C# kunt kiezen.
Wil je C++, maar wel grafisch en cross-platform, dan lijkt mij Qt juist superieur. Je hebt meer vrijheid qua keuze van compiler, het is cross-platform.

Wellicht bedoelt ie inderdaad dat MFC haar eigen container classes kent. Als dat de reden is om het niet te gebruiken dan snap ik niet waarom hij zo idolaat is van Qt waarvoor hetzelfde geldt, en waarvoor je zelfs een andere compiler moet gebruiken voor de ondersteuning van slots en signals terwijl dat ook best in standaard C++ te implementeren is.

Dat is dus niet waar, voor Qt heb je juist keuze welke compiler je wilt gebruiken. ICC, GCC (en MinGW onder Windows), MSVC++, het kan allemaal. Ik weet dus niet waar je dat vandaan hebt
Wel heb je natuurlijk qmake die met de Qt libraries meegeleverd wordt, die makefiles voor je genereert en je .ui bestanden interpreteert natuurlijk. Maar dat staat op zich los van de compiler die je gebruikt.

[452752]

Ik merk toch anders wel een groot verschil tussen programmeren in mijn vrije tijd of voor werk. In mijn vrije tijd contribueer ik alles aan open-source, ben ik veel bezig met cutting-edge, experimenteer ik met onbekend terrein en kan ik er helemaal in op gaan.

Voor mijn werk ben ik 50% van mijn tijd Engineer Change Orders aan het invullen om QA tevreden te houden, ben ik 25% van de tijd in meetings / daily scrum / sprint planning / sprint review mijn tijd aan het verdoen en hou ik 25% over om andermans legacy code her en daar aan te passen om aan de change-requests te voldoen en het TPS-report te handhaven.

Ik kan mijzelf aardig programmeur in hart-en-nieren noemen, maar op een doordeweekse dag van 9-tot-5 gaat bij mij de knop om richting "office-drone". Werk en privé strikt gescheiden houden is noodzakelijk om programmeren in vrije tijd leuk te blijven vinden.

[Compizfox]

delete pls

[ Voor 169% gewijzigd door Compizfox op 27-05-2012 02:11 ]

[farlane]

Compizfox schreef op zondag 27 mei 2012 @ 01:42:
Microsoft VC++ met MFC is toch Microsoft's implementatie van C++? Gebruikmakend van de taal C++, maar met WinForms en dergelijke.

MFC is een C++ library dat een OO benadering van de Win32 API moet voorstellen. Er waren er nog een paar : ATL van MS, BWL van Borland en er zullen er vast nog wel meer zijn. Er is wat overlap met de C++ standard library zoals Soultaker al aangaf, maar de meerwaarde lag m.i. meer bij het wrappen van het UI gedeelte van de API. ( WinForms overigens is een onderdeel van de .NET library; tussen MFC en WinForms zit een jaar of 10. )

Ik ben het overigens met je eens dat het tegenwoordig niet echt relevant meer is, Qt zou heel goed een betere keuze kunnen zijn.

[.oisyn]

Compizfox schreef op zondag 27 mei 2012 @ 01:42:
Microsoft VC++ met MFC is toch Microsoft's implementatie van C++? Gebruikmakend van de taal C++, maar met WinForms en dergelijke.

Visual C++ is Microsoft's implementatie van C++, net als dat G++ GNU's implementatie van C++ is. En MFC is net als Qt gewoon een framework om GUI applicaties mee te ontwikkelen. VC++ en MFC staan dus enigszins los van elkaar - je kunt een Qt applicatie compilen met VC++, en je zou in theorie ook een MFC applicatie kunnen compilen met G++.

Wat ik dus bedoel is dat als je toch .NET/Windows only (dat laatste is natuurlijk niet helemaal waar, want er we hebben Mono) wilt gaan, je imho beter voor C# kunt kiezen.

Er zijn genoeg redenen om een Windows-only applicatie in C++ te ontwikkelen. Bijvoorbeeld als performance of geheugengebruik een belangrijke factor is, of als je hardware aan moet sturen. Maar voor een gemiddelde GUI app zou ik wel voor C# icm WPF gaan.

Dat is dus niet waar, voor Qt heb je juist keuze welke compiler je wilt gebruiken.

Qt gebruikt zijn eigen compiler front-end (de Meta object compiler), omdat het de taal heeft uigebreid met speciale syntax om signals en slots te implementeren. Qt code kun je niet door een gemiddelde C++ compiler heen halen want die syntax is gewoon geen C++. De Qt front-end maakt er vervolgens C++ van die een gemiddelde C++ compiler wél snapt.

[Compizfox]

.oisyn schreef op zondag 27 mei 2012 @ 14:47:
[...]
Visual C++ is Microsoft's implementatie van C++, net als dat G++ GNU's implementatie van C++ is. En MFC is net als Qt gewoon een framework om GUI applicaties mee te ontwikkelen. VC++ en MFC staan dus enigszins los van elkaar - je kunt een Qt applicatie compilen met VC++, en je zou in theorie ook een MFC applicatie kunnen compilen met G++.

OK, dat had ik inderdaad een beetje krom geformuleerd. Hierin hebt inderdaad gelijk

[...]

Qt gebruikt zijn eigen compiler front-end, omdat het de taal heeft uigebreid met speciale syntax om signals en slots te implementeren. Qt code kun je niet door een gemiddelde C++ compiler heen halen want die syntax is gewoon geen C++. De Qt front-end maakt er vervolgens C++ van die een gemiddelde C++ compiler wél snapt.

OK thanks voor de uitleg. Maar dat neemt niet weg dat je, nadat moc is aangeroepen door qmake, je gewoon ICC, GCC of MSVC++ kunt gebruiken voor het 'echte' compileerwerk

[Mavamaarten]

Compizfox schreef op zaterdag 26 mei 2012 @ 22:40:
Dat snap ik, maar wat zijn dan volgens jou de voordelen van VB.NET boven C#?

Voordelen vind ik er niet echt, het is echt gewoon persoonlijke keuze. Persoonlijk vind ik de syntax van VB.Net leuker, ik hààt die { } dingetjes echt, ze staan onhandig op mijn toetsenbord.

[PeaceNlove]

Mavamaarten schreef op zondag 27 mei 2012 @ 14:56:
[...]


Voordelen vind ik er niet echt, het is echt gewoon persoonlijke keuze. Persoonlijk vind ik de syntax van VB.Net leuker, ik hààt die { } dingetjes echt, ze staan onhandig op mijn toetsenbord.

Omgekeerd vind ik Dim typen echt teveel moeite en dan moet er ook nog daarna een keer op de a en de s gedrukt worden

mjax schreef op vrijdag 25 mei 2012 @ 17:31:
Ik ga de knuppel in het hoenderhok gooien. Je zegt zelf dat je "geen programmeur in hart en nieren" bent. Dan moet je dit vooral niet willen, want je zult nooit een topper worden.

Nog nooit ben ik een UITMUNTENDE programmeur/developer/ontwikkelaar/hacker tegen gekomen die NIET 24x7 bezig is met zijn vak. Dit is gewoon a-way-of-life, je bent hier altijd mee bezig met inlezen, experimenteren, hobby-en, etc. Dus het is zeker geen 9-5 baantje.

Ter achtergrond: ik ben eigenaar van een softwarehuis en heb in die hoedanigheid honderden kandidaten voor development posities geinterviewd. Degene die nu nog bij ons werken, zijn ook echt die mensen voor wie softwaredevelopment bij hun leven hoort, iets waar je permanent mee bezig bent. Net als ik zelf trouwens.

Hier, je mag de knuppel weer terug, want ik vind dat een goede programmeur ook vooral goed is met de klant en dus vooral ookde wens van de klant in werkende code kan verwerken. En dan zie ik regelmatig bij mezelf en bij collega's code voorbij komen die werkt, maar bijvoorbeeld kan snelheid of resources gebruik veel beter kan. Belangrijker is echter dat wij doorgaans wel gewoon tevreden klanten hebben en onze projecten binnen budget en meestal ook op tijd afhebben. Een goede programmeur bij ons kan dus ook afwegingen maken om te zorgen dat je binnnen budget en tijd blijft.
En die programmeurs zijn dus geen mensen die 24/7 in code denken, maar regelmatig dus ook tijd besteden aan de klant onder werktijd en naar wat ik van hun weekend hoor ook hobbies zoals fietsen hardlopen of andere bezigheden hebben.
Aan de TS het volgende advies: ga een high-level taal doen, zoals we bij ons op het bedrijf ook gebruiken en zorg er voor dat je contact hebt met andere programmeurs die je code nakijken en commentaar geven waar nodig, en kijk omgekeerd ook in hun code en durf de vragen die je hebt te stellen.

[ Voor 74% gewijzigd door PeaceNlove op 27-05-2012 15:06 ]

[Mini-me]

Wat ik niet snap, is waarom iedereen begint in welke taal je zou moeten programmeren terwijl TS vraagt hoe hij kan groeien als programmeur.

Om een programma te kunnen schrijven, moet je weten wat het doel van het programma is. Je implementeert dus niet een programma, maar een stuk gereedschap om het doel te kunnen bereiken. Het programmeren van een stuk software is NOOIT het doel! Het doel is altijd het oplossen van een probleem.

"Gewoon beginnen prutsen" is dus de allerslechtste methode om te leren programmeren, want je hebt in feite geen idee wat je doet. Net zoiets als leren autorijden met een blinddoek voor, zodat je geen last hebt van alle informatie die je dashboard geeft.

Leer modelleren; leer de input en output begrijpen (input = bekende informatie, output = gevraagde informatie) en leer denken in abstracties. Het allerbelangrijkste is dus het kunnen identificeren van programmeerparadigma's. Geen enkele programmeur zal aangeven dat hij een codeklopper is, maar helaas zijn veel teveel programmeurs zich niet bewust van het feit dat geen de ballen verstand hebben van programmeren.

[Woy]

Modbreak:

Laat de hele discussie over welke taal de TS moet gebruiken voor de rest maar achterwege, die discussie is al vaak genoeg geprobeerd te voeren en loopt altijd op hetzelfde uit ( Welke taal moet ik leren? ).

Het gaat er hier in dit topic vooral over hoe de TS kan groeien als programmeur, de taal is daarbij vooral een bijzaak.

[.oisyn]

Compizfox schreef op zondag 27 mei 2012 @ 14:51:
Maar dat neemt niet weg dat je, nadat moc is aangeroepen door qmake, je gewoon ICC, GCC of MSVC++ kunt gebruiken voor het 'echte' compileerwerk

Klopt, ik heb ook nooit anders beweerd. Waar het om ging was dat als je redeneert dat je geen MFC moet gebruiken omdat dat geen echte C++ is oid (let wel, ik probeerde hier nog te begrijpen wat je oorpsronkelijk zei dus dit reflecteert niet per se jouw mening), dan moet je al helemaal geen Qt gebruiken want dat is in dat opzicht nog minder C++.

Mini-me schreef op zondag 27 mei 2012 @ 15:08:
"Gewoon beginnen prutsen" is dus de allerslechtste methode om te leren programmeren, want je hebt in feite geen idee wat je doet. Net zoiets als leren autorijden met een blinddoek voor, zodat je geen last hebt van alle informatie die je dashboard geeft.

Hier ben ik het absoluut niet mee eens, en je vergelijking klopt ook niet. Autorijden met een blinddoek voor is hetzelfde als programmeren met een blinddoek voor, en niemand suggereert om dat te doen. Klopt, programmeren is op zich geen doel, net als dat autorijden geen doel is. Het doel is dat je je bestemming bereikt. Gewoon beginnen met prutsen betekent met het autorijden dat je ritjes gaat rijden voordat je volleerd chauffeur bent. Uiteindelijk kom je er wel, maar je rit is met vallen en opstaan.

Of dat ook zinnig is lijkt me niet van belang om weer op terug te komen, dat is in het begin van deze topic al besproken.

[ Voor 10% gewijzigd door .oisyn op 27-05-2012 19:26 ]

[R4gnax]

PeaceNlove schreef op zondag 27 mei 2012 @ 14:58:
Hier, je mag de knuppel weer terug, want ik vind dat een goede programmeur ook vooral goed is met de klant en dus vooral ookde wens van de klant in werkende code kan verwerken. En dan zie ik regelmatig bij mezelf en bij collega's code voorbij komen die werkt, maar bijvoorbeeld kan snelheid of resources gebruik veel beter kan.

Belangrijker is echter dat wij doorgaans wel gewoon tevreden klanten hebben en onze projecten binnen budget en meestal ook op tijd afhebben. Een goede programmeur bij ons kan dus ook afwegingen maken om te zorgen dat je binnnen budget en tijd blijft.

Het is niet op de man bedoeld, maar: het lijkt er eerder op dat er vanuit de developer(s) naar de kant van management toe een en ander rammelt. Deadlines zouden wellicht beter gesteld worden met eerdere feedback van de verantwoordelijke (lead) developer(s) of een door management opgelegde deadline wel realistisch is. Als er problemen met de deadline boven komen tijdens het ontwikkelen dan zou dat tijdig aangekaart moeten worden zodat er bijgesprongen kan worden met extra budget, tijd of mankracht. Of, zodat er op een hoger project niveau een geinformeerde en gedocumenteerde beslissing kan vallen over het al dan niet weglaten / uitstellen van bepaalde features of het kiezen voor een meer simpele (en minder efficiente) implementatie.

Als het scenario wat je hier beschrijft inderdaad regelmatig voorkomt, is het eerder een indicator dat een programmeur niet voldoende skills met budgetering of planning heeft. Dan wordt er paniekvoetbal gespeeld en bochtjes afgesneden zodat het eigen stuk code 'werkt' en toch nog op tijd 'af' is, zodat vooral de eigen baan niet in het geding komt. Onderliggende oorzaak kan hierbij zijn dat een programmeur boven zijn/haar feitelijke kennisniveau aan het werken is. (Dat wil nog wel eens gebeuren wanneer iemand al langere tijd bij een kleiner bedrijf meeloopt, maar nooit met het niveau van het bedrijf als geheel meegegroeid is.)

[ Voor 7% gewijzigd door R4gnax op 27-05-2012 20:38 ]

[Gimmeabrake]

Ik ben niet in staat om een duidelijk antwoord te geven, maar ik kan wel vertellen over hoe ik mijn vaardigheden steeds weer verbeterd heb: op de trial-and-error manier. Mijn broer heeft me toen ik op de basisschool zat een keer wat QBasic geleerd, toen ik naar de eerste klas van de middelbare ging kreeg ik wat oude Visual Basic boeken. Ik ben later via VB.Net met C# in aanraking gekomen. De laatste twee genoemde talen heb ik puur en alleen van tutorials geleerd.

Ik ben op die manier met heel veel goede en slechte code in aanraking gekomen en heb (denk ik) wel de meeste basisprincipes in het programmeren goed onder de knie gekregen. Althans, mijn collega's vinden mijn code in ieder geval altijd goed en overzichtelijk in elkaar steken.

Ik kan je dus ook niet veel vertellen over met boeken leren, maar als je op de trial-and-error manier aan de slag gaat heb ik wel wat tips:

• Leg de lat niet te hoog. Begin eerst eens met programma's als een rekenmachine of een kladblok-clone. Met dat soort programma's krijg je beginselen onder de knie die belangrijk zijn als je verder wilt met wat geavanceerdere programma's.
• Het is niet erg om te copy-pasten, als je je daarna wel bezig gaat houden met de code die je gekopiëerd hebt en achteraf het gevoel hebt dat je de code begrijpt.
• Kijk veel naar code van derden en probeer een gevoel voor goede en slechte code te krijgen. Ik vermoed dat dit gevoel zich gaanderweg ontwikkeld, zo is het bij mij in ieder geval gegaan.
• Heb geduld en blijf lang zoeken naar wat er mis gaat als het niet werkt. Google is in zo'n situaties een goede vriend.
• Bedenk altijd dat als jij een bepaald stuk code heeeeeel vaak kopiëert en plakt en vervolgens een getalletje o.i.d. aanpast, er een snellere manier is. Als je op dit moment niet weet hoe je dat zou moeten doen: niet erg. Maar besef wel dat het sneller kan.
• Probeer in veel domeinen bezig te zijn: als je de hele tijd met tekstverwerkingstooltjes of rekenmachines bezig bent, leer je op een gegeven moment niet meer zo veel. Pas toen ik een chatprogramma wilde maken kwam ik in aanraking met Sockets en Asynchronous I/O, technologiën die je in .Net uitendelijk toch wel onder de knie wilt hebben en die in andere talen ook goed van pas komen.
• Als je het gevoel hebt iets te kunnen, ga dan eens naar source code van open source projecten kijken. Dat is vaak heel leerzaam.

Zo, dat is alles wat er zo in me opkomt over de trial-and-error manier van leren programmeren. Nogmaals: ik zeg niet dat dit 'the holy grail' is, maar ik weet wel dat veel mensen het zo hebben geleerd.

[PeaceNlove]

R4gnax schreef op zondag 27 mei 2012 @ 20:32:
[...]


Het is niet op de man bedoeld, maar: het lijkt er eerder op dat er vanuit de developer(s) naar de kant van management toe een en ander rammelt. Deadlines zouden wellicht beter gesteld worden met eerdere feedback van de verantwoordelijke (lead) developer(s) of een door management opgelegde deadline wel realistisch is. Als er problemen met de deadline boven komen tijdens het ontwikkelen dan zou dat tijdig aangekaart moeten worden zodat er bijgesprongen kan worden met extra budget, tijd of mankracht. Of, zodat er op een hoger project niveau een geinformeerde en gedocumenteerde beslissing kan vallen over het al dan niet weglaten / uitstellen van bepaalde features of het kiezen voor een meer simpele (en minder efficiente) implementatie.

Als het scenario wat je hier beschrijft inderdaad regelmatig voorkomt, is het eerder een indicator dat een programmeur niet voldoende skills met budgetering of planning heeft. Dan wordt er paniekvoetbal gespeeld en bochtjes afgesneden zodat het eigen stuk code 'werkt' en toch nog op tijd 'af' is, zodat vooral de eigen baan niet in het geding komt. Onderliggende oorzaak kan hierbij zijn dat een programmeur boven zijn/haar feitelijke kennisniveau aan het werken is. (Dat wil nog wel eens gebeuren wanneer iemand al langere tijd bij een kleiner bedrijf meeloopt, maar nooit met het niveau van het bedrijf als geheel meegegroeid is.)

Ik zie het probleem niet? Ik beschrijf een situatie waarin de programmeur breder kijkt dan puur zijn code / opdracht en waarin doorgaans beslissingen worden genomen die er voor zorgen dat het project binnen budget en tijd blijft. Er is nooit sprake van paniekvoetbal en ook kunnen we als programmeurs onderling bijspringen en weten we van elkaar waar we aan toe zijn en wie waar goed in is.
We nemen dus niet omwille van de tijd vieze shortcuts om het maar af te krijgen, maar doen dat weloverwogen (is dit echt iets wat de klant wil? Zoja en het lukt niet? Bel de klant voor overleg). En als de code werkt en er tijd over is, dan optimaliseren we, maar als die er niet is dan doen we dat niet (tenzij er eisen zijn aan de snelheid van bijv. de klant).

En omdat we zowel adviesbureau zijn als software ontwikkeling doen rammelt het altijd richting management, want de prioriteiten kunnen per dag weer verschillen. Oplossing is dus goed te communiceren naar elkaar toe.

Om toch weer wat ontopic te raken met een advies aan de TS: als je een dubbel array weg wilt schrijven naar een plain text bestand kan je dat in .Net op twee manieren doen: met een StringBuilder of door simpelweg string += newValue; te doen. De laatste werkt prima en is geen bug, alleen wel donders traag bij bestanden van +100MB. Als je net begint met programmeren zal je misschien de laatste methode gebruiken omdat je Stringbuilder nog niet kent, later zal je er bijvoorbeeld door iemand op gewezen worden dat een StringBuilder tcoh wat sneller werkt en in dit geval precies hetzelfde doet.
En als je mij de keuze geeft bij de sollicitatie tussen een kandidaat die goed is met klanten en string+= doet en een kandidaat die alle ins en outs kent van een taal, maar niet op niveau met de klant kan communiceren dan kies ik toch echt voor de eerste (en in de praktijk gebeurt dat dus ook bij ons).

[RobIII]

[quote]gerrymeistah schreef op maandag 28 mei 2012 @ 09:21:
• Het is niet erg om te copy-pasten, als je je daarna wel bezig gaat houden met de code die je gekopiëerd hebt en achteraf het gevoel hebt dat je de code begrijpt.
De praktijk wijst echter vaak uit dat als het probleem met een copy/paste is opgelost men door gaat met 't volgende probleem en niet meer achterom kijkt (totdat er eens een bug gefixed moet worden ofzo). Persoonlijk denk ik dat je veel meer hebt aan het juiste stukje code vinden maar het dan niet te copy/pasten maar er, in een geïsoleerd stoeiprojectje, mee te spelen, te doorgronden wat 't precies doet etc. en dan de eigen "doorgrondde" versie te implementeren. Al is de uiteindelijke code identiek aan zoals je 't gevonden hebt, je zult altijd zien dat, bijv., variabelenamen in je eigen conventies veranderd zijn etc.

[quote]gerrymeistah schreef op maandag 28 mei 2012 @ 09:21:
• Bedenk altijd dat als jij een bepaald stuk code heeeeeel vaak kopiëert en plakt en vervolgens een getalletje o.i.d. aanpast, er een snellere manier is.
Ik leg de lat doorgaans bij 2, niet 'heeeeeel vaak'. DRY. En dan heb ik 't niet over een for-loop die in zoveelhonderd plaatsen in je code staat; zoiets is altijd (mwa, meestal) specifiek voor dat lokale probleem.

gerrymeistah schreef op maandag 28 mei 2012 @ 09:21:
Als je op dit moment niet weet hoe je dat zou moeten doen: niet erg. Maar besef wel dat het sneller kan.

Dat is een van de belangrijkste lessen die je kunt/moet oppikken. Dat is nou net de reden waarom we automatiseren

PeaceNlove schreef op maandag 28 mei 2012 @ 12:01:
Om toch weer wat ontopic te raken met een advies aan de TS: als je een dubbel array weg wilt schrijven naar een plain text bestand kan je dat in .Net op twee manieren doen: met een StringBuilder of door simpelweg string += newValue; te doen.

offtopic:
Misschien wat mierenneukerige opmerking; maar ik zie niet hoe hier een StringBuilder of een += operator überhaupt aan te pas zouden komen. Je neemt een (buffered)stream en schrijf je zaken met Write(Line) of eender welke andere geschikte methode meteen in de stream

[Da_maniaC]

Mensen, wederom bedankt voor alle reacties en informatie!
Ik had niet gedacht zo ontzettend veel informatie te gaan krijgen.
Ik denk dat C# wel het beste in mijn straatje gaat passen.
Nu werden hierboven ergens boeken genoemd, welke een goede keus zouden zijn voor C+ (icm .net) geloof ik.
Maar wat zou voor C# een goed boek zijn?
Is er toevallig ook een boek wat het programmeren van C# wat meer als een beginner benaderd? (waar bijv. ook wordt uitgelegd welke ontwerpfase's er veelal zijn en welke software wordt gebruikt etc?

[azerty]

Software zal Visual Studio zijn als je C# ontwikkelt, dat is toch het meest gebruikte.

Uit ervaring zou ik durven zeggen dat de meeste boeken die C# aanleren toch wel vanuit de basis beginnen, waar dienen de boeken anders voor?

Een aanrader die misschien niet direct bij ontwerpfases of programmeren zelf past, maar die ik (als student zijnde) toch enorm interessant vond: Head First Object-Oriented Analysis and Design (A Brain Friendly Guide to OOA&D)

[Anoniem: 139454]

EddoH schreef op vrijdag 25 mei 2012 @ 17:46:
In de praktijk is het wel heel zwaar om nog in je vrije tijd te doen als je nog iets van een sociaal leven wilt behouden.
Je staat op, werkt, komt thuis (in mijn geval rond een uur of 7), kookt en eet wat, en dan heb je nog een uurtje of 2-3 voor je naar bed gaat.

Als je niet een compleet sociaal geiosoleerd leven wilt leiden of ook maar enige interesse hebt in andere zaken dan enkel software development dan is het redelijk onmogelijk om in je vrije tijd nog veel met software development bezig te zijn is mijn ervaring.

Ik ben een programmeur sinds 25 jaar, het vak geleert bij een softwarehuis..

Nu programmeer ik nog wel, maar doe daarnaast andere dingen zoals applicatiebeheer en ook systeem beheer van Linux/Unix, met specialisatie programmeren van shell scripts.

Ik wil niet voor een software huis - nou ja, zegt nooit - omdat ik de deadlines en voor me zelf opkomen niet leuk vindt , toen kon ik perfect uren inschatten, moest ik wel om te overleven, direct je mond optrekken, dat haal ik niet voor die uren die je gepland hebt.

Ik werkt liever, bij een gebruikers organisatie, veel meer vrijheid en deadlines vallen wel mee, maar hoort er bij als je ook programmeert.
.

[Anoniem: 296939]

Ik heb niet alle reacties gelezen maar hoop dat mijn bijdrage toch nog enige waarde heeft.

Ik heb mijn eerste 4 jaar van het middelbaar ASO gedaan. Aangezien de lessen economie niet meer plezant waren besloot ik iets anders te doen. Aangezien ik toen altijd goede punten had voor de lessen informatica (lees Office (ook Access), Photoshop en wat VBA) besloot ik Informaticabeheer te doen. Het eerste trimester daar was een echte ramp voor mij. Op programmeren haalde ik zo'n 19% en dacht ik aan opgeven. Aangezien we toch wel al een paar leuke dingen hadden gemaakt besloot ik in de kerstvakantie gewoon nog wat te programmeren en al doende werd ik beter en beter.
In het 6e jaar hadden we een eindwerk en stage. Op mijn stage leerde ik het meeste. We hadden op school pas de principes van OO geleerd maar aangezien de leerkracht het zodanig slecht uitgelegd had snapte eigenlijk niemand er iets van. Toen ik op mijn stageplek kwam kreeg ik de boek "HeadFirst: Java" mee en daar stond dit allemaal prachtig in uitgelegd. Ik kreeg toen een echte openbaring en snapte meteen hoe het allemaal in elkaar zat. Voor mijn eindwerk heb ik dan een klein facturatie/stockbeheer-pakketje geschreven voor de zaak van mijn waar de jury toch behoorlijk van onder de indruk was.

Na deze 2 jaar besloot ik dan maar om verder te gaan studeren en tot op heden studeer ik Toegepaste Informatica wat me prima bevalt. Zoals de meesten hier al zeggen: Je moet er echt door gepassioneerd zijn. In het 5e jaar begon ik als een echte leek maar door thuis niet enkel de oefeningen van school te maken en zelf wat te experimenteren onderscheidde ik me van de rest en werd ik de beste van de klas (heb er nog een prijs van gekregen van de school ).
Even een voorbeeldje: In het 5e jaar leerden we de basisprincipes van HTML. Van zodra ik thuis kwam begon ik in de broncodes van andere websites te kijken. Daarna begon ik aan mijn eigen website (die inmiddels niet meer online staat). Het jaar daarna leerden we op school PHP en ook daar heb ik mij avonden mee kunnen amuseren! Eerst bouwde ik een CMS van 0 af aan maar daarna begon ik wat te experimenteren met een framework (CodeIgniter). Aangezien ik steeds meer en meer over Ruby On Rails begon te horen ben ik een aantal maanden geleden ook dat beginnen te leren. Eens je de basis van het programmeren door hebt is het vaak niet zo gek moeilijk om een andere taal / framework (mits goede documentatie) onder de knie te krijgen.

Ik hoop dat dit je nogmaals duidelijk maakt dat je enkel een goede programmeur kan worden als je er echt door bezeten bent. Zoek een leuk projectje om aan te werken en start er gewoon mee. Je zal duizenden errors op je scherm zien staan, maar geef niet op en ga gewoon door. Vraag hulp aan de programmeurs die je kent of stel vragen op een (dit) forum.

Succes!

[Hydra]

.oisyn schreef op vrijdag 25 mei 2012 @ 10:45:
Ik zou wel durven stellen dat iemand die zelf geprutst heeft en geleerd van zijn fouten en een goede opleiding heeft gedaan er beter voor staat dan iemand die louter die opleiding heeft gedaan en het in een keer "goed" heeft aangeleerd. Juist door zijn eigen ervaring met vallen en opstaan zal hij in onbekende situaties een betere afweging kunnen maken. Zo werkt het eigenlijk met alles in het leven. Maar goed, daar heeft de TS niet zoveel aan aangezien hij niet zoveel tijd meer heeft om te vallen en op te staan

Mee eens. Maar ik zou niet weten of een autodidact of iemand die alleen een opleiding gehad 'beter' is. Ik neig naar de laatste. Je wil niet weten hoeveel autodidacten basics als recursiviteit niet snappen. Een fatsoenlijke opleiding leert je toch wel hoe je bepaalde problemen oplost. Het geeft je als het goed is geen kant en klare oplossingen maar leert je problemen te analyseren en op te lossen.

Bottomline: als je serieus als developer aan de slag wil; doe (bijvoorbeeld) een HBO-I opleiding.

Da_maniaC schreef op dinsdag 29 mei 2012 @ 18:37:
Mensen, wederom bedankt voor alle reacties en informatie!
Ik had niet gedacht zo ontzettend veel informatie te gaan krijgen.
Ik denk dat C# wel het beste in mijn straatje gaat passen.
Nu werden hierboven ergens boeken genoemd, welke een goede keus zouden zijn voor C+ (icm .net) geloof ik.
Maar wat zou voor C# een goed boek zijn?
Is er toevallig ook een boek wat het programmeren van C# wat meer als een beginner benaderd? (waar bijv. ook wordt uitgelegd welke ontwerpfase's er veelal zijn en welke software wordt gebruikt etc?

Sorry maar als je in de markt aan de slag wil als programmeur en ook doorgroeimogelijkheden wil hebben zul je toch echt aan een opleiding moeten. Op dit moment nemen ze geen autodidacten zonder uitgebreide aantoonbare ervaring aan.

Als je wil hobbyen prima; maar dat was niet de insteek van je topicstart.

mjax schreef op vrijdag 25 mei 2012 @ 17:31:
Nog nooit ben ik een UITMUNTENDE programmeur/developer/ontwikkelaar/hacker tegen gekomen die NIET 24x7 bezig is met zijn vak.

Beetje overdreven dit. De meeste developers die ik ken bouwen in eigen tijd niet echt meer dingen. Als je de hele dag al aan het programmeren bent, wil je ook wel eens wat anders lijkt me? Mooi dat jij de echte fanatiekelingen hebt, maar ik denk dat ze wat betreft het 24/7 verhaal misschien wat overdreven hebben

Daarnaast is het de vraag of je mensen met een volledig gebrek aan sociaal leven aan wil nemen natuurlijk

[ Voor 44% gewijzigd door Hydra op 30-05-2012 18:16 ]

[BikkelZ]

Je hebt een aantal categorieën:

- Mensen die geen talent hebben voor programmeren (en dan boeit de rest niet meer)
- Mensen die wel talent hebben maar geen enkele ervaring
- Mensen die wel talent en ervaring hebben maar geen theoretische onderbouwing
- Mensen die wel talent en theoretische onderbouwing hebben maar geen ervaring
- Mensen die het allemaal hebben
- Totale freaks

Ikzelf ben iemand die graag in het één na laatste stadium wil zitten, dus overdag programmeren en 's avonds net doen of je nog een leven hebt, inclusief relatie en niet direct coding / freaking gerelateerde hobbies.

Bepaal voor jezelf in welke categorie je wil zitten, en kijk naar jezelf waar het nog aan ontbreekt (behalve talent dan, daar is niet veel aan te doen ). Voor mezelf moet ik aan de volgende dingen werken:

- Leren hoe grotere software opdrachten te analyseren en te bedenken hoe ik die ga bouwen
- Projectmanagement skills
- Verwachtingsmanagementskills
- Meer geavanceerde OO-kennis (patterns etc.)
- Nieuwe technieken blijven leren (tot mijn pensioen +/- 75ste dus)


-----------

Over fanatiekelingen gesproken: Ik ben er nu een aantal tegen gekomen, en het zijn toch ook vaak niet de über autistische nerd-types die dat doen, maar meer het type ondernemers en mensen die zich helemaal vastbijten ergens in. Ik heb dat gewoon niet. 's Avonds programmeren vind ik best zwaar na een dag werken.

[ Voor 13% gewijzigd door BikkelZ op 31-05-2012 10:45 ]

[Anoniem: 296939]

BikkelZ schreef op donderdag 31 mei 2012 @ 10:41:
Je hebt een aantal categorieën:

- Mensen die geen talent hebben voor programmeren (en dan boeit de rest niet meer)
- Mensen die wel talent hebben maar geen enkele ervaring
- Mensen die wel talent en ervaring hebben maar geen theoretische onderbouwing
- Mensen die wel talent en theoretische onderbouwing hebben maar geen ervaring
- Mensen die het allemaal hebben
- Totale freaks

Ikzelf ben iemand die graag in het één na laatste stadium wil zitten, dus overdag programmeren en 's avonds net doen of je nog een leven hebt, inclusief relatie en niet direct coding / freaking gerelateerde hobbies.

[...]

Ik hou niet zo van in vakjes gestopt te worden
Ik vind programmeren plezant maar dat wil niet zeggen dat ik daarbuiten helemaal niets doe. Ik zit bij een studentenvereniging waar ik tijdens de week redelijk wat tijd in steek en tijdens de weekends ga ik werken. Als er dan nog wat tijd over is ga ik eens weg met vrienden of als het mooi weer is ga ik eens buiten zitten. Wanneer ik niet echt iets anders te doen heb, sla ik aan het programmeren. Dit zijn avonden waarop niet echt iets te doen is en tv kijken is niet echt iets voor mij... Je hoeft dus geen 24/7 te programmeren he

Bepaal voor jezelf in welke categorie je wil zitten, en kijk naar jezelf waar het nog aan ontbreekt (behalve talent dan, daar is niet veel aan te doen ). Voor mezelf moet ik aan de volgende dingen werken:

- Leren hoe grotere software opdrachten te analyseren en te bedenken hoe ik die ga bouwen
- Projectmanagement skills
- Verwachtingsmanagementskills
- Meer geavanceerde OO-kennis (patterns etc.)
- Nieuwe technieken blijven leren (tot mijn pensioen +/- 75ste dus)

Ik denk dat dit voor de meesten wel zo zal zijn. Wel denk ik dat je geen nieuwe technieken zult moeten leren tot je 75e. Je zal waarschijnlijk nog wel altijd moeten gaan werken maar ik denk dat je een andere functie zal krijgen en de jongere generatie het echte programmeerwerk zal doen ...

[BikkelZ]

Anoniem: 296939 schreef op donderdag 31 mei 2012 @ 11:24:
[...]


Ik hou niet zo van in vakjes gestopt te worden

Nou je kunt denk ik best wel aangeven in welke categorie je valt, wat je wil bereiken en wat je daar voor moet doen.

[Hydra]

BikkelZ schreef op donderdag 31 mei 2012 @ 10:41:
- Mensen die geen talent hebben voor programmeren (en dan boeit de rest niet meer)

Je hebt ook mensen die geen enkel talent hebben voor programmeren, maar wel ervaring. Dat zijn de ergste