Kennisdeling op het werk

[Verwijderd]

Aangezien wij hier op het werk met een redelijke bende programmeurs beginnen te zitten van allerlei slag (schoolverlaters, mensen die lang niet meer geprogrammeerd hebben, mensen met weinig werkervaring,...) had ik vorige keer bij de baas geopperd voor meer te doen rond kennisdeling. Omdat ik zie dat zowel bij mezelf als bij de collega's veel dezelfde fouten worden gemaakt.

Nu was hij hier wel voor te vinden voor zoiets 1 of 2 keer op de maand te doen maar hij wou hier wel een betere uitwerking van zien hoe dit praktisch op te lossen. Zelf had ik gedacht dat er soms iemand uitleg gaf over zijn werkwijze, samen code review van bepaalde stukken code, .. Maar zou graag weten of en hoe andere bedrijven hier mee omgaan.

Het zou dus vooral gaan voor elkaar wat te helpen in het zoeken van de beste oplossingen van problemen, best practices en van die zaken, maar ook hoe sneller te programmeren, enz enz.

Zijn hier mensen die zoiets doen op het werk? en zoja, hoe?

[Megamind]

Wij hadden 1x per maand op vrijdag een meeting met alle ontwikkelaars waarbij 1 ontwikkelaar iets ging uitleggen. Kon zijn over LINQ, Sqlserver, .NET 4.5 etc, gewoon dingen om je een beetje bij te brengen. Presentatietje maken en klaar.

[alienfruit]

Verder kan je natuurlijk ook een wiki bijhouden. Maar goed, die leest vervolgens toch niemand Ik vergeet er altijd in te kijken

[DrivinUCrazy]

Je kunt het doen met presentaties. Denk bijvoorbeeld aan een review van bepaalde hardware of software. De resultaten daarvan kun je presenteren.
Ook kun je bepaalde vraagstukken extra uitlichten, bijvoorbeeld hoe de beveiliging in een bepaalde toepassing is geregeld en waarom dit zo is gedaan.

Bij het bedrijf waar ik afstudeerde hadden ze ook een wiki voor op het intranet staan. Dat werkte best goed.

Dat idee heb ik daarna bij mijn volgende werkgever ook geopperd. De collega's waren wel enthousiast, maar ik ben daar weggegaan voor het van de grond was gekomen.
En dat terwijl je er niet zo gek veel voor nodig hebt; een simpel pc'tje, XAMP en een wiki-pagina zoals WikiMedia. Het probleem zit hem vooral in de bereidheid en discipline van de medewerkers om de wiki te vullen en te raadplegen.

Dat laat me eraan denken, ik heb nog ergens een thin-client staan. Ik ga voor mezelf weer eens een wiki opzetten.

[KirovAir]

Wij hebben één keer per maand een 'technische meeting'. Allemaal een paar uurtjes (betaald) overwerken en diegene die wat nieuws heeft geleerd, of iets wilt laten zien heeft daar dan de gelegenheid voor. Vaak een nieuwe versie van ASP, een nieuwe manier van werken, of code optimalisaties. Werkt tot nu toe heel goed.

[EnnaN]

Het probleem van een wiki is dat het als naslag misschien wel werkt (mits dicipline enzo wat lang niet altijd te realiseren is volgens mij), maar wat de TS ook wil, is dingen als "code review" en andere tips die minder makkelijk pro-actief op te zoeken zijn: een soort "je wist niet dat je het niet wist, maar daarom vertel ik je het". Anders moet je elke week de hele wiki doorlezen.,

[CMG]

Af en toe een dagje extreme programming? Met z'n 2e achter een machine, een tikt, ander denkt mee/verteld zijn visie/oplossing, zo leer je van elkaar.

[Janoz]

Als je het over kennisdeling icm programmeurs hebt neem ik aan dat je wilt voorkomen dat iedereen op een eilandje bezig is en dat je uiteindelijk toe wilt naar een situatie waarbij kwaliteit en stijl uniform zijn. Hierdoor kan elke programmeur in principe elk stuk code binnen de organisatie oppakken en daarmee aan de slag gaan. Hoe makkelijk dit gaat is in eerste instantie voornamelijk afhankelijk van hoe jullie werkzaamheden zijn. Zijn er 1 of 2 grote producten waar iedereen aanpassingen aan doet of zijn er juist een heleboel projecten waar telkens maar 1 programmeur aan werkt. In het eerste geval is peer programming en code review bijvoorbeeld een stuk makkelijker te verantwoorden (aangezien iedereen toch al op dat project zit).

