3 ms·

I find this to be a fairly hostile attitude toward management roles and unfortunately it's one that many people share. And it's ruining part of this industry. N

by sthlm 15y ago

I find this to be a fairly hostile attitude toward management roles and unfortunately it's one that many people share. And it's ruining part of this industry. Not every manager is a 20-year old MBA grad who's out to ruin your business. What you're describing -- a small team of independent programmers -- accounts for only one part of software engineering projects: programmers are at the center of the efforts, everything else is just overhead. Many projects are more complex. Development spans multiple long-termed iterations, is time and safety-critical, very expensive and only an integrated part of a larger development process (e.g. automotive, aeronautics, ...). A lot of the man hours on these projects go into tasks that don't directly include programming. These are not necessarily management roles. You have Architects, Test Designers, ... not to count all the roles that have nothing to do with IT at all (if you design a car, what percentage or project members are programmers?). I personally think that anyone who works in software engineering should have a strong background in programming/development. But active programming is not necessarily part of many roles in many software engineering projects today. If you don't wish to work in such an environment, no one is forcing you to. If you are, and you are unhappy, explore different options. But don't underestimate the incredible importance that non-programmer roles play in many, many, many projects.

Volpe 15y ago
> ... Architects, Test Designers... The two examples you use, would have to be the best examples of 'waste' in the software industry. I liken them to having someone on your team who is "The Debugger" where all he does is debug the developers code. Developers should know how to test their code/app and should know how to design their app, and know how to debug their app. Sure they could 'specialise' one or more of these areas but they should all be able to build software (i.e write code).
- nl 15y ago
  Specialization is an adaptation that seems wasteful when it isn't needed but makes a huge increase to efficiency when it is. Yes, architects and test designers can be a waste. But they can also act to make developer's lives easier. Good architects can code, but usually act at a higher level - making sure different projects (a) know about each other, and (b) work together. That's important because teams tend to focus on their own success without always taking account of the bigger picture.
  - Volpe 15y ago
    > Good architects can code... Is synonymous with good developers are also good architects. I think (if I can articulate my thoughts correctly) my meaning was, that there is an obsession with breaking tasks into specific roles that are then the sole responsibility of one person. To the point of inefficiency (given the number of people you have to talk to for a given feature). I don't agree that specialisation is wasteful (for the project at least). If it isn't needed, the person can still be a 'standard' dev. But if it is needed, they contribute more. (The only waste is to the individual if they specialise in an un-needed skill).
    - johnx123-up 15y ago
      > Is synonymous with good developers are also good architects. But, most architects are lazy genius. Only way to utilize their skills is not allowing them to code, but letting them designs and coach.
- wnight 15y ago
  I agree. Architects should just be senior coders - the people whose strategic decisions are usually right (mostly because they know how to test their assumptions). Having a specific person who doesn't do anything else but architect is broken - APIs are for programmers. If you aren't eating your own cooking you have absolutely no right to be claiming you did it well. Similarly, you could hire a developer on the strength of their testing and get them to champion a stronger infrastructure but like the architect they need to be an active developer to judge the usefulness of their solutions. I'd say managers (of coders) need to be coders too. They can survive not being if they're great managers, but they're doing it with a handicap of not being able to understand the tools and see the big-picture their team is missing. And the state of the art, not whatever they used in school twenty years ago. But, conversely I think I was a lousy employee early on (in terms of value created for the core product / hours spent) because I wasn't thinking of the business aspects of the company. So while I think everyone needs active programming skills to participate meaningfully in programming, I also think those programmers need to be aware of the business they're in, the entire industry trends, and that of the problem domain the work is in. If you design/make/sell a farming GPS, for instance, you'd better have farming experience. Perhaps the loosely overlapping networks of broadly-skilled individuals managing their own (but with input from an on the rest of the company) doesn't scale well, but I've yet to see a better idea.
iand 15y ago
I didn't intend it to be a hostile comment/attitude. It's just pragmatic. I can code, I can design and I can architect. That's great when it's me and a few others, but as a business scales up I should be able to recognise when there are better coders than me. If I refuse to get out of the way then I'm just a hindrance. Therefore I should adapt to the new business size and use my experience etc to help those better coders.

by sthlm 15y ago

Volpe 15y ago

> ... Architects, Test Designers... The two examples you use, would have to be the best examples of 'waste' in the software industry. I liken them to having someone on your team who is "The Debugger" where all he does is debug the developers code. Developers should know how to test their code/app and should know how to design their app, and know how to debug their app. Sure they could 'specialise' one or more of these areas but they should all be able to build software (i.e write code).

nl 15y ago
Specialization is an adaptation that seems wasteful when it isn't needed but makes a huge increase to efficiency when it is. Yes, architects and test designers can be a waste. But they can also act to make developer's lives easier. Good architects can code, but usually act at a higher level - making sure different projects (a) know about each other, and (b) work together. That's important because teams tend to focus on their own success without always taking account of the bigger picture.
- Volpe 15y ago
  > Good architects can code... Is synonymous with good developers are also good architects. I think (if I can articulate my thoughts correctly) my meaning was, that there is an obsession with breaking tasks into specific roles that are then the sole responsibility of one person. To the point of inefficiency (given the number of people you have to talk to for a given feature). I don't agree that specialisation is wasteful (for the project at least). If it isn't needed, the person can still be a 'standard' dev. But if it is needed, they contribute more. (The only waste is to the individual if they specialise in an un-needed skill).
  - johnx123-up 15y ago
    > Is synonymous with good developers are also good architects. But, most architects are lazy genius. Only way to utilize their skills is not allowing them to code, but letting them designs and coach.
wnight 15y ago
I agree. Architects should just be senior coders - the people whose strategic decisions are usually right (mostly because they know how to test their assumptions). Having a specific person who doesn't do anything else but architect is broken - APIs are for programmers. If you aren't eating your own cooking you have absolutely no right to be claiming you did it well. Similarly, you could hire a developer on the strength of their testing and get them to champion a stronger infrastructure but like the architect they need to be an active developer to judge the usefulness of their solutions. I'd say managers (of coders) need to be coders too. They can survive not being if they're great managers, but they're doing it with a handicap of not being able to understand the tools and see the big-picture their team is missing. And the state of the art, not whatever they used in school twenty years ago. But, conversely I think I was a lousy employee early on (in terms of value created for the core product / hours spent) because I wasn't thinking of the business aspects of the company. So while I think everyone needs active programming skills to participate meaningfully in programming, I also think those programmers need to be aware of the business they're in, the entire industry trends, and that of the problem domain the work is in. If you design/make/sell a farming GPS, for instance, you'd better have farming experience. Perhaps the loosely overlapping networks of broadly-skilled individuals managing their own (but with input from an on the rest of the company) doesn't scale well, but I've yet to see a better idea.

iand 15y ago

I didn't intend it to be a hostile comment/attitude. It's just pragmatic. I can code, I can design and I can architect. That's great when it's me and a few others, but as a business scales up I should be able to recognise when there are better coders than me. If I refuse to get out of the way then I'm just a hindrance. Therefore I should adapt to the new business size and use my experience etc to help those better coders.