The software developer’s brain works just like a computer, it has a RAM! When working on a product, the software developer has the product clearly in her RAM ranging from the tasks she has to do, the tasks other team members have to do to the general direction of the product.
Another thing that the developer has clearly in her mind is the structure of the code she is working on and all the little nifty bits and corners of the codebase. Something else which is true about the work a developer does is that things in the software development space change often, and in addition to that, this same developer may be involved with different teams and working on different products. She needs to always be in the “flow”.
Once things are in a developer’s RAM, one can say the developer is in a “flow”. It takes time to achieve this flow each time a developer has to sit down and write some code, and the time it takes differs from developer to developer. Working daily on a product drastically shortens the time it takes for a developer to get into the flow and the sooner a developer gets into the flow, the sooner and faster work gets done!
On the other hand, when this same developer stays away from working on the product for a while, it will take her a longer time to get into the flow. This can be explained by the fact the details of the product are no longer in the developer’s mind, rather somewhere deep on her hard drive, so it takes time to locate and load into RAM.
Poorly written code is one of the factors that makes it quite hard for a developer to get into the flow especially when she has been away for a while. Those large chunks of commented code (that made a lot of sense to do when she was actively writing the code) appear so strange and she is wondering why is it even there in the first place. The little hacks that saved her time then seem very hard to understand now and look so strange. Now imagine someone who is new to the team having to deal with all this, it will take ages for his RAM to get loaded with all the information he needs to be productive.
The life of a software developer is one that is constantly under pressure to provide solutions and if a developer cannot quickly get things into her RAM, she won’t perform at an optimal level.
The whole idea behind writing maintainable code is to be able to load the code into one’s RAM without the need for external assistance (as much as possible). External assistance could be some other document that explains what the code does, the need to talk to someone who’s has all the product details in his RAM and is the reigning codebase guru.
When code documents itself developers can boldly take a look at the code and get a good understanding of what is going on that they can confidently make valuable changes right away. The process of achieving maintainable code is a challenging one as one will have to do things now that make very little difference but mean a whole lot at some time in the future.