Een open omgeving is het belangrijkste, maar daar kom ik zo op. Je zult iig moeten beginnen met duidelijk voor ogen hebben wat kwaliteit nu eigenlijk is en hoe uniform je het wil hebben. Dat begint iig met je code style afspreken (je weet wel, dat geneuzel met accolades op dezelfde regel en hoever je inspringt, maar vervolgens ook wat de maximale lengte van een regel en/of een functie is) en daarna ook enforcen. Hiervoor kun je tooling gebruiken. Dan komt eigenlijk het belangrijkste. Een ambiance creëren waarin het in orde is voor iedereen om iedereen aan te kunnen spreken op hun code zonder dat dit escalerende conflicten geeft.

Je kunt bergen wiki's neerzetten en duizenden guidlines afdwingen, maar wanneer de junior niet aan de senior kan/durft te vragen waarom een bepaald probleem op een bepaalde manier opgelost is dan heeft het helemaal geen zin. Tooling zoals wiki's en metrics zijn niet meer dan dat: gereedschap. Het blijft uiteindelijk om de mens gaan die dat gereedschap moet gebruiken.

[YopY]

Sowieso: Werk nooit alleen. Deel een bureau, werk met z'n tweeën aan een project, en communiceer. Zorg er ook voor dat je regelmatig van partner wisselt (noem het partnerruil, kun je er grapjes over maken).

Wat wij doen (consultancybedrijf, circa 100 werknemers in NL, circa 35-40 developers): elke twee weken op dinsdag van 4 - 9 uur op kantoor aanwezig zijn, kennisdeling. Het is tegenwoordig een soort van mini-conferentie; vier tracks van elk 1 - 4 uur, waarbij presentaties, workshops, of gewoon samenzitten/brainstormen gecombineerd worden.

Het belangrijkste hierbij: het is verplicht, en het wordt niet betaald als overwerk; je wordt gewoon geacht er te zijn, en gepushed om het programma vol te krijgen. En ja, dit werkt. Voor de werkgever kost het gemiddeld twee 'billable' uren per persoon (100 * 2 * € ~(80 - 150)), plus een aantal uren voorbereiding indien nodig/gevraagd, plus eten; een relatief grote investering, maar wat je ervoor terugkrijgt is een team van enthousiaste medewerkers met zowel diepe als brede kennis over van alles dat door de werkgever weer verkocht kan worden.

[Verwijderd]

Ok, ff op alles proberen reageren :-)

Megamind schreef op maandag 13 augustus 2012 @ 09:54:
Wij hadden 1x per maand op vrijdag een meeting met alle ontwikkelaars waarbij 1 ontwikkelaar iets ging uitleggen. Kon zijn over LINQ, Sqlserver, .NET 4.5 etc, gewoon dingen om je een beetje bij te brengen. Presentatietje maken en klaar.

1 maal per jaar hebben we voor de gehele afdeling een opleiding van een week. Daarkomen meetal de nieuwste zaken wel naar voren. Tijdens zo een week is ook het idee ontstaan om iets meer aan het delen van kennis te gaan doen. Omdat we hier in het opleidingslokaal dichter bij elkaar zitten is het veel makkelijker om inkijk te hebben hoe de collega's werken en steek je iets op van elkaar. Enkel willen we dit nu uitbreiden omdat maar 1 zo'n moment op het jaar wat weinig is.

alienfruit schreef op maandag 13 augustus 2012 @ 09:59:
Verder kan je natuurlijk ook een wiki bijhouden. Maar goed, die leest vervolgens toch niemand Ik vergeet er altijd in te kijken

Wiki hebben we geprobeerd. Goed als naslagwerk, maar niet goed om bepaalde denkwijzen over te brengen. ook worden bij problemen veel sneller google geraadpleegd dan een interne wiki.

KirovAir schreef op maandag 13 augustus 2012 @ 10:08:
Wij hebben één keer per maand een 'technische meeting'. Allemaal een paar uurtjes (betaald) overwerken en diegene die wat nieuws heeft geleerd, of iets wilt laten zien heeft daar dan de gelegenheid voor. Vaak een nieuwe versie van ASP, een nieuwe manier van werken, of code optimalisaties. Werkt tot nu toe heel goed.

Hoe gaat dit bij jullie in zijn werk? Zo'n manier van werken is ook al iets wat ik zelf in het hoofd had. Enkel is de praktische uitwerking daarvan me nog niet echt volledig duidelijk.

