Comment by i-blis

19 days ago

I have always failed to understand the obsessive dream of many engineers to become managers. It seems not to have to do merely with an increase in revenue.

Is it really to escape from "getting bogged down in the specifics" and being able to "focus on the higher-level, abstract work", to quote OP's words? I thought naively that engineering always has been about dealing with the specifics and the joy of problem solving. My guess is that the drive is toward power. Which is rather natural, if you think about it.

Science and the academic world

I have always failed to understand the obsessive dream of many engineers to become managers. It seems not to be merely about an increase in revenue.

Is it to escape from "getting bogged down in the specifics" and being able to "focus on the higher-level, abstract work", to quote OP's words? I thought naively that engineering has always been about dealing with the specifics and the joy of problem-solving. My guess is that the drive is towards power, which is rather natural, if you think about it.

Science and the academic world suffer a comparable plague.

Don't you get bored with spending many years learning and becoming advanced or an expert in a system paradigm (like different hosting systems), a programming language (i.e. Perl), or a framework (pick your JS framework), only to have it completely obsoleted a few years later? And then in a job interview, when you try to sell yourself on your wisdom as expert on thing X, new to Y, they dismiss you because the 25 year old has been using Y since its release three years ago?

And when you're in an existing company, stuck in thing X, knowing that it's obsolete, and the people doing the latest Y that's hot in the job market are in another department and jealously guard access to Y projects?

How about when you go to interview, and you not ONLY have to know Y, but the Leetcode from 15 years ago?

So maybe I've given you another alternative to 'it has to be power, there's no other rational reason to go into management'.

Here's a gentler one: if you want to build big things, involving many people, you need to be in management.

