Table of Contents generated with DocToc

Work guide


Get to the first production version with as little effort as possible

Right now I may think I know what I am doing. However, I really do not. For this reason, I should get to the first version with as little effort as possible. This means I should build the first production version of any project with (in order of importance):

As simple code as possible (simple beats DRY)

Simple code beats clever code - this is doubly true for the first version! Clever code may be easier to extend / adapt, but it is harder to fundamentally change. The likelihood is very high that I will have to fundamentally change the first version of any project.

As little code as possible

Right now I may think I know what I am doing, but I really don’t. Therefore I should get to the first version with as little effort as possible. This means I should not waste time on clever code.

Get to the first version with as little effort as possible.


Ubiquitous language

What is it?

In the words of Martin Fowler: “the practice of building up a common, rigorous language between developers and users”.

To put it more plainly:

A company must always ensure that developers use the same names and words to describe the business concepts as your developers.

Why is it so important?

One of my key takeaways from the amazing DDD book is that an Ubiquitous Language is one of the most important things to create and maintain in a software company. I have worked in companies where there was no Ubiquitous Language. It was not good.

How do you achieve it?

By making it an explicit requirement. And then doing the work to ensure it happens and stays that way.

Reviewing pull requests

Always be polite and friendly

A pull request is a place for friendly collaboration. It is not a battleground. Always be nice and friendly to each other.

Misunderstandings can very easily happen

Remember, it is very easy for misunderstandings to happen over a text-based medium. Something you write in a slightly annoyed tone might be read as a fiery insult by the receiver. Just dont do it.

Strong disagreements happen. It is best to solve these face-to-face, else over the phone, or lastly via synchronous chat.

Come to the best agreement you can. Then respectfully describe the different viewpoints and what the outcome of the discussion was.

Jokes are of course okay, but should be used with caution. This is also because of the risk of misunderstandings.


Agile is such an integral part of our work life today that it deserves its own section.

Daily standup

Daily standups are a very important tool in the agile workflow.


Any system is only as good as its documentation.


Clipboard history

I originally stumbled upon this as advice given by Jeff Atwood, the founder of Stack Overflow. I had never used a Clipboard history app before. Now, 3 years later, I would never, ever live without it.

The best one (as far as I know) for OSX is Alfred with the Powerpack addon.


Getting the right people on the bus

You should hire engineers for, in order of priority:

  1. Cultural fit
  2. Work Ethics / Gets shit done
  3. Raw intelligence
  4. Specific languages / skills (e.g. Java, DevOps, CI/CD experience)

Interview process