Random Thoughts On Humility and Perfection
(Sorry for the recent codeless posts, but these are just some of the things I’ve been thinking about and dealing with recently)
As I continue down this road as a software consultant (still with a consulting firm), I find myself working more and more with other consultants who are considered “senior”, which for some reason includes myself. I’m starting to see that this can be one of the biggest roadblocks to change and one of the biggest producers of fear on a team. At least speaking for myself.
“We’re ‘Senior’, We Don’t Need No Stinkin’ Code Reviews”
This is the kind of mentality that, though common, is pretty unfortunate. We all know code reviews have been abused over the years, but does that really mean there is no benefit in “having a 2nd pair of eyes”, as they say? Isn’t this still a powerful way to learn and grow a team’s skills?
But this post is not about specific practices like code reviews. The greater point I’m trying to make is this: Is it possible for us all to put down our “senior” statuses and strive for perfection as a group of passionate developers without the fear of offending each other? I’m not sure this is completely achievable as long as we’re all allowed to have opinions, but it certainly sounds like a nice goal.
Even though perfection is unachievable, I want to get as close to it as I can. Both, in my walk with the Lord and in my craft as a software developer.
One of the main benefits I see to all this ALT.NET stuff is that when a group of developers (notice I didn’t say “senior developers”) can get together and critique each other’s ideas in a constructive way that actually leads to overall improvement and learning, then I’d say that’s a huge leap in the right direction.
“Now Let’s Not Get Crazy And Actually Try To Improve Our Code”
Fear quenches the ability to improve. If Joe Developer is afraid to make a suggestion to another developer or his team because he’s afraid of either a) someone getting offended and/or b) someone biting his head off, then chances are that the team’s overall skills are pretty stagnant and their ability to improve is severely limited. Fear can also come from working with unwieldy code bases. When everyone on the team is afraid to change anything because they don’t want to break something, then you’ve got some serious changes to implement. I’m starting to go through this process now on a couple of my current projects. One baby step at a time.
“We’re Too Busy To Learn Fundamental OO Principles And Practices”
Well, like a good friend of mine told me recently, “you’re gonna pay for it somewhere”. Either through lots of pain in the ongoing maintenance of poorly designed software or in the investment into your team to learn/teach better ways of building software in the first place.
Now that I’ve pretty much “settled in” to my new consulting firm, I’m going to really start spreading the knowledge that I have (what little that is) to try and build up the teams I work with as much as I can and perhaps encourage others to do the same. Because I know that ultimately by doing this, I’ll end up learning much more from other folks that I could possibly teach them.
The end goal of course being that the clients we serve are getting the highest quality work possible. But more on that in another post… 😉