4 ms·

This. The same programmers that complain about clueless micromanagement are usually also the ones with the "I don't want to know all this business shit" attitud

This. The same programmers that complain about clueless micromanagement are usually also the ones with the "I don't want to know all this business shit" attitude. Ridiculous. I know this stereotype exists, but I don't know many programmers who actually hold that attitude. The "business shit" is intellectually easier and not at all uninteresting. The payoff in learning it is quite high: in a functional organization, you get more respect and money for a relatively small investment. There might be some clueless 23-year-olds out there who reflexively dislike "business" because of Marxist-academic indoctrination, but that's a rare and transient state. If anything, the MBA micromanagers try to encourage this attitude by taking the "I will handle all of this" approach with the business side and the "big picture". They make it their turf by assertion, then wonder why the engineers under them seem not to give a shit. Engineers tune out when they don't have any power or control. It's a survival mechanism. If you can't do anything about it, don't waste cycles on it.

alanctgardner2 14y ago
I work with at least one guy who just straight-up isn't interested in managing, ever. As the team has expanded, he's moved two tiers down the org chart, but he isn't interested in learning the administrative portion at all. It's not about control, some people just seem to be allergic to meetings, dealing with stakeholders, etc. It's a perfectly valid viewpoint to have: some people just want to write code.
- blindhippo 14y ago
  The guy you mention likely is a solitary worker (I'm one as well). We tend to prefer not working in teams, other people slow us down and cause confusion in our work. But America's insistence on a "team" based work culture really hampers those like me. We can get 10x the amount of work done individually as we can as part of a team if left to our devices - but this is frowned upon, indeed looked at as a social "problem". I * sincerely* blame MBA culture for this detrimental attitude.
  - alanctgardner2 14y ago
    It's kind of an interesting viewpoint; how do you handle being 'crowded out' of a project? For example, if you started as the sole worker on something internal, but then it became customer-facing, and the team necessarily had to expand to get the work done. I can appreciate saying that you only get 10% of the work done if you're on a team, but you don't honestly think you can achieve as much as a ten man team? What about when more than 10 people are required? I guess my question is, as a self-identified 'solitary worker', would you take it upon yourself to leave a project if it reached a point where team expansion was necessary? Is there any good way to manage someone like you to get you to contribute to a larger project, or if it a lost cause?
    - adeaver 14y ago
      There is a difference between working on a team where everyone works on the same bits and you have to work around their projects and their timelines, and being part of a team where each 'member' works in a semi-siloed, semi-independant capacity. I much prefer the latter to the former since I don't have to work about anyone else makes changes to stuff without my knowledge but I'm still on the team, still met with the others to discuss what we are working on and how it impacts X or Y.
      - alanctgardner2 14y ago
        I can see the siloed approach working to a point, but there are two big drawbacks: - no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward. - no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it. Essentially, having all your team hived off from each other, doing their own thing: - gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge. - reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong). If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.
- mindcrime 14y ago
  I work with at least one guy who just straight-up isn't interested in managing, ever. As the team has expanded, he's moved two tiers down the org chart, but he isn't interested in learning the administrative portion at all. I just want to point out that there are different aspects of "managing". There's tactical, command and control, administrivia type stuff, and there's "solving problems, acquiring resources and providing high level coordination" and then there's "strategic decision making" kind of management. One can certainly lack interest in one of those, but might find the others interesting if exposed to that part of things. Personally, I consider most of what most managers do, to be "administrivia" which is of very low value, and I'd have no interest in ever doing that. But when a manager it tasked with actually identifying and solving problems, making strategic decisions, etc., that part can actually be as intellectually challenging as programming and can actually be fun in it's way. It's not about control, some people just seem to be allergic to meetings, dealing with stakeholders, etc. It's a perfectly valid viewpoint to have: some people just want to write code. That's absolutely true as well. I was largely that way when I was younger, but over time I've grown more interested in the other aspects of things.
