Samenwerking tussen developers

[-FoX-]

Ik open dit topic eigenlijk om een idee te krijgen hoe overige developers de samenwerking met collega's, mede developers, e.d. ervaren. Samenwerking in de brede zin van het woord.

Vaak is in (middel-)grote ondernemingen heel wat kennis (software development) beschikbaar in de meest uiteenlopende domeinen. Deze kennis is, naar mijn mening, erg gefragmenteerd aanwezig binnen menig bedrijven. Om een voorbeeld te stellen:
Persoon X erg veel kennis van productA en persoon Y erg veel kennis van productB. Echter dient persoon X op dit moment te werken met productB (voor een of andere klant). Nu kan deze persoon zelf van scratch beginnen en zelf ervaring opdoen.. dus ook het hele leertraject doorlopen. Maar dit is erg tijdrovend. Ook al omdat er tegenwoordig erg veel technologieën aanwezig zijn en het hierdoor zelfs mogelijk is dat je altijd met iets 'nieuw' moet beginnen. Het zou natuurlijk veel beter zijn als deze op een of andere manier support kan krijgen van persoon Y (simplistisch vb: chat applicatie).

Dit probleem gaat niet onopgemerkt voorbij voor de meerderheid. Dit is vooral te zien aan de tendens van het bloggen binnen een bedrijf (al dan niet extern), oprichten van community's, ...

Dit is al een eerste aanzet, maar lijkt me zeker niet voldoende te zijn.

Op welk gebied ervaar je deze tekortkomingen van het communiceren, samenwerken, ... binnen éénzelfde bedrijf (en daarom niet perse dezelfde locatie)? Op welke manieren ga je ermee om en wat lijkt voor jou een ideale oplossing te kunnen zijn voor dit probleem?

Het gaat me niet zozeer om effectief samenwerken; dus aan dezelfde applicatie. Maar eerder over het effectief houden van de kennis. Zodat er op relatief weinig tijd veel bijgeleerd kan worden en weinig tijd verloren gaat.

Het wordt namelijk eens tijd om alles eens goed te defragmenteren

[NetForce1]

Het verspreiden van expertise wordt vaak als een van de voordelen van pair programming genoemd. Voorwaarde is dan natuurlijk wel dat beide developers op dezelfde locatie zijn.
Als je allebei op een andere locatie zit wordt het een stukje lastiger. Je kunt dan natuurlijk gaan bloggen oid, maar je krijgt nooit alles op die manier gedocumenteerd.
Wat ook altijd handig is (naast de genoemde communities/bloggen/messaging) is om 'even' in andermans code te loeren hoe eea aangepakt kan worden.

[Verwijderd]

-FoX- schreef op maandag 08 mei 2006 @ 15:37:
[..] Op welke manieren ga je ermee om en wat lijkt voor jou een ideale oplossing te kunnen zijn voor dit probleem? [..]

Ik zie het niet als een probleem. In elk kennisintensief vakgebied, wat voldoende volwassen wordt, ontstaan specialisaties. Alleen moeten bedrijven die specialisten dan natuurlijk wel op de juiste plekken inzetten.

[ Voor 19% gewijzigd door Verwijderd op 08-05-2006 19:06 ]

[Verwijderd]

De situatie in het bedrijf waar ik werk, geeft juist compleet het tegenovergestelde van de situatie die de TS nu schetst weer.

Momenteel werk ik met (lees: zit ik in één kamer met) twee ontwikkelaars. (Als het goed is, is er sinds vandaag een programmeur bij gekomen, maar ik was vrij .). De ene programmeur is erg sterk in sequentieel programmeren (heeft 20 jaar werkervaring, maar geen afgeronde opleiding) en heeft totaal geen kaas gegeten van OOD. De andere programmeur is elektrotechnicus met firmeware kennis.

Al met al geen slechte combinatie (voor wat betreft de markt waarin mijn bedrijf zich bevindt), maar nu komt het euvel. Wanneer een software project wordt gestart, wordt er totaal niet gedocumenteerd en wordt er meteen gestart met code kloppen (in het kader van: ieder voor zich en god voor ons allen). Na weken van programmeren worden de applicatie software en de firmware software aan elkaar geknoopt en getest en dan ontstaan de problemen.

Naast het feit dat er niet gedocumenteerd wordt (op een kort en bondige functionele analyse na), is toegang tot kennis beperkt mogelijk (na een aantal keer vragen, wordt een klein tipje van de sluier opgelicht bijvoorbeeld en weet je er eigenlijk nog niet het fijne van). Er is wel eens gesproken over een intranet forum/blog/o.i.d., maar dit soort ideeen worden niet waar gemaakt of het wordt deels waar gemaakt en vervolgens niet gebruikt.

Met mijn HBO opleiding informatica, twee jaar werkervaring en een nog niet voltooide deeltijd master opleiding, heb ik geprobeerd om deze tere punten tijdens vergaderingen boven tafel te brengen. Helaas is me tot op heden nog niet gelukt om een revolutie in onze bedrijfscultuur teweeg te brengen, sterker nog: er is weer vrolijk een nieuw project begonnen, waarin er stevig code wordt geklopt zonder ook maar een enkele gedachtegang op papier te zetten.

Aantal punten waardoor mijn inziens de "samenwerking tussen developers" stuk loopt:
- Het leeftijdsverschil: ik ben 23 en zij... niet .
- De bedrijfscultuur: zij werken er al een stevig aantal jaren en ik zit er nu net een jaar.
- De manier van werken: proberen om zo snel mogelijk een werkend product te hebben, zodat er geld verdiend kan worden.
- Het solo karakter van de beide programmeurs.

Kortom: ik ervaar de communicatie en het samenwerken momenteel als zeer slecht. Het hoeft inderdaad, zoals de TS opmerkt, niet zozeer het samenwerken aan eenzelfde applicatie te zijn, als wel het delen van kennis. De kennis die mij met mijn huidige project, mits deze op tijd en wel voor aanvang van het project was aangeleverd, wellicht een hele hoop ellende en lang overschreden deadline had kunnen schelen.

[Verwijderd]

Verwijderd schreef op maandag 08 mei 2006 @ 22:39:
Aantal punten waardoor mijn inziens de "samenwerking tussen developers" stuk loopt:
- Het leeftijdsverschil: ik ben 23 en zij... niet .
- De bedrijfscultuur: zij werken er al een stevig aantal jaren en ik zit er nu net een jaar.
- De manier van werken: proberen om zo snel mogelijk een werkend product te hebben, zodat er geld verdiend kan worden.
- Het solo karakter van de beide programmeurs.

Dat lijkt me best een samenwerkings-hel (massive understatement). Nog dapper van je dat je uberhaupt iets probeert te verbeteren...

Wat doe je als blijkt dat je niet voldoende moment kunt genereren om de beoogde interne veranderingen teweeg te brengen? (heb je voor jezelf een soort van do-or-die target gesteld wellicht?)

[bartje321]

