Coding for the Long Term

“Long term” here means this, as probably most things I say, may not be applicable to those who don’t have responsibility for evolving a system with a medium or large team of developers over years. In other words, it’s what I call “enterprise”.

Programming is made up largely of a series of decisions. What’s the next step in the process? What’s the next refinement to make? What’s the interface to my software? But the most frequent decisions are made as we write the code itself. How to represent the current state so that our code can be written to achieve the desired state. Do I use an array for this? Do I write a loop here or spend the time looking for a built in function? Do I need a “default” case in this switch?

How we represent our data, or state, will constrain the style of the code — at both a macro and granular level of detail. The shape of the two together have an effect far beyond completing the task at hand. The decisions we make when coding should be influenced by this knowledge.

I’m not saying I know for sure, but when I’ve explained to others before why I emphasized a particular way of doing something, they’d say “That makes a lot of sense. I never thought of it before”. Actually, it’s usually just a discernment for which of two choices is the better overall, and why.

So I’m going to humbly share some of that. Some of it may only apply to one language, but often the concepts are transferable.