Posted by February 22, 1983. I started work at CCA (Computer Corporation of America) – an over-named company that built a very slick database engine – MODEL 204. It is in use today, running on mainframe systems around the world. Its economical, high performance Boolean engine is still without peer on those machines, as far as I know (suitably ignoring very old marketing claims).
I remember meeting June for the first time (NOT her real name, which was Ellen). She was assigned to give me some personal help to learn some of the then-3M lines of IBM Assembler code that comprised the engine. She voiced her resentment personally and pointedly. “No one helped ME learn anything” she complained. That was a true statement, and her help for me was meager as well.
Eager to make an impression, I worked 14 hour days for about 3 months to hammer out my first project which was a serviceability aid for crashes we had – across 3 flavors of mainframe OS architectures – MVS, VM and the ancient DOS. I had made an impression and kept at it (ok, 14 hours turned to 10) for years.
June’s complaint has stayed in my ear for a long, long time. The problem of taking knowledge workers and turning them into teachers is vividly exposed in Fred Brooks’ The Mythical Man Month, based on a real-life mammoth project at IBM. Basically, you do it at the expense of getting anything done – it’s a recipe for delay and backwards progress.
But how do we get newbies productive in the software business? If you think of new people as threats to one’s empire (or knowledge priesthood), it’s probably a good time to stop reading here; this article is an intentional threat to your false security.
Some new folks need no help, to be sure, and populate startups and other ventures with enthusiastic, over-confident talent. There is a definable danger in putting too-young talent in too-exposed positions, as their mistakes can escalate to the point of a threat to business viability, truly. That danger can be spotted early on in efforts that weigh heavily on unproven technologies, which, despite their academic papers and over-claims of industry adoption, turn out to be not as great as claimed. Indeed, some turn into unmitigated disasters and a squandering of resources, rising to the $2B level.
Ok, so mentoring is what I’m talking about, in some sense of the word. Maybe “coaching” is more like it, but it’s mentoring on-the-way-by. That is, in the course of project work, taking a little time to help a neophyte grow professionally. Corporations never miss a chance to systematize anything, so official mentoring programs abound and carry a varying level of effectiveness. I do recommend being and having a mentor and I have numerous stories that warm my heart to recall and tell. And I am active in that now, for the record.
One of my favorite mentoring engagements happened in the 2014-2016 timeframe at IBM. I started a meeting with 5 young engineers who were fresh out of school to bat around ideas regarding patents – one of the very good programs IBM has sponsored over the years. Some of them were skeptical, others wondered why I would take time to do this. But in the end, we hammered out a patent application for Cognitive Surveys. The patent was granted after my move to HCL, but more than one of the co-inventors thanked me for the effort.
I don’t cite this to boast (ok, a little because it feels good to give back) but to encourage other folks on the older side of the equation to build up the next generation corps of software engineers and application developers in our business going forward. Even if patents are not a tool to use, what is? IBM had an official “Think Friday” time when you were not to work on your real assignment, but to think and dream. Award-winning work got done that way. And whether it’s official or not, I would vaunt such a practice as a venue for mentoring and growing.
As Nike says – “Just do it”.
J D Curtis 