When first learning to develop software, it’s natural to focus on getting your code to work as your first priority. As development is an incremental process, between multiple changes and attempts to get your code working, it’s natural that your first working version of your code is probably, to put it bluntly, a mess.
As you progress in your career, you realize the importance of developing code that is easy to read and understand, because at the end of the day, any software developed or maintained by a team has to be read and understood by other developers, not just the original developer. If no-one else on your team and understand your code then it’s unmaintainable and that poses a long term risk; if it breaks who is going to be able to fix it?
I commonly see posts online by new developers who are first starting out questioning the point and importance of spending time to refactor code, ensuring code is clear and readable, in essence, all attributes of maintainable code. The first time you come across code that you struggle to understand and you’re faced with making updates or fixing an issue, you’ll quickly realize the importance of developing code that is easy for other humans to understand.
This is not a new concept, it’s summarized clearly by the famous quote from Donald Knuth:
“Programs are meant to be read by humans and only incidentally for computers to execute.”
