DEV Community

Cover image for Software Engineering is a Loser’s Game

Software Engineering is a Loser’s Game

Tyler Hawkins on September 20, 2021

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 dep...
Collapse
 
bdelespierre profile image
Benjamin Delespierre • Edited

I like your article, Tyler. And I love your metaphor, I believe there's some truth to it. But I I've always professed quite the opposite:

An expert is a person who has made all the mistakes that can be made in a very narrow field.
― Niels Bohr

My advice, especially to new developers, is this:

Get out there. Code something. Code anything. Do something ugly. Push it to production. Feel the pain of seeing it falling apart when your first users input some unexpected data or use it in a very, very silly way. Dig your way though the logs. Understand what's going on. Fix it. Make it better. Make it more ergonomic so people use it correctly without you telling them. Repeat the cycle as fast as possible. Accumulate experience.

Development is not like tennis or ping-pong (sorry). It's an art. And there are no straight do or don't out there. Just a bunch of principles and recommendantions that you should always take with a pinch of salt. At the end of the day, those architecture gurus are not there on a late saturday night when you're debugging your app.

While programming is little more than talking to the machine, development is another level. It's a communication, a dance, between machines, people, businesses, structures, infrastructures. It's debatable one can ever find an axiomatic truth about what makes a good software. It's like trying to define once and for all what's good dancing 💃

If you think I'm wrong, then I suggest you write down your findings in a methology book on "How to deliver value with certainty using software." You're a guaranteed billionaire overnight 😂

All that said, I mostly agree with Tyler and just wanted to have some fun here 🙃 Have a good one and follow me if you'd like to know more on how to improve your coding game 😎

Collapse
 
thawkin3 profile image
Tyler Hawkins • Edited

Thank you Benjamin for the thoughtful reply!

I love the Niels Bohr quote and wholeheartedly agree with it and with your summary of it:

Get out there. Code something. Code anything. Do something ugly. Push it to production. Feel the pain of seeing it falling apart when your first users input some unexpected data or use it in a very, very silly way. Dig your way though the logs. Understand what's going on. Fix it. Make it better. Make it more ergonomic so people use it correctly without you telling them. Repeat the cycle as fast as possible. Accumulate experience.

Correct me if I'm wrong, but I think we are definitely mostly agreed here, saying the same thing but in slightly different ways. Trying and failing and gaining experience is a valuable thing. And then, we learn from these mistakes. After feeling the pain of our code breaking in production, we learn these lessons and apply them consistently.

Taking your example, maybe the user entered some unexpected input which broke the app, so now you as the developer have learned that you should write code that can fail gracefully or that can handle bad input. You've learned to write better unit tests (or maybe you didn't write any tests at all! 😱). You've learned to think about more than just the happy path and to think about how things can fail. And hopefully you've documented this knowledge somewhere that you can frequently refer to it so that you don't make these mistakes again.

So in short, through your experience, you learn to stop making the mistakes in which you've previously defeated yourself. You figure out how to play the loser's game.

P.S. I'm not sure if you've ever read Michael Lopp's essay on "Stables and Volatiles", but based on some of the ideas you've expressed I think you would really enjoy it: randsinrepose.com/archives/stables... 😄

Collapse
 
bdelespierre profile image
Benjamin Delespierre • Edited

P.S. I'm not sure if you've ever read Michael Lopp's essay on "Stables and Volatiles", but based on some of the ideas you've expressed I think you would really enjoy it: randsinrepose.com/archives/stables... 😄

Thanks a bunch, I'll have a look 👀

Correct me if I'm wrong, but I think we are definitely mostly agreed here

You are not wrong. I might add that pain is, IMHO, an essential component of the learning process. Trying to avoid it and staying in your comfort zone is perhaps the worst mistake you can make in that looser's game. One that will surely impede your growth and therefore, your ability to avoid making other mistakes.

A personnal example of mine is that I rejected automated testing until 2017, deeming them worthless and demeaning people who wrote them. Simply because I was afraid of subjecting my work to an objective standard of measurement 🥲

So, beat yourself up as much as you can tolerate 😅 Trust me, the payoff is huge.

Thread Thread
 
vberen profile image
Nicklas Wessel

I think developers are masochist.
We like the frustration of finding a solution to a problem, or debugging for hours (i mean, i hate it.. i hate that i somehow love it)

But damn, it is painful sometimes

Thread Thread
 
bdelespierre profile image
Benjamin Delespierre

Development is indeed an activity we love to hate 😂

Thread Thread
 
rorygren profile image
RoryGren

But the kick, oh that kick, after the hours of "losing" shots, seeing your artwork in the wild, handling everything users can throw at it...
Yeah. Worth it!
Thanks for the article. It's a good read!

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

Added some clarification here! dev.to/thawkin3/comment/1iaka

Collapse
 
pedrobritto profile image
Pedro Britto

Thank you for this post, Tyler . Thinking of software engineering as a loser's gamer is really insightful and you made some good points there. By not using automation and not following some simple checklists we are in greater risk of beating ourselves down. It's quite easy to avoid.

Cheers!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Pedro!

Collapse
 
dvddpl profile image
Davide de Paolis • Edited

