I started programming at the age of 11, when my uncle hinted that the computer could automate a boring task for me: calculate the value of color ring resistances that I pulled from scrapyard devices.
I never really did get back to electronics after that...
What gripped me was the puzzle-like quality of writing code and how you can use it to have an impact on the real work of people.
My career is being fueled by two questions; At first it was "how to achieve quality and robustness, without killing development speed". For example: back in the TDD heyday I spent a lot of energy trying to find out what the insight was beneath the dogma. I noticed that a lot of tests that I wrote were pointless and those caused slowdown rather and prevented refactoring. And then sometimes it did work beautifully. So what was the knowledge here?
Later I added the question of "how to solve the right problem". (Yes, I only thought of that question after a few years as a professional developer…) Me and my team sometimes spent days or weeks working on something, all the while dutifully moving post-its and doing sprint reviews, and still we managed to miss the mark. To have improved all the wrong points.
At some point it finally <s>hit me</s> was pointed out to me often enough that the answer lies in "testing your assumptions like a goldsmith tests gold". Each release should test if you understand the value that your software brings. You write code with the mindset of proving whether your code can handle this problem / edge case / user need (of course coupled with the basic Parnas/Liskov strategies like decoupling and information hiding). And this is of course also applicable to the structure of your process.
My code is on <a href="https://github.com/jauco" class="icon brands fa-github"></a>.
