Programming? Theorie vs Praktijk?

[Verwijderd]

Geachte heren en damens,

Een hele goede dag,

Ik ben pas begonnen met een opleiding als applicatieontwikkelaar en heb als eerste boek java object georienteerd programmeren gekregen.

Zou iemand uit ervaring mij kunnen vertellen hoe men uiteindelijk in een echt project voor een werkgever nou programmeert?

Moet men alle functies van de programmeertaal uit het hoofd leren? Kan men een boek of document bij het werk houden met de functies van de programmeertaal?

Heeft iemand ervaring met programmeren voor een werkgever? Deel deze dan a.u.b.!

Bij voorbaat dank,

Met vriendelijke groet,

DV

[ Voor 12% gewijzigd door Verwijderd op 26-02-2014 19:59 ]

[BLACKfm]

Ik zit er niet in, maar ondanks dat een beetje parate kennis wel handig is lijkt het me niet dat je alles maar moet kunnen weten.

Als jij alles nog moet leren en opzoeken ben jij langer met een opdracht bezig, en tijd is geld. Jij kunt niet aan je klant verkopen dat je ergens 4 dagen over doet (en dus ook in rekening brengt) als iemand die de kennis wel nagenoeg volledig bezit er in een half dagje klaar mee is.

Aan Jan met de pet overigens wel, maar als die persoon gaat shoppen wordt jij natuurlijk gepasseerd.

Verder weet je door kennis op te doen vanuit je studie/opleiding wat je wel en niet kunt en daarmee meer opdrachten kunt binnenhalen omdat je weet dat iets mogelijk is. Als je dan niet helemaal precies weet hoe het dan werkt kun je natuurlijk altijd extra bronnen gebruiken.

Dat lijkt me overigens niet specifiek van toepassing voor het programmeren, maar voor werk in het algemeen.

[RobIII]

Verwijderd schreef op woensdag 26 februari 2014 @ 19:58:
Moet men alle functies van de programmeertaal uit het hoofd leren?

Nee. Je moet leren omgaan met een hamer, spijkers, zaag en nijptang en als je een paar kastjes en stoeltjes hebt getimmerd bouw je vanzelf ook een vogelhuisje en schuur. En daar heb je dan steeds minder aanwijzingen bij nodig en doe je steeds meer op inzicht, intuïtie en ervaring. Laat ik je dan een schuurmachine zien of geef ik je een schroevendraaier met schroeven dan ben je (na een mogelijke initiële korte uitleg) snel(ler) op gang met die dingen en naarmate je gereedschapskist groter en voller wordt heb je steeds meer "aanleg" en "gevoel" voor die dingen. Natuurlijk heb je zo nu en dan nog eens een bouwtekening nodig, maar daar hoef ik dan niet meer op te zetten hoe je een hamer moet vasthouden

Verwijderd schreef op woensdag 26 februari 2014 @ 19:58:
Heeft iemand ervaring met programmeren voor een werkgever? Deel deze dan a.u.b.!

Doe dat dan maar in WI

Programming >> Werk en Inkomen

[ Voor 30% gewijzigd door RobIII op 26-02-2014 21:31 ]

[MrSleeves]

Door ervaring ken ik een hoop functies, maar vooral principes redelijk uit mijn hoofd. Dat laatste is belangrijker dan de functies, daar heb je Intellisense voor (ik grap wel eens dat .net zo makkelijk is omdat je alleen tab in hoeft te drukken om te programmeren).

[Verwijderd]

Prachtig gezegde.

[ Voor 42% gewijzigd door Verwijderd op 26-02-2014 20:39 ]

[Tarkin]

Je moet niet alles van buiten kennen. Maar voor heel veel zaken is het toch echt wel handig. Bij ons kan je echt het verschil merken met iemand die om de 5 minuten moet zoeken hoe nu weer iets ineen zit, en de mensen die on the fly direct weten hoe ze iets moeten implementeren. Dit geld ook voor patterns enzo (wij gebruiken heel veel het builder pattern).

Het komt ook wel met ervaring dat je zoiets leert hoor, dus je moet niet bang zijn als je in het begin nog niet alles direct ziet.

[Zoijar]

