Just the right amount of thinking things through

This may become a little bit of a weird, “metah” article. But I feel like it’s an important one. It relates to something I have been thinking a lot lately about how, both professionally and personally, something that I think holds important life lessons. Maybe it’s because I am turning “half a century” later this year, that these types of thoughts and considerations are on my mind, I don’t know.

Here’s the deal: I think that, both personally and professionally, there’s a lot to be said for a) not overthinking things, b) not underthinking things either. Let me try to explain what I mean with that.

You don’t want to be overthinking

I know that some problems are very hard. It’s super difficult to get it all in your head, to rationalise all the parameters, to assess the impact of all the different factors, and to play out what will be the right decision in a given set of, usually ever-changing circumstances. So you think and you think and you think things through – but often times that just does not get you any closer to a practical solution. In my experience, very often you are better of “just getting going”, chopping away at the problem and moving the solution forward in what you think will be the right direction. It’s not possible to solve the whole thing all at once, and overthinking it will not get you closer to that solution. It will just continue to look like a massive sticky hairball, a “big ball of mud” that is impossible to manage or untangle. Stop thinking, start doing is often very sound advice.

You don’t want to be underthinking

On the other side, you definitely don’t want to be underthinking your problems either. Simplifying things too much will obviously amount to randomness, and while that may work some of the time, it clearly won’t work much of the time. You want to give your problems as much thought as you productively and efficiently can give it to move you closer to a likely solution, is my take. Work in the general direction of the potential solution, step by step, and eventually you will find that you will have come to have met your challenge. And if the potential solution does not end up being the real solution, just iterate, and start again. Not a big deal. You’ve only invested a small amount of time in it anyway, so it’s easy to admit that you were off course. Failure, or simply being wrong about something, is not that bad – really!

A personal, and professional balancing act – also in the data modeling world

So it’s a balancing act, at which we will get better with experience. And I am convinced that this applies to both your personal, and your professional life: you want to find a balance between overthinking and underthinking your problems, and think through them for just about the right amount.

 
So much for the “life advice”. But obviously I started thinking about this partly since in my professional life I have also noticed that this a great way of doing things.

I am now 1000% dedicated to the work we do at Hackolade, and there are great advocates of Domain Driven Data Modeling. We apply the principles of Domain Driven Design to data modeling – and that will very often imply exactly what I was talking about above. Break down the data models into manageable domains. Work on these with a common language to reach a shared understanding. And iterate and evolve when and where needed.

I am truly loving the way the Hackolade team aligns with all of the above. In your search for the pragmatic balance between over- and underthinking, I have found that

• Tools that create artifacts – like data modeling tools – are really useful in finding that balance. Turns out that writing stuff down is a great way of overcoming hurdles and revealing details that would not be obvious in your head.
• Doing iterations, trying- and retrying to get closer to the right balance, requires a nimble toolset. Otherwise, your tool will not help – it will just get in the way.
• Same thing for your data platform: choose one that allows you to iterate – easily. Rigid lifelong table schemas will also get in the way. Go figure!

I hope this was a useful article for you, and of course, as always, I would love to hear your feedback.

Cheers

Rik