🥯

When educating ourselves as software developers, we face an abundance of books, conference talks, youtube videos, and blog posts. The multitude of voices can be overwhelming and makes it hard to identify a melody in this concerto with neither sheet music nor a conductor.

Standing out from the sound carpet are some very sonorous voices, highlighting opinionated points of view. Sometimes it is all too comforting to listen to them: Finally, somebody who cut through the fog of uncertainty and knows what needs to be done! Finally, there is the principle that will produce elegant, clean code! Finally some clarity. Finally some orientation. What a relief! Let’s go and apply this principle everywhere.

After a year or two, or three, or five, the idea has aged – rarely like wine, and more often like milk – and it gets replaced by another one. This cycle of excitement and disappointment has little to do with the value of the idea, but mostly with group dynamics and attention management.

With an inundating abundance of technical advice flooding the gates of our attention, how can we decide which advice is worth following, and which should better be ignored? It is easy to get lost and resort to a depressive cynicism: Is there a thing such as meaning to be found in this tintinnabulation at all? Or is it just a great white noise of nothingness? To not fall into cynicism we might resort to conservatism: Perhaps we should just not be amongst the early adopters? We better wait until time has proven a principle. Let others get themselves a bloody nose when working at the bleeding edge of technological development.

Both the cynical and the conservative strategy of dealing with the problem is missing out on opportunity. We lack a critical tool, a tool to tell sense from nonsense. With this, we could reap the benefits of adopting better ideas earlier. This applies not only to individual decision making, but also to the software development industry as a whole.

But how can we tell whether an idea is good or not without having tested it? This is a classical question from an ancient discipline called logic. Logic does not help to prove that a statement is correct, and thus cannot replace the test against experience. But at least it helps with identifying arguments which are flawed. By applying logic, we can filter out a lot of ideas early on and thus spare us some pain in gathering experience.

This post is a short logical inquiry into how to tell some of the most prominent patterns of people trying to sell you a technological nothing burger. It is basically an application of the theory of Critical Rationalism to the problem.

The main idea of Critical Rationalism is to reject ideas if they cannot be tested. This can be applied to a lot of ideas circulating in software development technology discussions.

The core insight is that there are statements which are testable and other statements which are not. The ones which are not testable but logically flawed, are simply wrong. The ones which are not testable but logically correct are sometimes called “logical tautologies”, sometimes “analytical truths”. They are always true, regardless of how experience is going to materialize. That is why they do not communicate anything about the “world”.

Analytical Truths are Meaningless

Whenever somebody makes a statement which is an analytical truth, they are making words without communicating their experience. Analytical truths are meaningless.

Here is an example:

When applying this principle X, you have to make sure you don’t apply it too much.

This statement is simply true, and it is so regardless the idea we are supposed to apply. Its truth lies in the meaning of the word too. Doing something too much is inadvisable, because this is what too much means. What we would need to know to turn this sentence into a meaningful one is: how much is too much?

Every principle has limits. Every decision is a trade-off. Every decision should depending on context. Most software developers have understood that. Few people will be taken serious claiming they have found a solution which can be applied regardless of context and which has no downsides.

But saying “Apply this principle based on your specific trade-offs”, “When applying this pattern, take the context into account” (and so on) does not mean anything. Nonetheless, these statements can be found in a lot of talks, blog posts and books.

"It depends" is an answer to any question and yet to no question at all.

Value lies in answering the hard questions: What are the limits of this idea? What context information do we have to take into account? What does it depend on? Which are the trade-offs? And even more specific: How can we assess the weights in these trade-offs?

The interpretation assuming best intentions from the speaker making an analytical true claim would be that they believe they have an idea at the tip of their tongue but they struggle getting it out there. Asking those questions will either help them communicate the experience they have in mind or will show that they don’t actually know what they want to say.

Hulling one’s statement into a tautological wrapper is a strategy of self-immunizing the claim. It means the claim cannot be proven wrong anymore. This comes at the cost of depriving the claim of its meaning.

When writing or presenting an idea, make sure you ask these questions and try to answer them. It is hard. Often you might find out that you have nothing to tell, really. In other cases you will find that pursuing these questions will sharpen your idea and make the experience you want to talk about accessible to your audience.

When listening to other people, listen carefully whether they actually make a statement that you know how to apply to your problems. If that remains unclear, because they resort to tautological statements, ask them for examples. With their examples, can you answer some of the hard questions together? If not, it is a good idea to discard their advice.