5 ms·

Ownership is good, but only up to a point. In this approach, developers end up being independent contractors on a payroll. If you focus only on deliverables an

Ownership is good, but only up to a point. In this approach, developers end up being independent contractors on a payroll. If you focus only on deliverables and deadlines, you'll end up with developers using a mix of different approaches, libraries and even languages. It hurts team cohesion and makes the logistics of project management much harder since Joe can't take over Tom's code now that Tom has the flu. As I see it, one of the main tasks of a technical manager is to set conventions so everyone would feel at least semi-comfortable with everyone else's code. That's not micro-management, that's management.

sloxy 9y ago
> one of the main tasks of a technical manager is to set conventions I'd be more inclined to say one of the main roles any manager is facilitation more than anything else. Any manager that "sets convention" is somebody who wants the easy part of technology without the corresponding hard part. Talking about technical solutions is easy. Implementing it is much harder. I've come across multiple "technical managers" who were hands on with code greater than x years ago and they always end up talking out of their arse. And that's not to mention the numerous wrong choices they've committed to/spoke about at a high level meeting with zero notion.
- maltalex 9y ago
  I think that we're talking about two different types of managers. I was talking about a technical manager, as in a tech lead/lead engineer/lead developer/whatever you want to call it - someone who has to manage and coordinate the day to day of people doing technical work (on top of taking part in the said work). I think you're talking about someone more business-oriented.
bluesnowmonkey 9y ago
One view of management is that it's about making sure the cogs of the machine are completely interchangeable. Everything is uniform, orderly, perfect. Everyone is replaceable. No one's contribution can be distinguished from that of any other. Everything must be measurable and measured. See how the graphs in our status updates always show progress! This is actually an extremely inefficient and demoralizing environment for those involved. Yeah, it's easy to take over when someone leaves, because they were so hamstrung by the environment that they never built anything interesting. And you're going to be doing a lot of this taking over, because people are always leaving, because they were hamstrung. So this idea that we can't trust individuals to stick around and do a good job, and we have to make sure they never have enough power to do damage when they make a mistake, it's a self fulfilling prophecy. It makes them untrustworthy and drives them away. It really is about ownership. Programmers who are achieving at a high level move much faster and do much greater things. It's worth letting them make mistakes to retain the best people and get their best work. The only catch is figuring out how to keep them accountable for their decisions. OK, you want to use this new tech or try this new architecture. How do we tie your compensation and career progress to the success of those decisions?
- deleted 9y ago
  [deleted]
- dasmoth 9y ago
  Couldn't agree more. This does seem to be a relatively rare perspective right now, though. (Somewhat seriously) are you hiring?
- falcolas 9y ago
  When the mantra among developers is "the only way to get a raise is to change jobs", and people are moving on a bi-yearly basis - yeah, you need to plan for cogs. No amount of ownership is going to cover for an otherwise brilliant developer who jumps ship once the project has shipped its MVP. And if that brilliant developer wrote that project in, say, Haskell (because they wanted to learn it), that project is probably doomed from a financial point of view - a quality Haskell developer willing to do maintenance on an existing project will likely cost more than the project is worth in the first place. The root of this problem does lie in management, but it's a self fulfilling prophecy at this point: employees have taken the lesson to heart. Even companies which do give fantastic benefits are going to still see high turnover, and need to account for that.
- fpisfun 9y ago
  The idea of interchangeable cogs is completely unattainable if a non technical manager is the one hiring, replacing, etc the cogs. If you think about it it makes sense that the only type of person who could ever theoretically pull this off would be a master programmer who understands the project at such a deep level that tasks can be broken down into pieces consistently. I'm not saying it's possible but it's definitely impossible for any non technical manager to do.
- newfoundglory 9y ago
  There's a big spectrum between "interchangeable cogs" and "nobody even writes in the same language or architecture" and I don't think either of those extremes would be a good development environment.
- Terr_ 9y ago
  Ownership (by devs) doesn't have to mean a hyper-personalized idiosyncratic creation. Part of the pride of ownership can be making something understandable and modifiable by other people. The bigger problem is that many companies do not reward that, they reward doing it quickly and not asking too many questions.
Joeri 9y ago
A manager is not a developer, only developers can set good technical standards. A manager's job is to make sure there is a lead developer with clear authority to set technical standards.
- maltalex 9y ago
  A technical manager can certainly be a developer. I'm not talking about business people setting technical standards, I'm talking about tech leads/lead developers.