Na weken van programmeren worden de applicatie software en de firmware software aan elkaar geknoopt en getest en dan ontstaan de problemen.

stel voor om dayly/weekly builds te gaan maken dan moeten ze wel samen werken.

[AtomicWing]

Verwijderd schreef op maandag 08 mei 2006 @ 22:39:

Typisch een verhaal voor verandermanagement. Lees anders eens het boek "Leren veranderen" (90-14-06158-7)

Wat veel wordt gedaan is het uitdelen van het boekje "Wie heeft mijn Kaas gepikt", waar Kaas staat voor vastgeroeste mensen, werkwijzen, etc.

Succes ermee...!

[-FoX-]

Verwijderd schreef op maandag 08 mei 2006 @ 22:39:
De situatie in het bedrijf waar ik werk, geeft juist compleet het tegenovergestelde van de situatie die de TS nu schetst weer.
verhaal

Lastige situatie om in te werken. Kan het best aannemen dat je er op een bepaald punt geen zin meer in hebt, en dat de hele situatie dan ook verwatert, zonder dat je er erg in hebt. Maar zover zou ik het zeker niet laten komen. Als dit er staat aan te komen, denk ik dat het verstandiger is om een andere job te zoeken waarin je dit wel kan verwezenlijken. Misschien wel harde woorden, maar ambitieuze mensen worden nog altijd te vaak geremd in zaken waarin ze een interne structuur erg kunnen verbeteren. Momenteel heb ik dit probleem niet zo, maar ken ook wel een aantal mensen die in deze situatie zijn terechtgekomen.

Het is niet vreemd dat het product op zo'n kort mogelijke termijn gerealiseerd dient te worden, aangezien de kosten dan ook lager zijn. Zo zien zij het toch. Voor jou kan het misschien handig zijn om je toe te leggen op een aantal tools en processen om de interne werking te verbeteren.
Een voorbeeld is om een tool te gebruiken voor geautomatiseerde builds zodat fouten sneller aan het licht komen. Of kortere iteratie cycli voorstellen. Een andere mogelijkheid zou nog kunnen zijn om een aantal tools te gebruiken die de code quality analyseren... Het zijn maar een aantal tips, maar deze kunnen je misschien al op weg helpen.

Maar jouw probleem handelt eerder over een stroeve interne werking en samenwerking op dezelfde projecten. Al is dit wel een punt dat hier besproken kan worden, zag ik het eerder ruimer.

In een bedrijf zitten meestal een aantal specialisten die erg goed zijn in wat ze doen. Niet iedereen kan alles perfect goed kennen en vandaar moet er met deze kennis, voor de interne mensen, zo goed mogelijk omgegaan worden. Hiermee bedoel ik dat het voor een medewerker mogelijk moet zijn om op zo'n kort mogelijke tijd een duidelijk en helpend antwoord moet krijgen van de overige experten. Je kan dit een beetje zien als "interne consultancy". Aangezien een bedrijf hier alleen maar profijt (hogere klanttevredenheid, minder kosten, ... ) aan heeft, ben ik op zoek naar een manier om dit te verwezenlijken. Echter is dit niet zo eenvoudig aangezien deze medewerkers vaak verspreidt zitten over meerdere locaties en ook vaak bij klanten zitten of onderweg zijn.

Een mogelijke oplossing zou "instant messaging" zijn, maar om dit te integreren in een bedrijf is niet zo eenvoudig (licenties, setup kosten, hele-goedkeursings-traject, ...).
Wat zouden andere mogelijke oplossingen kunnen zijn?

[Alarmnummer]

Wij hebben 1 keer per maand een tech meeting om de kennis te verspreiden. Verder hebben de meeste mensen bij ons in het bedrijf wel een of meerdere specialiteiten, dus als je iets wilt weten zijn er genoeg mensen die je kunt vragen. Het bedrijf waar ik voor werk (JTeam) werkt erg nauw samen met Interface21 en daardoor zijn er meestal ook interface21 consultants bij ons over de vloer (we delen een aantal kantoor ruimtes) dus daar kunnen we ook naar toe stappen als we iets willen weten.

[ Voor 3% gewijzigd door Alarmnummer op 09-05-2006 08:37 ]

[-FoX-]

Alarmnummer schreef op dinsdag 09 mei 2006 @ 08:36:
Wij hebben 1 keer per maand een tech meeting om de kennis te verspreiden. Verder hebben de meeste mensen bij ons in het bedrijf wel een of meerdere specialiteiten, dus als je iets wilt weten zijn er genoeg mensen die je kunt vragen. Het bedrijf waar ik voor werk (JTeam) werkt erg nauw samen met Interface21 en daardoor zijn er meestal ook interface21 consultants bij ons over de vloer (we delen een aantal kantoor ruimtes) dus daar kunnen we ook naar toe stappen als we iets willen weten.

Is nog altijd erg locatie gebaseerd en houdt ook in dat je weet bij wie je moet aankloppen voor een bepaald probleem. In grotere bedrijven is dat vaak niet het geval.

Tech meetings zijn wel een goed idee om kennis te verspreiden; maar is het niet zo dat er vaak alleen maar aan 'surface-scratching' van een bepaalde technologie / principe wordt gedaan?

Mij gaat het eerder om aan instant expertise-sharing te doen, zonder hierbij al te veel tijd te verliezen en snel tot een oplossing te komen.

Om een concreter voorbeeld te geven:
Een senior profiel werkt aan een applicatie waar er gebruikt gemaakt wordt van JBoss application server. Hij heeft voldoende kennis om het project te realiseren. Nu komt er opeens de vraag om een clustered JBoss op te zetten. Aangezien een andere medewerker certified JBoss expert is, kan hij dit aan deze persoon vragen, en binnen enkele minuten weet hij wat hem te doen staat.
- Geen stijle leercurve om tot het resultaat te komen.
- Hiervoor heeft hij geen uren tijd verloren met problemen die optraden
- Klant is erg tevreden, 1 enkele persoon kan ineens zoveel meer..
- Een volgende keer, weet hij precies wat hij moet doen.
Dit is maar een hypothese aangezien het clusteren van JBoss relatief simpel is. Maar het gaat om het idee

[Verwijderd]

Verwijderd schreef op dinsdag 09 mei 2006 @ 00:57:
[...]

Dat lijkt me best een samenwerkings-hel (massive understatement). Nog dapper van je dat je uberhaupt iets probeert te verbeteren...

Wat doe je als blijkt dat je niet voldoende moment kunt genereren om de beoogde interne veranderingen teweeg te brengen? (heb je voor jezelf een soort van do-or-die target gesteld wellicht?)

Eerlijk gezegd heb ik de problemen een beetje op zijn beloop laten gaan, aangezien mijn studie momenteel een hogere prioriteit heeft. Desalniettemin, blijft het frustrerend in de rest van de dagen dat ik niet op school ben en dus gewoon moet werken.

