I would be outright lying if I said I didn’t have an ego attached to what I do.
I take pride in software that works; in a beautiful solution to a hard problem.
I take pride in seeing my work in the world.
I take pride knowing that I’ve solved a lot of hard problems in my career, and I feel prepared to do it again.
There are two problems here.
The first is eloquently illustrated by this meme:
The second is far more subtle:
When we’re developing software in a team, those small bits of ego add up. Because it’s not just one person on the team that thinks that way: everyone tends towards that about something.
The problem with the ego here is that it gets in the way of true confidence in your code. Ego is great — without it we may have never tried to get better; but the progress your team makes comes from true confidence, not from the ego.
What’s the difference?
If I have tests that prove how the code works (and doesn’t work!) with certainty, that isn’t ego. I ‘have the goods’ to back it up, so to speak.
Contrast that if there aren’t tests in place.
You, of course, know it couldn’t possibly be your code that’s causing the problem, right? That is, until it turns out to be your code that causes the problem.
For the record, I had this happen to me just a week ago: There’s a particularly hard-to-test aspect of Angular (a form/component unloading after a failed? save) that has been causing trouble, and because it exists at the boundaries; it’s particularly insideous to test and it only intermittently happens in certain environments. All this means that while my ego believes it couldn’t possibly be something I wrote, deep down, I don’t have the confidence to assert that; because there aren’t tests in place around it.
You probably know where I’m going with this. There’s a hierarchy to actual confidence in your system, in descending order. Incidentally confidence works inversely proportional to ego, here.
Systems built on TDD (High confidence, low need for ego)
Systems covered with Unit Tests and Integration Tests
Systems covered with Integration Tests
Systems covered with no tests (Low confidence, high need for ego)
Tests can give you confidence, but their confidence comes from the foundation they were built on. When that confidence isn’t there, ego takes over, and that can be bad for a software team.
P.S. For the foreseeable future, I’m migrating my in-person TDD immersion training for .NET software teams to online training. This training helps ensure the entire team is operating from the same worldview with regards to TDD and tests. It’s a chance for your team to learn TDD together, and learn where it works and doesn’t work. It’s a chance to build team trust and confidence both in themselves and their software. It’s a chance to help your team hit their deadlines without all of the panic that usually ensues. If this sounds like something your team could use to help it build better software, faster, go to https://www.doubleyourproductivity.io/paid.html to learn more.