My Story

Getting into commercial programming I was initially shocked. Let me tell you my horror story about me and my customer Paul. Paul asked me to build a new feature for his website: Hi Frederik, I need you to build a search feature for my website. I need to validate that customers will actually use it, so please make me a good offer.

Commercial programming was shocking to me!

Since Paul was a longtime customer of mine, of course, I want to help him. Sure Paul, if I don’t build it extendable and skip automated testing it can be done both cheap and fast. But it will be a risk if it needs to expand in the future. Pauls agrees to the risk so I start coding. Fast forward a few months, Paul wants to expand the search feature: Hi Frederik, the search widget is a huge success! I need you to also integrate this new product category. But we don’t know how many more sales it will generate so again I must ask for you to implement it as cheaply as possible.

Paul’s request seems simple enough to implement, but it requires a few risky changes. Since I was very busy at the time I didn’t bother to confront Paul with the risks. After the new feature is deployed to production a bug strikes! Paul calls me: Frederik! The search shows the wrong products, it is costing us a lot of money, I trusted you to implement it without errors! I expect this to be fixed asap!

Bugs in production will keep you up at night!

After a heated discussion with Paul about the risks he accepted initially I ended up correcting the error and only charging half the price it actually cost to fix it to preserve the good relationship. After all it was me that caused the error. Fast forward a few months and Paul wants the feature to be expanded again, this time with many additional categories: Hi Frederik, We are selling more than ever because of the search widget and I need you to expand it with ten additional product categories! I know from last time that the state of the code is bad. I also know that a change of this size is going to introduce even more bugs than last time, so I don’t really want to go that way. The only option I see is to make a complete rewrite of the code, but that is going to be expensive and time-consuming. And Paul will not be happy with either. For me as a programmer it is a lose-lose situation, the customer trusted me to be professional and create a system that would support and grow with his business, and I failed. I have seen similar stories happen more often than I would like to. And it sucks, every time

I believe it is possible to create systems in such a way that we will never end up in a state where the best option is to do a complete rewrite. Software should be changeable so it can match the need of the business and not the other way around. But unfortunately, I often see that software is created in a way that makes it almost impossible to change. When we create code and compromise on quality it will come back to haunt us. Usually the reason we compromise is to save time, but in many cases the time saving is just an illusion. If we write the code using good practises we will usually not spend more time implementing it. After working with the mentality of creating shortcuts in my code and getting burned by it. I changed my approach to focus on quality and how to create code that can be extended per default. I was sick of not knowing when I would be called up in the middle of the night to fix a bug, or not be able to change my code to support a new requirement.

I want to teach developers how to gain confidence crafting code

I want to teach developers how to gain confidence crafting code that they can be proud of and can grow as the requirements change. My mission is to help with creating quality code that is maintainable in the long run.