Nee, je moet weten wat bepaalde dingen doen, wat je er mee kan, en wanneer je ze wel eens goed zou kunnen gebruiken. Dan heb je een goede IDE met code completion. Je moet wel alle data stucturen kennen en weten hoe efficient alle operaties zijn zoals insert/delete, van het begin, random access, etc. En je moet uiteraard alle taal constructies kennen.

Een echt project? Je gaat zitten, start je IDE op, opent de solution, en ziet een miljoen regels ongedocumenteerde code. Of je dit en dat even wilt toevoegen

[ Voor 18% gewijzigd door Zoijar op 27-02-2014 08:21 ]

[Verwijderd]

Hebben jullie nog meer voorbeelden zoals die van Zoijar, bij voorbaat dank!

[merauder]

Verwijderd schreef op donderdag 27 februari 2014 @ 08:26:
Hebben jullie nog meer voorbeelden zoals die van Zoijar, bij voorbaat dank!

Wanneer bezig met het oplossen van bugs

while ( bug != opgelost) { aanpassen(); refresh(); }

[SavageNL]

Tegen de tijd dat je echt gaat werken voor een werkgever wordt op zijn minst verwacht dat je de syntax van een taal helemaal kent. Wanneer gebruik je wat voor lus, hoe maak je klassen (in de praktijk niet echt nodig omdat je IDE dit kan, maar ik heb sollicitanten gezien die het niet wisten en dan begint het gesprek toch anders). Weten hoe je IDE werkt is ook erg handig .
Dingen als concurrency en beveiliging zijn ook aspecten die belangrijk zijn als ontwikkelaar al is dat niet perse iets wat specifiek is voor een taal. Object georiënteerd kunnen denken en kunnen modelleren zijn wat mij betreft ook noodzakelijk.

Standaard kennis van datastructuren is volgens mij ook noodzakelijk. Wanneer gebruik je een lijst, array, set of map enz. Verder helpt het als je ervaring hebt met de taal en dus andere functies ook kent of op zijn minst weet dat er voor bepaalde dingen standaard componenten/functies zijn. Kennis van patterns is zoals Tarkin zegt ook best belangrijk, bij standaard problemen moet je weten dat jij niet de eerste bent die het op gaat lossen en dan moet je op zijn minst weten dat er ook een standaard manier voor is, en het helpt als je ook weet hoe de standaard manier geïmplementeerd moet worden.


Programmeurs werken met een computer en over het algemeen heb je tijdens het werk vrij toegang tot het internet. Je kunt in principe dus altijd alles opzoeken, maar je moet weten waar je op moet zoeken en het helpt als je niet voor iedere regel code even moet googelen.

Als je op moet zoeken hoe je een methode moet maken in Java dan kom je wat mij betreft niet voorbij een sollicitatie. Daarentegen verwacht niemand dat je uit je alle implementaties van Collection uit je hoofd kent (wel de belangrijkste) of dat je weet wat de Robot klasse doet (toevallig voorbeeld van een klasse waarvan ik weet dat ie er is maar ik heb hem nooit echt nodig gehad).

[Shadowhawk00]

Zoijar schreef op donderdag 27 februari 2014 @ 08:20:
Een echt project? Je gaat zitten, start je IDE op, opent de solution, en ziet een miljoen regels ongedocumenteerde code. Of je dit en dat even wilt toevoegen

Je vergeet dat je meestal nog even wat settings ergens vandaan moet toveren, misschien nog een database moet initialiseren met scripts die eigenlijk niet helemaal lekker werken en met een beetje mazzel bouwt het project nog niet eens. En moet je de fix wel voor morgen 9 uur af hebben.

Maar afgezien daarvan klopt het wel redelijk


Maar goed google werkt ideaal als je een functie nodig hebt, zolang je een beetje globaal weet hoe dingen heten komt je een heel eind.

[ Voor 10% gewijzigd door Shadowhawk00 op 27-02-2014 17:49 ]

[Zoijar]

Shadowhawk00 schreef op donderdag 27 februari 2014 @ 17:48:
Je vergeet dat je meestal nog even wat settings ergens vandaan moet toveren, misschien nog een database moet initialiseren met scripts die eigenlijk niet helemaal lekker werken en met een beetje mazzel bouwt het project nog niet eens. En moet je de fix wel voor morgen 9 uur af hebben.