CMG schreef op maandag 13 augustus 2012 @ 10:13:
Af en toe een dagje extreme programming? Met z'n 2e achter een machine, een tikt, ander denkt mee/verteld zijn visie/oplossing, zo leer je van elkaar.

We proberen het eigenlijk open te trekken naar het gehele team. (14 tal programmeurs). We zijn nu in kleinere teams verdeeld maar dat is meer een logische onderverdeling (per onderdeel van het bedrijf waarvoor gewerkt wordt)

Janoz schreef op maandag 13 augustus 2012 @ 11:32:
Als je het over kennisdeling icm programmeurs hebt neem ik aan dat je wilt voorkomen dat iedereen op een eilandje bezig is en dat je uiteindelijk toe wilt naar een situatie waarbij kwaliteit en stijl uniform zijn. Hierdoor kan elke programmeur in principe elk stuk code binnen de organisatie oppakken en daarmee aan de slag gaan. Hoe makkelijk dit gaat is in eerste instantie voornamelijk afhankelijk van hoe jullie werkzaamheden zijn. Zijn er 1 of 2 grote producten waar iedereen aanpassingen aan doet of zijn er juist een heleboel projecten waar telkens maar 1 programmeur aan werkt. In het eerste geval is peer programming en code review bijvoorbeeld een stuk makkelijker te verantwoorden (aangezien iedereen toch al op dat project zit).

Een open omgeving is het belangrijkste, maar daar kom ik zo op. Je zult iig moeten beginnen met duidelijk voor ogen hebben wat kwaliteit nu eigenlijk is en hoe uniform je het wil hebben. Dat begint iig met je code style afspreken (je weet wel, dat geneuzel met accolades op dezelfde regel en hoever je inspringt, maar vervolgens ook wat de maximale lengte van een regel en/of een functie is) en daarna ook enforcen. Hiervoor kun je tooling gebruiken. Dan komt eigenlijk het belangrijkste. Een ambiance creëren waarin het in orde is voor iedereen om iedereen aan te kunnen spreken op hun code zonder dat dit escalerende conflicten geeft.

Je kunt bergen wiki's neerzetten en duizenden guidlines afdwingen, maar wanneer de junior niet aan de senior kan/durft te vragen waarom een bepaald probleem op een bepaalde manier opgelost is dan heeft het helemaal geen zin. Tooling zoals wiki's en metrics zijn niet meer dan dat: gereedschap. Het blijft uiteindelijk om de mens gaan die dat gereedschap moet gebruiken.

Codelines zijn er, maar worden veel te weinig afgedwongen. (Is ook iets waarvoor die kennisvergaderingen zouden kunnen gebruikt worden, code lines meegeven, interne framework meer promoten,...)

We maken in het bedrijf eigenlijk alle software die maar nodig is. Meestal zijn dit kleinere projecten waar 1 programmeur aan werkt en dan binnen zijn eigen team (elk team zit op een bepaald deel van het bedrijf). Er is wel overlapping tussen de teams maar niet zoveel. Iedereen kan eigenlijk hier vragen stellen aan iedereen. Enkel wordt het niet gedaan omdat er zo iets heerst van, we moeten goed doorwerken en vragen stellen kost tijd. Daarom dat we naar 1 contactpunt zouden willen gaan op bepaalde tijdstippen waar het mogelijk is om tijd te "verdoen" aan vragen stellen.

Je gaat minder rap iemand zijn code gaan nakijken als je er nooit moet in zijn. Das is natuurlijk het grootste nadeel aan het principe 1 programmeur == 1 applicatie.

In ieder geval al bedankt voor de reacties / het meedenken

[KirovAir]

Verwijderd schreef op maandag 13 augustus 2012 @ 12:06:


Hoe gaat dit bij jullie in zijn werk? Zo'n manier van werken is ook al iets wat ik zelf in het hoofd had. Enkel is de praktische uitwerking daarvan me nog niet echt volledig duidelijk.

Wat bij ons voordelig is, is dat we binnen het bedrijf programmeerstandaarden hanteren ongeacht de kennis. Je zit dus enkel één (of meerdere) stadia lager, of hoger dan de ander maar je snapt wel de basisblokken van elkaars programmeerwerk.

Iedereen die ook maar iets te vertellen heeft geeft dat van te voren aan via een mailtje, en zo krijgen we een week van te voren een mailtje over wie wat te vertellen heeft. Als er geen nieuwe ontwikkelingen zijn in .NET land gaat het vaak over updates in een bepaalde applicatie (een async AJAX grid implementatie ipv een normale, of een implementatie van SignalR.) en dan een kleine demonstratie over de gebruikte code en technieken. Sommige verhalen ken je al, alleen zo blijft de kennis wel verfrist worden. We hebben hier ook een redelijke informele sfeer, waardoor programmeerverhalen/problemen waar de programmeurs tegen aan liepen ook leuk om te horen zijn.

