Good code

UX for programs


When a programmer writes code, most often they are not writing code for other humans to read, but they are merely scribbling down instructions for a computer to interpret. I think this philosophy is wrong.

When programmers program, they’re not just writing down instructions for a computer, they are also writing code for other humans to read. Code should be thought of less in terms of functionality, and more in terms of user experience.

How will another programmer, as a user of your source code, experience it? How consistent is the structure? How intuitive is the architecture? How much state does a user need to memorize in order to understand the control flow?

Read back on a program you wrote a while ago and think about the following things:

  • How many tasks does a single file have? If >1, how can you split it up?
  • How consistent are your files? How have you split up function definitions and function execution? Can you immediately see what is exposed and what’s not?
  • How many levels do you nest your folders? How can you improve your nesting levels?
  • How glancable is your code? Can you immediately see where one function starts and another function ends? How can you improve legibility?
  • How composable is your code? Can you reuse a function in another file without adjusting it? How you make it so that your functions are more terse?

Reading back on your code you might see things you’d do differently. Try to find the common denominator and strive to improve that. If you’re working in a team, review each other’s code and comment purely on readability.

It’s important to write readable code. How clearer it is what you write, how more it will benefit you (and your collaborators) in the long run.

Email me when Code & Meta publishes stories