Don't Gloss Over Complexity

We have a poor habit in the tech industry of glossing over the complexity of things. Sometimes this is done deliberately, but very often it happens accidentally, as the result of skipping due consideration, or at a subconscious level.

I saw this play out on Twitter this week in a scenario that’s all too common. An early career developer, enthusiastic about what they know and eager to share that knowledge with others, denigrated as “not a real developer” by someone with greater experience.

This is a situation that’s played out time and again. It’s easy to find examples of these kinds of aggressions that, in accumulation, serve to push people out of the industry.

One of the many contributing factors that leads to these situations is the way that we all forget the inherent complexity of lessons we’ve already learned.

Do you know how to ride a bike? Do you remember how hard it was to learn to ride?

I have some vivid memories of learning to ride a bike as a child, including a slow wobbly ride down our garden path where I was terrified that I’d hit our (very solid) letterbox. Guess what I hit. Ouch.

That memory is over 40 years old, but it still stands out.

I have some much newer memories from when I taught my daughter to ride. It was something she intensely wanted to do, but it was hard work. We went to the local park twice a day for her to practice - and boy was she proud when she showed off her new skills to her Mum.

Learning to ride a bike is hard because it’s a complex dynamic process. You can’t just steer the bike, you have to pedal and balance at the same time, making adjustments many many times every second. If you fail at any one of those, you fall off.

And yet, how many of us think about all those adjustments when we ride?

This is what happens to complexity once we master a skill - it becomes an automatic subconsious act, allowing us to concentrate on the next goal.

We don’t think about riding a bike, we think about how to not be squished by traffic, how we’re going to navigate to the local shops, and about what we’re going to buy when we get there.

As developers, there are so many similar examples of complex topics that become simple once we’ve mastered them.

I remember coaching first year computer science students who had never touched a computer before, helping them to comprehend the extremely literal way that computers execute each instruction in order, one at a time. (This was at the start of the ’90s, pre-word-wide-web, when computer ownership wasn’t the ubiqutous thing that it is today.)

Sequential execution of instructions is such a fundamental concept that I rarely think about it, but it’s something that has to be learned by every aspiring developer.

Think about some of the other concepts that new developers need to grok: conditional branching; looping; functions; data types; file types.

Now think about some of the more complex concepts you’ve already mastered - or perhaps you’re already working on.

Recursion. Pointers. Manual memory management. Abstraction. Encapsulation. Inheritance. Composition. OOP. Generic Types. SOLID. DRY. Unit testing. Functional programming. Monads. Functors. And so on…

Here’s the crux of the issue.

We can easily assume that something easy to understand because we understand it, and that anyone who doesn’t understand it is just not as smart. This can happen because it is so extremely easy to under-appreciate the complexity of what we already know.

We who have already climbed a mountain of understanding should be gracous and encouraging towards those who are still early in their climb. Especially since we’ve got more climbing ahead of us.