[booleandilemma]

Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does not come from just crushing tickets non-stop for extended periods of time.

Of course it doesn't. And that's because "the transition" he refers to is an illusion at best, and a lie we tell ourselves at worst. It's all about politics and getting on your boss' good side. Toot your own horn and you'll move up the ladder of made up titles. Congratulations. It's not more complicated than that.

Most managers don't look at code, and even when they do, they can't distinguish good work from CRUD boilerplate. Most managers don't know what it is you do, only what you say it is you do.

And the reason why we're in this situation in the first place is because our management class is filled with people who just want things to work without issue so they can collect a paycheck off of someone else's labor and provide for their families.

Managers don't care about your work, and you are being tricked into caring about your work so that managers don't have to.

[b7r6]

The situation that you describe is regrettable common in my experience, but by no means ubiquitous, and I'm optimistic actually reaching the end of its lifespan.

I've been out of big-name marquee tech for several years now, but as recently as late last decade it was in fact possible to achieve meaningful seniority as an engineering manager on the back of serious engagement with the subject matter. I at one time managed a team of roughly ~35 serious engineers and several managers in a critical path and was considered senior enough to be called an L7 because I read at least and usually commented on one or more diffs a day, and worked on and usually landed a diff or two a week.

I don't know where the meme started that managing technical work was orthogonal to understanding technical work, but CTOs like Carmack disagree (FWIW little old me does as well). In almost any other field from fabrication in a shop full of machines to a law firm, the top person is the most expert person, and I think it's a weird path-dependent aberration that software got off that proven paved path.

YMMV but this stuff is IMHO getting so complicated that I think managers will be trending more rather than less technical for the foreseeable future.

[YZF]

YMMV. The transition is real. Whether you can get rewarded for it is a different question. Sure, in some organizations it doesn't matter, but in others it matters.

There's is a continuum in how well you can perform as a software developer and this is a non-linear phenomena. That said the "title" is definitely often a made up thing.

It's not like politics don't come into play. Politics are always at play. But doing an obviously poor job with great politics won't work in most organizations and you can be a good engineer and still understand the politics and advance your abilities and advance in the organization.

[GenerocUsername]

4/5 managers from my career fit this description.

I've had 2 managers who were better than this, and they were prior programmers who still understood the code but had moved up.

The best managers are good coders who realize that by directing they can actually accomplish more across many areas than they could have as a individual contributed.

But 4/5 are disconnected paycheck collectors who need to be told stories

[Spivak]

I wanna push back on this.

> Good coders who realize that by directing they can actually accomplish more across many areas.

This isn't a manager, this is a director. Great to have but not the person you want directly managing teams. The people you want directly managing teams are "servant managers", "shit umbrellas" or because it's silly there's even terms for these just "non-shitty managers." Managers should be people who enable the devs not because of their coding talent but because of their non-coding talent. They organize all your work into a nice little streams so you don't have to carry the mental load, advocate for the needs of your team by translating tech speak into product management speak, dealing with all the external requests to your team (i.e. saying no), handling on-call schedules, coordinating with the release managers and support, helps you with career development, the list goes on.

A good dev manager lets you turn off brain to all annoyances and distractions not related to your technical work.

[User23]

You’re describing a good secretary.

[twblalock]

No, that is a very good description of a competent team lead.