[NMe]

Wat wij doen is actief werken aan een sfeer waarin mensen "hoe zou jij ... aanpakken?" vragen. Als het iets is dat voor meer mensen boeiend kan zijn wordt het whiteboard er du moment bij gehaald en maken we er een leermomentje voor iedereen van. IMO werkt dat beter dan elke X tijd een vast leermoment, want dan ga je geforceerd op zoek naar dingen die mogelijk interessant zijn, en dat pakt vaak niet uit in een optimale manier om wat nieuws te leren.

[Janoz]

Verwijderd schreef op maandag 13 augustus 2012 @ 12:06:
[...technische meeting...]
Hoe gaat dit bij jullie in zijn werk? Zo'n manier van werken is ook al iets wat ik zelf in het hoofd had. Enkel is de praktische uitwerking daarvan me nog niet echt volledig duidelijk.

Dat is eigenlijk heel simpel. Gewoon een middag in de maand agenda's blokkeren en vervolgens een lijst punten bijhouden die iedereen aan kan vullen. Dit kan een onderwerp zijn dat diegene wil bespreken, of iets zijn waar diegene een presentatie(tje) over wil geven. Zorg wel dat je 1 iemand de verantwoordelijkheid geeft over het bijhouden van de agenda. Gedeelde verantwoordelijkheid is immers geen verantwoordelijkheid.

We proberen het eigenlijk open te trekken naar het gehele team. (14 tal programmeurs). We zijn nu in kleinere teams verdeeld maar dat is meer een logische onderverdeling (per onderdeel van het bedrijf waarvoor gewerkt wordt)

Die eilandjes zou je moeten doorbreken. Het zal inderdaad zo zijn dat elk van die eilandjes veel domein kennis heeft, maar je moet zorgen dat de technische kennis overal hetzelfde is. Nu heb je domein en technische kennis op elk eilandje zitten. Wissel gewoon af en toe een beetje uit. Dat kost in het begin meer omdat iemand in het andere deel ingewerkt moet worden, maar levert op de lange termijn meer op omdat de uitwisselaars de kennis overdragen en er dus niet (onbewust) overal het wiel opnieuw uitgevonden wordt.

Codelines zijn er, maar worden veel te weinig afgedwongen. (Is ook iets waarvoor die kennisvergaderingen zouden kunnen gebruikt worden, code lines meegeven, interne framework meer promoten,...)

Niet afgedwongen guidelines zijn nog slechter dan geen guidelines. Er is genoeg tooling om de guidelines te controleren. Neem bijvoorbeeld een tool als Sonar. Dat is een aggregatie van vele metrics tools waarmee je in 1 keer een overzicht kunt krijgen van de totale kwaliteitsstaat van je applicatie. Zorg vervolgens dat die scores ook onderdeel worden van je acceptatie criteria.

We maken in het bedrijf eigenlijk alle software die maar nodig is. Meestal zijn dit kleinere projecten waar 1 programmeur aan werkt en dan binnen zijn eigen team (elk team zit op een bepaald deel van het bedrijf). Er is wel overlapping tussen de teams maar niet zoveel. Iedereen kan eigenlijk hier vragen stellen aan iedereen. Enkel wordt het niet gedaan omdat er zo iets heerst van, we moeten goed doorwerken en vragen stellen kost tijd.

Doormodderen kost ook tijd. Een vraag stellen met daaropvolgend een korte discussie lijkt misschien verloren tijd te zijn. Maar wanneer 3 mensen in stilte hetzelfde probleem op 3 verschillende manieren aan het oplossen zijn ben je meer manuren aan het verbranden, nog los van de technical debt die wordt geïntroduceerd.

Daarom dat we naar 1 contactpunt zouden willen gaan op bepaalde tijdstippen waar het mogelijk is om tijd te "verdoen" aan vragen stellen.

Dat werkt niet. Als je iets ziet heb je dan een vraag. Als je moet wachten tot het einde van de week/maand ben je alle context kwijt (als je de vraag überhaupt onthouden hebt) Daarnaast werkt iets dergelijks beter 1 op 1. Als je dat met een club van 14 man bespreekt hebben in eerste instantie 12 mensen die het niks interesseert.

[RocketKoen]

