Uncle Sidney was notorious. I think even he’d agree to that.
He might indeed be someone’s uncle, but he isn’t my uncle or the uncle of anyone I know.
He was the main instructor for one of the programming languages used (and created!) by one of my former employers. But if you said Uncle Sidney, everyone within earshot of him knew who you meant. Sidney was his own weather system, with lots of thunder.
His reputation preceded him, for everyone’s safety.
Portrait of Sidney
Likely in the same moment in which you were signed up for Sidney’s class, you were warned that you DO NOT under any circumstances show up late for class. Leave home an hour early, if you have to. Don’t be late. Your manager will hear about it, loudly and in no uncertain terms.
His insistence on timeliness wasn’t pure whim, or even simply a matter of respect. He had the timing of every day of his class down to the minute. If you delayed the start of class, that would throw him off schedule. And there was no “just start without me, I’ll catch up” in this world. This class was intense, and he needed you on board and attentive for every minute.
Second thing you learned: don’t fall asleep in class. I did this once. You better believe he noticed, stopped the class, and called me on it — loudly, crossly, but not unkindly. We took a short break. Again, he needed our attention for every minute.
The stories could go on and on. Some of the stories were not so great. “Sidney yells because he cares,” we’d say. It helped me to think of being yelled at as a badge of honor, but not everyone can let shouting roll off them like water from the back of a duck.
Some stories were more entertaining. My favorite moment was when he quipped that Friday was actually “fried day” because people were fried by then… and then he laughed so much at his own corny joke that he couldn’t continue class for at least a full minute. Which, of course, threw him off schedule.
I emerged from those classes reasonably conversant with the programming language. It’s been years since I last used it, and most of my knowledge of the language is gone now. However, several other lessons from Sidney stick with me.
Slow down, smart people
I find myself repeating this one as I’m mentoring: smart people have a tendency to rush, especially by jumping to conclusions. We’re gratified to put some of the puzzle pieces together and think we see the whole picture. We see A and B, and we get excited. We immediately decide F and G, therefore K… skipping a bunch of intermediate steps. Then when K doesn’t turn out to be true, we’re confused and stuck.
The answer is often to rewind and start again with A, taking it one step at a time. A, then B, then C, then D… wait, what about E? It turns out E isn’t true after all, which explains why K was a faulty conclusion.
Here’s a concrete example. Let’s say a specific input to a function should be generating a certain output, but it isn’t. We stare at the function, and we don’t see how we could possibly be getting the results we are seeing, given the input we’re passing in — or more accurately, given the input we assume we’re passing in.
Slow down a bit. Check to see if the values we’re passing in are what we expect. They are. Slow down a bit more. Are the values we’re passing to the function the same as what the function is receiving? “How could they not be??” you might ask. Check anyway. Wait, they’re not… I pass 5 and 100 and the function is receiving 0 and 0?? How can THAT be?
And that’s exactly the reason for slowing down: you’ll find those problems that exist in the cracks, in places where you assumed everything was going according to plan. Maybe you never saved your most recent code changes, so the code that is running isn’t the same as what’s on your screen. No wonder E isn’t true.
Don’t always take notes
There’s some evidence that writing things down with pen and paper, rather than typing them, improves retention. Writing by hand might force you to do more processing to put the ideas in your own words, whereas typing lets you record what was said closer to verbatim, without necessarily comprehending it.
Sidney took this a step further, calling me out on my tendency to try to write down everything. He would provide us with notes, he promised. Try putting the pen and paper aside and just listening. Just absorb the ideas and make sure you understand. Too much writing, especially in a class as fast-paced as his, and you might start to miss the current idea because you’re too busy trying to record the previous idea. This can snowball quickly.
Ask the question ASAP
If I’m listening to someone lecture, I often hold a question in my mind, rather than asking it. I am trying to allow for the possibility that they’re going to explain it momentarily, or that I have all the information and I just need to make some mental leap to understanding. This is not a great habit.
With some lectures, the information is cumulative. If you don’t understand the point that was just made, you are going to be confused by the point currently being made, baffled by the point coming next, and completely lost in a matter of minutes. And at that point, it can become hard to admit that you actually lost the teacher several minutes prior and you need them to recap a lot.
Put another way: the best time to ask is as soon as you have the question, or as soon as you realize you’re confused. The next best time to ask is when you’re kicking yourself for not having asked because you’re now completely lost. As challenging as it is to confess being lost, it’s only going to get worse the longer you stay lost.
Could you teach it?
Related to the point about asking the question right away: one of Sidney’s tricks was to ask the class if we all understood something. Are we sure we all completely understood it… yes, nods all around.
Okay, he’d say, then explain it back to me.
Uh oh. Suddenly, we’re not sure we understood it so well after all. Oops.
It’s not necessary that you understand everything perfectly on the first try, or that you could explain it to others after just one hearing. It is definitely useful to know that there are layers of understanding, and to know when you might be expected to be at a deeper layer than you are. Now, I routinely check my understanding: did I just barely follow what I was being told? Could I explain it to someone else if they asked? If not, what do I need to ask to get clarification? Or is my minimal understanding sufficient for now?
You influence others too
Uncle Sidney retired before I left that company. On his last day, I made sure to catch up with him to say my goodbyes and wish him well in his retirement.
And it really hit me — as one of the original developers of that language, he’d taught “generations” of developers how to reason about it. He’d taught us how to slow down, skip the note-taking sometimes, ask the questions, and check our understanding. And everyone who taught the language would do so in his footsteps as well, even if their approaches and teaching styles were entirely different. In that way, his influence on the organization was not so unlike an uncle after all.
What’s your legacy, and what do you hope it will be? When you move on from where you are now, what will people remember about you? What habits will they pick up from you, what lessons did they learn from you, and how did you influence the culture and people around you?
Originally posted 10 September 2023 on Medium.
