A few weeks ago I got an idea to create a set of programming tutorials for non-developers. Since I had been receiving questions about developer’s career and how to become one, I thought of creating digestible guides to show how easy it is to start coding. In a way: “Look, it’s as simple as riding a bike, you should be ashamed you haven’t googled it by yourself. In 60 min you can host a website, write a web crawler, store and analyze data. Do you still make excuses for not learning it?”
But then I realized I was about to oversimplify; I wanted to present difficult concepts and skip the tiresome and lengthy parts, which was wrong. Or wasn’t it?
I am a fan of good stories. Storytelling engages, grabs audience’s attention, eases the process of learning. But storytelling has a dark side, it shows things simpler than they are, which might lead to messing up with people’s ability to understand the basics accurately. It’s rewarding to share a personal story and get laughs, make people enthusiastic about your approach - no doubts about that. But if a person decides to leave his current career for IT just because of my “rainbows and sunshines in IT” post, it might be a disaster, and I would be responsible for it. I know, I am overthinking, but it doesn’t seem right.
Growing complexity is an issue not only in software development. We all might agree that things should be as simple as possible, and when they are not, we speak of the need to “reduce complexity”. Removing unnecessary elements, adding visuals, using better metaphors. But where is the line between using engaging examples and oversimplification? Is there a guide on how to approach problems (not only IT) and make them simpler without messing up the core concepts? How do I know what is safe to remove?
When I explained my idea of simplified tutorials for non-developers to my brother (a software developer), he immediately shared his concerns:
Our work is not always exciting. There are ugly, legacy parts. There are issues that you have to solve, and it takes days, even weeks. Often those are not your mistakes. Hiding all those unpleasant parts is unfair. Unfortunately, that’s a considerable part of our work.
A while ago I had an interesting discussion on my blog post about storytelling. My colleague made a point that overused storytelling leads to knowledge gaps, lack of real problem-solving skills - “Just because there is void in the mind behind the stories.” It was a very valid point.
It seems that I tend to oversimplify things. It’s probably time to find some treatment. But I don’t want to stop using stories and metaphors, because it’s a powerful explanation tool.
Complex vs. Complicated
So how to simplify things without confusing people? Jurgen Appelo is an incredibly insightful person, and let’s investigate his approach for simplification. In his book, Management 3.0, we can find a chapter about simplification, where Jurgen digs into the differences between complex and complicated. Up until reading “Management 3.0”, I was confident that complex and complicated are synonymous, while they are apparently not.
Simple well-structured software can show very complex behavior, whereas complicated messy software can still behave orderly and fully predictable. - Jurgen Appelo
Jurgen uses two dimensions to explain the difference:
The first dimension is about the structure of a system:
- Simple - few features, easily understandable
- Complicated - many features, hard to understand
The second dimension explains the behavior of the system:
- Ordered - predictable
- Complex - somewhat predictable
- Chaotic - unpredictable
The structure and functionality of a basketball are simple - it’s made out of rubber, and it bounces. A clock is way more complicated, but a trained watchmaker understands it - he can take a watch to pieces and put it back again. People, for example, are not as predictable as a ball. There is no simple cause and effect: searching for meaning in life or politics. The atmosphere or stocks are chaotic; given the technologies we already have, we still can’t figure out many details.
Ways to remove unnecessary information
There are two approaches to exclude redundant information. Simplification touches only the first dimension, moves vertically. It makes the structure more understandable, by omitting some elements, moving from top to bottom. When people get the core idea, you can slowly expand the structure. Human brains absorb new features if you keep the behavior unchanged. For example, to explain an F1 car start with a regular car and gradually add enhancements.
Linearization makes the behavior more predictable, moves axis horizontally. And here is where the complications start: if something is unpredictable, you can’t present it as ordered. As Jurgen mentioned in the book, simplified behavior doesn’t make it easier to understand the real and messy concept. Be careful not to linearize something because the reduced behavior of what you explain may not be what your listener had expected. If something is unpredictable, use similarly variable metaphor.
Simplified tutorials - Do or do not?
Let’s come back to the initial idea of creating simplified development tutorials for all interested in changing their careers. There is nothing wrong with creating a shortened programming guide. Learning a tool or technology is a straightforward process: the more you progress, the more advanced topics you get.
However, I have to distinguish learning to code from getting paid to build software. Software developers solve human problems, and humans are complex by nature - they change their minds, and it impacts developers. From this perspective, IT doesn’t look like an ordered world. Furthermore, Maciej Aniserowicz, a Polish IT blogger, in one of his YouTube vlogs shared an interesting thought:
Programming is a constant fight with machines. You want them to make what you promised to a project manager. Computers tend to disobey your orders and throw unseen exceptions.
It sounds like pure chaos, or Maciej is overexaggerating? What’s your approach to simplification?