alternate title – Techs Managing Techs; not Required, but it Helps
This evening, catching up with my RSS feeds, I happened upon this old screencast from Jon Udell, looking over the shoulder as he and Anders Hejlsberg take a look at LINQ, a work-in-process set of extensions
for the .NET framework. Udell captured my curiousity with this description of the session …
You have to be a certain kind of person to enjoy watching Anders run LINQ through its paces, Intellisensing his way through the construction of C# queries against object, SQL and XML data, but I am that kind of person, and I find it utterly hypnotic.
I love listening to Hejlsberg narrate result sets as blah blah blah blah blah, and Udell calling out the power of muscle memory and his triple quoted multi-line literal with percent markers in Python. In the screencast, we see Hejlsberg type and retype, fixing typos and narrating his stream of programming consciousness while we hear the clack of the keys in the background; Udell drops in occasionally to interrupt the stream for a quick explanation. It’s the kind of web video I just won’t show to my family; they’d get that look of pity in their eyes, as they fight to hold back the derisive jokes …
But seriously, it is an interesting process to observe. I found myself drawing parallels to other programming projects I have in the hopper, and even caught some hints on how Intellisense / autocompletion works (sounds like it could be driven dynamically by a well defined XML schema; hmmm, I could visualize how that could work …).
I found myself thinking about a presentation I gave yesterday, to an application development group on a range of topics, business and technical. One of the sections that generated the most boisterous conversation was one predicated with an admission – this is the toughest topic to discuss with techs. The general message was Knowledge Management, the specific issue was documenting code and configuration changes to production systems. Examples of good and bad brought a healthy give and take discussion that culminated in a terrifically honest question – why do we have to take such care in documenting these changes? Who does it really benefit?
- Approvers (so they don’t have to chase you down for an explanation)
- Auditors (so they don’t have fodder for audit findings
… and the most important, the most self-serving, and the best reason …
- Authors (so they can remember what they were doing six months later)
The best reason to document is entirely selfish – do it to guarantee your own productivity.
This was something I could attest to, from personal experience. I think I am a very good commenter / documenter, because it has paid off for me in the past. I’m still a coder by training, and I definitely remember when I didn’t document as much. It only takes one …
… bad experience of having to reverse engineer my own code – because the comments just stunk.
… good experience of being able to pick up a piece of code I haven’t looked at in six months and quickly get back into it – because there were well-structured, decent comments in place
It’s the kind of observation, made from experience, that can resonate with technical folks. It’s the same kind of ongoing, hands-on interest in the art of technology that makes screencasts and prose from folks like Udell really interesting, and (I believe) a required part of any tech managers job – balanced, of course, with the business of technology.
I don’t think deep technical experience is required for managing techs – but it certainly helps.
This Post Has 0 Comments