4 ms·

I've been looking into this subject lately as I am now moving into management positions and attempting to figure out the best way to do so. Software Developers

I've been looking into this subject lately as I am now moving into management positions and attempting to figure out the best way to do so. Software Developers, let's say I gave you a problem, and that problem was currently being solved with an O(n^2) algorithm, and it turns out that problem was taking up 50+% of your cycles, and because of how it was solved there is hard-coupling that disallowed better approaches, and that you can resolve this problem into an O(1) algorithm? Would you want to hear about that algorithm? Because it's called communication. The model I now think of Development teams is that you have Developers at the center, and then everyone else are teachers assisting them. A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI. He will start by creating designs, but he will allow the developer to make their own mistakes and eventually the Developer will become a Master UX Designer in his own right. This is true of every element of the Software Development LifeCycle. From technical to designing the product itself. Once you have a Developer that understands Databases, understands Backend, Frontend, CSS, UX, understands the Product, works with the Users and dog-foods his own product, you will find the amount of time that it takes to get a superior product will drop massively. The example I like to give here is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity. Meta about the article: I think it's moving forwards but it's got so much going on it's hard to pay attention to any single point.

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
throwawayswede 5y ago
Don't take this the wrong way but your comment represents many things that are wrong with the industry. Meta about your comment: Major condescending-vibe overall. > Would you want to hear about that algorithm? Because it's called communication. First of all, drop the patronizing tone. Second: what are you saying? Developers don't communicate? Don't communicate efficiently or correctly? Specify the thing that is wrong and your proposed solution and then it can be assessed. As it stands your first paragraph is meaningless. For what it's worth I've worked with marketing teams that have communication skills that match a random rock on the street, so this is not a developer issue. That "developers are all geeks and nerds and can't talk to people, and i'm here to fix it" is an old tired routine that needs to be dropped. > A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI You're assuming a random developer is: A) interested in learning UI design, B) needs to learn to design UI, and C) that whoever this random UI person wants or even can teach them. You're building too many assumptions on top of each other. This kind of comments resembles the thinking process of a person with "product manager" position in a small/medium size company. Deep down (consciously or subconsciously) they don't really respect or see the value of the individual developer, but they see the team more like a bunch of horses going around the mill. They optimize for "the product" and throw around sophists-like pseudo-philosophical thoughts that appeal to like-minded individuals or to their bosses.
- bjornsing 5y ago
  > This kind of comments resembles the thinking process of a person with "product manager" position in a small/medium size company. Deep down (consciously or subconsciously) they don't really respect or see the value of the individual developer, but they see the team more like a bunch of horses going around the mill. They optimize for "the product" and throw around sophists-like pseudo-philosophical thoughts that appeal to like-minded individuals or to their bosses. There’s some truth to that somewhat cynical description. :) But how do you organize software development without falling into that hole? A product has to make sense as a whole, and the only/easiest way to accomplish that is to make a single person responsible for its high-level specification. From there the negative cultural fallout you describe is to some extent inevitable (although you can and should counteract it of course).
arawde 5y ago
> Once you have a developer [who does everything], development time to get a superior product will drop massively I feel like you're just going to get stressed engineers who are stretched thin across multiple domains. This sounds horrible

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

throwawayswede 5y ago

Don't take this the wrong way but your comment represents many things that are wrong with the industry. Meta about your comment: Major condescending-vibe overall. > Would you want to hear about that algorithm? Because it's called communication. First of all, drop the patronizing tone. Second: what are you saying? Developers don't communicate? Don't communicate efficiently or correctly? Specify the thing that is wrong and your proposed solution and then it can be assessed. As it stands your first paragraph is meaningless. For what it's worth I've worked with marketing teams that have communication skills that match a random rock on the street, so this is not a developer issue. That "developers are all geeks and nerds and can't talk to people, and i'm here to fix it" is an old tired routine that needs to be dropped. > A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI You're assuming a random developer is: A) interested in learning UI design, B) needs to learn to design UI, and C) that whoever this random UI person wants or even can teach them. You're building too many assumptions on top of each other. This kind of comments resembles the thinking process of a person with "product manager" position in a small/medium size company. Deep down (consciously or subconsciously) they don't really respect or see the value of the individual developer, but they see the team more like a bunch of horses going around the mill. They optimize for "the product" and throw around sophists-like pseudo-philosophical thoughts that appeal to like-minded individuals or to their bosses.

bjornsing 5y ago
> This kind of comments resembles the thinking process of a person with "product manager" position in a small/medium size company. Deep down (consciously or subconsciously) they don't really respect or see the value of the individual developer, but they see the team more like a bunch of horses going around the mill. They optimize for "the product" and throw around sophists-like pseudo-philosophical thoughts that appeal to like-minded individuals or to their bosses. There’s some truth to that somewhat cynical description. :) But how do you organize software development without falling into that hole? A product has to make sense as a whole, and the only/easiest way to accomplish that is to make a single person responsible for its high-level specification. From there the negative cultural fallout you describe is to some extent inevitable (although you can and should counteract it of course).

arawde 5y ago

> Once you have a developer [who does everything], development time to get a superior product will drop massively I feel like you're just going to get stressed engineers who are stretched thin across multiple domains. This sounds horrible