Photo credit: nyuhuhuu
I just read a thoughtful article, Revisiting XP: be a thoughtful programmer by exercising more collective ownership. The article discusses various recommendations for building, and being part of, a high-quality, high-performing–and highly-enjoyable–software development team. This is what I call a “software A-team”.
The article starts off rather disconcertingly, on the bleakness of the typical software engineering team:
I get astonished the more that I find how software engineers are passionate about struggling. Really, I sense a consistent appreciation for masochism throughout our beloved software development community nowadays. It shouldn’t have to be this way.
As I read the article, I found myself agreeing with essentially every recommendation, but I also found myself feeling that it would be very disappointing to work in an environment where I had to consciously worry about these things.
I just spent the past five years working with a team of incredibly talented software engineers with very nearly zero “struggling”. Sure, there were various coding styles, documentation styles, attitudes about technical debt, elegance, etc. But overall, the driving forces were a shared sense of purpose, mutual respect, and personal friendship. These forces implicitly–and easily–trumped any minor development style difference. The result was a team that consistently delivered quality results, on time. And just as importantly, from a sustainability perspective, it was an enjoyable–often, outright fun–environment in which to work. I think this is the very definition of software A-team.
1 comment for “Recognizing a Software A-team”