Hoe wij het doen:
Als je iets gemaakt hebt, laat je het "reviewen" door een collega. Die kan jou tips geven over hoe iets beter kan. En andersom, als jij iets hebt gedaan dat beter is wat hij gedaan zou hebben, leert hij weer iets.
Dwingt je ook meteen om je code zo te schrijven dat iemand anders het kan begrijpen. Een van de eerst lessen die je leert, maar bij veel mensen ook het 1e dat ze weer vergeten.

[YopY]

Vragen stellen zou je ook via een mailinglijst kunnen doen, gewoon een [e-mail] adres openen waar je alle vragen en opmerkingen (evenals bijvoorbeeld interessante links e.d.) naartoe kunt sturen. Hebben we ook, toevallig, komen wel eens interessante zaken langs.

[Not Pingu]

YopY schreef op maandag 13 augustus 2012 @ 11:51:
Wat wij doen (consultancybedrijf, circa 100 werknemers in NL, circa 35-40 developers): elke twee weken op dinsdag van 4 - 9 uur op kantoor aanwezig zijn, kennisdeling. Het is tegenwoordig een soort van mini-conferentie; vier tracks van elk 1 - 4 uur, waarbij presentaties, workshops, of gewoon samenzitten/brainstormen gecombineerd worden.

Het belangrijkste hierbij: het is verplicht, en het wordt niet betaald als overwerk; je wordt gewoon geacht er te zijn, en gepushed om het programma vol te krijgen. En ja, dit werkt. Voor de werkgever kost het gemiddeld twee 'billable' uren per persoon (100 * 2 * € ~(80 - 150)), plus een aantal uren voorbereiding indien nodig/gevraagd, plus eten; een relatief grote investering

Staat je werkgever er dan echt achter? Want dit klinkt meer als: 'zolang het ons maar niks kost'. Een halve dag vragen van je personeel voor iets wat ook het bedrijf wat oplevert geeft niet het idee dat men er echt heil in ziet.

[Cartman!]

Gewoon tijdens het werken actief met elkaar in discussie over oplossingen/werkwijzen/ideeen werkt erg prettig. Af en toe houden we een 'code review sessie' waarin iemand kort iets presenteert, daarna bespreken we de implementatie. Meestal op vrijdagmiddag een uurtje.

[H!GHGuY]

Ik ben 100% voor code reviews:
1) bugs worden gespot
2) coding guidelines worden beter enforced
3) zowel de reviewee als de reviewer (!) hebben de opportuniteit om bij te leren
4) automatisch "delen" van code ownership (zonder elkaar dit toe te wensen, moet je je altijd afvragen: wat als X morgen tegen een boom rijdt? Welke gevolgen heeft dit voor het bedrijf?). Code die review gehad heeft is makkelijker over te nemen door de reviewers
5) na verloop van tijd gaat de code kwaliteit van de volledige groep omhoog (aangezien iedereen onrechtstreeks leert van de sterksten in de groep) - volgt uit puntje 3
6) nog-niet gereviewede code wordt beter (de reviewee wil die "lastige vragen" over "waarom die TODO er nog staat" of "waarom dat stuk code zo belachelijk inefficient is geschreven" of "waarom dat stukje framework code die 300LOC vervangt door 1 line niet is gebruikt" vermijden) - Dit betekent ook dat code review zichzelf na verloop van tijd minder relevant maakt als tool om code kwaliteit te verbeteren.
(Dit wordt ook aangehaald als reden waarom code kwaliteit in grote open-source projecten met behoorlijke review, zoals de linux kernel, beter is)

