Don't Write Unreadable Code

Anyone, from newcomers to experienced engineers, has stumbled upon or heard of books like "Clean Code", "Code Complete" and so on. A lot of them promote generally good guidelines but not all of them aged well. It's been a while since I read them, I honestly can't recall which one taught me what, but there are a lot of things you HAVE to learn by experience. Those lessons stick around the longest.

I've always tried to write readable code, but with time I realized that it's a very subjective characteristic. You might craft something today in an understandable and easy-to-follow manner, to the best of your ability. Then you go back to it a year later and nothing adds up anymore. It's not always that extreme, but that feeling of "this is definitely readable" fades away with time. This should be your first clue that:

Readability is a property of code you write at a certain point in time.

At that time you have a mental model of what you're building, you have some knowledge, and you're intently looking at your code as you touch it up until it "looks good". Then a year goes by, and you have to rebuild that mental model, things you knew then might have faded away, and it feels like the first time you're reading those lines. All you can do today is make the best effort. Here's a second clue for readability:

Readability varies heavily among software engineers based on their background.

On the other hand, there exists objectively unreadable code (but even then, where's the threshold beyond which it becomes unreadable?). Function names are unclear, functions are 1000 lines, tests are limited, and documentation is out of date. Between that and the fact that "readability" is not measurable, my best advice to you is to stay away as much as you can from writing unreadable code. The alternative to writing unreadable code is not to write universally, forever readable code. I want to move away from that myth and relax the requirements. Try the best you can today to not make it unreadable since you don't have a metric or a threshold to hit (e.g. test coverage). Have someone review it and verify it makes sense to them, then move on. As a third clue (or corollary):

Readability is heavily subjective, no tool can measure it accurately.

Thoughts

Don't chase the unattainable level of universal readability. Try your best with what you know at that point in time with some consideration for the future. You can do this exercise and leave some code you wrote along for a month, then go back to it and see if it feels readable (whatever that means to you). Then try six months later, then a year. You might notice that what felt readable a year prior doesn't feel AS readable now. If you've done good work, the best you can hope for is that it makes sense and it gives you enough to put the pieces together again. Another exercise could be to read an open source project that might be held in high consideration by the community (e.g. React, Go std library). How readable is that to you? How readable is code written for a Comp. Eng. thesis by a researcher? Do all those one-letter variables look readable to you?

I feel like any technical characteristic that's leaning on a subjective viewpoint is hard to impose. You might think what you write checks the readability requirement, then you hand it off to someone else and suddenly it doesn't anymore. That said, try your best to be consistent, be clear on the description of your tests, comment on the why not the what, and generally try your best to stay away from unreadable code by any means necessary.