Wellicht is het wel handiger om een (nogmaals) een vergadering te plannen die gericht is op verbeteringen van de interne structuur. In ieder geval dank voor jullie reacties.

-FoX- schreef op dinsdag 09 mei 2006 @ 07:59:
[...]
Maar jouw probleem handelt eerder over een stroeve interne werking en samenwerking op dezelfde projecten. Al is dit wel een punt dat hier besproken kan worden, zag ik het eerder ruimer.

Inderdaad waar, ware het niet dat ik nu solo aan een project aan het werken ben voor ruim een jaar. Terwijl de kennis van de communicatie met de betreffende firmware bij beide programmeurs aanwezig is, maar helaas beperkt verstrekt wordt (vragen, vragen, vragen misschien heb ik dat te weinig gedaan, maar waar ligt de grens?). De kennis en de expertise is dus wel aanwezig, maar wordt simpelweg niet gedeeld.

Daarnaast heeft het project veel vertraging opgelopen, omdat er niet eens een kort en bondige functionele analyse voor mij aanwezig was. De bedoeling was om eeen Communicatie module te maken, terwijl nu de complete originele applicatie verbouwd is. Ergens in het midden van het traject, kwam de opmerking "oh... en dit moet ook kunnen". "Dit" betekende voor mij een complete ombouw van de huidige technische implementie (interface, database, tussenlagen etc.).

Wellicht dat ik nog een deadline ga stellen tot na de zomervakantie, als ik dan nog niks heb kunnen veranderen (dmv. vergaderingen etc.) dan is het misschien verstandiger om inderdaad iets anders te zoeken.

[LauPro]

Verwijderd schreef op dinsdag 09 mei 2006 @ 09:33:
Inderdaad waar, ware het niet dat ik nu solo aan een project aan het werken ben voor ruim een jaar. Terwijl de kennis van de communicatie met de betreffende firmware bij beide programmeurs aanwezig is, maar helaas beperkt verstrekt wordt (vragen, vragen, vragen misschien heb ik dat te weinig gedaan, maar waar ligt de grens?). De kennis en de expertise is dus wel aanwezig, maar wordt simpelweg niet gedeeld.

Kan het niet zo zijn dat die twee personen niet geheel tevreden zijn met hun positie en zich daarom 'indekken'. Door deze 'kostbare' informatie achter te houden kunnen ze moeilijker worden ontslagen omdat dat anders (bwvs) 4 maanden tijd kost om iemand weer op dat niveau in te werken. Wellicht dat je dat eens kan pijlen, of men wel tevreden is bij het huidige bedrijf en of er niet andere zaken lopen (en dat kan heel ver terug gaan als ze al een tijdje werken).

[EfBe]

Een aantal factoren belemmeren verspreiding van kennis:
- ego
- tijd
- onduidelijkheid wat er precies gewenst is.

Het kost echt tijd om artikelen te schrijven om collega's iets te leren. Verder is het vaak onduidelijk waar gebrek aan is. En er is een groot probleem met ego's vaak: degene met het grootste ego denkt ook vaak het meeste te weten, maar dat is zelden het geval.

Maar het allergrootste struikelblok denk ik is het verschil tussen kennis en wijsheid. Je kunt wel 1001 feitjes en triviaatjes op een partij webpages zetten op het intranet, maar daar wordt de gemiddele programmeur alleen maar overspannen van en niet zozeer wijzer. Via boeken en artikelen op het internet zijn er al genoeg manieren om de kennis op te doen, dus dat nog eens dunnetjes overdoen middels eigen artikelen e.d. lijkt me overbodig. Waar men in moet investeren is het opbouwen van wijsheid. En dat heeft altijd een context nodig, bv een huidig project: dus binnen een project kennis omzetten in wijsheid door alleen voor het project belangrijke kennis te verzamelen en die bv behandelen in een artikel of in een uur durende sessie (waarbij iedereen die iets te melden heeft erover zn zegje mag doen).

Echter veelvuldig valt alles in het water omdat men bv geen tijd heeft of wil vrijmaken, of het als parate kennis verondersteld, of communicatief een onbenul is of gewoon niet genoeg betrokken bij het vak van software engineering. Vooral dat laatste is schrijnend: het merendeel van de mensen die nu software bouwt is meer geinteresseerd in de leaseauto/baanproperties dan het werk dat men doet.

[LauPro]

@EfBe: ik vind het opmerkelijk dat je volledig voorbij gaat aan het feit dat er veel diepere redenen voor iemand kunnen zijn om niet volledig te presteren. Grappig dat je het dan gooit op 'ego' maar dat iemand terughoudend is kan heel andere oorzaken hebben. Zeker in de ICT geldt vaak 'voor jou 10 anderen', dus waarom zou je als je in een situatie zit waar je flink bent genaaid door je werkgever helemaal open kaart gaan spelen? Je kan dan veel beter je kaarten achter de hand houden, dan is jouw plek voor de komende tijd teminste veilig.

Uiteindelijk lopen dat soort relaties natuurlijk altijd stuk, sowieso is het voor de werknemer niet prettig werken over het algemeen als je _altijd_ op je hoede moet zijn, en de werkgever kan het natuurlijk ook zat worden dat hij zo wordt geterroriseerd (als ze het teminste doorhebben).

Dit bovenstaande heb ik al paar keer in mijn omgeving gezien en zelf ben ik ook in een dergelijke positie geweest een tijd (ben ik nu gelukkig uit).

[MicroWhale]

leuk topic!

persoonlijk denk ik dat het probleem opgelost kan worden door een aantal factoren te veranderen:

1. projectmatig werken
2. communicatie
3. uniforme werkwijze

1. er wordt vaak niet projectmatig gewerkt. Dingen worden niet vantevoren vastgelegd: Denk aan het vastleggen van specificaties, het afbakenen van het werkgebied, gebruikte technieken, leverings-schema van aan te voeren informatie, test-schema, etc...

Door deze dingen vast te leggen en hiervoor een planning te maken, voorkom je dat mensen hun eigen weg gaan. Voortgangsvergaderingen zijn voor de haalbaarheid en het onvermijdelijke bijsturen van de planning ook noodzakelijk.

2. Als er tijdens het project problemen ontstaan worden deze vaak niet gemeld omdat men denkt dat 'het maar een klein issue is'. Dit kan echter grote gevolgen hebben voor de rest van het project en het zelfs compleet in de soep laten draaien. Het is daarom van uiterst belang dat, als mensen ook maar denken dat ze een issue gaan krijgen, deze besproken wordt met collega's en de projectmanagers. Zo kan bij de signalering bijgestuurd worden en niet in de test-fase.

Schroom niet om je collega erbij te roepen als je er even niet uitkomt. Veel programmeurs verzinnen voor kleinere stappen een oplossing die er al blijkt te zijn of maken iets compleet nieuws, waardoor er andere complicaties ontstaan. Zo kan het gebeuren dat er, zonder communicatie, 3 "sorteer" algoritmes geschreven worden door 3 programmeurs. Dit hadden ze, met communcatie en overleg, kunnen vermijden. Het bespaart veel onnodig werk en tijd.

