Thriving on the Technical Leadership Path

> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

My main problem is that I look like an idiot while writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.

All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.

I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.

Also, get ready for a lot of gatekeeping. “Oh, you don’t really want to be a manager! It’s so much more responsibility and work. You should be happy to be a foot soldier for the rest of your career! Management is not all it’s cracked up to be. As you can see I’m stressed all the time! Now excuse me, I have to go close on my second vacation home in Hawaii.”

I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..

There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.

There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.

So now the only thing left that tickles my fancy are the "abstract" problems.

Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.

If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.

Here is why - (for the sake of discussion, "principals" refers to principals and above)

- In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political motivation.

- Principal engineers almost unilaterally have a series of noteworthy accomplishments that create a catalyst for innovation for all engineers around. The depth they create inspires people to really understand tech.

- Discussions with them require managers to have more depth themselves. Rarely can managers win arguments without brushing up on tech.

- Regarding some comments about "CRUD apps" as universal easy things all engineers can solve I find perplexing. Problems in distributed systems are all trying to make CRUD possible and organizations are still figuring out how to do that at scale.

- Regarding arguments about ageism for principals, yes, I agree that ageism exists to a certain degree. However, I find most principal engineers are older as you go up the chain. Therefore, what you are really saying is ageism exists for engineers < principal level. Where you can have new hires know the same depth as them and pay less for. Can you imagine trying to hire folks that built S3, Python, Kafka, etc. be replaceable by younger folks?