4 ms·

I fail to see your point. You are saying that communication can help developers be more efficient then you give an example of a good developer who did not need

by Iv 5y ago

I fail to see your point. You are saying that communication can help developers be more efficient then you give an example of a good developer who did not need a team to develop a ground breaking product?

ItsMonkk 5y ago
Sorry, the problem is communication. The solution is no communication. You do so by teaching your developers everything they need to know.
- throwawayswede 5y ago
  > You do so by teaching your developers everything they need to know. I feel bad for people who are going to work on your team.
- mehphp 5y ago
  oof..
- romanhn 5y ago
  I don't mean to pile on, please take this as advice from someone who has been in engineering management for quite some years... You seem to have some preconceived notions about managing people (and engineers specifically) that will, frankly, cause you a lot of trouble were you to implement them with your teams. Minimizing all communication will lead to a total breakdown of context - you want to strive for more of good communication (immediate team collaboration, access to stakeholders, healthy relationships with other teams) and less of bad communication (pointless meetings, status updates, cross-team blockages). Having engineers be responsible for everything is also a solid recipe for burn out and dissatisfaction, as others have pointed out. Most engineers do actually enjoy learning, but the manager's role is to encourage and provide opportunities, not to be the teacher, or appoint teachers. I highly recommend reading existing literature on management, and not paving your own path here. Start with Camille Fournier's "The Manager's Path".
- selfhoster11 5y ago
  I don't want to be an expert in everything. I want to have a passing knowledge of UX, JS and so on, but my area of expertise is Java backend. Let's keep it that way.
- thrower123 5y ago
  Ah yes, the human-hatrack developer. Hats! More hats! You're not a real full-stack developer unless you can do the work of eight or ten people on one salary. I've done this, it's not sustainable.
kirkules 5y ago
I think somewhere in there was a point about how when these different roles (backend, frontend, ux, dogfood, etc) are distributed across multiple developers instead of one, connections between the roles are outside of a brain and so need to be optimized explicitly. It was framed for a reader already convinced that management of developers is not useful, but didn't make that clear. Lesson for GP: implicitly assuming a position that your audience may not have can be confusing -- a barrier to communication Edit: from other comments, looks like i was wrong and it was utter nonsense

by Iv 5y ago

ItsMonkk 5y ago

Sorry, the problem is communication. The solution is no communication. You do so by teaching your developers everything they need to know.

throwawayswede 5y ago
> You do so by teaching your developers everything they need to know. I feel bad for people who are going to work on your team.
mehphp 5y ago
oof..
romanhn 5y ago
I don't mean to pile on, please take this as advice from someone who has been in engineering management for quite some years... You seem to have some preconceived notions about managing people (and engineers specifically) that will, frankly, cause you a lot of trouble were you to implement them with your teams. Minimizing all communication will lead to a total breakdown of context - you want to strive for more of good communication (immediate team collaboration, access to stakeholders, healthy relationships with other teams) and less of bad communication (pointless meetings, status updates, cross-team blockages). Having engineers be responsible for everything is also a solid recipe for burn out and dissatisfaction, as others have pointed out. Most engineers do actually enjoy learning, but the manager's role is to encourage and provide opportunities, not to be the teacher, or appoint teachers. I highly recommend reading existing literature on management, and not paving your own path here. Start with Camille Fournier's "The Manager's Path".
selfhoster11 5y ago
I don't want to be an expert in everything. I want to have a passing knowledge of UX, JS and so on, but my area of expertise is Java backend. Let's keep it that way.
thrower123 5y ago
Ah yes, the human-hatrack developer. Hats! More hats! You're not a real full-stack developer unless you can do the work of eight or ten people on one salary. I've done this, it's not sustainable.

kirkules 5y ago

I think somewhere in there was a point about how when these different roles (backend, frontend, ux, dogfood, etc) are distributed across multiple developers instead of one, connections between the roles are outside of a brain and so need to be optimized explicitly. It was framed for a reader already convinced that management of developers is not useful, but didn't make that clear. Lesson for GP: implicitly assuming a position that your audience may not have can be confusing -- a barrier to communication Edit: from other comments, looks like i was wrong and it was utter nonsense