Haha, ja, inderdaad

[merauder]

Shadowhawk00 schreef op donderdag 27 februari 2014 @ 17:48:
Je vergeet dat je meestal nog even wat settings ergens vandaan moet toveren, misschien nog een database moet initialiseren met scripts die eigenlijk niet helemaal lekker werken en met een beetje mazzel bouwt het project nog niet eens. En moet je de fix wel voor morgen 9 uur af hebben.

En als je echt gelukt hebt, blijkt de bug in een obscuur minified javascriptje te zitten.

[Verwijderd]

In theorie zijn praktijj en theorie hetzelfde

Het belangrijkste is om op de basis van geleerde processen en methoden niet te stoppen met nadenken. Er zal geen bedrijf zijn wat de boekjes naar de letter toepast. Als je ergens nieuw bent, is het dan ook een goed idee even goed te kijken en eventueel te vragen. Zelfs als je een goed punt zou hebben, wordt het over het algemeen niet gewaardeerd om nieuw in te springen 'dat het anders moet omdat boekje dit zus of zo zegt'.

Vaak is de werksfeer en bedrijfscultuur een goede indicator van achtergrond waarom dingen zo zijn. En vergeet vooral ook niet dat alles in de boekjes ook maar door mensen is bedacht die van mening zijn een goede structuur te leggen. De meeste bedrijven nemen de stukken die goed passen, en vullen dat aan met andere methoden en eigen ideeen.

[Verwijderd]

Mooi advies

[Onbekend]

Verwijderd schreef op woensdag 26 februari 2014 @ 19:58:
Zou iemand uit ervaring mij kunnen vertellen hoe men uiteindelijk in een echt project voor een werkgever nou programmeert?

Per werkgever en bedrijfscultuur is dit anders.
Het ene bedrijf maakt veel kleine applicaties die vaak snel gemaakt en getest moeten worden, en het andere bedrijf werkt aan een groot softwarepakket waarbij de oplevertermein vaak in maanden wordt gegeven.
In de praktijk komt het vaak op neer dat je tijdens het programmeren tot nieuwe/andere inzichten komt, en het oorspronkelijke ontwerp wordt aangepast. Documentatie is soms een vak apart en dat wordt regelmatig naar de achtergrond verschoven. Voor kleine projecten is dat niet zo'n ramp maar voor grote projecten kan dat later veel tijd kosten.

Moet men alle functies van de programmeertaal uit het hoofd leren? Kan men een boek of document bij het werk houden met de functies van de programmeertaal?

Weet wat je kan, en wat de programmeertaal zou moeten kunnen.
De exacte syntax is vaak gemakkelijk op het internet te vinden, en de IDE helpt ook vaak een handje mee. Later, als je bepaalde functies vaak gebruikt, ken je de syntax uit je hoofd en hoef je veel dingen niet op te zoeken.

Vaak gebruik je misschien 10% van de functies van de programmeertaal, en de specialistische functies maar een paar keer. Je hoeft dat laatste zeker niet uit je hoofd te kennen, en op het internet staan genoeg voorbeelden van code.

[RobIII]

Verwijderd schreef op woensdag 26 februari 2014 @ 20:21:
Prachtig gezegde.

Verwijderd schreef op donderdag 27 februari 2014 @ 08:26:
Hebben jullie nog meer voorbeelden zoals die van Zoijar, bij voorbaat dank!

Verwijderd schreef op donderdag 27 februari 2014 @ 20:10:
Mooi advies

Niet om te zaniken maar 't zou wel leuk/mooi zijn als je zélf een beetje actiever deelnam aan de discussie dan wat je nu doet...

[jeroen3]

Je moet ook vooral veel goede code lezen en je stijl erop verbeteren.
Code flans je zo in elkaar, maar als je geen discipline hebt in hoofdlettergebruik en spaties en tabs dan kun je het wel vergeten.

[RobIII]

jeroen3 schreef op vrijdag 28 februari 2014 @ 23:36:
Code flans je zo in elkaar, maar als je geen discipline hebt in hoofdlettergebruik en spaties en tabs dan kun je het wel vergeten.

