I’ve recently become fascinated by the idea of “winner’s games” and “loser’s games.” There are several great articles which explain the idea in depth, but here’s a quick summary:
An observation was made by Simon Ramo in 1973 that there is a big difference in how games are won in amateur tennis versus professional tennis.
When two amateur opponents are playing, the game is often won not through the winner’s great skill but because of the loser’s mistakes. The loser often commits unforced errors by hitting the ball out of bounds, missing easy shots, or double faulting. In other words, the loser beats himself. Points are “lost” by the loser more than they are “won” by the winner. This is a “loser’s game.”
When two professional opponents are playing, the game is won primarily due to the winner’s skill. Neither player commits many unforced errors. The winner places his shots well and outperforms his opponent to defeat him. Points in this kind of game are “won” by the winner more than they are “lost” by the loser. This is a “winner’s game.”
So, if you’re playing a loser’s game, a winning strategy is to simply try to avoid making mistakes and let your opponent beat himself.
(If you’ve ever played tennis or ping pong before, I hope at this point you’re nodding your head in recognition. As an avid ping pong player, I’ve seen this scenario play out in the office at work on a daily basis.)
The application of this observation is that you should attempt to understand whether any given activity you’re involved in is a winner’s game or a loser’s game. Gaining that understanding teaches you how you should play the game.
You can read more about these ideas in this article by Charles Ellis, this article from the FS blog, or this article from Ben Hosking.
Parallels to Software Engineering
Now, what if we consider software engineering to be a loser’s game? That is to say, we often beat ourselves by committing unforced errors and making mistakes. If we are amateurs, so to speak, how can we keep the ball in play rather than hitting it into the net?
It’s a simple thing to say, “If you want to be good, just stop making mistakes.” But that’s somewhat unhelpful. That’s like saying to those in poverty, “Why don’t you just stop being poor?”
It’s also unhelpful if we take this analogy too far. If avoiding mistakes is the ultimate goal of software engineering, is the best software engineer the one who writes no code or does nothing? Obviously, no. Software engineers are paid to write code to help bring to life some product in order to achieve some vision (make the business money, solve a real-world problem, simplify a task, etc.), so that must be the real ultimate goal.
So it appears that we must balance producing valuable output with avoiding mistakes. This leads to an interesting thought experiment: In what ways do we beat ourselves, and how can we avoid making these amateur mistakes?
Unforced Errors
Here’s a list of possible unforced errors we commit. I’m sure you may be able to add more to this list as well.
Not understanding the problem before trying to code a solution
Not understanding the tools or programming languages we use
Not carefully reviewing our own code before asking for a code review
Not manually testing our own code before asking for a code review
Not writing unit tests
Not following agreed-upon company standards
Solving These Unforced Errors
Now that we’ve identified some potential unforced errors, how do we avoid making them?
For starters, we can put safeguards in place to help us catch and correct our mistakes before they become too costly. All code repos should be configured with code linters, code formatters, and a suite of automated tests. These safeguards can be run as part of a CI pipeline prior to allowing any code to be merged.
We can also be more thorough in our own attention to detail when writing code. After creating a merge request, we should always do a self code review before asking others to review our code. We should always manually validate our changes as well.
Nothing is more frustrating as a code reviewer than reviewing someone else’s code who clearly didn’t do these checks themselves. It wastes the code reviewer’s time when he has to catch simple mistakes like commented out code, bad formatting, failing unit tests, or broken functionality in the code. All of these mistakes can easily be caught by the code author or by a CI pipeline.
When merge requests are frequently full of errors, it turns the code review process into a gatekeeping process in which a handful of more senior engineers serve as the gatekeepers. This is an unfavorable scenario that creates bottlenecks and slows down the team’s velocity. It also detracts from the higher purpose of code reviews, which is knowledge sharing.
We can use checklists and merge request templates to serve as reminders to ourselves of things to double check. Have you reviewed your own code? Have you written unit tests? Have you updated any documentation as needed? For frontend code, have you validated your changes in each browser your company supports? Have you ensured that all user-facing text is translated? Have you ensured that the UI meets accessibility standards and guidelines?
By performing these checks ourselves, aided by automated tools, we show an added measure of professionalism and respect for our coworkers. Trust will grow and velocity will increase. The key is to be diligent and disciplined.
Conclusion
Software engineering is a loser’s game. So let’s learn to play the game and stop losing to ourselves.
Latest comments (57)
A M A Z I N G 🔥🚀✨
The language used and all hits close to home, thanks for sharing the knowledge. ✨
Thank you Júlio!
This post is great. Very simple, very to the point, very well stated.
Also, the title was arresting, which is perfect.
Thank you Ryan!
Great and interesting article! There should be more such quality articles on dev.to.
Thanks Tyler!
Thank you Branislav!
To extend the metaphor for software engineering, it's only a loser's game while you're an amateur. At some point, you are in fact playing a winner's game, creating great software based on your creativity along with acquired skills and wisdom gained through experience and discipline.
Absolutely! I've been thinking that I should follow this up with a second article about making software engineering a winner's game. Once you move past the amateur mistakes, there's definitely a point where you can begin to build groundbreaking new software and where you can innovate and disrupt. That's where the real fun begins.
Thank you for this interesting article! ❤
This week at my job I made a similar mistake, I submitted an unfinished pull request and I felt so incompetent! 😓
I think it's important to persevere though. To me it works like this: when you're trying something new, you do it once and maybe you get 50% of the things correct. The next time, you get 60% of them correct. The next time again, you get 80% correct, and so on.
You're right about having a check-list, but there are circumstances in which you just don't have the time to look at it, so repetition is crucial.
Absolutely! It’s all about growth. It’s ok to make mistakes, and sometimes they’re embarrassing! The important part is to learn from them so that we get better.
Thank you all for the thoughtful comments! I'm seeing several comments that indicate that I should better clarify some thoughts when it comes to making to mistakes.
Yes, everybody makes mistakes. Yes, it's ok to make mistakes. Yes, even "professionals" make mistakes. No, I'm not advocating that we should never try new things. No, I'm not advocating that we shouldn't take risks.
What I am advocating for is that we learn from our mistakes. Let's not keep making the same mistakes over and over again. When we do make mistakes, let's accept responsibility, own them, catch them quickly, and correct them quickly. I'm advocating for growth, self-improvement, diligence, and ownership.
Going back to the tennis metaphor, let's learn to stop hitting the ball into the net when returning an easy shot. It's ok that we sometimes do, but let's learn why we do and learn how to not hit the ball into the net as often.
Thank you again to everyone that has read or shared this article! It's been amazing seeing the community response and attention this article has received.
Good article and good analogy with the real life example, but I don't think that software development is a loser's game.
You only play a loser's game when you don't learn from the mistakes you make and from other people mistakes.
It's impossible to not make a mistake whatever you are doing in your life.
And there is nothing bad in making mistakes.
Most open minded people encourage themselves and people around them to make as much mistakes they can and to celebrate them, because mistakes are a essential part of the life and the process.
They can't be ignored.
The point is not to don't make any mistake, but to make them as much as you can and to reflect on them and learn from them.
Some clarification that might be helpful: dev.to/thawkin3/comment/1iaka
Understood.
Thanks for clarification.
You obviously made a mistake since you got so many comments and had to clarify additional things, and that's great.
You will definitely learn something from this post.
On the other side, you made a great headline since so many people read this.
Anyway, congrats on your courage to publish the post.
Keep up the good work and good luck 🙂
Great article! Some other things that may fit into this list:
Singles: making the mistake of not having someone check what you’ve produced
Doubles: not knowing your partner well (or communicating effectively) leads to mistakes, e.g. both running for the same ball at once (accidentally working on the same task at the same time)
Teams: bad communication can cause mistakes. Having a team of totally different skill levels and not managing that carefully leads to mistakes (passing a difficult ball to an inexperienced player). Not making team members fully aware of the direction you’re heading leads to mistakes (own goals).
Time management issues: when under pressure, people cut corners or make silly mistakes. If developers have enough time, they can do a good job the first time. This could be considered a business/management issue… but in some workplaces there is often too much time time pressure.
Not re-testing the whole solution after making changes. Sometimes you change one thing and another thing breaks. A well known plane manufacturer reduced testing time (in an effort to save costs) and didn't test thoroughly after making changes. It is speculated that this led to two separate plane crashes from same failure.
I’ve missed more than 9,000 shots in my career. I’ve lost almost 300 games. Twenty-six times I’ve been trusted to take the game-winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.
-- Michael Jordan
Some clarification that might be helpful: dev.to/thawkin3/comment/1iaka
My first reaction was a little bit offended by the title of the article, then I read it and I loved it.
I liked the analogy and the way you explained the concepts.
Thanks so much for sharing!
Thank you Jaime! I’m glad you kept reading!
I think one thing that contributed greatly towards what you termed as "loser's game" is that fact that software engineering time span of evolution shrinks from about every 10 years to every 3 years. That stated, an average software engineers/programmers hasn't yet attained the proficiency or mastery required before being distracted by another new tool/language/framework that happens to come along or in vogue.
In other words, we are becoming "expert beginners" in lots of areas; doing just enough to get things done.
For more informatuion on expert beginners, read:
daedtech.com/how-developers-stop-l...
Interesting introduction to this concept of loser's game! What I took away from this is:
In tennis, to win the losers game, you need to know the basics to avoid unforced errors which is hitting the ball over the net and inside the court. Whereas in software engineering, the basics aren't just those couple of things, but rather that huge list that you wrote in the article:
So it looks like I have a lot of basics to consider to avoid those unforced errors before I can even consider myself an 'amateur' that's winning the losers game.
I think it really depends on what side of the coin you look at. In your analogy with the professional players. If one player, places his shots all over the court did I really win based on skill, or did I just tire out my opponent by placing him in a stressful overworked situation enough that he started to make mistakes, and beating themselves. Playing back to the losers game.
I believe software engineering is very similar. Most of us are put in stressful situations, to where we believe we need to move fast. Applying stress, and having to rush is where mistakes are made.
Where software engineering becomes a winners game, is when we have a voice. When we can push back on a timeline. When we can ship the product when it's done. Move at a speed that matters.
Absolutely! Outside pressures can cause us to make mistakes as we rush to get code out the door. Having a voice, working under reasonable deadlines, and working in a psychologically safe environment are all crucial factors to success that you've identified.
Couldn't agree more. I think it's a lesson too on what to automate/delegate; admittedly people are afraid of automating too many things, but sometimes they're worth doing. One less bullet to soot you in the foot later.
Now on the code review side, things can get pretty dicey when people have different ways/ideas of doing stuff. That said, keeping it as simple as possible works wonders. Simple = less mistakes (typically), plus they're easy to test.
Good insight! Yes, when it comes to code reviews, it's important to remember that humans are involved in the process, and humans can be irrational and emotional creatures. 😅
These are some of my favorite articles when it comes to having productive code reviews:
I smell perfectionism in this article, which has invaded the industry of developers. It's good to do these things, but not the end of the world if mistakes are still made, which they are.
Perfectionism, no. But growth, self-improvement, and ownership, yes!
Added some clarification here: dev.to/thawkin3/comment/1iaka