adeaver 14y ago
I use to hold that attitude as did a lot of the people I worked with. Just said 'tell me what you want the thing to do and I'll make it happen', didn't really care about the business side of things. That changed a few years ago (can't remember the exact reason why) when I started learning about the industry I was working in (because it was something I wanted to know about) and saw my work getting better and coming back with fewer and fewer change requests and a couple of Oh, that was a great way of doing X. You get it! Made a world of difference.
damoncali 14y ago
If you can't do anything about it, don't waste cycles on it. I think the point is that you can do something about it - it just requires stepping out of the engineering midset for moment now and then. I've seen this fatalistic attitude frequently, both in software developers and "real" engineers (mechanical, electrical, etc). It's not healthy for the engineer or the organization, and I can't quite figure out where the attitude comes from.
- michaelochurch 14y ago
  Engineers are culturally unusual in being very tolerant of criticism (from other engineers). That's because our compilers, nominally subordinate, yell at us on a daily basis about minor syntactic errors. With managers, you can't take the same approach. You cannot simply tell your boss that his managerial style is nukular buttfail. That gets you fired.
mindcrime 14y ago
I've known a few programmers who really just were not interested in the business side of things. And I've known a few who were really interested in it. On balance, I think this stereotype exist for a reason, but - as with all stereotypes - it is flawed when treated as a general truth. Engineers tune out when they don't have any power or control. It's a survival mechanism. If you can't do anything about it, don't waste cycles on it. Yeah, I've definitely seen this. But, on the flip side, I've seen manager types who want the technical people to get move involved in understanding the business issues and develop more of an ability to contribute at that boundary (to the extent that such a thing actually exists) between the "business world" and the "IT world". If you folks will indulge me a bit of (related) self-promotion, I've written two recent blog posts[1][2], touching on a specific technique and methodology that I see gaining some steam, which deals with operating at that "chasm" between the worlds. In the first part, I argue that, in the future to come, developers are going to need to learn more about the business world AND that managers are going to have to learn more about technology. [1]: http://fogbeam.blogspot.com/2013/02/so-what-is-capability-case-anyway.html http://fogbeam.blogspot.com/2013/02/so-what-is-capability-ca... [2]: http://fogbeam.blogspot.com/2013/01/why-capability-cases-are-must-when.html http://fogbeam.blogspot.com/2013/01/why-capability-cases-are...

alanctgardner2 14y ago

I work with at least one guy who just straight-up isn't interested in managing, ever. As the team has expanded, he's moved two tiers down the org chart, but he isn't interested in learning the administrative portion at all. It's not about control, some people just seem to be allergic to meetings, dealing with stakeholders, etc. It's a perfectly valid viewpoint to have: some people just want to write code.

blindhippo 14y ago
The guy you mention likely is a solitary worker (I'm one as well). We tend to prefer not working in teams, other people slow us down and cause confusion in our work. But America's insistence on a "team" based work culture really hampers those like me. We can get 10x the amount of work done individually as we can as part of a team if left to our devices - but this is frowned upon, indeed looked at as a social "problem". I * sincerely* blame MBA culture for this detrimental attitude.
- alanctgardner2 14y ago
  It's kind of an interesting viewpoint; how do you handle being 'crowded out' of a project? For example, if you started as the sole worker on something internal, but then it became customer-facing, and the team necessarily had to expand to get the work done. I can appreciate saying that you only get 10% of the work done if you're on a team, but you don't honestly think you can achieve as much as a ten man team? What about when more than 10 people are required? I guess my question is, as a self-identified 'solitary worker', would you take it upon yourself to leave a project if it reached a point where team expansion was necessary? Is there any good way to manage someone like you to get you to contribute to a larger project, or if it a lost cause?
  - adeaver 14y ago
    There is a difference between working on a team where everyone works on the same bits and you have to work around their projects and their timelines, and being part of a team where each 'member' works in a semi-siloed, semi-independant capacity. I much prefer the latter to the former since I don't have to work about anyone else makes changes to stuff without my knowledge but I'm still on the team, still met with the others to discuss what we are working on and how it impacts X or Y.
    - alanctgardner2 14y ago
      I can see the siloed approach working to a point, but there are two big drawbacks: - no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward. - no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it. Essentially, having all your team hived off from each other, doing their own thing: - gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge. - reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong). If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.
mindcrime 14y ago
I work with at least one guy who just straight-up isn't interested in managing, ever. As the team has expanded, he's moved two tiers down the org chart, but he isn't interested in learning the administrative portion at all. I just want to point out that there are different aspects of "managing". There's tactical, command and control, administrivia type stuff, and there's "solving problems, acquiring resources and providing high level coordination" and then there's "strategic decision making" kind of management. One can certainly lack interest in one of those, but might find the others interesting if exposed to that part of things. Personally, I consider most of what most managers do, to be "administrivia" which is of very low value, and I'd have no interest in ever doing that. But when a manager it tasked with actually identifying and solving problems, making strategic decisions, etc., that part can actually be as intellectually challenging as programming and can actually be fun in it's way. It's not about control, some people just seem to be allergic to meetings, dealing with stakeholders, etc. It's a perfectly valid viewpoint to have: some people just want to write code. That's absolutely true as well. I was largely that way when I was younger, but over time I've grown more interested in the other aspects of things.

adeaver 14y ago

I use to hold that attitude as did a lot of the people I worked with. Just said 'tell me what you want the thing to do and I'll make it happen', didn't really care about the business side of things. That changed a few years ago (can't remember the exact reason why) when I started learning about the industry I was working in (because it was something I wanted to know about) and saw my work getting better and coming back with fewer and fewer change requests and a couple of Oh, that was a great way of doing X. You get it! Made a world of difference.

damoncali 14y ago

If you can't do anything about it, don't waste cycles on it. I think the point is that you can do something about it - it just requires stepping out of the engineering midset for moment now and then. I've seen this fatalistic attitude frequently, both in software developers and "real" engineers (mechanical, electrical, etc). It's not healthy for the engineer or the organization, and I can't quite figure out where the attitude comes from.

michaelochurch 14y ago
Engineers are culturally unusual in being very tolerant of criticism (from other engineers). That's because our compilers, nominally subordinate, yell at us on a daily basis about minor syntactic errors. With managers, you can't take the same approach. You cannot simply tell your boss that his managerial style is nukular buttfail. That gets you fired.

mindcrime 14y ago

I've known a few programmers who really just were not interested in the business side of things. And I've known a few who were really interested in it. On balance, I think this stereotype exist for a reason, but - as with all stereotypes - it is flawed when treated as a general truth. Engineers tune out when they don't have any power or control. It's a survival mechanism. If you can't do anything about it, don't waste cycles on it. Yeah, I've definitely seen this. But, on the flip side, I've seen manager types who want the technical people to get move involved in understanding the business issues and develop more of an ability to contribute at that boundary (to the extent that such a thing actually exists) between the "business world" and the "IT world". If you folks will indulge me a bit of (related) self-promotion, I've written two recent blog posts[1][2], touching on a specific technique and methodology that I see gaining some steam, which deals with operating at that "chasm" between the worlds. In the first part, I argue that, in the future to come, developers are going to need to learn more about the business world AND that managers are going to have to learn more about technology. [1]: http://fogbeam.blogspot.com/2013/02/so-what-is-capability-case-anyway.html http://fogbeam.blogspot.com/2013/02/so-what-is-capability-ca... [2]: http://fogbeam.blogspot.com/2013/01/why-capability-cases-are-must-when.html http://fogbeam.blogspot.com/2013/01/why-capability-cases-are...