3. Duidelijke afspraken over code-format, documentatie-format, etc... Zelfs ook hoe code geschreven wordt kan vastgelegd worden, welke variabelen welke namen krijgen, etc.. Deze zorgen ervoor dat code en documentatie een uniform karakter heeft en dus door alle betrokken ontwikkelaars (en vooral door de project-manager) begrepen kunnen worden!

Dit laatste punt wordt vreselijk onderschat. Documentatie en leesbaarheid van code is een van de belangrijkste aspecten van code. Waarom? omdat je je code vaak maar één keer schrijft en daarna wordt die 1000x gelezen, door jou én anderen.

[EfBe]

LauPro schreef op dinsdag 09 mei 2006 @ 10:35:
@EfBe: ik vind het opmerkelijk dat je volledig voorbij gaat aan het feit dat er veel diepere redenen voor iemand kunnen zijn om niet volledig te presteren. Grappig dat je het dan gooit op 'ego' maar dat iemand terughoudend is kan heel andere oorzaken hebben. Zeker in de ICT geldt vaak 'voor jou 10 anderen', dus waarom zou je als je in een situatie zit waar je flink bent genaaid door je werkgever helemaal open kaart gaan spelen? Je kan dan veel beter je kaarten achter de hand houden, dan is jouw plek voor de komende tijd teminste veilig.

Dat is dus wat ik bedoelde met mijn laatste paragraaf, mensen zijn meer aan het werk om de dingen die niet met software engineerin horen dan om de betrokkenheid bij het project, het werk, het vak.

Verder snap ik je redenatie niet echt. Als je nl. ergens gaat werken ga je met je werkgever een verplichting aan: jij levert prestatie, hij levert daarvoor een beloning. Je niet inzetten voor je werkgever houdt dus in dat je jouw deel van de deal verzaakt. Als dat is omdat je werkgever zn deel niet nakomt, dan moet je of je werkgever daaraan houden of de deal verbreken.

Uiteindelijk lopen dat soort relaties natuurlijk altijd stuk, sowieso is het voor de werknemer niet prettig werken over het algemeen als je _altijd_ op je hoede moet zijn, en de werkgever kan het natuurlijk ook zat worden dat hij zo wordt geterroriseerd (als ze het teminste doorhebben).

Dit bovenstaande heb ik al paar keer in mijn omgeving gezien en zelf ben ik ook in een dergelijke positie geweest een tijd (ben ik nu gelukkig uit).

Mja, ik zie niet echt in waarom dit betrekking heeft op het topic. Een verstoorde werksituatie is naar, maar dat is iets tussen werkgever en werknemer, en daar ging deze discussie niet over. In een normale werksituatie komen de dingen voor die ik opnoemde, daar doelde ik dus op. Mensen die zich niet in willen zetten voor het project omdat ze gebruilleerd zijn met hun werkgever moeten OF die problemen oplossen OF verkassen naar een andere werkgever.

[LauPro]

EfBe schreef op dinsdag 09 mei 2006 @ 12:38:
Dat is dus wat ik bedoelde met mijn laatste paragraaf, mensen zijn meer aan het werk om de dingen die niet met software engineerin horen dan om de betrokkenheid bij het project, het werk, het vak.

Oke, daar kan ik inkomen maar dat heeft denk ik dan ook voor een deel met beloning enerzijds te maken en anderzijds dan waarschijnlijk te weinig controle vanuit de werkgever.

Verder snap ik je redenatie niet echt. Als je nl. ergens gaat werken ga je met je werkgever een verplichting aan: jij levert prestatie, hij levert daarvoor een beloning. Je niet inzetten voor je werkgever houdt dus in dat je jouw deel van de deal verzaakt. Als dat is omdat je werkgever zn deel niet nakomt, dan moet je of je werkgever daaraan houden of de deal verbreken.

Dat is denk ik een beetje het schoolvoorbeeld zoals het zou moeten gebeuren, alleen er zijn genoeg situaties waar dit niet in op gaat. Sowieso, mocht een werknemer een gezin hebben e.d. dan zal hij/zij niet zo snel dat soort beslissingen nemen, dan maar een iets minder prettige werkomgeving.

Mja, ik zie niet echt in waarom dit betrekking heeft op het topic. Een verstoorde werksituatie is naar, maar dat is iets tussen werkgever en werknemer, en daar ging deze discussie niet over. In een normale werksituatie komen de dingen voor die ik opnoemde, daar doelde ik dus op. Mensen die zich niet in willen zetten voor het project omdat ze gebruilleerd zijn met hun werkgever moeten OF die problemen oplossen OF verkassen naar een andere werkgever.

Het heeft wel degelijk betrekking op dit topic, want je moet oorzaak en gevolg niet door elkaar halen. Als je bijv. stelt dat de zelfingenomenheid van iemand de oorzaak is dat er een slechte samenwerking en congruentie ontstaat dan vind ik dat een onjuiste constatering.

De oorzaak dat iemand zich moet indekken (voor zijn eigen belang) kan veel dieper gaan dan 'een slechte werkgeversverhouding' zoals ik al aan gaf. En je moet juist die oorzaak zien weg te nemen wil je het probleem oplossen om zo een goede collaboratie tot stand te laten komen

[EfBe]

Nou, als een persoon A samenwerkt met een persoon B en B vindt dat hij/zij zich moet 'indekken', dan is dat mooi klote voor A, want die persoon A heeft daar geen bal mee te maken maar wel last van, nadeel van en kan zelfs daar schade van ondervinden in bv financiele zin of carrieremogelijkheden omdat een project mislukt.

Ik kan ook niet begrijpen dat iemand zich in gaat dekken en dat dat dan goed of begrijpelijk gevonden wordt. Men werkt nl. niet voor zichzelf bij een werkgever maar voor de werkgever. Dat staat nl. in zn contract. Andersom verwacht men nl. ook dat de werkgever gewoon lapt aan het eind van de maand, toch? Waarom is dan de andere kant, nl. de verplichtingen van de werknemer, ineens minder belangrijk?

(als de werkgever in gebreke blijft, dan is dat lullig, maar daar kun je stappen tegen ondernemen en is t.a.t. een kwestie tussen werkgever en werknemer, en niet tussen werknemers onderling.)

Verder geloof ik niet zo in 'voor jou 10 anderen', tenzij je echt helemaal niets kunt, maar daar hebben we het niet over, want die personen kunnen sowieso niets aan andere leren

[ Voor 27% gewijzigd door EfBe op 09-05-2006 16:18 ]

[Verwijderd]

@Vrieler (ik heb de rest van de thread nog niet gelezen, dus misschien is dit mosterd na de maaltijd...)

