💾 Archived View for mediocregopher.com › posts › boilerplate.gmi captured on 2024-08-24 at 23:59:31. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

In Defense of Boilerplate

Let's say someone is building you a house, and one day you come out to check on how they're doing. You expect to see them with a bucket, a trowel, and a pile of bricks, laying them one by one. Instead you see them wielding a crazy contraption which seems to output a brick wall out of nowhere at a very high speed. When you ask them about it, they respond "oh yeah, the other way is boring so I use this instead".

How much confidence does this give you in your new wall? Keep in mind, the answer wasn't "this thing outputs a better wall for this this and this reason". The quality of the wall was apparently besides the point in the builder's mind. For all you know (and perhaps for all the builder knows) the quality of the wall is actually worse.

If you're writing software for yourself, or for something which doesn't matter, then maybe the amount of fun you've had writing the software _is_ more important than its quality. But if someone else is going to be relying on your software in any capacity you owe it to them to do it right, regardless of how stimulating it is for you.

Let's turn this around. Why is some piece of code boring to write? Because it's known. You will not learn anything by writing it, you will not be trying anything new, you merely need to write it down. It's more a typing exercise than actual programming. Taking the point of view of a user, this is exactly what I want. I don't care if the program I'm using is pushing boundaries, or how many lines of code were saved writing it. I care if it works, first and foremost. If the programmer who wrote it is so familiar with this type of program that writing it didn't induce a single neuron to fire then that's _a good thing_. That gives me confidence it's going to work.

Some may point out that not being engaged while writing code will lead to mistakes. I respond that that's what tests are for. Writing tests should be as boring as writing the rest of your code. Often when I'm writing tests for some code I feel like I'm just rewriting it into some bizzaro upside-down form of itself. This is good. You can mistype something once, but rarely twice.

Am I saying that I never use code generators, utilities, or frameworks to help with my programming? Of course not. But I reserve these tools for the bits of my program which are secondary to what it actually needs to do. Things like logging, metrics, tracing, mocks etc... can all get elevated out into some lightweight framework or injected via a generated interface wrapper because ultimately the code can fulfill all of its requirements without them. They are certainly useful to _me_, the programmer, but the user doesn't care about them, and so their quality does not need to be as guaranteed.

Once I'm working on the actual application logic itself, i.e. the bits which make a program useful to someone, then I write by hand. If a helper function here or there could save me some typing then sure, I'll use it. But I write that helper too, to ensure it does what it needs to do. I am the one who's responsible for this code, afterall.

Over time I've come to look forward to "boilerplate days". It's like doing dishes. I plug in some music and vibe out, and at the end of it I have a pile of good work to show for it.

-----

Published 2024-02-23