I know I've written about this before, but I sincerely believe that to improve the quality of work performed by the software industry, not to mention get more bodies into the field who write good code, it's critical that we spend time educating and mentoring people. I still believe that our craft has more of a blue collar aspect to it than a lot of people are willing to admit. Just as carpenters and electricians learn their skills from others, so should developers.
I've probably been more talk than anything about this for the last several years, and I tell myself that it's because there are only so many hours in the day. Like anything else, it just depends on how your prioritize your time. To that end, I'm trying to adjust those priorities within reason. At work, I've been very active in suggesting that we turn up our mentoring game, and I'm doing that with two people new to positions similar to mine. In a growing company, I feel pretty strongly that the culture and standards are best handed down, because it's hard to legislate or codify that sort of thing. In this spring's Orlando Code Camp, I'll once again speak for a couple of sessions on topical stuff. I'm doing a presentation for the next monthly user group meeting as well.
I'm not sure why this sort of thing is so hard for us, as an industry, but I suppose it might partly be because of the personality stereotypes that, well, can often ring true. Also, when you're newer to the game, you tend to concentrate more on being clever and "smart" instead of doing as little as possible to meet acceptance criteria. (Yeah, there's a difference between lazy thinking and doing as little as possible, believe it or not.) Of course, when you work in the context of crappy process, that doesn't help you hone your skills either. Being a good developer isn't a technical problem at all. Like most things, it's a people problem.
For me, it's easy to recognize that I've been fortunate enough to work in some really great teams that do stuff "right." There are a lot of core similarities in these experiences, even if the in-the-weeds execution has varied a bit. It's funny how often I come back to the Agile Manifesto, because those four points almost always settle arguments when people start to get dogmatic about the way one builds software. (For reference, I get tired of arguing about the way to phrase user story titles.)
The reality that we need to live with is that there aren't enough warm bodies to fill seats that are really good at this, unless you want to start paying them well above fair market value. So the next best thing is to help each other along. We can learn a lot from the trades.
No comments yet.