61–70 of 120 posts
Unsurprisingly the article comes to the conclusion that anyone can be trained, that 10x engineers are overrated, etc. The AI promotion strategy seems to be improving: AI is not mentioned in the article, but individual learning and meritocracy are dutifully devalued to fit the narrative.
Earlier quoted context omitted.
possibly we're saying the same things in different ways, or maybe it's just hard to pin the difference down in a words what do you mean by "the smallest unit of software ownership and delivery is the engineering team" in practice? what's the largest scope of work some engineer can do entirely on their own recognizance?
well obviously there's a ton of variance here. but in the type of engineering i'm most familiar with, any sizable amount of production services or surface layer being owned by a single person is a bad thing. individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.
I've had a great time on teams where folks can go off and build great tools/libraries/etc that others can use and adapt, without needing a whole team around them—ideally there's lots of collaboration, but it doesn't have to be formally structured
I guess the main difference is that you don't have to operate a tool or a library; if somebody has issues with it, they can patch the code themselves or simply adapt around it in their own code
I also enjoyed working on simulation and optimization problems for similar reasons; there's lots of direct business value, but there's enough slack around it that if I go somebody else can take a model over and maintain it without any issues
unfortunately lots of organizations do not know how to make library-style code "count" the same way a service or stateful component "counts"
Earlier quoted context omitted.
People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward. I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially s…
> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
Earlier quoted context omitted.
Beyond budget constraints, those brilliant engineers may not be good team players. Their brilliance may be in the way of finding the necessary compromises and doing the required but not intellectually challenging work.
I dunno, almost all the brilliant engineers I've known have also been great team players and mentors. Not all, but I'd say it's pretty correlated. The reason brilliant assholes stand out is one of those statistical paradoxes whose name I've forgotten: somebody who's an asshole has to be brilliant to succeed, while team players can get pretty far with a wide range of skill levels.
> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…
I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job. Individual ownership at the individual engineer boundary can breed distrust within a team or org, but oft…
> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…
Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages.
We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.
Earlier quoted context omitted.
People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward. I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially s…
> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :(
moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient
Earlier quoted context omitted.
I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job. Individual ownership at the individual engineer boundary can breed distrust within a team or org, but oft…
I personally think _most_ people should treat their jobs as a _day_ job - unless they have actual ownership in the company (beyond what would be a 50-100k payout at option time)
Trying to hire an employee and tell this story that they "own" the product is just silly. It's like companies that try to describe themselves as a family - just kind of a weird and incorrect use of a real word that has other meaning.
Earlier quoted context omitted.
People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward. I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially s…
> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc.
If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.