frobozz 9y ago
Conventions set collaboratively by the team as a whole gain better traction than those dictated by a leader. Common ownership does not end up with a random patchwork of technologies. Teams make collective decisions on them. I might like to write CGI programs in Prolog with a MarkLogic db, I'm not going to unilaterally decide to write my bit of a team application like that when everyone else writes WSGI Python applications with Postgres.

sloxy 9y ago

> one of the main tasks of a technical manager is to set conventions I'd be more inclined to say one of the main roles any manager is facilitation more than anything else. Any manager that "sets convention" is somebody who wants the easy part of technology without the corresponding hard part. Talking about technical solutions is easy. Implementing it is much harder. I've come across multiple "technical managers" who were hands on with code greater than x years ago and they always end up talking out of their arse. And that's not to mention the numerous wrong choices they've committed to/spoke about at a high level meeting with zero notion.

maltalex 9y ago
I think that we're talking about two different types of managers. I was talking about a technical manager, as in a tech lead/lead engineer/lead developer/whatever you want to call it - someone who has to manage and coordinate the day to day of people doing technical work (on top of taking part in the said work). I think you're talking about someone more business-oriented.

bluesnowmonkey 9y ago

One view of management is that it's about making sure the cogs of the machine are completely interchangeable. Everything is uniform, orderly, perfect. Everyone is replaceable. No one's contribution can be distinguished from that of any other. Everything must be measurable and measured. See how the graphs in our status updates always show progress! This is actually an extremely inefficient and demoralizing environment for those involved. Yeah, it's easy to take over when someone leaves, because they were so hamstrung by the environment that they never built anything interesting. And you're going to be doing a lot of this taking over, because people are always leaving, because they were hamstrung. So this idea that we can't trust individuals to stick around and do a good job, and we have to make sure they never have enough power to do damage when they make a mistake, it's a self fulfilling prophecy. It makes them untrustworthy and drives them away. It really is about ownership. Programmers who are achieving at a high level move much faster and do much greater things. It's worth letting them make mistakes to retain the best people and get their best work. The only catch is figuring out how to keep them accountable for their decisions. OK, you want to use this new tech or try this new architecture. How do we tie your compensation and career progress to the success of those decisions?

deleted 9y ago
[deleted]
dasmoth 9y ago
Couldn't agree more. This does seem to be a relatively rare perspective right now, though. (Somewhat seriously) are you hiring?
falcolas 9y ago
When the mantra among developers is "the only way to get a raise is to change jobs", and people are moving on a bi-yearly basis - yeah, you need to plan for cogs. No amount of ownership is going to cover for an otherwise brilliant developer who jumps ship once the project has shipped its MVP. And if that brilliant developer wrote that project in, say, Haskell (because they wanted to learn it), that project is probably doomed from a financial point of view - a quality Haskell developer willing to do maintenance on an existing project will likely cost more than the project is worth in the first place. The root of this problem does lie in management, but it's a self fulfilling prophecy at this point: employees have taken the lesson to heart. Even companies which do give fantastic benefits are going to still see high turnover, and need to account for that.
fpisfun 9y ago
The idea of interchangeable cogs is completely unattainable if a non technical manager is the one hiring, replacing, etc the cogs. If you think about it it makes sense that the only type of person who could ever theoretically pull this off would be a master programmer who understands the project at such a deep level that tasks can be broken down into pieces consistently. I'm not saying it's possible but it's definitely impossible for any non technical manager to do.
newfoundglory 9y ago
There's a big spectrum between "interchangeable cogs" and "nobody even writes in the same language or architecture" and I don't think either of those extremes would be a good development environment.
Terr_ 9y ago
Ownership (by devs) doesn't have to mean a hyper-personalized idiosyncratic creation. Part of the pride of ownership can be making something understandable and modifiable by other people. The bigger problem is that many companies do not reward that, they reward doing it quickly and not asking too many questions.

Joeri 9y ago

A manager is not a developer, only developers can set good technical standards. A manager's job is to make sure there is a lead developer with clear authority to set technical standards.

maltalex 9y ago
A technical manager can certainly be a developer. I'm not talking about business people setting technical standards, I'm talking about tech leads/lead developers.

frobozz 9y ago

Conventions set collaboratively by the team as a whole gain better traction than those dictated by a leader. Common ownership does not end up with a random patchwork of technologies. Teams make collective decisions on them. I might like to write CGI programs in Prolog with a MarkLogic db, I'm not going to unilaterally decide to write my bit of a team application like that when everyone else writes WSGI Python applications with Postgres.