Je hebt echt wel andere hordes om te nemen dan je te bekommeren over:

code:

if (foo == bar) {
    //...
}

vs.

code:

if (Foo == Bar) 
{
    //...
}

Leer eerst uberhaupt maar eens programmeren en je bekwamen in je vak en als je je dan écht verveelt ga je lekker in De Devschuur Coffee Corner - Iteratie 5 een discussie beginnen over tabs vs. spaties. Aangaande je "dan kun je het wel vergeten": als een werkgever een potentieel werknemer op basis daarvan wel/niet aanneemt is 't een werkgever waar je niet eens moet willen werken

jeroen3 schreef op vrijdag 28 februari 2014 @ 23:36:
Je moet ook vooral veel goede code lezen en je stijl erop verbeteren.

Hier geldt 'tzelfde. In 't land der blinden is éénoog koning. Als je als beginner geconfronteerd wordt met bagger code lijkt 't misschien heel wat; als je daarop je "stijl verbetert" heb je een stap terug genomen. Je moet eerst uberhaupt 't verschil leren zien tussen "goede code" en "goede code" voordat je er iets mee kunt gaan doen. Dus ook hier geldt: bekwaam je eerst (tot op bepaalde (voldoende) hoogte) in 't vak voordat je "je stijl" erop gaat aanpassen.

Ik heb veel liever dat iemand z'n datastructuren kent of het verschil kent tussen een static method en instance method dan dat 'ie een mooie "stijl" heeft met hoofdletters en spaties en andere ongein. End of the day word je namelijk betaald om iets te programmeren dat iets (goed, snel, efficiënt, veilig of ...) doet (lees: een probleem oplost) en niet om met je code te gaan staan in een schoonheidswedstrijd.

[ Voor 39% gewijzigd door RobIII op 01-03-2014 00:13 ]

[Sibylle]

RobIII schreef op zaterdag 01 maart 2014 @ 00:05:
[...]

Je hebt echt wel andere hordes om te nemen dan je te bekommeren over:

code:

if (foo == bar) {
    //...
}

vs.

code:

if (Foo == Bar) 
{
    //...
}

Leer eerst uberhaupt maar eens programmeren en je bekwamen in je vak en als je je dan écht verveelt ga je lekker in De Devschuur Coffee Corner - Iteratie 5 een discussie beginnen over tabs vs. spaties. Aangaande je "dan kun je het wel vergeten": als een werkgever een potentieel werknemer op basis daarvan wel/niet aanneemt is 't een werkgever waar je niet eens moet willen werken

Maar je moet wel gewend zijn aan werken met richtlijnen op dit gebied. Als al je collega's gewend zijn aan:

code:

string_search(char c)

en jij schrijft al je functies als

code:

perform_a_search_in_a_string(char c)

dan worden ze daar niet vrolijk van

