State is now my enemy, instead of my friend. Unless there are very good reasons for mutating state (such as speed), I prefer immutable data and functional programming as the default style. Pretty much every bug I’ve ever encountered could be contributed to state mismatch in the program/system. Making everything immutable as default severly limits the surface area where this problem can arise. OOP is still what I reach for when I want to encapsulate state. Functional Core, Imperative Shell is a nice pattern to adopt for example.

Static vs dynamic typing is an interesting debate, and I’m not sure it’ll ever be resolved. I do however feel that it’s combinations that are more interesting to talk about. FP + immutability as default + dynamic typing works quite nicely together. FP and immutability (FPi) delievers on the promise that Java and OOP was supposed to deliever on: Code reusage. It’s almost criminally easy to write libraries that can be treated as black boxes from both sides of the fence. As long as the library doesn’t do any state, but is completely pure the following holds true: The program doesn’t need to care about the inner workings of the library, and the library doesn’t need to care about the overall state of the program consuming it. The moment state touches the library it no longer holds true.

Mutability everywhere causes lots of problems as any reference can now change any other part of the program. Static typing does give a lot of value here as it gives you some assurance that you haven’t messed up in your thinking. Mutability is also very difficult to contain as it contaminates anything it touches with complexity, and is in my opinion the primary reason for the massive code bases in the first place. It’s simply easier and cheaper to have a big massive monolith if mutability is the default mode of operation in your programming langauge of choice.

Funnily enough the last craze of the industry with microservices seems to be a weird mixture of FP and OOP. Since everything needs to be send over the wire between the microservices it’s sent as values, and thus immutability is enforced at the edges of the microservices. State is now distributed between the servers though with each server sort of acting like an object. Inconsistencies in state are now also easer to arrive at than it was with OOP and monoliths.

When I first started coding I was told what to code. Then I learnt fairly early on that it is good practice to think before you started coding. After a while I started to do smaller designs after having thought a bit about the problem. Eventually I started to incorporate talking with the customer about the problem to understand it. In one of Rich Hickey’s talks he talked about the cost of mistakes, starting with mistakes like typos, advancing to problems in the programming language/framework and finally ending up with the complexity of the real world problem you’re trying to understand and the cost of you misunderstanding it. Each step up in the pyramid increased the cost of the mistake by one factor. Looking back at my path towards mastery of programming I see a progression from the smallest stage where I spent a lot of time worrying about typos and minor mistakes that are quite cheap to fix, to grappling with why programming was so hard when I had this nagging feeling that it shouldn’t be THAT hard, and now where most of my focus is on trying to understand the domain of the customer and the problem they’re trying to solve.

I’ve come to value stability, a lot. When everything was still new it was exciting to learn new tech, now I just want to get on with solving the business needs of clients. Churn is one of the worst things you can encounter in an eco system and/or language and leads to burnout. It requires tremendous amounts of effort to make people put up with churn. Javascript is probably the best example of this. Backed by multiple international companies, it’s the langage of the web and has a reasonably mallable core and still people complain about the churn. Rightly so.