Geplaatst op 8 January 2010, 12:28 door Mylène Reiners
in java, open source
Het valt me de laatste tijd steeds meer op, dat wij, ontwikkelaars, een enorm lui zootje zijn. Uiteraard zullen er uitzonderingen zijn, maar overdrijving wil wel eens helpen om een punt te maken.
Het komt best vaak voor dat mensen emails sturen met vragen die zonder enig probleem op het Internet te vinden zijn - soms duurt (volgens mij in elk geval) het schrijven van de email langer dan het zelf zoeken geduurd zou hebben...
Share this | 373 keer bekeken | 0 reacties
Het valt me de laatste tijd steeds meer op, dat wij, ontwikkelaars, een enorm lui zootje zijn. Uiteraard zullen er uitzonderingen zijn, maar overdrijving wil wel eens helpen om een punt te maken.
Het is geen ramp, maar de kans bestaat natuurlijk wel dat als er een keer een echt belangrijke vraag komt, daar maar half naar gekeken wordt - de afzender vraagt immers altijd naar de bekende weg. Jammer.
Misschien een goed voornemen voor 2010 om eerst even zelf na te denken voor je hulp inroept?
En uiteraard (voor de ontvanger) om eraan te denken dat iemand kan veranderen, en niet altijd met onzinvragen hoeft te komen...
En uiteraard (voor de ontvanger) om eraan te denken dat iemand kan veranderen, en niet altijd met onzinvragen hoeft te komen...
Een tweede punt waar ontwikkelaars regelmatig de fout in gaan, is in het gebruik van de (door mij zo gewaardeerde) Code Inspection Tools (Checkstyle, PMD, Findbugs etc.).

Stel, je hebt een stuk code geschreven, en ineens komt je architect (of lead developer, of klant of....) met het onzinnige idee om Code Inspection Tools in te zetten. Je doet een controle met Checkstyle, en je hebt een paar duizend warnings.
Kun je twee dingen doen: de warnings die het vaakst voorkomen uitzetten in je configuratie file (dat is in elk geval een heel snelle manier om minder warnings te krijgen....). Je zou ook je IDE (Eclipse is daar in elk geval erg goed in) zo kunnen instellen dat de meeste zaken automatisch goed gezet worden (met format source bijv.), en de overige warnings oplossen...
Goed voornemen in dit kader is dus niet meer meteen de eerste optie te kiezen....
Om toch even mijn stokpaardje van stal te halen (zie een hoop andere blogposts): Goed voornemen 3: Nadenken voordat je iets doet (denk aan code schrijven, code kopiëren etc. - maar het gaat natuurlijk veel verder dan alleen code)...
Drie voornemens zijn meer dan genoeg... Als je er een of twee kunt volhouden, petje af!
Share this | 373 keer bekeken | 0 reacties
Reageer
Top artikelen




