What is your problem!

Published: December 02, 2025

Story time!

Once upon a time Dev Junior, walked into the glassed office of Mr Senior saying; “I think we should start using Eight!”

 

“Eight? The number eight? Why is that?” Mr Senior replied.

 

“Yes, it’s the new thing. It’s cool, looks like a pair of shades if I tilt my head. It’s completely smooth, doesn’t have any sharp edges so nobody will get cut. Also, it’s like an infinity symbol! Right?! Who doesn’t like infinity?!”

 

Two nights before Junior had been watching this amazing presentation on TuYuub or Witch called “How Eight solved all our problems”. Junior had skipped ahead a bit, into the fun part. The speaker had been energetic, inspiring and full of shit (Junior didn’t get the last part though). The guy used fancy words like “orthogonal”, “vectorisation”, “memory bound” and “performance heuristics”. Junior felt like he had learned a lot!

 

The problem was that on the first slides, the presenter had introduced the problem; to sum the numbers three and five.

 

Fun fact, Mr Junior and Mr Senior got the same first name.

This is obviously a made-up story, I tried to be funny. Maybe it worked, maybe it didn’t. Regardless, it serves as a principle example.

Have you been there? Have you been the uninformed (junior?!) developer that has found something that looks cool and shiny? I know I have, many times. I still do! However, the point is that the problem is the problem of software development. Why do you think that it’s good to write a prototype? It’s because you will understand the problem that you are solving, while writing the prototype. Why do you think that it’s good to trash the prototype? Because with your new found knowledge of the problem you will be able to build a solution that is a better fit than when you started the prototype.

This is one reason estimations so notoriously hard and all developers hate them. To some degree, we don’t know enough about the problem we’re solving before we do it! The devil’s in the details and there are just soooo many details!

Breakdown

In order to understand if Eight is a good solution, we have to ask questions. What would good questions to Junior be then? Let’s take the story apart!

• “It’s the new thing” › “new” is temporal and does not mean that its better than what was there before (something that just soooo many people don’t seem to understand).

• “It’s cool” › Subjective at best, completely irrelevant at worst.

• “looks like a pair of shades if I tilt my head” › Why do you tilt your head? Is that part of the problem our product is solving?

• “completely smooth … nobody will get cut” › Do we currently have problems with users cutting themselves on the other sharp digits? Like number 4?

• “infinity symbol” › Relevance? I agree, infinities are interesting, but is it relevant to the use case of our product?

In order to have any level of confidence about if Eight is a good solution or not, you have to understand your problem!. How are you otherwise able to evaluate? What do you evaluate against?

Tangent

This is why I undoubtedly believe that Kubernetes is vastly over-used. Are you regularly being taken by surprise that you suddenly have 10x more users than yesterday? Are your services constantly dying and need a self-healing policy? (why does it crash? who cares, just restart!!). Et cetera.

Kubernetes has it’s place but the question should be phrased When? rather than Why?. Articles in the form of Why Developers Need Kubernetes is focusing on the solutions, not the problems that must exist before Kubernetes is a viable alternative.

Do you know what they never tell you? It takes a lot of man power to run a Kubernetes system. It’s expensive as hell.

Right … , enough about Kubernetes!

Problems

Niche problems have custom and interesting solutions. However, 90-99% of the code you will ever write will be for generic, boring and mundane problems. That should be solved with generic, boring and mundane technologies. If you are lucky enough to work in an R&D lab, that percentage will probably be lower, but you will also know that without reading my rant about this.

Understanding your problem is the challenge.

People, ugh!

Personally, I hate people. It’s one of the reasons I’m into computers at all. I find them hard to work with, incomprehensible and non-deterministic. Compare that to a little algorithm work. Right?!

Alas!

Problems are always for people, or downstream from a problem for people. There are exactly zero only-technical problems! Nobody, ever, sets out to implements a solution to be nice to a computer (this might be up for debate in the coming years considering AI) The challenge is that the further downstream from a person the problem you are solving is, the harder it is to see your mission. You might also mislead yourself by succumbing to the shiny bling-bling temptations! The mission is always to solve a problem for a person. So, what is your problem? No user cares if your binary is statically linked, or a python bash php spaghetti hell. Does it work? Does it solve the problem? Is it fast enough (for the important measure of ‘fast’).

A good trick to finding out your problem is to state it for a human;

When the operators handles the current digit 4, they cut themselves.

This is a problem statement! It just states the facts, it doesn’t judge or have other opinions.

Now we can brainstorm on solutions. I’ve got three!

1. Swap out the digit to number Eight. It does not have sharp edges so nobody will get cut.
2. Change the font to something that has soft angles.
3. Get the operators gloves to handle the digit 4.

Ask yourself, am I writing code that solves the problem?

Resources

Go watch Rich Hickey on Design in practice. It’s an hour long and you should probably watch it at least twice, including note taking and a week in between to let the ideas properly fester.