De keerzijde van code reviews:
1) management moet erachter staan (maar met de punten hierboven moeten zij wel te overhalen zijn)
Anders wordt er niet gereviewed en wordt de code niet aangepast of krijg jij de blamage dat je je collega's als het ware pest.
2) de programmeurs moeten ervoor openstaan (of aangepord worden door collega's en management)
3) de ego-paradox (zoek maar even 'paradox' op deze: http://programmers.stacke...f-spaghetti-code-what-now) - de volledige reactie is misschien ook hier wel deels van toepassing.

Mocht management het toch allemaal niet zo goed weten, dan kun je nog altijd proberen om het van onder uit te laten groeien. Ga gewoon regelmatig een collega vragen of hij een stukje van je wil reviewen en reageer heel ontvankelijk voor commentaar (maar ga ook in een productieve discussie waar nodig). Met wat geluk zijn er enkele collega's die dit overnemen en jou of andere collega's om review vragen. Toon de reviewer ook het resultaat van zijn input (maw feedback op de feedback).

Er zijn tools te vinden die code review makkelijk maken (bvb code collaborator, crucible, ...) en die mogelijk ook integreren met jullie source control systeem.

[ Voor 28% gewijzigd door H!GHGuY op 13-08-2012 18:20 ]

[Verwijderd]

Ben zelf ook voor code reviews, misschien kun je een maandelijkse code review day kan organiseren.

Dagindeling:
- Eerste helft van de dag krijgt iedereen een stuk code die hij of zij voor de lunch moet bekijken. In overleg is de code anoniem of niet. Hoeft echt niet 100% nagekeken, gewoon indrukken, voorbeelden eruit vissen, algehele indruk. Dit zet je vervolgens in enkele slides (zeg max 3 pp).
- Tweede helft van de dag gebruik je om aan elkaar te laten zien wat je gevonden hebt, wat er beter kan, en om input te vragen.Je hoeft niet echt te presenteren; de groep kan zelf ook eerst commentaar leveren op wat er getoond wordt, misschien dat daar nog veel meer opmerkingen uit voortkomen dan wat je oorspronkelijk ertoe zette om het in de slide te plaatsen. Dit maakt het lekker laagdrempelig (mijn ervaring is dat niet alle coders even makkelijk presenteren, ikzelf ben er daar ook 1 van).
- Rest van de tijd kan gebruikt worden om code daadwerkelijk ook te verbeteren, een testje toe te voegen om later refactoring mogelijk te maken, verzin het maar. Er zal genoeg uitrollen mag ik hopen. Het doel is om alle rot zo zichtbaar mogelijk te maken (want hoe je het went of keert, ook code gaat langzaamaan beschimmelen).

Voorbereiding:
- Stukken code die opgeschoond mogen worden maar waar nooit iemand aan toekomt. Moet je even voor rondvragen en vantevoren even kijken wie, hoe en wat en mogelijk anonimiseren als er wat onderlinge angst is. Het beste is als er een cultuur heerst waar fouten gemaakt mogen (en zelfs moeten) worden gemaakt, alleen daar leer je van.
- Beamer
- Ruimte. Probeer ergens anders te gaan zitten, bij elkaar, dan heb je echt het idee van collectief samen aan verbetering te werken. Voor kennisdeling moet je vertrouwen onderling kweken, dit lukt alleen face-to-face.
- Snacks en fris

Afhankelijk van hoe uitgebreid je het opzet hoeft het geen hele dag te duren, maar 1 dag per maand besteden aan kwaliteitsverbetering zou voor een organisatie toch echt niet teveel moeten zijn. Verkoopt ook lekker aan klanten: "wij doen aan continue kwaliteitsverbetering en kennisdeling", hmm, lekker sappig.

Zou het op vrijdag organiseren met daarna een borrel om weer vriendjes met elkaar te worden

[ Voor 4% gewijzigd door Verwijderd op 14-08-2012 11:53 ]

[Cartman!]

Van een situatie een paar jaar geleden waarin iedereen op een eigen eilandje zat te werken met eigen technieken, tools en voorkeuren zijn we nu heel dicht bij dat iedereen op dezelfde manier werkt. Als iemand 2 weken op vakantie is (of tegen die boom aanrijdt...) dan is het veel makkelijker overnemen. Het is veel beter voor het groepsgevoel en je hebt meer het idee dat je het met elkaar doet. Elkaar om advies vragen wordt leuk en leerzaam ipv. dat het voor losers is, met z'n allen word je er beter van

[Verwijderd]

Nogmaals allemaal bedankt voor de feedback. Ik ga dit allemaal eens rustig op papier zetten en hiermee bij mijn baas langslopen. Hopelijk krijgen we dit hier een beetje van de grond.

Op sommige zaken is het wel moeilijk een oplossing vinden. Zo zijn de bureau indelingen niet ideaal hier (van de 4 teams zitten er maar 2 samen) wat ff snel langslopen toch wel bemoeilijkt. Om een of andere reden is een vraag stellen waarvoor je door een deur moet stappen moeilijker :-).

Ik denk dat het beste is dat we beginnen in stapjes, eerst meer onze code standaarden proberen doorduwen, dan misschien eens rustig beginnen met af en toe code review. En dan maar hopen dat we bij de rest van de bende ook genoeg enthousiasme te zien krijgen :-)

[CMG]

is het dan geen optie om de devvers in een hok te gooien?

[H!GHGuY]

Verwijderd schreef op dinsdag 14 augustus 2012 @ 11:51:
Ben zelf ook voor code reviews, misschien kun je een maandelijkse code review day kan organiseren.

