Introducing friction

When things are too easy, it is no fun, coding with an AI included.

Jakob Wolman
6 min read2 days ago

Have you ever tried playing a computer game that was way too easy, lay a jigsaw puzzle in five minutes, or had an AI write your email? It is easy, and satisfying to complete a task so quickly. But in the long run, it makes the whole endeavor boring. There is no challenge, no learning, and it requires little skills.

Just like many other natural systems, humans are antifragile. Our muscles are strengthened by stressors (exercise).

I’m known for always taking the stairs. As a matter of principle, I don’t use elevators unless I have to go more than five floors up. I don’t mind riding the elevator, and I also think it is a pain to climb the stairs. But I know that the little exercise I get during a normal workday is worth much more than the comfort of riding an elevator.

The same thing is true for our minds. We need challenges to be able to learn. It is often said that we learn from failure. This is true, but little is learned if the failure is absolute. Instead, the failure should be small enough that we can find a new path that leads to success. Small failures are the same as friction. Small enough failures will allow us to safely experiment, and find out what is working and what is not. Without friction, there is little learning. It is also not very motivating work.

Consider playing a board game. The first couple of times you play you mostly learn the rules. If it is a straightforward game, designed for kids, the rules are often easy to understand. But most board games for kids are built on chance, giving little opportunity for improving skills. For a grown-up, they quickly become boring, beyond the joy of playing with kids. There will be little challenge or learning. A more interesting board game will allow you to explore the rules and try different strategies. There might be different ways of winning the game, having to adapt to your opponent. You might be able to develop long-term strategies, and short-term tactics and learn tricks that bend the rules of the game. As you become a more skilled player, you might want to invest in extensions of the game to add new rules and new possible strategies. The gamemakers know, that as long as you keep learning, you will keep playing.

I believe much of the same is true in any craft. As we become more skilled we can create new things and keep learning. We can take on bigger challenges and overcome new obstacles.

This is also true for software development. When you start as a junior software developer, straight out of school, you think you know everything (at least I did when I graduated as an engineer). It takes a few months before you realize that you know very little. This is a humbling experience. You start to understand how much there is to learn. Once you get over the blow to your ego, you will pick up new skills. You learn some of the basics, and understand how systems work, before you start to abstract them away, moving up the stack to use new tools and languages.

Software development today is very different from only ten years ago. System complexity has grown immensely together with new technologies and new possibilities. There are so many more strategies you need to understand when you build a system today. What platforms should we build on, what languages, and what are the scale, availability, data, and security requirements? Should we build or buy services to solve specific problems? As the world of software has grown more complex, the tools to support the development process have become more sophisticated. Many of the problems some of the dinosaurs of software development (people like me) learned to deal with have now been hidden under layers of abstraction. As a software developer today, you seldom have to optimize garbage collection, care about networking between your servers, read machine logs, or do other things that were common in the pre-cloud era.

Recently, software developers have been presented with a new abstraction layer through AI coding tools. You can now prompt your way to an application. Copying and pasting from Stack Overflow has been replaced by autocomplete-style coding support. You can get fully running applications without having to care much about the language they are written in, how they are deployed, or how the code is written.

Until….

Until your AI model no longer can solve the increasingly complex task you want your application to be able to perform.

Until something goes wrong and the application keeps throwing strange error messages or simply does not work in the way you expect it to.

Until the business comes with a very specific requirement that you know AI cannot support you in building.

Until you have to change cloud vendor, do a security assessment, and explain your code to an investor.

Until your application has to do something novel, something nobody has ever had software to do before.

Until you have to scale the project with 10 engineers to meet critical business deadlines.

Don’t get me wrong, I think AI coding tools are fantastic. Especially for more senior engineers who know what they are doing and can become more productive with the support of tools. But for junior engineers, using AI will remove so much friction that little learning will happen. Instead of gaining experience in building, experimenting, and understanding a full system, they will revert to making the code an AI wrote pass tests and run. Instead of understanding why an error is thrown the whole trace is pasted into an AI chat hoping for a solution, but never understanding the root cause. This provides way less learning and much more frustration.

Just as we have built a generation of developers who are used to not having to care much about infrastructure, machines, networking, and other basics (remember, the cloud is just someone else’s computer) we are now standing on the verge of training a generation of developers not having to care about some of the fundamentals of how to create good software. I might be old-fashioned, and even borderline alarmistic, but I strongly believe that the friction junior developers experience is the learning they need to go through to understand the full system.

AI tools have the potential to remove dull and repetitive work, making us able to spend more time solving actual business problems. However, it should not be at the cost of missed learning opportunities. Before you abstract a vital part of the software development process away, you have to understand it. At least if you are going to learn how to build great software.

Therefore I encourage people to not be afraid of friction. Don’t be put off by the investment in time and effort to do something an AI could do for you in minutes. The learning and understanding that come with the work are often worth more than the output itself.

Hold off with using the AI for answers. Go explore, and employ an AI tool when you have done enough research to understand if the solution presented to you makes sense or not. Optimize your work for learning, not for speed. I know it might sound counterintuitive, but throughout the lifecycle of the software you are building, it will make you faster. Not only that, the learning you pick up along the way will prove valuable in your next project as well, building your skills and becoming a better developer.

--

--

Jakob Wolman
Jakob Wolman

Written by Jakob Wolman

Systems thinker and agile coach turned manager. Learn by sharing and discussing. Passionate about knowledge sharing.

Responses (1)