We engineers are masters of self-deception when it comes to our aptitudes to handle complexity. We believe we are way better at handling complexity than we actually are. In practice the level of complexity that people can master (me including) is disappointing low.
Instead of self-deceiving ourselves, we should embrace our limitations and aim for simplicity. This is what all geniuses of our time have been preaching for. Simplicity prevails.
“Simplicity is the ultimate sophistication.” — Leonardo da Vinci
It is common for tools to be too complex. We all know that only a tiny fraction of the features of Word are used, still the usual trend for a product is towards adding more and more features. Often, the best thing for a product is taking something away from it. Only simple tools prevail.
One problem with simplicity is that it is often confused with easiness or triviality. Easiness and triviallity are subjective properties relative to a user. They refer to the sense of familiarity or ordinarity. Simplicity is an objective property that refers to purity, the absence of mixing distinct elements.
Let us look at some simple features that are clear wins.
Using Venn Diagrams for Access Control
Have you ever been confused by the security settings of an application, not knowing what would be accessible or not to other users? Venn diagrams are simple and can be used to make an interface intuitive. Win!
Using Pictures instead of Texts to Log
Have you ever found yourself overwhelmed by the difficutly to compare tens of print statements to understand state mutations over time? Comparing texts is hard; comparing images is easy. Using a visual log is simple and supports better debugging. Win!
Using Examples to Test Programs
To test your code you exercise it with chosen inputs that serve as examples? Well, you could have invented unit testing. As Fowler says: “Kent’s framework had a nice combination of absurd simplicity and just the right features for me”. Win!
Using Live Code instead of Static Code to Understand Programs
Have you ever felts exhausted trying to mentally run code in your head when inspecting static sources? The underlying question is: what prevented you from runinng it and see it live? Finding a suitable unit test and breaking at the start of the method you are inspecting can be automated to become a one-click operation. Win!
Have you ever been repelled by the sheer amount of options in a search form? For instance this one. That’s tackling the problem of search wrongly. Google, Airbnb, and Facebook got it right, offering essentially one unique text input and hiding the magic of relevance matching. Win!
These examples show what I consider to be the level of complexity we can handle, and should aim at. These features are so simple to use they will immediately look easy and trivial. This is a good thing.
://ewernli 
Very nicely written. One thing I would take a slightly different angle on though is – instead of emphasizing the need to run code to understand it, ideally code should be so simple that running it mentally is easy. This is where lambda and shell pipelines win – there aren’t multiple variables that change (i.e. immutability). That’s the prevention of complexity, but failing that yes unit tests that advertise the functionality are a cure for existing bad code. On the other hand – complex tests with mocking etc. are also hard to understand. If code is written well, mocking shouldn’t be needed (though that’s an asymptotically impossible goal).