Do you enjoy brick laying and calculating angles around doorways? You're the engineer. Do you want to be the architect hiring engineers, working with project managers, and assessing the budget while worrying about approvals? They're different types of work, and it's not about 'power' like you are suggesting. Autonomy and decision-making power are more the 'power' engineers often don't get (unless they are lucky, very very smart or in a small startup-like environment).

  • N=1 but I do love constantly learning new things, and building small, purposeful, tailored products with small groups of people.

    I've gone back and forth across the lead and management lines many times now, and it is career limiting in many many ways. But it's too fulfilling to give up. And I swear there is magic in what small, expert groups are able to produce that laps large org on the regular.

    • From my (limited) experience, that magic is incredibly linked to autonomy and ownership.

      Some research around British government workers found higher job satisfaction in units with hands-off managers. It resonates with my own career. I’m really excited and want to go to work when I’m on a small, autonomous team with little red tape and politics. Larger orgs simply can’t — or haven’t — ever offered me the same feeling; with some exceptions in Big 3 consulting if I was the expert on a case.

      4 replies →

    • isn't that more a question of company size and industry (i.e. less regulated than healthcare and financial services) than whether management is good or bad?

      I don't see why it contradicts my little rant above. Of course I also prefer small, nimble teams with lots of autonomy, with individuals who thrive being delegated only extremely broad tasks. The only part where I think there's a difference is the constantly learning.

      I love constantly learning. My issue isn't that. It's that I don't want to HAVE to constantly be practicing at home and on the weekend. I did this in my 20s and I can't/won't do this anymore. I just have no time or energy now as an Old.

      3 replies →

  •     > only to have it completely obsoleted a few years later
    

    Not really. There aren’t as many fundamentally new ideas in modern tech as it may seem.

    Web servers have existed for more than 30 years and haven’t changed that much since then. Or e.g., React + Redux is pretty much the same thing as WinProc from WinAPI - invented some time in ~1990. Before Docker, there were Solaris Zones and FreeBSD jails. TCP/IP is 50 years old. And many, many other things we perceive as new.

    Moreover, I think it’s worth looking back and learning some of the “old tech” for inspiration; there’s a wealth of deep and prescient ideas there. We still don’t have a full modern equivalent of Macromedia Flash, for example.

    • I agree with you, but it's very hard to argue the same in an interview, even with other engineers (that's if you get the interview).

      There are companies that are willing to consider general aptitude and transferable skills when hiring, but a vast majority compares candidates using checklists of technologies

    • > React + Redux is pretty much the same thing as WinProc from WinAPI

      I can't tell if this is sincere or parody, it is so insufferably wrong. Good troll. I almost bit.

      1 reply →

  • >only to have it completely obsoleted a few years later

    Almost nothing goes obsolete in software; it just becomes unpopular. You can still write every website you see on the Internet with just jQuery. There are perfectly functional HTTP frameworks for Cobol.

  • > Do you enjoy brick laying and calculating angles around doorways? You're the engineer. Do you want to be the architect hiring engineers, working with project managers, and assessing the budget while worrying about approvals?

    These are inherently different levels of power. I'm not sure how your example is supposed to be the opposite when you compare someone laying bricks to someone making hiring and firing decisions about groups of people. Your scenario is fundamentally a power imbalance

  • You might be right about a Leetcode effect and the difficulty to find new interesting positions. But OP wasn't stressing that at all but the desire to architect and manage. I might have put to much emphasis of the managing and too less on the urge to architect and see things from above. I agree.

    I am scientist and worked from time to time as a research engineer merely to pay the bills, so I may see things differently. I always like doing lab / field work and first-hand data analysis. Many engineers I know would likely never stop tinkering and building stuff. It may be easier for a scientist than for an engineer to still get trilled, I don't know.

  • And I would argue that what you are describing is why we end up in a system where the people who are talented and have in depth knowledge end up in "dumber ~ managerial" roles and we end up losing real talent and knowledge because of the incentives you explicitly describe.

    If only the world incentivized ICs with depth of knowledge to stay in those roles for the long haul instead of chopping off our knowledge of specificity at the apex of their depth of knowledge. So many managers have no talent, no depth of knowledge and a passable ability to manage people.

  • In my opinion, time spent learning Perl or an outmoded framework still helped me learn new things and stretch myself. A lot of that knowledge is transferable to other languages or frameworks. After learning QuickBasic and REXX it was pretty easy to pickup Ruby and Python. ;-)

    • > knowledge is transferable

      I concur: Perl taught me to mentally parse and build (complex) regexes, a highly transferable skill. The Lisp course I was taught in the late 80s, certainly helped me grok Clojure and find it a pretty natural fit. I think this is a very common trope.

  • > only to have it completely obsoleted a few years later?

    That sure beats having it completely obsoleted a few weeks later, which sometimes feels like the situation with AI

  • Thank you for adding color. This is the exact reason why I want to get in to management. Sadly, I am just not cut out to manage people. Nowadays, my role is more of a hybrid between Principal and EM, which may be awkward at times. If it weren't for excellent PM & PgM, I'd be stretching myself too thin.

    • Why aren't you cut out?

      It's a skill that takes practice -coordinating disparate people and groups, creating communication where you notice they're not talking to each other, creating or fixing processes that annoy or cause chaos if they're not there, encouraging people, being a therapist, seeing what's not there and pushing a vision while you get the group to go along, protecting people from management above and pressures around, etc are mostly skills that you learn.

      Sometimes no one will give you feedback so you have to figure it out yourself (unless you're lucky to get a mentor), so you just have to throw yourself in and give yourself grace to fail and succeed over time.

      The only skill of these I think is possibly genetic or innate, is being able to see the big picture and make strategical decisions. A lot of tech people skew cognitively in narrow areas, and have trouble conceptualizing the world beyond.

      One challenge here is the ubiquitous 'managers just approve vacations and waste space' sentiment on here and in some places. These people are a chore to manage (and sometimes are better not being present in your group).

I actually don’t think the author wants to become a real manager, he wants to play a video game where he sends NPCs around to do stuff.

Real managers deal with coaching, ownership, feelings, politics, communication, consensus building, etc. The people who are good at it like setting other people up to win.

  • As a manager who is trying to do all the things you listed well, I would love it to be more like a game sending NPCs around. Ignoring the macro implications of AI, even if very successful at or resistant to it, I’d think there would be very, very few people who are actively seeking people drama. Educating kids can be fun, but educating adults in the business domain is almost always a drag as in any given professional room, you would be very lucky to find one person who is genuinely there out of curiosity rather than obligation or fomo.

    • Huh. Can’t speak for everyone, but big, messy cross functional problems where you need 5 different types of experts to build a shared mental model is my jam. Maybe it’s a culture thing but I rarely encounter technologists resistant to learning how other teams work.

    • I think you might have missed the point

      > I’d think there would be very, very few people who are actively seeking people drama

      Theoretically as a manager you get the bump up the power dynamic ladder (and probably pay ladder) because you are taking on the responsibility of "people drama". Being a good manager is antithetical to treating living, breathing human beings as NPCs in a game.

  • Do you have a different take on winning then me?

    In engineering the only teams that win are the teams that ship code. Dealing with coaching, ownership, feelings, politics, etc, should all arrive at the same outcome: ship code.

    • Perhaps they have a different take on engineering than you.

      Shipping code is not the end goal of engineering. In fact, more code you ship more liability you have. Main goal is solving problems.

      > Engineering is the practice of [...] solve problems within technology, increase efficiency and productivity, and improve systems. [0]

      [0] https://en.wikipedia.org/wiki/Engineering

      1 reply →

As an engineer, I can never actually let a system write code on behalf of me with the level of complacency I've accumulated over the years. I always have opinionated design decisions, variable naming practices. It's memorable, relatable, repeatable across N projects. Sure, you can argue that you can feed all this into the context, but I've found most models to hallucinate and make things unnecessarily opaque and complex. And then, I eventually have to spend time cleaning up all that mess. OP claims they can tell the model over the phone what to do and it does it. Good for OP, but I've never personally had that level of success with my own product development workflow. It sounds too good to be true if this level of autonomy is even possible today without the AI fucking something up.

  • I've started collecting all my opinionated practices in a file I call ENGINEERING_PRINCIPLES.md, which I share across all my projects and reference in every CLAUDE.md. It contains variable naming practices, rules of thumb for writing good code comments, guidelines for unit & integration tests, general architectural principles (avoid global state & push side effects to the boundary aka "functional core, imperative shell", avoid Java enterprise-style OOP hell, etc.), …

    So far, the code Claude has generated looks fairly decent and stylistically not too different from what I would write myself.

  • > I always have opinionated design decisions, variable naming practices

    That's the source of your difficulty. Research wu-wei.

Once you've written enough image caches, I think you often find yourself ready to move on to the higher level architecture of a larger project.

Often too it's the architecture that can cause a grand idea to crash and burn—experienced devs should be moving toward solving those problems.

For me, getting into management was less about feeling bogged down in the specifics, but more about control (directed mostly above). Anyone who’s had a bad manager or bad decisions they need to adhere to might be familiar with the feeling that caused me to dip my toes into management.

Like I’ve been in situations as an IC where poor leadership from above has literally caused less efficient and more painful day-to-day work. I always hoped I could sway those decisions from my position as an IC, but reality rarely aligned with that hope.

I actually love the details, but I just don’t get too deep into them these days as I don’t want to micro-manage.

I do find I have more say in things my team deals with now that I’m a manager.

  • Asking as a fellow manager - do you ever wonder some of the people you manage might be thinking of you in the same way? Someone making terrible decisions, making them less efficient? And, have you ever noticed that something you strongly pushed back when you were an IC did not matter, or was actually the right thing in retrospect?

    • > do you ever wonder some of the people you manage might be thinking of you in the same way?

      I'm almost certain some of those I manage do think of me in this way. I try to explain my thought process and decision making to those I manage, and I am always looking for genuine critical feedback. I also own up to it when I've made a bad call. Overall, my anonymous ratings are pretty high, and my teams have seen exceedingly low turnover so I take those as good signs.

    • I used to be so deeply annoyed with leadership decisions as an IC. When I got into management my attitude completely shifted. Leadership only cares about shipping code. Thinking they care about anything else and you're fooling yourself. So whatever your team cares about your decisions doesn't matter. Are they shipping code? All good. Team dynamics will work itself out as long as you're pushing to main.

      Now I'm back to being an IC and I just do the job. Want me to change this variable name so its more readable, in your opinion? No problem. I shall change const foo to const bar.

Some people want the thing done more than they want to do the thing. That gets to extremes of exploitative parasitic behavior, but it's true at much less obnoxious scales: ever used a programming language's standard library instead of inventing your own _whatever_? Probably a yes.

That can extend to arbitrary absurdity. You are probably not growing your own food, mining your own ore, forging your own tools, etc etc etc.

It's all just a matter of where you rely on external tools/abstractions to do parts of the work you don't want to do yourself.

>the joy of problem solving

It's frontier exploration that brings me joy. If a clanker can do something, then it's a solved problem. I use all the tools at my disposal to push the frontier of problems solved. Wasting my time re-inventing the wheel brings me the opposite of joy.

On a similar note, I have never heard the phrase “higher level abstractions” abstractions so much. Everywhere I look, higher level abstractions. It’s becoming one of those phrases I have an instant reaction to. The word “abstraction” used to mean something, man…

I don't really want to be a manager of humans, although my role as an engineer is a leadership role that has some overlap.

But I'm acutely conscious that in the 5+ years that I've been a senior developer, my ability to come up with useful ideas has significantly outstripped the time I have to realize those ideas (and from experience, the same is often true of academics).

At work, I have the choice between remaining hands-on and limiting what I can get done, or acting more like a manager, and having the opportunity to get more done, but only by letting other people do it, in ways that might not reflect my vision. It's pretty frustrating, to be honest.

For side projects, it's worse. Most of them just can't be done, because I don't even have the choice.

> My guess is that the drive is toward power

Not really for me. Programming is an effort type job. The more effort you put in the more you get out. True in other professions sure but multiplied with dev work. When became a dad everything changed. Solve hard problem or spend time with kid. I couldn't juggle the two. So i made a choice and fortunately had an opportunity to move into management.

Anyway full circle now I'm back to being a dev and this go around couldn't be easier with our ai agents. Point is I went into management because I was forced, not at all for power.

  • Are you saying you were forced to go into management because you felt like you couldn't be an effective engineer without working overtime? I'm confused. That sounds more like your work environment was terrible

    • You're spot on. And maybe I've only ever worked in terrible eng environments which is an interesting thought for me. I'll have to reflect on this. Sounds like you've had the opposite experience?

      1 reply →

It’s more that there’s a career ceiling and ageism is a looming threat. There are far more management jobs than high-level IC and for decades there’s been this thought that older engineers will be replaced with younger ones more aggressively than managers, although the big tech layoffs raise questions about whether that’s still true. I know multiple people who moved into management not because they were enthusiastic about it but because that was the best path for their career.

I liken it to being an author.

You want to write a book about people's deepest motivations. Formative experiences, relationships, desires. Society, expectations, disappointment. Characters need to meet and talk at certain times. The plot needs to make sense.

You bring it to your editor. He finds you forgot to capitalise a proper noun. You also missed an Oxford comma. You used "their" instead of "they're".

He sends you back. You didn't get any feedback about whether it makes sense that the characters did what they did.

You are in hell, you won't hear anything about the structure until you fix your commas.

Eventually someone invents an automatic editor. It fixes all the little grammar and spelling and punctuation issues for you.

Now you can bring the script to an editor who tells you the character needs more development.

You are making progress.

Your only issue is the Luddites who reckon you aren't a real author, because you tend to fail their LeetGrammar tests, calling you a vibe author.

  • Weird analogy. This makes sense if you liken this automatic editor to a LSP or compiler of the language you're writing in.

  • Except that the editor doesn't focus on little things but the structure. It is the job of copy editor to correct all the grammar and bad writing. Copy editor can't be done by AI since it includes fixing logical errors and character names. My understanding is that everybody, including the author, fixes typos when they find them. There is also proofreader at the end to catch typos.

For many people, code is just a means to an end to solve problems and build. The joy from solving problems doesn't disappear. Would you use traditional (not WebAssembly) assembly to build a web application? Probably not. LLMs make a lot more sense if you think of it as a tool to translate requirements into solutions.

I became a manager so I could solve bigger problems. Good managers do dive into the details. It's a mistake to think that as a manager, you don't have to concern yourself with the minutia. You still have to do homework and deep thinking. you just don't have to write the code

It has nothing to do with power. I just want to build bigger, cooler things, faster.

  • It sounds more like you want to have bigger, cooler things, not build them? The joy of building is what the person you're replying to is talking about AI abstracting away

    • I am still getting joy out of building things. If anything, I have a bit more joy than I used to because I can accomplish small things faster. I still find the work to be mentally demanding and interesting, and there are a lot of new interesting problems to solve.

      I empathize and understand that not everyone has this experience.

I don't think it's about power. I feel more empowered as an engineer than I would as an engineering manager. As an engineer I have the power over all the intricate details of how systems work. As an engineering manager if I am lucky I would get to decide whom to fire if my team's budget gets a cut.

I think it's that there is only that much demand for solving really complex problems, and doing the same thing over and over is boring, so management is the only way forward for many people

My 15 year old son has been building his own video games with Unreal Engine for a few years..

I was recently looking for mentors to work with him and advance his skills, targeting college aged kids / young 20s..

It was surprising to me how many people I came across in this field at this young age that are trying to focus on the "higher level" game planning aspects and not so much on the lower level implementation specifics.

"I thought naively that engineering always has been about dealing with the specifics and the joy of problem solving"

For me it's the other way around. Engineering was always a means to an end - I just want to build products. It was a creative artform more than a scientific endeavour.

Engineering, to me, is simply "the art of compromise."

You can't do that from a high level abstract position. You actually need to stand at the coal face and think about it from time to time.

This article encodes an entitled laziness that's destructive to personal skill and quality work.

I think plenty would be willing to be managers if you removed the volatility of human personalities from it. At least for me, it means I get to focus on the more interesting tech work and not worry about writing tests or github actions.

another way to look at it is that management is a job with a set of skills, challenges, and rewards, just like any other, but as a civilisation we seem to have tied it to power and hierarchy, and made it something you need to be promoted into rather than choosing as a career from the outset (MBAs notwithstanding). maybe a lot of engineers would have gone into the engineering management path if they could have, and engineer was just seen as the more entry-level option.

i like the aspect of engineering that's building useful or interesting or fun things for people, and i'll always experiment with new tech that facilitates that

Software dev has been promoted as a good career path for almost 2 decades now. Naturally you'll have a bunch of people going in only because of money.

A few years ago, when Agile was still the hot thing and companies had an Agile "facilitor" or manager for each dev team, the common career path I heard when talking to those people was: "I worked as a java/cobol/etc in the past, but it just didn't click with me. I'm more of a peoples person, you know, so project management is where I really do my best work!".

Yeah, right...

  • Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!