Karl van Heijster

Karl van Heijster

Software developer, philosopher, testing enthusiast

Nijmegen, The Netherlands


Philosopher Ludwig Wittgenstein famously said: “What can be said at all can be said clearly; and what we cannot talk about we must pass over in silence.” Karl van Heijster firmly believes that this holds every bit as much for code as for conversation.

Karl is a software developer at Cito, one of the world’s leading organizations in the field of developing assessment tests. His developer journey revolves around continuous, iterative improvement. He has a Master’s degree in Philosophy, so even though he is pretty knowledgeable on the subject of code and communication, he knows he knows nothing.

Karl chronicles his observations on the world of software development every week at www.karlvanheijster.com (in Dutch).

Area of Expertise

  • Information & Communications Technology


  • Software Development
  • Philosophy
  • TDD
  • Testing
  • .NET
  • Code

The art of the pull request

Do you ever grumble when a team mate asks you to review their pull request? And be honest: have you ever approved one just to get rid of the hassle? Then this session is for you!

Many developers see code reviews as an annoying interruption to their work. But being able to properly assess a code change is essential to maintain the quality of your codebase. Fortunately, this process does not have to be painful.

At the end of this session you will know what questions to ask for a successful code review – and how to convey this information as effectively as possible in your PR.

A team that masters the noble art of the pull request prevents bugs and technical debt. Such a team can concentrate on what matters most: delivering value for your customer!

Always up to date documentation with maximally descriptive tests

Have you ever cried out: what the hell does method/class/module do?! Then this talk is for you. It turns out, not all code is self explanatory. Oftentimes, you’ll need more than the code itself to get a good grasp on it – you need functional documentation.

Now, nobody likes writing documentation – and for good reason! Writing and maintaining traditional docs takes up a lot of time and energy while offering little added benefit. So no, you shouldn’t write extensive specification documents – you should write better tests. By paying some extra attention to their scope and readability, you can transform your tests from a simple validation mechanism to an authoritative source of information for developers.

At the end of this session, you’ll know how to write readable tests that greatly improve the development speed of you and your team by codifying your application’s specs. This talk is for all developers who have been burned too many times by incorrect or altogether missing documentation.

As an added benefit, you’ll learn how to write tests that only break when requirements change, facilitating continuous refactoring.

Why testers should review code

It sounds like a law of nature: coders code and testers test. But this division of labor leads to inefficient work processes with long feedback cycles. To guarantee quality and speed of the development process, automated testing must become a first class citizen for the entire team.

Testers and coders will have to work together better. Testers need to learn to read code, coders must incorporate testing into their development flow. Code reviews are excellent moments when they can ask each other the ultimate question: does this code meet the requirements? And do we have a set of tests to prove it?

At the end of this session you will know how to encourage a team to write better code faster and more consistently – and how to save both testers and coders a lot of work!

Testing: A philosophical retrospective

First, you code, then you test: it does not happen often that such an obvious idea harbors so many misconceptions. What assumptions underlie this idea? And what happens when you critically examine them? – Then your notion of software development changes dramatically.

In this session I sketch out how testing helped transform my team from cynical and struggling to motivated and high-performing. – Who tests? How? When? And above all: why? Over the years, we have had to revise our answers to all these questions.

At the end of this session, you will be aware of some ingrained patterns in the way you develop and test software. Critical reflection on those patterns will be the first step towards improvement.

Karl van Heijster

Software developer, philosopher, testing enthusiast

Nijmegen, The Netherlands


Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top