Vastly Oversimplified Programming Concepts

a rant

Vastly Oversimplified Programming Concepts

In tech we talk far too much about how to do various things, then toss around marketing speak for the rest of our careers. It might be better to talk about why we do those things. That way, we can spend our careers moving forward on really difficult problems our great-grandfathers started fixing instead of jumping from buzzword to buzzword every decade.

Here's a list of current buzzwords and the underlying problem they're trying to fix. I can guarantee you that the buzzwords and products will change. The problems will continue on.

Note that none of this involves any sort of specific  tools, technologies, programming languages, or products. These are problems we face in technology creation today that we'll still have 50 years from now.

Most of the time TDD is shown with three nodes. Lately, though, some practitioners have been using five. It's the same concept: write tests in the same symbolic system as the solution in order to verify your mental model of what the solution is actually doing. Information flows Code -> Developer

TDD: Test-Driven Development (TDD)

TDD is a coding practice to help the programmer understand that their mental model of the code does not reflect the actual code itself

That's it. There are some follow-ons, of course, like if your mental model is exactly in-line with the code then logical errors are unlikely (although business errors can be quite common!). Another follow-on is that TDD is much more about design than testing. Once you realize that it's a practice or habit that's all about sending information from the code back to the mind of the coder, all of that other stuff sorts itself out.

ATDD is a business communication process to keep the human language consistent with what the technology actually is supposed to do. Information flows Developer <--> Developer using an executable programming language as a medium

ATDD: Acceptance Test-Driven Development (ATDD)

A business practice that helps everybody involve in developing technology talk about what they want from the system in a logically-consistent way without getting into exactly how anything is going to be built (or, ideally, not built)

Microservices couples everything to do with this particular business feature at this particualr point in time to a bundle of technically-independent code. If you're using the words "microservices" and "architecture" in the same sentence, you might not understand either. An infinite number of architectures should be able to support any given set of microservices. Monoliths, for instance, are just microservices compiled together into one compilation unit


Microservices are a coding practice that simplifies the mapping of business value to code as much as possible by decoupling any sort of technical details used to support the implementation from the technical details used to deliver the implementation. (Microservices have no architecture, although they certainly can create very complex architectures when grouped together in various ways!)

Type systems are only stable across one particular business' feature and only for a limited period of time. The more you try to couple them into the larger biz, the tech stack, the world, or whatnot, the more you end up in monolith land. Nothing wrong with that, understanding that trade-off is the difference between knowing WTF you're doing and simply writing stories about how tough X was If you don't know the problem, you'll never know the solution when you see it.

Good Enough Programming

Code that provides value to others and that you never have to touch is good enough. There are a lot of programmers who are trying to code great systems when they've never even coded a single thing in their career that was good enough.

Myths and Misunderstandings


TDD is About Testing

TDD is a communication tool