The purpose of a software developer’s job is primarily to write code that:
- Works. Obviously not only compiles but does something functional. Your client wants the system to do “X” then your code should do “X”.
- Communicates with other developers. Code should be readable, easy to understand and by virtue of that be easy to change. By definition all software developers can write code that works but how many can write code that is easy to understand by the next developer that reads it?
So of the two points which is the more important? I would argue the second.
Imagine two different scenarios:
- The code works right now, but is hard to understand. When requirements change I can’t change the code (and of course requirements will change!). This is because code that is hard to read is hard to understand. Code that is hard to understand is hard to change.
- The code does not work (maybe does not compile or doesn’t do what it’s supposed to do functionally), but it’s readable and understandable. I can change the code to work now and in the future.
It is more important that the code is easy to understand by your peers than it is that it works. You may argue “well yeah, but I work alone”, well in this case the peer is you. Ever written code and then come back 6 months later and thought the code is hard to read/understand/change?
Unless you are the sort of developer who only jumps from one greenfield project to the next (in that case let god have mercy on your soul) you will very likely spend more time reading code than writing it. Even if you are the sole developer writing the code.
To quote Robert C. Martin (AKA “Uncle Bob”):
Unfortunately, too many programmers think they are done once they get a program to work. Once it works, they move on to the next program, and then the next, and the next. In their wake, they leave behind a history of tangled, unreadable, code that slows down the whole development team.