Aantal punten waardoor mijn inziens de "samenwerking tussen developers" stuk loopt:
- Het leeftijdsverschil: ik ben 23 en zij... niet .
- De bedrijfscultuur: zij werken er al een stevig aantal jaren en ik zit er nu net een jaar.
- De manier van werken: proberen om zo snel mogelijk een werkend product te hebben, zodat er geld verdiend kan worden.
- Het solo karakter van de beide programmeurs.

Leeftijdsverschil: Ik had je vader kunnen zijn (wat leeftijd betreft ), maar ik heb nog nooit moeite gehad om samen te werken met 'jonkies', en heb van een aantal van hen ook een hoop kunnen leren. En (hopelijk) zij van mij.

Bedrijfscultuur: Ik werk nu al dik 8 jaar bij hetzelfde bedrijf, en daarvoor 12 jaar bij m'n vorige werknemer. Maar da's geen verdienste, of iets wat me een 'streepje voor' biedt. 't Zegt meer over mezelf (nogal honkvast), en wanneer een nieuwe collega bewezen heeft iets bij te dragen te hebben, dan zal 'ie dat ook moeten doen, en krijgt 'ie van mij alle ruimte en zelfstandigheid om echt iets bij te dragen. Met de kans dat 'ie zo nu en dan op z'n bek gaat, maar daar leer je alleen maar van, en dat hebben we allemaal meegemaakt. (en ik ga nu ook nog wel 's op m'n bek)

Manier van werken: Hier heb ik nog wel 's discussies met m'n jongere/nieuwere collega's over. De balans tussen een deadline halen en een perfect product afleveren is altijd een afweging. Als ik ieder project zo zou willen doen als ik zelf zou willen (i.e. ontwerp en code waar ik 100% achter sta), zou ik geen enkel project op tijd af krijgen. Of we zouden de deadline drastisch moeten verschuiven, en dat is in 't verkoop traject niet verkoopbaar omdat een concurrent wel binnen die deadline belooft te leveren.
Vaak is een keuze van "'t is niet mooi, maar 't werkt wel" handiger. Je hebt dan die klant(en) binnen, en kunt daarna zorgen dat e.e.a. zo wordt dat je er zelf ook trots op kunt zijn. Dat laatste (trots op je eigen dingen zijn) is voor mij de belangrijkste drijfveer om te programmeren, maar de belangrijkste drijfveer van het bedrijf waarvoor ik werk is blijven bestaan, en winst maken.
Soms maak ik m'n eigen doelstellingen ondergeschikt aan die van m'n werkgever, want ik wil toch ook wel iedere maand iets op m'n bankrekening zien...

Solo karakter: Daar heb je denk ik de kern van 't probleem. Software ontwikkeling is vrijwel altijd een kwestie van teamwork, en wanneer mensen niet in een team kunnen werken of niet geleerd hebben om in een team te werken, is een project bijna gedoemd te mislukken.
Het feit dat die 2 mensen zo langs erkaar heen kunnen en mogen werken is het echte bedrijfscultuur probleem.

[JKVA]

Toch denk ik zeker niet dat een groot bedrijf slechtere onderlinge kennisdeling heeft.

