First-year of college at UCSC. First computer science class. Introduction to Programming. The language: Pascal.

Failed it. Failed it badly. Knew I was going to fail it halfway through the class.

This was my chosen profession. I’d been a grocery store clerk, a butcher, a video store clerk, the guy who backs up the system to tape drives on Saturday, and a bookseller. I wanted to be a computer scientist, and I failed my first class… badly.

There were situational reasons. First-year in college. Adjusting to living in a dorm. Meeting all sorts of strange new people. The distractions were innumerable, but the real reason was character.

This is how I work. I walk into a situation, and I’m furiously trying to figure it out, “Which situation is this?” I am parsing the people, the words, and the mood, and I’m searching for familiarity. I am not calm until I find this familiarity, and when I do BAM Ok, what’s next? How do we make progress from here? Let’s go. Like… now.

You think this results from years of being a leadership type who is constantly thrown into random situations where I am required to build situational awareness quickly, and you’d be partially correct. Here’s the rub: I’ve always been this way.

Voracious consumer of information, professional introvert, and ownership of a painfully short attention span. Combine all those, and you get me: usually well-informed, very aware of what those other shifty humans might be plotting, and probably already thinking about something else. Ta-da.

There are situations where this particular set of skills is advantageous, particularly in situations where I have relevant experience. In these situations, I can hit the ground running, quickly assess, and equally quickly get us moving in a credible direction.

There are an equal amount of situations where my skills/habit put me at a disadvantage. Which takes us back to Pascal.

Incapable of Achieving Your Dream

I’d programmed a bit on my Atari 400 and a lot on my Apple ][ and IBM PC, but this was hacking. Slowly trying to figure out how it all worked, copying code snippets out of magazines, and attempting to convince myself that I understood how a computer worked. When I arrived in my first computer science class, my prior experience gave me the impression that the class was “been there, done that.” It looked like code, so, yeah, I understand what’s going on here.

When it quickly became apparent that I didn’t know what was going on, I didn’t ask for help (introvert), nor did I focus on solving the core problem (short attention span). I missed the basic rules of how a programming language is structured. Essential details that I’d never seen before. When it came time to demonstrate applied knowledge, my YOLO shenanigans failed me. Worth noting: I was moderately successful in high school with YOLO shenanigans. Hustle. Bluster. Call it what you want; you can’t hustle your way through the necessity of hard work.

UCSC at the time had an option where there were no grades. You could select a written evaluation, and while I do not remember the specific words, I vividly remember how it made me feel: “The thing you’ve wanted to do all your life. You are incapable of understanding, let alone doing the work.”

Deep breath. New strategy.

Next semester. Different professor, but same course. First day and every day, I took copious notes. First homework assignment. 25 problems. I answered every problem, and if I had a hint of confusion about my answer, I went back to the book and re-read the section to make sure the answer was understood and defensible.

Next week, the professor announced a separate extra credit lab where we’d learn a new language called “Scheme.” Totally optional. I signed up. First tutorial, there were 10 of us in the lab. Scheme, a language based on recursion, was confusing. I never missed a lab.

Next week. First programming assignment, which included a bonus objective. I wrote the code, and I obsessed about the bonus objective. Ten points for the assignment. I got 12 total with the bonus. Eventually, our first test. 100 points possible. I got 110 for answering the Scheme extra credit question.

Every week.

Fast forward to the end of the semester. Our final programming assignment was a contest to see who could design the most efficient version of an algorithm. Work together as a team. Ask for help. I took the assignment to my extra credit lab, which was now just the Teaching Assistant and myself talking about Scheme. I told him about the contest, and we spent the lab whiteboarding different approaches. The result: a contest win and more sweet, sweet extra credit.

My grade-less report card still sits in a drawer in the cave. The phrase I remember, “Best in class.”

Deep Vertical Knowledge

This article is not how I became an amazing software engineer. My academic ups and downs at UCSC continued. Data Structures blew my mind. C++ blew my confidence. When I started at Borland, I was a below-average junior engineer. Improving steadily over the years and in awe of those talented humans around me who made it look so easy.

Seven years later, when I became a manager, I was average again. The learning cycle restarted. Sitting here now, years later, I am very clear I have strengths and areas I need to invest in. Took years to figure that out.

As a leader, these days a senior leader, I preach delegation a lot. It’s the complicated act of giving accountability for the work to others. You often delegate works you know you could complete, but your job as a leader is to give others opportunities while also learning how to coach and guide them towards the essential lessons better learned via experience than lectures.

Delegation is an art. When handing off a set of work to another human, it needs to feel like support, not avoidance. Well-executed delegation feels like a vote of confidence. Poor delegation looks like abdication. Great, my manager just handed me a disaster. Now what? Poor delegation re-enforces the perception that managers are out of touch and unaware of what is going on.

This article is about preventing this perception and understanding when it is in your best interest to Go Full Pascal. Contrary to what I suggested earlier, Going Full Pascal isn’t just hard work because the work should always be some version of hard. Going Full Pascal is when it is necessary to work hard and acquire deep vertical knowledge so that you understand every single nook and cranny of the complicated situation in front of you.

This is not a move you attempt in every situation; it’s the one you keep in your back pocket for when the sky is falling, and you don’t need to prop the sky up; you need to prevent it from falling ever again. You’ll know you’ve done this when you’re done, and everyone sees the solution, and they clap. Loudly.

Not Micromanagement

A few years ago, I revised my thinking about managers continuing to code. I went from “No way” to “Stay programming limber.” Like coding, you can send deeply confusing messages to the team when you Go Full Pascal. You’re always one poorly formed sentence from signaling to the team that you’ve Gone Full Micromanager.

How to avoid the micromanager label? That’s another important article. Today I want to remind you that just because it says manager in your title doesn’t mean you are absolved for doing the hard work of deep vertical knowledge.

I’m built to be a competent leader. I seek information so that I understand how the world works. My introversion has made me into a good listener because you talking is less scary than me talking. My short attention span means that chances are, when you speak to me about what I’m working on, I’m giddy excited because I seek stimulating situations that hold my attention.

I’ve become a better leader because I know when my skills and habits are a detriment. I’ve come to understand bias and how it impacts my team. I’ve worked hard to be a good public speaker who conveys excitement and speaks slowly and clearly. I have objects on my desk right now that I hold in my hand to remind me to focus my attention when it wants to wander.

And I know when to Go Full Pascal.