Do you want to code ‘by the book’?
By: Philip Englund
Tags: Software Architecture, Development, Learning To Code, Software Development

Photo by Sven Mieke on Unsplash

I remember what it was like to be completely new in programming.

I wanted to learn everything. Everything. And to do things the right way.

But the worst part is probably, I thought I had to.

But what’s the right way, really?

When I started my education to become a web developer, I deeply thought that there was such a thing as the ‘right’ way to code. But I quickly came to other conclusions.

So, what do I mean by code ‘by the book’?

Writing code by the book, to me, feels more like fixating around all the processes more than the purpose or goal. A fixation that there is a textbook example of how you should do it.

I remember how I, as well as the majority of my classmates, believed in this in the beginning. We were asking for the right solutions, how problems really should be solved.

This is partly no big surprise since most experienced workers in a lot of other fields of work have perfected their methods and ways of working, so one might easily think that you can be taught expert ways and book examples in this occupation also.

Don’t get me wrong, there’s a lot of things you could learn from experienced developers, but it’s a dangerous thing in this line of work to rely on others’ expertise solely because of their expertice in order to solve your problems.

So to this, I say no. Do not write code by the book.

Write code by the domain.

Or more specifically, write code by the domain you are working with right now. Your domain should dictate the code you write and at the very least how you write it. Why?

Because code is documentation, in a lot of ways.

“We’re not engineers! We’re writers!” — Robert Tublén (my main teacher)

The code you write is an explanation for your ways of solving problems in your domain. And solving them with textbook examples, which are often very generic, will most likely dictate your domain instead of the other way around.

And what’s the problem with that you might ask.

Well, a lot of things.

Say you’re owning a car rental business. You have decided that you should have a website that customers can use to book cars.

You come across a fantastic, widely used booking library. But as it turns out, there’s no support integrating big parts of your business logic. All the items that can be booked have to be yellow, have two wheels at the most, and also none of the items can be booked for longer than a day. But the library is great! You could almost say that it’s a textbook example!

So what do you do now? Sell your fleet of cars to buy a bunch of yellow vehicles with only two wheels? Congratulations, you’re now the owner of a bike rental business.

This example is not very likely to come across in real life, but I think you get the point. Shiny processes, what others think is good, what others are using, what others are praising, or even textbook examples never come with any guarantees that it will suit your needs.

So think about, what problems am I trying to solve? What is there to suit my needs? You’ll be minimizing the risk of saying “Well that library didn’t have support for that so now we can’t do that anymore”

But why should your domain dictate the way you write code?

Because it will make everything easier. It will make it easier for yourself and everyone reading your code.

I heard Kevlin Henney in one of his talks say “Code in the language of your domain”. What does this mean?

Your code represents a lot of things, your knowledge or skill of the language you’re writing in, but also your understanding of the domain.

So, if you write code in the language of your domain you’re making it easier for everyone else to understand what piece of domain logic you’re covering and what problems you are solving.

Take a look at these two. Lets say we need to get every ID of every booking a specific user has done in our system. Yes, we’re back in the car rental business.