Loved this article. and loved the parallel with Ping Pong.
I always found that we developers have a tendency of
shoot ourselves in the foot by underestimating tasks, overengineering solutions or simply by focusing on wrong things ( cure the symptom of a problem and not solve the root cause).

Expecially loved you list of unforced errors and i could not stress more on the first one:

Not understanding the problem before trying to code a solution

Too many time I have seen team members diving head first into coding something without previously properly thinking about the problem, understanding the context and the scope, coming up with a couple of alternatives and discussing them with other peers, and instead find themselves with a rejected merge request days or weeks later..
Thanks for sharing

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Davide! Those are some great additional items you've identified to add to our list of unforced errors.

Collapse
 
sangpham2710 profile image
sangpham2710

high-quality content

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you!

Collapse
 
gg2021 profile image
GG2021

Great article! Some other things that may fit into this list:

  • Who is playing the game? Are you playing singles (tennis), doubles (badminton), or team game (soccer)?

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.

Collapse
 
ndrone profile image
Nicholas Drone

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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.

Collapse
 
maddy profile image
Maddy • Edited

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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.

Collapse
 
subfuzion profile image
Tony Pujals

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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.

Collapse
 
jaygcoder2020 profile image
Jay G

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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:

Collapse
 
rusimovmilan profile image
Milan Rusimov

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Some clarification that might be helpful: dev.to/thawkin3/comment/1iaka

Collapse
 
rusimovmilan profile image
Milan Rusimov

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 🙂

Collapse
 
bklau2006 profile image
BK Lau

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...

Collapse
 
justintrang profile image
Justin Trang

I like your way of thinking - but I dont agree with you.

Stop making error, or making less error won't help you win the game.
It also depends on how you define "the game", but I believe it's more important to learn form your errors and dont make them again.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Tell me more!

I don't think I'm understanding your statement here though. Isn't "stop making errors, or making less errors" (my words) the same thing as "learn from your errors and don't make them again" (your words)?

Collapse
 
justintrang profile image
Justin Trang

I think "stop making errors" sometime stop you take risks.
Personally I think it's ok to try and fail, and learn from your mistakes

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

Gotcha, thank you for clarifying! Yes, this is a great point. We absolutely should continue to innovate and try new things and not be afraid to fail.

So maybe something I should help clarify is that when I talk about learning to stop making unforced errors, I don't mean to stop taking risks. Professionals in any field still make mistakes, and no one is infallible.

But thinking back to the analogy of amateur tennis vs. professional tennis, if we can learn from our past mistakes and stop hitting the ball into the net repeatedly, I think that is a good thing. As an experienced developer innovates and explores and takes risks, they would still be wise to apply lessons they've learned in the past so that they don't repeat the mistakes that they've made early on in their career.

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

Added some general clarification here since I'm seeing a recurring theme in some of these comments! dev.to/thawkin3/comment/1iaka

Collapse
 
z2lai profile image
z2lai • Edited

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:

  • understanding the problem before trying to code a solution
  • understanding the tools or programming languages we use
  • carefully reviewing our own code before asking for a code review
  • manually testing our own code before asking for a code review
  • writing unit tests
  • following agreed-upon company standards

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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.

Collapse
 
bpkinez profile image
Branislav Petrović

Great and interesting article! There should be more such quality articles on dev.to.

Thanks Tyler!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Branislav!

Collapse
 
dedhammaman profile image
dedhammaman

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Perfectionism, no. But growth, self-improvement, and ownership, yes!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Added some clarification here: dev.to/thawkin3/comment/1iaka

Collapse
 
finfin profile image
Fin Chen

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

Collapse
 
thawkin3 profile image
Tyler Hawkins

Some clarification that might be helpful: dev.to/thawkin3/comment/1iaka

Collapse
 
rmadhuram profile image
Raj Madhuram

Nice article! I was reflecting a bit on who is the opponent here: We often fight tight deadlines, shifting business requirements, ever changing technology landscape, losing talent to competitors etc.

Although there is truth to this article's assertion, I believe the opponent's tactics is also a big factor!

Collapse
 
exoticallisticsm profile image
Salieu Sesay

The article is really well written.

I really appreciate the insight and pointers to become a better coder, while also avoiding careless mistakes that make coding more difficult than it already is.

Thanks Tyler, and Cheers...🥂

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Salieu!

Collapse
 
apongpoh profile image
Apongpoh

Thanks for the awareness! well written article.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Apongpoh!

Collapse
 
papaponmx profile image
Jaime Rios

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!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Jaime! I’m glad you kept reading!

Collapse
 
j0ldfield profile image
j0ldfield

That's a terrible article to write about haha. There is merit though

Collapse
 
thawkin3 profile image
Tyler Hawkins

Tell me more!

Collapse
 
_juliotati profile image
Júlio Tati

A M A Z I N G 🔥🚀✨
The language used and all hits close to home, thanks for sharing the knowledge. ✨

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Júlio!

Collapse
 
gokulaet profile image
Gokul Raj

Thoughtful content and Well Written...!!! Thanks

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Gokul!

Collapse
 
ryanhaber profile image
Ryan Haber

This post is great. Very simple, very to the point, very well stated.

Also, the title was arresting, which is perfect.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you Ryan!

Collapse
 
lgcallejask profile image
lgcallejask

I really enjoyed reading this short article. Thank a lot for sharing!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you for reading!