111–120 of 121 posts
I've worked as an EM at four different companies, from large enterprises to small startups, and I think "the role of engineering manager" is a myth. Your role varies wildly from one company to another. In every company I've worked at, my job has never been the same: In the end, engineering management basically requires you to counter-balance whichever of the four pillars your team needs most: Product, Process, People…
Earlier quoted context omitted.
> identifying and executing on whatever is highest value that you have the skills for There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers…
If people think that not being hands-on for a year is unmanageable, then we as an industry are doing something horrifically wrong. It would mean that no engineer could ever aspire to become a parent, take a sabbatical, further their education, or experiment with alternate career paths. But I promise you that that is not actually the case. In fact, it is often the engineers who've stifled every other part of their lif…
Earlier quoted context omitted.
FWIW, I enjoyed and agree with your thoughtful comment, and found the response disappointing. Having known privately-owned mom-and-pop businesses, I can confirm not everyone is out for profit at all costs, even in America. For some, it's enough to make ends meet doing something you're passionate about.
> I can confirm not everyone is out for profit at all costs, even in America Definitely, I didn't mean to imply that every business in the US wants to profit at all costs, I just meant that the culture skews towards that. The US culture towards work tends to have a certain response to cases like one where someone has a popular product/service/business but would rather maximize work/life balance than income. In other…
Earlier quoted context omitted.
> identifying and executing on whatever is highest value that you have the skills for There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers…
> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail. The fundamentals like ne…
So if you don't have the understanding of these technologies when the project requires it, you are obsolete and you have no right to be in a leading position. And such fundamental technologies are born continuously.
So this myth that you can have fundamentals and that's enough is definitely untrue.
There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs. The success of that fad is no doubt partially due to the economic climate. People want the tech industry money, but don't have the tech industry skills. Leadership is timeless, humans have always…
Earlier quoted context omitted.
> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail. The fundamentals like ne…
Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally co…
These are indeed good examples of things that are merely tools, not fundamental knowledge.
Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory.
O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushing your workload to a remote cloud (mainframe) won't be exactly be new to them.
Databases have been studied and their properties understood for a very long time.
Sure, the exact details vary a bit and the command line options are different, but that's not significant.
Earlier quoted context omitted.
Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally co…
> Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These are indeed good examples of things that are merely tools, not fundamental knowledge. Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory. O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushi…
> Databases have been studied and their properties understood for a very long time.
No they haven't. Noone ever considered schemaless databases or column-storage databases or vector databases for half a century after the birth of computing. So that kind of knowledge (relational DBs, etc in the 60s and 80s) meant nothing in light of these new technologies, and required completely different skills and knowledge.
But it's clear you are not familiar with these technologies, so it's a waste of time to engage with you now
Earlier quoted context omitted.
This is like claiming that one of the North Korean nuclear scientists is credible on atomic bombs after theirs immediately fell into the ocean. Presiding over a disaster doesn't give you some magical insight on why you completely failed.
He didn't "preside over a disaster". He was a recent engineering hire who joined two months before the launch.
Earlier quoted context omitted.
He didn't "preside over a disaster". He was a recent engineering hire who joined two months before the launch.
I dunno, he was one of two people in charge of one of its biggest technical disgraces (capacity management). That's pretty bad. But what's worse is that he thinks that actual product changes from 3.5 to 4 were good ideas, and that's enough to make me categorically question his judgment.
His argument in favor of the changes was that Digg was at risk of going out of business and needed to take big swings to try and turn things around.
Earlier quoted context omitted.
I dunno, he was one of two people in charge of one of its biggest technical disgraces (capacity management). That's pretty bad. But what's worse is that he thinks that actual product changes from 3.5 to 4 were good ideas, and that's enough to make me categorically question his judgment.
I didn't see anything in that story that suggests he was responsible for capacity management. His argument in favor of the changes was that Digg was at risk of going out of business and needed to take big swings to try and turn things around.
I'm referring to this:
"The week before launch, the capacity planning project was shifted to Rich and I."
>His argument in favor of the changes was that Digg was at risk of going out of business and needed to take big swings to try and turn things around.
At the end, yeah. But this statement earlier was fairly uncritical:
"promised to move us from a monolithic community-driven news aggregator to an infinitely personalized aggregator driven by blending your social graph, top influencers, and the global zeitgeist of news"
It sounds like he thinks more that it was a failure to execute than that it was a complete bastardization of the core purpose of Digg that brought people to it. Digg v4 was doing algorithm slop far too early and crudely and overtly. It was enshittification without all the lubrication to get users to accept it like Facebook and others did.