Raising the bar


Continuous improvement is absolutely essential for any serious software developer.  Personally, my drive for constant improvement is not so much the next shiny developer toy (though this happens occasionally), but the idea that there is always some way to deliver value to the customer better and cheaper than what I’m doing now.

Driving personal improvement can be a great example to teammates, but for an entire team (or even teams you don’t work with) to improve, you’ll have to expand your horizons.  You’ll need to maximize the value of your keystrokes, so to speak.

So you sent an email to your teammates about a possible design improvement.  Why not blog about it?  So you read a new design or patterns book.  Why not give your team a presentation and summary?  So you refactored some gnarly code.  Why not tell the whole team on your improvements?

Keeping self-improvement to your self might not improve your situation as much as you might like.  Unless you’re flying solo, other team members will eventually write code that you will despise.

###

Driving local improvement

Instead of deriding poor design, look towards collective improvement and raise your team’s collective bar.  Some different bar-raising techniques include:

  • Creating a team blog
  • Starting a book club
  • Hold brown-bag sessions on patterns, practices, refactorings, and others
  • Pairing and mentoring sessions with junior developers

If you’re only improving yourself, your code will improve, but it won’t impact the team’s codebase as much as everyone’s code improving.  And it’s not just code either.  Communication and process improvements will provide at least, if not more value than coding improvements.  Body language can tell you if you’re on the right track when running ideas past your domain experts.  If you can’t recognize these signals, you’re creating quite a bit of waste.  Driving awareness and action of improvement areas are part of what’s required of you to earn your pay.

Driving community improvement

Something I’ve made a personal commitment to do is to try and drive some community improvement.  I’m already at a great place that expects XP practices, and we can always expand and improve, but every shop I run into has serious dysfunctions.  I’d like to try to raise the bar through:

  • This blog and the literally tens of people that read it
  • Screencasts on shiny new objects values, principles and practices I think are important
  • Local book clubs
  • Skype/VNC sessions with interested folks (probably for a small fee)
  • Code camp sessions

I have my selfish reasons for these things, as everyone else’s code is terrible.  Except mine, of course.  You can hear angels singing when I apply ReSharper shortcuts.

There are about an order of magnitude more bad developers than good ones, and another order of magnitude from good to great.  The onus is on the upper-level practitioners to mentor others and raise the collective bar of our community.

Should you TDD when flying solo?