Recently I spent a few months mentoring a young man of 55 as part of the Chicago Python User Group's mentorship program. He was--his employer is--in transition to the cloud, and there's no better language with which to explore the cloud than Python. He very wisely signed up on his own initiative.
His background was very deep in
COBOL. You may be (I was)
surprised to learn how much of the cloud is still contained within the
mainframe: flight reservations, US government filings, and yes even
your credit card transactions are being routed through musty
cloth-lined copper wires leading to one refrigerator-sized CPU in New
Jersey. I kid, of course: these mainframe systems have seen their own
modernization trend, including a recent panic to fill positions being
abandoned by
retirees.
But my impression is that the language itself has changed almost not
at all since the 60s. Think back to a time when your favorite
Javascript framework was cool, then think back to a time when Object
Oriented programming was cool . . . then think back to a time when
GOTO was cool . . . then think back a couple of decades beyond that.
My mentee presented me with a tabula rasa--pretty much everything was going to be new. Nothing against him: I think he demonstrated that knowledge itself isn't so important to a successful mentorship as the capacity to learn, and he had honed these tools throughout his long engineering career. But as his mentor it happened more than once that I whiffed on what I thought would be an impressive revelation of Python's simplicity. The ease and readability of using spaces instead of brackets was lost on a coder who had skipped using brackets.
This may start to sound like "notes on a mentorship deathmarch" but really I'm wanting to share my experience and in so doing, try to reorient the mentorship message away from technical guidance towards a kind of mentorship Zen. The mentee does the work, the mentor listens and responds and guides her or him to the right way. I should say to the obvious way--because that way may not be obvious at first unless your mentee is Dutch ;) .
This is a bit of Pythonist easteregging from the import this
manifesto known as "The Zen of Python". Calling it up now I see that
I've mis-remembered it, and I'm glad to have the opportunity to
correct myself:
>> import this
...
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
...
Setting aside the jab at Guido van Rossum (Python's Benevolent Dictator for Life), I'm realizing that in its cryptic way this expresses a goal of Python mentorship. Previously I had remembered "right way to do it", which is a different message. Anyone can find a way to do it by StackExchanging. As mentors we can instruct the mentee in the right way--we can cut and paste our way through our relationship with them. But the mentee won't really learn anything about Python if she or he doesn't have the experience of "obviousness". It's going to be an experiential thing--almost a perceptual thing--and not so much a knowledge thing. Ultimately we'd like to give them an experience of how gracefully expressive they can be when writing Python.
The word "Zen" has occurred and so I feel
justified in following this train of thought to Zen and the Art of
Motorcycle
Maintenance
where Robert Pirsig's notion of "Quality" might substitute for
obviousness:
The nature of our culture is such that if you were to look for instruction in how to do any of these jobs, the instruction would always give only one understanding of Quality, the classic. It would tell you how to hold the blade when sharpening the knife, or how to use a sewing machine, or how to mix and apply glue with the presumption that once these underlying methods were applied, "good" would naturally follow. The ability to see directly what "looks good" would be ignored. (300)
Here "classic Quality" stands for a technical knowledge without real understanding, a fractured quality which he hopes to heal through his argument. Maybe it's unfair to apply Pirsig's cynicism to our current code-camp culture, as instruction which simply reproduces knowledge with the hope that a sense of what is Pythonic will follow. I believe mentorship to be a better pattern for instruction, but given a short engagement, how do we teach them to see what "looks good"? How can a mentor lead a mentee to an understanding of Quality?
I don't think Pirsig would answer except to offer the example of the mechanic at work, wherein the work itself teaches the meaning of Quality. Vault the book ahead into the digital age and developers will identify with his description of being "in the zone":
I've said you can actually see this fusion in skilled mechanics and machinists of a certain sort, and you can see it in the work they do. To say that they are not artists is to misunderstand the nature of art. They have patience, care and attentiveness to what they're doing, but more than this . . . there's a kind of inner peace of mind that isn't contrived but results from a kind of harmony with the work in which there's no leader and no follower. The material and the craftsman's thoughts change together in a progression of smooth, even changes until his mind is at rest at the exact instant the material is right. (304)
Coding is hand-eye work, too,
but the tools are transposed into the laptop; to replicate that
continuous loop of sensory feedback we really have to get our mentees
set up properly at the outset. The first couple of sessions are well
spent just learning how to interact with the interpreter, how to run a
script and see a result, how to write to a file. My mentee was using
an IDE which I think can be good, but I made a point of showing him
tab-completion in IPython too. The effect of setting up should be to
get the mentee flowing, to get them "unstuck"; it really is the first
lesson. Then if they don't know something they can check it
themselves.
Of course this may not come naturally for the mentee at first, but spending time in this state of attention with her or him will enable them to apprehend the obviousness of good Python code. tl;dr: pair programming. And listening and responding, being present for your mentee. Mentorship has a Zen of its own :) .
In fairness to the "right way" there's a lot of material to get through in preparation for the revelation of obviousness. A lot depends on the gumption of the mentee: they come in wanting a data-driven website, and they'll have it if they put in the time. The trap here will be pushing your own agenda: as a mentor your task feels very large, you know too much that you want to share. Instead empty your mind and listen. Your goal should be to walk with your mentee along a short, well-groomed path towards their goal.
In doing so my mentee and I skipped over whole swaths of Python that would be essential to "knowing Python". I'm a fan of decorators, e.g., but IMO they may be jarring to those for whom the syntax of Python functions itself is new. I trust that these language features will introduce themselves to my mentee in due course. I did insist on a brief testing lecture, though--couldn't call myself a Quality Engineer and leave that out ;) .
By the end we did get to pair on a
little Pythonic refactoring
session.
I'm sure the result could be even Pythonic-er, but importantly my
mentee took it and ran, tightening up some other code in the same
style.
I'm really impressed with all the work he got done. There's more
mentoring to do of course (always more), but we're on the path :)
. . . .
(More about Rob in his own account of our mentorship <3, thanks for the use of the photo.)