Don't Make Me Think About Code

Intro

I consider the structure and prose of my code more often than most programmers. While reading about usability design I came across Steve Krug’s First Law of Usability: “Don’t make me think!”

This is law was originally written for web or mobile UI design, but applies to programming as well. Programming is a creative activity, where one or many attempt to painstakingly describe a solution to a computer in precise detail. As a programmer spends more time working in a given codebase the structure that unfolds becomes their interface. Designing this interface, or architecting the software, can make or break a project. To write code that is clear, self-evident, or single responsibility is to avoid future thinking.

Small Example

Here is a short piece of code that conditionally calls a navigate() function:

function changeRoute(shouldChange: boolean) {
	const route = shouldChange ? '/route-a' : '/route-b';
	navigate(route);
}

There is nothing wrong with the above code. It has a single, simple purpose, and does it in a straightforward manner. However, even here we have managed to introduce more thinking than required. Consider this alternative:

function changeRoute(shouldChange: boolean) {
	shouldChange ? navigate('/route-a') : navigate('/route-b');
}

The following code avoids creating a variable, simplifying the code. Decisions like this are small, but add up to an easier to reason about pile of code.

Automation

As a lazy dev, linting and formatting is essential. Many claim to not care about formatting, making these tools is unnecessary. By not automating this process you are forced to repeatedly make formatting decisions on your own. By automating formatting decisions you can spend more time focusing the task at hand. I find code with a uniform structure to be much more readable as well.