I’m a Senior Principal Engineer at a large tech company. My work is to define the 1-3 year future for a $1B slice of the company’s revenue, that 1% of it’s employees work on.

There is nearly zero code in my daily work. The closest I get is being occasionally tagged into a pull request to resolve a dispute or clarify the long term vision, but even then that’s usually API contracts or data schemas that cross code bases-- and not actual code. I spend about 1/5th of my time with the engineers who actually do things and write code, but it’s to talk through math, CS fundamentals, algorithms, or system design on their current project – not code.

Day to day the bulk of my time is trying to convince non technical people, mostly in our Product organization, that we can actually make certain evolutions. Or to drop innovators dilemma type assumptions that add a year to our time to market. I get them to agree and then collaborate with them on large documents that define these futures. I vouch that we can do it, at what cost and on what timeline, and they vouch for how much it will make. We spend months writing documents like this and then pitch them up to the stratospheric leadership of our company to ask for 10-20% more resources to make 20-50% more money 2-3 years from now. I simultaneously do system design for these evolutions and sketch out the high level details of new components or what needs to change in existing components, to make the beginnings of a workable execution plan if we do get resources.

This is all fun and I’m grateful my career has kept changing and being different. Though I do miss the pure joy I find in coding all day, alone. But I am worried that the longer I stay this high level the more I will be full of shit, technically. I’m only effective at finding this intersection of customer desire and engineering reality if I know what is easy, or hard, to do. And I have a lot of examples of high level “technical” people at my company being full of it. It’s usually odd details, like they don’t know that certain problems were solved 10 or 20 years ago. So they twist designs and projects into knots to avoid or re-solve problems that the modern cloud or whatever language or library just has out of the box. Or they prevent profitable market opportunities because they think something is impossible, based on a gap in their knowledge of algorithms or newer tools or realities about how fast computers are these days.

I don’t want to be full of it. People like me eventually get fired if our Big Bets can’t actually be built, or enough people realize we are often wrong about details.

And I also worry that, as an IC, the longer I stay so non-technical the less likely I am to pass the technical portion of any interview. I also think it’s unlikely folks are directly hired into this kind of high level position, anyways, so I need to be able to slip back into a more technical role.

So how do I keep up? How can I be less full of it next year than I am now? I can leetcode, and I should, but that’s far removed from what I feel is the important part of my atrophying technical skills: the small details in tools that determine how large systems fit together and evolve.

  • MadhuGururajan
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 month ago

    I am not at your level so take it with a grain of salt:

    A lot of the fundamentals remain the same. Every new feature is just syntactic sugar on top of fundamental building blocks. You only need to read about new fundamental concepts… which I think you can take in as they trickle in and based on whether you need to apply said new concept (highly unlikely)

    If you want to keep your coding muscle memory trained… just participate in code competitions like the upcoming advent of code. Or contribute to open source. These two are the best at letting you pick the latest technology and play with it. Anything else might restrict you.

    Edit: on the concern about interview preparedness.

    Its ok to forget. Tryimg to remember everything is a fools errand. Instead focus on useful methods of thinking like divide and conquer, dynamic programming, which data structures you would use, trees, graphs, string apgorithms. Abstraction is helpful to preserve your sanity.