Really... No!

Code reviews is niet iets wat je ff "later" doet; dan gebeurt het niet:
- veel te veel code ineens (denk eens na hoeveel code 10 developers op een maand wel niet schrijven)
- door alles op 1 hoop te gooien (ipv kleine stukjes) is het niet verteerbaar
- uitstel = afstel
- een maand later heb je wel weer "beter" dingen te doen

Code reviewen is iets wat je dagelijks doet. Wij hebben een scriptje dat integreert met onze source control en onze code review tool: na het committen (maar bij systemen als git/mercurial, liefst voor het pushen) even tooltje draaien. Deze genereert een XML-file op maat van de code-review tool.
Alles bij elkaar is het dus: 2 tooltjes draaien en dan op de WebUI van de review tool even aan klikken wie moet reviewen - 5 minuutjes werk dus. (Voor sommige stukken code zijn zelfs vaste reviewers).
Vervolgens krijgen reviewers een mailtje met de uitnodiging te reviewen (of ze kijken gewoon in hun review queue). Aanpassingen van review remarks worden gewoon aan bestaande reviews toegevoegd tot iedereen akkoord is. Bij systemen als git/mercurial kun je na approval pushen.

Code review is iets wat je in je developer cultuur moet inbakken. Iedereen reviewt, iedereen wordt gereviewed.
Hoe groter de groep, hoe formeler je typisch reviews doet (en waarschijnlijk ook: hoe meer budget er is om degelijke tooling te gebruiken). Wij komen ook van een punt waarin een code review een meeting van een uur was waarin de reviewee door de code liep en wat uitleg gaf (liefst in een logische volgorde) aan de reviewers, die dan vragen stelden en opmerkingen gaven.
Ook nu, met de review tool, is het soms nodig om na een ronde opmerkingen even samen te zitten en violen te stemmen. De review tool maakt het gros van de reviews minder tijdrovend en beperkt de uren samenzitten/discussie tot die punten waar het echt nodig is.

[ Voor 17% gewijzigd door H!GHGuY op 16-08-2012 09:23 ]

[Mormeldier]

Wij hebben binnen het bedrijf geen officiële processen hiervoor, maar het type projecten wat wij doen vereist dat iedereen binnen het project precies weet wat de anderen doen. Kennisoverdracht is vitaal.

In het project waar ik nu aan werk gebruiken we een losse agile methode. We werken met drie programmeurs aan een bootloader, kernel, platform en apps. Elke twee à drie weken verander je van onderwerp, dus waar ik vorige week nog aan de kernel werkte heeft een collega dat nu overgenomen. Daarbij toetst hij mijn documentatie op de wiki, reviewt en test hij mijn code en hebben we verschillende gesprekjes over zijn vragen. Zo hebben we goede kennisoverdracht, kwaliteitscontrole én leer je elkaar af en toe nog eens wat.

Dit kan natuurlijk alleen als je baas het ermee eens is, want het heeft wel impact op de looptijd van een project.

[scorpie]

H!GHGuY schreef op donderdag 16 augustus 2012 @ 09:13:
[...]


Really... No!

Code reviews is niet iets wat je ff "later" doet; dan gebeurt het niet:
- veel te veel code ineens (denk eens na hoeveel code 10 developers op een maand wel niet schrijven)
- door alles op 1 hoop te gooien (ipv kleine stukjes) is het niet verteerbaar
- uitstel = afstel
- een maand later heb je wel weer "beter" dingen te doen

Code reviewen is iets wat je dagelijks doet. Wij hebben een scriptje dat integreert met onze source control en onze code review tool: na het committen (maar bij systemen als git/mercurial, liefst voor het pushen) even tooltje draaien. Deze genereert een XML-file op maat van de code-review tool.
Alles bij elkaar is het dus: 2 tooltjes draaien en dan op de WebUI van de review tool even aan klikken wie moet reviewen - 5 minuutjes werk dus. (Voor sommige stukken code zijn zelfs vaste reviewers).
Vervolgens krijgen reviewers een mailtje met de uitnodiging te reviewen (of ze kijken gewoon in hun review queue). Aanpassingen van review remarks worden gewoon aan bestaande reviews toegevoegd tot iedereen akkoord is. Bij systemen als git/mercurial kun je na approval pushen.

