Did I Actually Write That?

As young to mid-level programmers/developers/whatever, we often find it hard to fess up to mistakes or admit ignorance.  We're young, we're lacking a stream of successes on which we can build our confidence, and if we're in a weak work environment we're lacking a mentor who gives us a positive culture which acknowledges weaknesses and failure -- but helps us learn to grow past those.

As more seasoned whatevers we often let egos get in our way of fessing up to those mistakes or weak spots in our knowledge. That might be even worse than the factors earlier in our careers, but regardless it's still a large problem because it's giving us and our colleagues a false sense of security. I also think it gets in the way of, or tamps down, the desire for continual improvement in our craft.

I always find it refreshing to hear industry leaders like Jeff Atwood bring this up in very public venues like Dot Net Rocks. On one of the DNR shows Atwood had a great quote along the lines of "A young developer's code sucks, and they don't know enough to admit it, much less fix it. A professional developer knows his code sucks and works to fix it."  Jeremy Miller said something very similar on the Alt .NET Podcast, and I've seen any number of amazing brain children on Twitter fess up to the same thing.

Hearing and reading folks like that step up and admitting their failures certainly makes it a lot easier for us folks down on the food chain admit ours. It ought to at least. If you can't, then you ought to re-evaluate where you're checking your ego when you sit down to code...

Several months ago I was working on a project that had been idle for four or five months. I was looking over a bunch of tests to try and refresh myself about how a part of the system functioned -- the class and method names I chose at the time ended up being not as expressive as I'd thought when I initially wrote them, and I was using the tests to drive back through the behavior.

I came across a test that was checking a custom sort routine's correctness. Stand up a list of items in unsorted order, call the sort routine, then check the order's sorted. Simple, no?

I started reading through the test's implementation and broke out in loud laughter. My colleagues at Quick Solutions, who already think I'm nuts, must have had that impression cemented in. Why?

I found the assertion I was doing to check the validity of the test was simply counting the number of elements in the list. What the hell was I thinking when I wrote that? Did I actually write a sort validation that simply counted the number of elements after sorting? Obviously, because TFS's history showed me as the guilty culprit.

I have no idea what I was doing when I wrote that code, and I've no idea why I didn't write more tests around that functionality.  Thankfully my implementation was correct, so the sucky, stupid test didn't impact the rest of the system.

That was the only bad code in that entire project of 45K lines of code. Every other line of code was such a work of art that it brought tears of joy to my eyes. Right.

What's the point here? Several.  First, your code sucks and you know it. Fess up to it.

Second, figure out why that code sucked and don't make the same mistakes tomorrow.

Third, and this is the hard one, be open about the mistakes you've made. Check your ego at the door(which is a hard thing), because your openness will benefit your entire team and your project. Your credibility goes up with your colleagues and your client because you're showing you're concerned about quality: You know you need to pay off that technical debt. You know you're working on educating yourself and your team to improve their chops.

Hopefully you'll also find this trait spreading to your colleagues and hopefully they'll start the same process: admit their code sucks, move on, and improve what they're writing.

Your code sucks. It's OK to admit it if you're working on fixing it. Honest.