Author Archives: Dirk

Stilte Ik Spreek

Leave a reply

This post is in Dutch

“Stilte, ik Spreek” door Sylvie Verleye is een boek over presentatie ervaringen van 30 vrouwen aan de top.

De volgende tips worden in detail toegelicht:

Tip 1: Leer het begin en het einde van je presentatie uit het hoofd
Tip 2: Voeg humor toe door voorbeelden en quotes
Tip 3: Kernboodschappen als geheugensteunen
Tip 4: Oogcontact en interactie met je publiek
Tip 5: Slides ondersteunen de presentatie en niet de spreker!
Tip 6: Durft te vereenvoudingen
Tip 7: Vraag feedback
Tip 8: Elevator Talk is hét presentatietype voor boardmeetings
Tip 9: De kracht van presentaties
Tip 10: Zoek actief het Podium op

Silverlight 4 In Action

Leave a reply

“Silverlight 4 In Action” by Pete Brown

Got me up to speed in less than a week.

97 Things Every Programmer Should Know

Leave a reply

Advice from 97 experts combined in one book full of wisdom is the one-line summary for “97 Things Every Programmer Should Know” by Kevlin Henney.

The book focusses on all aspects of software development.

The topics it covers are:

Bugs and fixes
Build and deployment
Code guidelines and code layout
Design principles and coding techniques
Domain thinking
Errors, error handling and exceptions
Learning, skills and expertise
Nocturnal and magical
Performance, optimization and representation
Professionalism, mindset and attitude
Programming languages and paradigms
Refactoring and code care
Reuse versus repetition
Schedules, deadlines and estimates
Simplicity
Teamwork and collaboration
Tests, testing and testers
Tools, automation and development environments
Users and customers

Junior Developers need a DoD-y!

Leave a reply

Junior developers have a hard time to answer the question whether something is done. They need DoD-y!

It contains two elements they have not a lot of experience with: estimating the remaining time to complete (ETC) and knowing when something is completed according to the company’s standards.

Both will come with time and often they are not experienced enough to understand all aspects of the work yet. Scrum solves this by requesting the team to create a Definition of Done (DoD).

Below an example of what this could look like;

A DoD focusses on task decomposition. “How to eat elephant” … “bit by bit”!

If you get an understanding on what to do, the estimation of the time needed will become easier as well.

Branching Strategy Explained In One Picture

Leave a reply

Normally you would start from a main TFS project called Trunk and immediately branch this into Dev. All development is done on Dev: developers check-in/check-out content.

After a certain period, groups of finished functionalities are merged into Trunk from Dev. This is done by the quality gate keepers i.e. architects, team leads, release managers after checking everything is ok.

When everything is ready to go into production a version branch, for example 1.0, is split off from Trunk and production hot fixes can be done on branches of these version branches, for example 1.0HF1 for 1.0. This to guarantee at any time, we can build and recreate any production version.

Nightly builds are run on Dev to create the latest build and on Trunk to create a latest stable build output. Normally only latest stables can be deployed in environments other than development i.e. test, quality and production.