Code review is iets wat je in je developer cultuur moet inbakken. Iedereen reviewt, iedereen wordt gereviewed.
Hoe groter de groep, hoe formeler je typisch reviews doet (en waarschijnlijk ook: hoe meer budget er is om degelijke tooling te gebruiken). Wij komen ook van een punt waarin een code review een meeting van een uur was waarin de reviewee door de code liep en wat uitleg gaf (liefst in een logische volgorde) aan de reviewers, die dan vragen stelden en opmerkingen gaven.
Ook nu, met de review tool, is het soms nodig om na een ronde opmerkingen even samen te zitten en violen te stemmen. De review tool maakt het gros van de reviews minder tijdrovend en beperkt de uren samenzitten/discussie tot die punten waar het echt nodig is.

Ik wilde het al gaan vragen maar gelukkig ben je me voor

Is het geen goed idee om een continuous integration server in te richten die automatisch na iedere check-in static analysis tools laat draaien en een rapportje genereert? Die static analysis tools checken niet alleen op coding standards, maar ook op complexiteit van je code bijvoorbeeld.

@TS kijk eens naar Sonar (www.sonarsource.org)

[Matis]

Wij hebben op de zaak tweewekelijks een R&D-meeting. Hierin worden de financiele toestanden toegelicht, vacatures en solliciaties besproken en bestaat de kans voor R&D-ers om hun vragen te stellen en/of hun zegje te doen.
Vaak proberen we dan ook één collega een kleine presentatie te laten geven over zijn expertise. We hebben nogal wat disciplines binnen R&D (PCB-ontwerp, FPGA, Baremetal C, GNU C en C++/ Qt ontwikkelaars).

Daarnaast hebben we een Wiki, maar niet die van wikimedia, maar een andere, waar ik nooit wat in gevonden krijg

Wij hebben sinds kort een Configuration Management-groepje opgericht. Hierin hebben we besloten code-review toe te gaan passen, coding-styles en flexelint.
Ook gaan we allemaal een versiebeheersoftware (Git) draaien, met een fine grained integratiemodel.

[ Voor 19% gewijzigd door Matis op 16-08-2012 09:54 ]

[dommerick]

Een Eat & Learn presentatie doet het ook altijd kort. Daar wordt gewoon een presentatie gegeven onder het genot van een gratis lunch.

[YopY]

Not Pingu schreef op maandag 13 augustus 2012 @ 17:04:
[...]


Staat je werkgever er dan echt achter? Want dit klinkt meer als: 'zolang het ons maar niks kost'. Een halve dag vragen van je personeel voor iets wat ook het bedrijf wat oplevert geeft niet het idee dat men er echt heil in ziet.

Het is de werkgever die het verplicht, . En het kost hun echt wel wat; zoals aangegeven, het begint 's middags om 4 uur, en de werknemers moeten er nog naartoe rijden, dus op zo'n dag raakt de baas gemiddeld 2,5 uur aan inkomsten mis. Daar komt nog het diner bij (geen idee hoe duur catering is), en de werknemers kunnen ook uren krijgen om te werken aan voorbereiding hiervoor.

[curvemod]

Ik denk dat je voor de grote lijnen al behoorlijk wat feedback gehad hebt, je zou voor de kleine vraagjes ook nog kunnen denken aan een interne microblog.

De voordelen daarvan zijn dat collega's soms beter de context van je probleem begrijpen en dat je er als organisatie achter komt hoe mensen bepaalde dingen doen. Als hier problemen door geconstateerd worden kan dit weer aanleiding zijn voor een wiki artikel of bv een workshop.

[Cartman!]

Wij werken met alle developers (front- en backend) in 1 grote open ruimte wat dus heel leuk werkt om kennisdeling mogelijk te maken. Iedere afdeling heeft zo een eigen ruimte, dus we worden niet lastig gevallen met designmeuk ofzo

[H!GHGuY]

scorpie schreef op donderdag 16 augustus 2012 @ 09:36:
[...]
Is het geen goed idee om een continuous integration server in te richten die automatisch na iedere check-in static analysis tools laat draaien en een rapportje genereert? Die static analysis tools checken niet alleen op coding standards, maar ook op complexiteit van je code bijvoorbeeld.

Daarmee creëer je nog geen kennisdeling...

[Janoz]

H!GHGuY schreef op vrijdag 17 augustus 2012 @ 10:03:
Daarmee creëer je nog geen kennisdeling...

Nee, maar wel een startpunt. Wanneer je bv daadwerkelijk automatisch de code standaard controleert kun je hem ook beter afdwingen. Rapportage kan als startpunt dienen voor het bespreekbaar maken zonder dat het gelijk persoonlijk wordt. Een tool is immers een objectieve buitenstaander.