> For the complete documentation index, see [llms.txt](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/learning-path/clear-code.-beautiful-code..md).

# Clear code. Beautiful code.

Readable code is not an aesthetic luxury. Software is changed far more often than it is first written, so another engineer must be able to understand what the code does, where its invariants live, and how to change it safely.

In interviews and real work, a slow but well-explained solution is often more useful than a clever solution nobody can safely modify.

The industry has influential classics. Read them critically: a book gives you vocabulary and heuristics, not universal laws for every language and system.

Three books for you:

* Robert Martin "Clean Code: A Handbook of Agile Software Craftsmanship"
* Robert Martin "The Clean Coder: A Code of Conduct for Professional Programmers"
* Steve McConnell "Code Complete: A Practical Handbook of Software Construction"

Also read the style guide for your language and inspect a well-maintained codebase in its ecosystem. Language and project conventions matter more than forcing every example into one book's preferred shape.

While reading, refactor one of your earlier programs. Preserve its behaviour with tests, improve the names and boundaries, and inspect the diff. Be able to explain why each change makes the next change safer or easier.

Do not forget to take the damn notes in your own words :)