File this under “soft skills.” Let me start with a recent experience.
Last week I was leading a team of youth working around their local community. My oldest son was one of my co-leaders and he had just come back from his first year at The Citadel as well as Basic Camp as an Army officer candidate. He had learned new leadership skills and techniques over the past year and he was looking to try them out. A couple of times during the week he pulled techniques from his leadership toolkit that I didn’t think were effective for the situations he was dealing with. However, I have the benefit of hindsight and experience.
I’ve been working with children and youth since my days as a drug and alcohol resource educator while I was a cadet at The Citadel, basically going back about 25 years. My son has been in leadership roles for the last 3 years or so. Therefore, I have 20 more years of experience to draw in than he does. While it was relatively easy for me to consider alternative techniques from what he used, a large part of that is because of the experience I have had. I admit, it’s hard to consider things from his perspective. It’s hard remembering what it was like when I was newly working with youth.
We can make this same mistake in our professions, especially in IT. There was a #SQLChat discussion in which the topic of source control came up. It’s easy to think about what should be a standard professional practice but it’s easy precisely because we have the benefit of experience. Source control’s importance is often clear due to experience. Those of us who have ever lost code understand the need for source control. But if someone hasn’t been exposed to using source control for tasks such as branching and/or hasn’t suffered the loss of code, it’s usefulness may not initially seem important. After all, day-to-day it’s an additional set of administrative tasks that takes time away from coding. Given that use of source control is not widely taught in academia as a must practice, that means a lot of new graduates from computer science curricula aren’t aware of its importance.
We also have to realize that those new to the field may not be getting slots in mature development shops. That means they may be going to shops that don’t use source control or don’t use it properly. So if they aren’t getting the knowledge in college and they aren’t getting it at their initial job, we shouldn’t be surprised if its importance is lost on them. To that point, the question of whether or not they are professionals came up. They are professionals. It’s not their fault that there isn’t a standard professional body of knowledge (BoK) for development like there is for professional engineers or project managers (see PMI’s PMBOK) . If we had such a BoK, it might be appropriate to make a distinction as is done with engineers. However, until then, we’ve got to remember to look through their eyes and seek to educate.
And this doesn’t just apply to source control. It applies to any area or topic we consider important in our profession. Another item that came up after the #SQLChat ended was handling data. As an industry we’re only now becoming mature in this topic. We’ve been forced to due to numerous public security breaches. This is just one example among many. Remember to try and look at something through a rookie’s eyes. It’s likely a different perspective than through yours as a graybeard, or on the way becoming a graybeard.
