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.

Full-time fun - why join an early stage startup

9 days into May, and I feel like I have a bit of an "announcement" to share that has been a few months in the making.

End of last year, I came to the end of a long (10,5 years!) and rewarding journey at Neo4j. I had put my heart and soul into that project, and was at the same time sad and thankful for the goodbyes that I had to say. Lars Nordwall and Emil Eifrem will forever be in my heart, as will be so many other wonderful graphistas that I got to know and love.

At the end of a journey like that, you would think that you want want to take it easy, or take your time, or do nothing for a while. And in some ways I did. But in other ways, I just did not want too much idle time. Having some time to reflect would be good. Having too much time to reflect would have someone like me go pretty crazy, pretty fast.

So when Pascal Desmarets and I had a wonderful lunch sometime in January, I decided pretty quickly that I was not going to let the opportunity pass, and that I would want to do some part time work for Hackolade. It seemed like a great idea - and now, 3+ months later, I feel like it really was. Earlier this month, on May 1st, I joined the Hackolade team as full time member - and I could not be more stoked about that. Let me tell you why I feel that way.

Confusing words in Data Modeling

For a few weeks now, I have been helping out my friends at Hackolade with some really interesting work around their core product, the Hackolade Studio and how to make it even more successful in the marketplace. This means talking to a LOT of people - both current customers, active users, partners, friends in the industry - and more. It’s been fantastic to talk to so many interesting people, and to learn so much from their insights.

During these conversations, I have noticed that there’s quite a bit of work to be done to clarify and straighten out the meaning of the words that we use in these conversations. I have noticed that in the NOSQL data modeling space, we are not always very precise with our words - and that this imprecision can lead to all kinds of misunderstandings. Specifically, I have been struck by the confusion around 3 words: model, schema, and metadata.

The Agility Angst

First of all: let me start by showing my age. I was born in 1973, and yes, that does mean that there's a big, and I mean BIG, party coming later this year. Big Five Oh looming around the corner - and to be honest I am very, very fine with that. I am happy with my age - except when I am being dropped like a baby at the back of the cycling bunch. Then not so much - dammit.

What does my age have to do with anything? Well - it basically means that I grew up with a very, very different type of software development practice. OO was still young. The mythical man-month was still a thing. And methodologies all depended on strict, rigid waterfall development models.

Nothing wrong with the odd waterfall, of course, but with the emergence of more and more, and better and better, software tools, libraries and frameworks - this whole idea of the time consuming waterfall process has kind of become irrelevant. Who would still go through this entire process and ask their users to wait for months before they would be able to give any feedback? What users would accept that type of arrogance on behalf of their IT department? Seriously?

The modeling mismatch

After having spent 10+ years in the wonderful world of Neo4j, I have been reflecting a bit about what it was that really attracted me personally, and many - MANY - customers as well, to the graph. And I thought back to a really nice little #soundcloud playlist that I made back in the day: I basically went through dozens of #graphistania #podcasts that I had recorded, and specifically went back to the standard question that I was asking my interviewees on the podcast: WHY do you like graphs??? WHY, for god's sake!!!

Unsurprisingly, people very often came back with the same answer: it's the DATA MODEL. The intuitive, connected, associative, visual, understandable structure that we humans love interacting with: the labeled property graph (LPG). Have a listen to what people were saying:

Graphistania · The Best Thing about Neo4j