Integendeel, zelfs betere. Ik heb bij een klein bedrijf gewerkt (zo'n 10 mdw) en daar waren op ongeveer alle gebied wel wat goeie mensen aanwezig en bereid om heel eventjes te helpen. Tijd is immers geld, vooral hun tijd. Je vraagt het namelijk meteen aan een eigenaar van het bedrijf en die wil graag zo veel mogelijk uren kunnen declareren.

Nu zit ik bij een veel grotere kiet. (Eén van de grootste van NL) Ondanks dat ik er nu pas net twee maanden zit, ken ik er ondertussen enkele tientallen mensen, waaronder enkele managers, goede programmeurs/architecten en nog wat andere vakgebieden. Als ik er nu niet uitkom, vraag je het gewoon even. Meestal kunnen ze wel tijd vrijmaken voor je en bijna altijd kom je er op deze manier wel uit. Of je hebt wat nieuwe inspiratie die je verder helpt.

Ook worden er ontwikkeldagen gehouden, seminars van bijvoorbeeld de makers van Spring ofzo, cursussen. Er is een kennisbank op het intranet, maar die vergeet ik altijd te gebruiken. De meeste van die dingen staan tenslotte ook wel op google.

Ik weet niet of dit typisch is voor een grotere club of dat het aan mij en mijn mede afstudeerder ligt. Ben er namelijk via afstuderen binnengekomen. Grappig detail om aan te geven dat het ook andersom werkt, dus hoe medewerkers de nieuwelingen weten te vinden. Onze opdracht gaat namelijk over JSF en het halve bedrijf is al bij ons langs geweest om te vragen of het iets is, hoe het werkt en of ze het al zelf moeten gebruiken. Het werkt dus ook twee kanten op.

Concluderend komt het er denk ik voornamelijk op neer dat het bij grotere bedrijven gemoedelijker aan toe gaat en mensen dus meer tijd voor je over hebben. Bij kleinere bedrijven ben je al snel "geld van de baas aan het verspillen" met een simpel onderzoek of vraag.

[Verwijderd]

JKVA, kleinere bedrijven hebben doodgewoon minder tijd/geld voor research, omdat development al een flinke hap uit 't budget neemt.

Gevolg is dan vaak dat je als ontwikkelaar vaak het research-deel in je eigen tijd doet, en daar als individuele ontwikkelaar je voordeel mee doet. Niks mis mee (als je werk je hobby is), maar het delen van die kennis met collega's is dan niet binnen het bedrijf geformaliseerd, en vindt dus pas plaats wanneer een collega een "heb jij dat wel 's gehad?" vraag stelt.
In m'n eigen team (5 ontwikkelaars) probeer ik die communicatie wel te bevorderen ("gewoon roepen als je een probleem hebt"), maar dingen als ontwikkeldagen, seminars en een kennisbank zijn luxes die we ons gewoon niet kunnen veroorloven.

Maar aan de andere kant, tijdens de Microsoft DevDays vertelde iemand van (ik geloof) Origin hoe ze Visual Studio 2005 Team Suite hadden omgezet naar hun 'ontwikkelstraat' manier van werken, i.p.v. 'agile'.
Als ik op zo'n manier zou moeten werken, zou ik per direct ophouden ontwikkelaar te zijn. Geef mij dan maar een klein team waarbij je niet door een specialisme beperkt wordt.

[JKVA]

Oh, maar ik ga ook niet roepen dat ze meteen die Spring gasten moeten uitnodigen, maar als ik kijk hoe gemakkelijk nieuwe technologieen weggebonjourd worden, omdat niet 123 het voordeel ervan duidelijk is of omdat het twee middagen leertijd kost.

Een paar weken geleden is me het overigens gelukt om ze de overstap te laten maken naar (My)Eclipse en CVS. Zeker nu met die nieuwe IDE waar allemaal interessante "nieuwe" termen (JSF, Struts, Hibernate, enz) in staan, lijkt het animo voor nieuwe dingen wel gegroeid, maar dat is pas één deel van het probleem.

Ook bijvoorbeeld zaken als continues integration, unit tests, formele methodieken voor requirements of projectfasering zijn niet aanwezig. De eerste hoeft van mij ook niet, dat is al veel te geavanceerd, maar de laatste drie zijn naar mijn idee essentieel, groot bedijf of klein bedrijf.

Het gaat er naar mijn idee vooral om dat kleinere bedrijven vaak banger voor veranderingen zijn, precies om de reden die je roept: onzekere toekomst, risico's, financiën... Echter, veel van deze zaken kunnen op de iets langere duur (vaak ook al vrij korte duur) voordelen opleveren.

Als je niet meegaat in de stroom met nieuwe dingen, kom je naar mijn idee in een neergaande spiraal en wordt het steeds moeilijker om kwaliteit te leveren, planningen te halen, te groeien en uiteindelijk weer meer centen te verdienen.

Daar komt bij dat kleine bedrijven het juist moeten hebben van innovatie, want qua efficientie en zo kunnen ze niet tippen aan de grote jongens. Waarom zou je dan geen tijd besteden aan het enige voordeel dat je hebt ten opzichte van de groten? (unieke concepten buiten beschouwing genomen...)

[LauPro]

EfBe schreef op dinsdag 09 mei 2006 @ 16:15:
Nou, als een persoon A samenwerkt met een persoon B en B vindt dat hij/zij zich moet 'indekken', dan is dat mooi klote voor A, want die persoon A heeft daar geen bal mee te maken maar wel last van, nadeel van en kan zelfs daar schade van ondervinden in bv financiele zin of carrieremogelijkheden omdat een project mislukt.

Ik kan ook niet begrijpen dat iemand zich in gaat dekken en dat dat dan goed of begrijpelijk gevonden wordt.

Je kan dat dan wel gaan baggetaliseren maar daarmee blijft het probleem en het bevestigt alleen maar mijn vermoedens en ervaringen aangezien het in dit topic weer naar voren komt.

Men werkt nl. niet voor zichzelf bij een werkgever maar voor de werkgever. Dat staat nl. in zn contract. Andersom verwacht men nl. ook dat de werkgever gewoon lapt aan het eind van de maand, toch? Waarom is dan de andere kant, nl. de verplichtingen van de werknemer, ineens minder belangrijk?

Dat ligt geheel aan de situatie, wellicht heeft die werkgever wel een aantal maanden verzuimd om geen loon uit te betalen of loonsaneringen in het verleden moeten toepassen.

(als de werkgever in gebreke blijft, dan is dat lullig, maar daar kun je stappen tegen ondernemen en is t.a.t. een kwestie tussen werkgever en werknemer, en niet tussen werknemers onderling.)

Dat is ook weer een gedachtengang van zoals het zou moeten gaan, jij kan wellicht wel die scheiding aanbrengen, mij lukt het waarschijnlijk ook wel maar er zijn ook mensen die echt niet prettig zullen werken als ze niet met een goed gevoel naar hun werk gaan. Je kan wel stellen dat je voor de 40 uur die je maakt in een week een vast salaris aan het einde van de maand krijgt, alleen in een contract staat meestal niet vastgelegd wat het humeur of de instelling van mensen moet zijn.

Verder geloof ik niet zo in 'voor jou 10 anderen', tenzij je echt helemaal niets kunt, maar daar hebben we het niet over, want die personen kunnen sowieso niets aan andere leren

Het gaat niet zozeer om die personen maar meer om de werkgever, als ik bijv. een bouwkundig architect aan zou nemen voor een bepaalde klus die ruim 5 jaar duurt, en die persoon zegt zijn contract op na 2 jaar dan heb ik als werkgever een probleem. Sowieso moet ik dan op korte termijn op zoek naar iemand anders, zal waarschijnlijk in eerste instantie detachering gaan worden (=duur) en die persoon moet ook weer worden ingewerkt. Uiteraard een incalculeerbaar risico, maar mocht een bedrijf al in een slechte financiële positie zitten dan kan dat net de nek om doen. Ik wil geen discussie starten over wat de verantwoordelijkheden zijn als ondernemer, alleen de situatie ligt niet zo zwart-wit mijns inziens

Verwijderd schreef op dinsdag 09 mei 2006 @ 21:07:
Het feit dat die 2 mensen zo langs erkaar heen kunnen en mogen werken is het echte bedrijfscultuur probleem.

De bedrijfscultuur wordt meestal geïnitieerd door het management (werkgever). Ik vind het wel opvallend dat over het algemeen genomen (zonder dat ik mensen in hokjes wil duwen) de werknemers de werkgevers de 'schuld' geven en de werkgevers de werknemers . Volgens mij is de oplossing: praat met elkaar. Maar gezien de verantwoordelijkheden van de ondernemer vind ik dit wel een taak van de werkgever. Misschien meer functioneringsgesprekken inplannen?

@Afterlife: goed punt, als development niet binnen de reguliere uren voor de werknemer mogelijk is dan is deze persoon in principe geheel vrij in hoeverre hij in zijn eigen tijd daarin wil investeren. Zelf ben ik voorstander van een 20%-regeling zoals o.a. bij Google, waar je als werknemer 20% van je tijd vrij mag besteden aan research & development. 20% kan best een hap uit het budget zijn, maar het zorgt er voor je bedrijf wel voor dat je in-house R&D hebt. En dat is volgens mij een zeer kostbaar iets om goed te kunnen innoveren.

[Verwijderd]

@ Afterlife.
Misschien had ik mijn redenen iets meer mbt. mijn bedrijfssituatie moeten beschrijven.

Leeftijdsverschil
Het is niet zo dat ik het erg vind om met mensen te werken die ouder zijn dan ik. Integendeel, dat zijn juist de personen waar je het van zou moeten leren. Met name de kneepjes van het vak. Waar ik echter in het bedrijf waar ik werk tegen aan loop, is dat ik het idee heb dat er niet altijd geluisterd wordt naar jongeren.

Als ik bijvoorbeeld ideeën aandraag om iets documenteren, dan krijg je als reactie (en met name van de personen die ouder zijn en langer hier werken, vandaar de opmerking ) "dat kan niet", "dat zijn schoolmanieren", "dat kost teveel tijd". Terwijl er verder ook geen moeite wordt gedaan om er een middenweg in te vinden of wellicht het idee eens te beoordelen of er lering uit te trekken.

Bedrijfscultuur
Ik krijg ook wel erg veel ruimte, maar naar mijn idee ook veel te veel. Bijvoorbeeld krijg ik weinig tot geen begeleiding. Nu is dat niet zo'n probleem, maar soms (en dat heb ik meegemaakt) ga je op verkeerde voet verder of je zit vast. Momenteel heb ik twee jaar werkervaring en als ik nu een project start, zou ik het onmiddelijk anders doen en ook meteen starten met het maken van een analyse (ongeacht de reacties). Maar vorig jaar, was dat niet het geval. Nu krijg ik dus allerlei opmerkingen over de software die ik heb gemaakt ("dat is niet goed", "waarom is daar voor gekozen").

Gisteren stelde ik tijdens een meeting mbt. mijn software voor om dit soort meetingen in de toekomst elke twee weken te doen (zodat problemen snel opgespoord kunnen worden). Daar wordt dan niet enthousiast op gereageerd en vervolgens wordt er ook niet meer over gepraat.

Manier van werken
Het is inderdaad een afweging, maar concluderend uit bovenstaand: "their way, or the highway"

Solo karakter
Totaal met je eens, zie bovenstaande punt met betrekking tot begeleiding.

@ EfBe
Ego is inderdaad een kritiek punt. De programmeur die hier het langst werkt, heeft het grootste deel van de producten (firmware) gemaakt, maar hij vindt het dan ook plezierig dat iedereen aan hem moet vragen hoe iets precies werkt. Doordat hij dan zo vaag mogelijk antwoord geeft, heeft hij de garantie dat mensen alsnog iets komen vragen.

[LauPro]

Verwijderd schreef op woensdag 10 mei 2006 @ 09:21:
De programmeur die hier het langst werkt, heeft het grootste deel van de producten (firmware) gemaakt, maar hij vindt het dan ook plezierig dat iedereen aan hem moet vragen hoe iets precies werkt. Doordat hij dan zo vaag mogelijk antwoord geeft, heeft hij de garantie dat mensen alsnog iets komen vragen.

Dat vind ik een beetje kromme redenering, denk dat hij meer het idee heeft dat het een beetje zijn kindje is (al hoeweel dat formeel waarschijnlijk anders ligt) en daardoor het liefst geen andere mensen ziet werken aan 'zijn' code.

[Verwijderd]

LauPro schreef op woensdag 10 mei 2006 @ 10:22:
[...]
Dat vind ik een beetje kromme redenering
[...]

Het is terecht te zeggen dat iemand het niet prettig vindt dat er aan zijn of haar idee wordt geknutseld ZONDER hiermee te overleggen.

Echter, ter bevordering van de communicatie en samenwerking tussen developers (de context van dit topic) is het onterecht om bepaalde informatie zolang mogelijk tot je zelf te houden (en dus geen moeite doet om uit te leggen hoe "jouw kindje" is ontworpen), zodat een andere programmeur later in een project gedwongen is om heel de code om te schrijven.

Overigens, vind ik het persoonlijk nogal triest als je alles maar voor jezelf wilt houden. Over ego gesproken.

[LauPro]

Verwijderd schreef op woensdag 10 mei 2006 @ 10:35:
[...]
Het is terecht te zeggen dat iemand het niet prettig vindt dat er aan zijn of haar idee wordt geknutseld ZONDER hiermee te overleggen.

Ik vraag me af of het 'terecht' is, aangezien als je voor een baas werkt de code niet voor jezelf maakt maar voor het bedrijf. Maar als er vanuit dat bedrijf niet verplicht wordt om te documenteren dan wordt het een redelijk grijs gebied.

[..]zodat een andere programmeur later in een project gedwongen is om heel de code om te schrijven.

Denk niet dat er direct code moet worden omgeschreven, maar in plaats van in 2 uur klaar te zijn kan dezelfde opdracht zonder die documentatie/informatie misschien wel 6 uur duren.

Overigens, vind ik het persoonlijk nogal triest als je alles maar voor jezelf wilt houden. Over ego gesproken.

Zoals ik meermaals probeer aan te geven hoeft het niet alleen met ego te maken te hebben maar is het vaak een belangenkwestie.

[ Voor 3% gewijzigd door LauPro op 10-05-2006 14:19 ]

[Verwijderd]

JKVA schreef op dinsdag 09 mei 2006 @ 22:28:
Ook bijvoorbeeld zaken als continues integration, unit tests, formele methodieken voor requirements of projectfasering zijn niet aanwezig. De eerste hoeft van mij ook niet, dat is al veel te geavanceerd, maar de laatste drie zijn naar mijn idee essentieel, groot bedijf of klein bedrijf.

De laatste 2 worden alleen essentieel op het moment dat je ontwikkelteam groter wordt. Toen ik begon (dik acht jaar geleden) bestond 't ontwikkelteam uit 3 man, en was er in feite niets geformaliseerd. Daar was eigenlijk ook geen behoefte of noodzaak toe, omdat we alledrie bezig waren met dezelfde "missie" (de markt veroveren), en omdat we elkaar blindelings aanvoelden.

Pas toen we echt begonnen te groeien werd 't echt essentieel om de boel wat beter te formaliseren, maar ook nu gaan we daar nog niet al te strict mee om. We zijn nog steeds een klein bedrijf (30+ mensen in Nederland, Belgie, Frankrijk, VS en Australie) en hebben de luxe dat we geen maatwerk ontwikkelen, maar alleen "standaard" software voor ons marktgebied. Natuurlijk leiden dan vaak requirements van klanten of prospects wel tot aanpassingen van / uitbreidingen op de produkten, maar omdat er voor de klant niet direct een prijskaartje aan zo'n requirement hangt, hoeft dat niet zo erg geformaliseerd te worden. Vaak is 't voldoende wanneer 't wordt meegenomen in de volgende versie, en dan hoef je in eerste instantie alleen maar te zorgen dat de requirement vastgelegd wordt in de feature request list voor die versie.

"unit testing" wordt al vanaf het begin van de software ontwikkeling gebruikt, maar heette toen nog gewoon "gezond verstand". Je bent gek als je substantiele dingen in je business logic wijzigt, en dan niet test of er misschien dingen in de bestaande functionaliteit zijn omgevallen.
Of je dat nu test door Junit / Nunit / Dunit / whatever te gebruiken of door een aantal testers een lijst scenario's te laten doorlopen, doet er niet zoveel toe. Behalve dat 't eerste ten koste gaat van resources in je development afdeling, en 't tweede ten koste van je QA afdeling.

Als je niet meegaat in de stroom met nieuwe dingen, kom je naar mijn idee in een neergaande spiraal en wordt het steeds moeilijker om kwaliteit te leveren, planningen te halen, te groeien en uiteindelijk weer meer centen te verdienen.

Naar mijn ervaring springen kleine bedrijven juist veel sneller op de bandwagon van "nieuwe dingen". Werken in een klein bedrijf houdt meestal in dat je je niet kunt vastbijten in je specialisatie, maar dat je overal inzetbaar moet zijn. Je moet dan van veel meer dingen op de hoogte zijn, en je in veel meer dingen verdiepen.
En als je er dan achter komt dat bv. in een web applicatie het voor de user interface vaak veel handiger is om een stukje van 't scherm te updaten via javascript en een XmlHttpRequest (OK, toen nog IE only, omdat andere browsers nog geen XmlHttpRequest ondersteunden), zet je dat direct in. Wel met de restrictie dat 't IE only is, maar bij een browser based app op een intranet kan dat zonder problemen.
Bij een groot bedrijf moet zo'n beslissing eerst door de validatie-molen, en wordt 't in feite pas toegepast wanneer AJAX een hype is geworden...

Daar komt bij dat kleine bedrijven het juist moeten hebben van innovatie, want qua efficientie en zo kunnen ze niet tippen aan de grote jongens. Waarom zou je dan geen tijd besteden aan het enige voordeel dat je hebt ten opzichte van de groten? (unieke concepten buiten beschouwing genomen...)

Verkijk je niet op de efficientie van kleine bedrijven. Voordeel is, dat de klant z'n wensen vaak direct kan communiceren met de ontwikkelaar(s), zonder tussenkomst van project managers, etc. Hierdoor kan die ontwikkelaar (wanneer 'ie een beetje over communicatie-vaardigheden beschikt) direct aangeven of iets haalbaar is, of een alternatief aanbieden dat beter binnen de structuur van het produkt past. En aangeven of 't haalbaar is en binnen welke termijn. Bij die termijn moet de ontwikkelaar dan wel leren om altijd z'n eigen inschatting x 3 te doen, want daar komt 't in de praktijk op uit.
Die communicatie kan in formele vergaderingen met de klant gebeuren, maar ook (en vooral) in een telefoontje van bv. een afdelingshoofd (bij de klant) die vraagt of iets niet een beetje aangepast kan worden zodat 't voor z'n mensen wat handiger werkt.
Geen idee hoe vaak ik (als ontwikkelaar, vaak zonder medeweten van m'n werkgever) een klant vroeger al heb voorzien van een update waar nog nooit iemand iets van had getest, met de melding "ik heb een nieuwe testversie bij jullie neergezet, zou je kunnen kijken of dit is wat je bedoelt?".

Het is niet erg om een klant als proefkonijn te gebruiken, als ze maar weten dat ze dat zijn, en als er iets tegenover staat (functionaliteit waar ze om gevraagd hebben).

[Verwijderd]

Vrieler, goed verhaal, en 't maakt me jouw positie een stuk duidelijker.

Verwijderd schreef op woensdag 10 mei 2006 @ 09:21:
Manier van werken
Het is inderdaad een afweging, maar concluderend uit bovenstaand: "their way, or the highway"

Mijn conclusie zou in zo'n geval zijn:
- Aankaarten bij het management en zien of zij bereid zijn om de bedrijfscultuur op korte termijn te wijzigen, en anders...
- "the highway" is ook zo slecht nog niet. De IT markt trekt nog steeds aan, en je zou dan solliciteren vanuit een situatie met baan. Dat is altijd gunstig, omdat je dan niet alles hoeft aan te pakken dat op je pad komt.

Je bent doodgewoon op een plek beland dat niet jouw plek is. Kan gebeuren, en zoek je eigen plekje.
Tip: kijk 's naar kleinere bedrijven. Kans is groot dat je dan ook regelmatig zonder begeleiding in 't diepe wordt gegooid (wegens gebrek aan resources om je te begeleiden), maar de kans is ook groot dat je zomaar naast iemand komt te zitten die je de kneepjes snel kan bijbrengen, of als vangnet kan dienen wanneer je een iets te enthousiaste sprong hebt geprobeerd.

/me is dol op teams waarin iedereen elkaar door en door kent...

[JKVA]

@afterlife
Eigenlijk al jouw punten heb ik op een andere manier ervaren bij mijn vorige werkgever. Bijvoorbeeld documentatie. Dat je geen javadoc en jcoverage en zulke doc generatie tools gebruikt, ok, maar in de code stond letterlijk geen documentatie, buiten code die gecomment was omdat er even een fout optrad en het niet netjes afgewerkt was.

Ook wordt er veel met (tijdelijke) stagiaires gewerkt, waardoor geautomatiseerde tests nog belangrijker worden omdat ze niet de impact kennen van wijzigingen en vaak minder krithsch zijn.

Dat AJAX verhaal heb je helemaal gelijk in. Wij werkten 5-6 jaar geleden er al mee. Toen waren ze ook nog innovatief. Nu zitten ze een beetje vast aan de gebruikte zaken omdat er een tijd lang niet geinnoveerd is en het nu een hele grote stap is.

Ook het direct communiceren met een klant is naar mijn idee niet altijd goed. Als stagiaires de klant in hun MSN lijst hebben staan en constant zitten te chatten over requirements, dat is niet echt efficient. De requirements wisselen namelijk weleens en het formaat ervan is ook niet denderend. In die gevallen heb je gewoon een projectleider nodig die "nee" durft te zeggen en kan inschatten wanneer hij dat moet doen.

Ik moet hierbij wel zeggen dat ik dit op mijn eigen ervaringen baseer en het ergens anders (hopelijk) beter kan zijn.

[Verwijderd]

Documentatie is bij kleine bedrijven inderdaad vaak een ondergeschoven kindje. Bij een klein ontwikkelteam is de korte termijn ROI van documenteren niet zo groot, omdat de communicatielijnen heel kort zijn: snap je iets niet in een module van je collega, dan vraag je 't 'm even, hij zit tegenover je... Bovendien heb je er vaak i.v.m. deadlines en weinig resources doodgewoon de tijd niet voor.

Op langere termijn en wanneer het ontwikkelteam groeit merk je echter keihard dat die documentatie essentieel is, al is 't maar als beschrijvende comments in je code. Daarom heb ik een paar jaar terug (toen onze markt toch wat slapjes was) een inhaalslag gemaakt, en veel tijd besteed aan het documenteren van bestaande code.

Wij werken trouwens nooit met stagiaires in het ontwikkelteam. Ten eerste omdat we niet de tijd hadden om zo'n stagiaire goed te begeleiden, en ten tweede omdat je de code (in een productie omgeving) dan zo goed moet reviewen dat je 't net zo snel zelf kunt schrijven.
Stagiaires hebben dus ook geen klanten op hun IM lijst. Sterker nog, ik heb ook geen klanten op m'n IM lijst, al hebben wel veel klanten m'n email adres, en een paar m'n directe doorkiesnummer.
Ontwikkelaars moeten niet gestoord kunnen worden door instant messages die meestal niets te maken hebben met datgene waar ze op dat moment mee bezig zijn. Dat haalt ze uit hun concentratie, je moet switchen naar iets heel anders, en daarna moet je weer helemaal omschakelen naar de dingen waar je mee bezig was.
Mijn Skype staat dan ook altijd uit, totdat een collega die bij een klant zit me mailt of ik 'm even aan wil zetten omdat er een probleempje of een vraag is...

[JKVA]

Ik weet ook niet wiens idee dat MSN was. Het was in ieder geval gruwelijk irritant, maar wat doe je ertegen? Je kunt moeilijk die klant blocken, dat wordt ook niet gewaardeerd.

Verder kan het zijn dat ik nogal generaliseer m.b.t. kleine bedrijven, maar waarschijnlijk is het niet overal zo erg.