It's maybe a bit orthogonal? (Or maybe misleading.) I'll fill in with anecdotes and try to make more sense:
When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform.
So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded.
And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team:
We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing).
I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions).
I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it.
For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own".
And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code.
For many engineers (and me of course) this can be the most rewarding way to work.
The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?"
They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)
> For many engineers (and me of course) this can be the most rewarding way to work.
Agreed, this is also the world I grew up in. Nothing is as rewarding as working on something where you have ownership to set the direction and deliver.
For most of my career I had never heard of "product managers" and it was bliss. Somehwere along the line software engineer transformed from being the intellectual lead of the business, to simply a ticket-taker writing code for things some completely non-technical "product managers" decided should be done this week. And the inability to be allowed to think or plan for anything beyond a two week sprint window is mentally crushing.
I've moved to different roles now since software engineering became such a miserable job. I'd jump back in a heartbeat though if there was a company operating like we did in the 80s and 90s where engineers owned engineering.
When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform.
So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded.
And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team:
We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing).
I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions).
I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it.
For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own".
And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code.
For many engineers (and me of course) this can be the most rewarding way to work.
The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?"
They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)