This week I read this quote, and it really resonated with me:

Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – even as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.

When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked and glazed artefact that approximates what you thought you wanted to make removes the very human element of discovery and learning that’s at the heart of any authentic practice of creation. Where you know everything about the thing you shaped into being from when it was just a lump of clay, you know nothing about the image of the thing you received for your penny from the vending machine.

Source: Aral Balkan on Mastadon.ar.al

I think coding itself is just the defining part of translating ideas into machine code, however, getting those ideas mature enough that they CAN be translated is very hard.

Much like using coding agents, or working with outsourcing, the quality of the requirements directly correlates with how precise the expression of that idea is coded into the system.

Being good at managing the requirements and defining things well is the path to achieving very good systems with much less cost. But in order to do that, you have to know the needs or problems that said system aims to solve, and that is the hard part.

Most of the time we have a vague idea of what we are trying to achieve, but actually materiallizing it can be really tricky.

One thing that has helped me in the past, specially when I’m not the product owner, is to try to interview the people whose problems would be solved the most, or whose workflows would be improved the most.

These are the people that can, if you meticulously craft you questions, give you the most insight about the problem and the path to the solution.

I specify that good questions are key because quite frequently, these are not technical people in the sense of being able to predict technical hurdles and problems, therefore their perspective will be mostly functional, and the burden is on you to be able to understand that, and foresee said hurdles.

This is a skill that I’m very much improving each time I need it, and I like to think that is because I’ve already overcome the initial plateau of the learning curve, and I’m on the rising edge.

Regardless, the quote itself has also a deeper meaning about how we as humans perceive effort into making something out of nothing but ideas.