"When In Rome" Programming

I'm writing this blog post because I think a lot of us in the software development profession believe in too many of our own myths.

The conception for many is that approaches to programming ought to be divided into various competing schools, of which one will eventually prove "correct". Many professional software engineers will tell you that programming is "problem solving at it's most fundamental state", and that our beliefs about how software ought to be crafted are slowly but surely converging on a sort of core truth about how to describe and solve problems.

I think that's baloney. I think software engineers have radically more in common with plumbers, electricians, and framers than mathematicians or philosophers. There's no core truth about what a home ought to be (if you think there is try living in a longhouse or an igloo or on a house boat and report back). The way we build houses is limited by our economic conditions and engineering capabilities, and is guided by our cultural understanding of what a home should be.

This is the point I want to get across about software engineering. Obviously we operate within technical and economic confines. But IMO typically the way we choose to build software within those confines is not a philosophical school of thought but rather a cultural artifact, a product of applying our lived experiences to the many layers and branches of existing ideas that came before us.

Software engineering as a field is not in any way unique or special. It does not make you a fundamentally competent problem solver. I mostly mention this because the claim is a pet peeve of mine.

If you want to be the kind of engineer who feels comfortable dropping into any code base, you should try to be well traveled in terms of the software communities you participate in and learn from. When you learn a new programming language/framework/toolset/whatever, don't just learn the syntax and the idioms. Do your best to avoid carrying over your assumptions from your previous experience and try to put yourself in the same frame of mind as the locals. You need to learn to speak the language the way the locals do, because you need your code to make sense to the rest of your team.

Be deeply suspicious of attempts to use x tool in y style (a codebase full of C++ that looks an awful lot like C, or maybe a TypeScript codebase where half the code is written with fp-ts). It is absolutely valid and good to learn from and incorporate ideas from other programming communities, but often what's really going on is that one or more engineers simply aren't comfortable in the programming culture they landed in and don't feel they should be required to adapt.

Finally a note to people who make decisions about programming languages: Less is more. Languages with a gazillion features that aim to be "multi-paradigm" make working on a team harder. You should have a clear idea of what code in <X>lang looks like, and do your best to make it impossible for code to look any other way. The language should be cohesive, consistent, and as small as you can get away with. Some languages I've personally used that nail this are Go, Gleam and Wren. Take a note from them and godspeed.