About #craftsmanship

I’ve had some health issues in the last few months. Moving from one doctor to another made me realise something important. Great engineers, just like great doctors, keep asking “why?”.

This question is not only about curiosity. It’s a tool. When we go to a doctor, we expect a diagnosis, not stating the obvious. Cough, fever, stomach pain - these are not much different from timeouts, noisy logs, or odd metrics. In fact, naming observed symptoms is usually easy enough, to be done by the patient alone.

Everybody knows that programmers are spoiled. When not enjoying free fruits in their fancy offices, they probably work from the end of the world that looks like a paradise. Even during challenging economic conditions, the market still tries to exceed their expectations… A comfortable life and great earnings - who wouldn’t want that?

In fact, there’s much more to appreciate. Most developers experience levels of organizational maturity that other industries have never dreamed of. The work culture that has developed over the years really stands out. Yet, we programmers rarely notice that.

The calendar doesn’t lie. A decade of my professional career in software development has just passed. 10 years of experience always felt like a magical and very distant boundary. Am I a better engineer now? Am I a different person? Absolutely! Yet, it didn’t happen overnight.

Reviewing these changes is a fascinating exercise. Sometimes I struggle to remember what I had for lunch the day before… But 10 years?! That’s really a lot of time! Yet, I feel it was really worth the effort.

Keeping our domain (business) logic together is usually a really good idea. It not only makes it easier to reason about the most important part of our code but also increases its cohesion. Yet, decoupling the domain code from all the rest (orchestration, persistence, etc.) can be tricky.

In this post, I’d like to share a simple pattern that helps me with that. The amazing Unit Testing Principles, Practices, and Patterns book calls it the CanExecute/Execute pattern.

We want our applications to be maintainable, reliable, resilient, and scalable. All these features seem to share the same idea: being flexible. This flexibility is often manifested in the early design documents close to the buzzwords and technology names. But that’s only the marketing. The true test of flexibility comes with the first go-live. “Production will verify” as my former colleagues used to say.

Flexibility is usually a good thing. It means being able to adapt. Bending without breaking. Flexibility gives us a margin of error when something unexpected happens. Just like it was “made” with production in mind.