De development van PHP heeft bijvoorbeeld wel n btje gefaald hierin ( http://me.veekun.com/blog...-a-fractal-of-bad-design/ ).


Iig iets om in je achterhoofd te houden, maar denk dat je inderdaad wel grotere uitdagingen tegenkomt

[ Voor 4% gewijzigd door Sibylle op 01-03-2014 00:13 ]

[RobIII]

Sibylle schreef op zaterdag 01 maart 2014 @ 00:13:
[...]


Maar je moet wel gewend zijn aan werken met richtlijnen op dit gebied. Als al je collega's gewend zijn aan:

code:

string_search(char c)

en jij schrijft al je functies als

code:

perform_a_search_in_a_string(char c)

dan worden ze daar niet vrolijk van

Dan geef je ze een bakje koffie en zeg je dat ze zich niet zo moeten aanstellen. Vervolgens overleg je even en pas je je functienaam aan. Inhoudelijk, of beter: functioneel, verandert er geen zak en zal 't de klant, opdrachtgever, chef, baas, directeur worst wezen hoe die functie heet. Dat je in een team werkt en daarom een bepaalde conventie hanteert zodat het een beetje een samenhangend geheel wordt doe je (voornamelijk) om sociale (en mogelijk puristische) redenen; niet omdat 't beter werkt of beter betaalt

Point being: als je dan eindelijk je opleiding af hebt en een leuke baan gevonden hebt dan kun je eens gaan kijken naar de "lokale" cultuur daar. Maar wil je die baan uberhaupt krijgen heb je er meer aan je tijd te steken in 't onder de knie krijgen van de vele concepten die 't programmeren rijk is. Gaandeweg pik je dan heus wel wat "handigheidjes" op op het gebied van goede functienamen e.d. zodat je ook niet helemaal bleu de arbeidsmarkt op komt.

[ Voor 19% gewijzigd door RobIII op 01-03-2014 00:21 ]

[planB]

jeroen3 schreef op vrijdag 28 februari 2014 @ 23:36:
Je moet ook vooral veel goede code lezen en je stijl erop verbeteren.

Probeer eerst eens debuggen. Zoiezo zal je bij de meeste bedrijven als "rooky" niet gelijk ingezet worden om een grote enterprice app in eklaar te zetten vanaf scratch.
Debuggen van andermans code is een goede leerschool hoe somminge dingen (wel en niet) op te lossen.

(Over Syntax format, tabs, spaties etc: gebruik hetgene wat je al tegenkomt in het betreffende project: zo blijft de code gelijkvormig.)

(Hmm, moet sneller leren typen )

[ Voor 3% gewijzigd door planB op 01-03-2014 00:20 ]

[RobIII]

planB schreef op zaterdag 01 maart 2014 @ 00:17:
(Hmm, moet sneller leren typen )

Als je betaald krijgt per LOC wel ja

[ Voor 6% gewijzigd door RobIII op 01-03-2014 00:28 ]

[Phantasmagoria]

Verwijderd schreef op woensdag 26 februari 2014 @ 19:58:
Geachte heren en damens,

Een hele goede dag,

Ik ben pas begonnen met een opleiding als applicatieontwikkelaar en heb als eerste boek java object georienteerd programmeren gekregen.

Zou iemand uit ervaring mij kunnen vertellen hoe men uiteindelijk in een echt project voor een werkgever nou programmeert?

Moet men alle functies van de programmeertaal uit het hoofd leren? Kan men een boek of document bij het werk houden met de functies van de programmeertaal?

Heeft iemand ervaring met programmeren voor een werkgever? Deel deze dan a.u.b.!

Bij voorbaat dank,

Met vriendelijke groet,

DV

Werkgevers vinden het wel fijn als je volledig 'los' bent in de gekozen programmeer omgeving. Je zult snel je toegevoegde waarde moeten kunnen tonen.

Als je net van school/de cursus komt is dat echter meestal niet het geval. Vergelijk het met je rijbewijs. Ervaring is een essentiele component. Optimaal kom je in een leer/werk traject, waarbij je de ruimte krijgt de bekende beginnersfouten te maken, eventueel begeleid door een mentor. Geen idee hoe het staat met de mogelijkheden daaromtrent in de huidige economie...

Als je meer ervaren raakt wijzigt de focus van het sec leveren van een business solution (dat spreekt dan inmiddels voor zich) naar technische optimalisatie, gebruikervriendelijkheid, robuustheid, elegantie, onderhoudbaarheid, connectivity etc. Idealiter kom je zo nu en dan met oplossingen waarvan men dacht dat deze niet mogelijk waren (in de gekozen ontwikkelomgeving).

Overigens hoef je echt niet altijd elk detail van een opcode oid te weten en een hele boekenplank met manuals op de werkplek te hebben. Google is your friend.

[88Weighed]

Echt programmeren doe ik niet, maar ik schrijf wel regelmatig scripts. Mijn grootste hulp (en ook die van mijn programmerende collega's):
https://www.google.nl/

[Ramon]

88Weighed schreef op zaterdag 01 maart 2014 @ 09:44:
Echt programmeren doe ik niet, maar ik schrijf wel regelmatig scripts. Mijn grootste hulp (en ook die van mijn programmerende collega's):
https://www.google.nl/

Echt waar joh? Mijne is toch vooral http://stackoverflow.com/, misschien ook eens proberen.

[Zoijar]

Want google vindt geen so topics....