The environment that nurtures creative programmers kills management and marketing types--and vice versa
I disagree with this. True, it kills control freaks, but most management doesn't start out out like this. The problem is that when people who expect to be in charge see that they don't have even a minimal level of control, they start to crack down. And that oppressiveness results in the employees (programmers in this case) fighting back, often with passive-aggressive behavior.
Programmers have to accept that they are a part of the problem to start with. The almost instinctive animosity I see towards management is a sign of this.
Look, you're being managed by someone who doesn't really understand what you do. Failing to communicate properly (and yes, the greater onus is on the highly specialized talent to make an effort to communicate with the unspecialized than vice versa!) means that the person attempting to manage you doesn't know what you're doing, when it will be done and what he can do to alleviate problems. Most halfway decent managers just need enough information to manage. If your response to "when will it be done?" is "dunno" or "it's done when we're ready" or "between 5 days to three weeks" then you're not communicating very well and that person is going to think you're deliberately being vague, even if you're just being honest.
Second: "creative?" C'mon gimme a break. Most programmers work on business applications, how "creative" do they need to be in their day to day work? It's plumbing, not much more. Yes, occasionally you do have serious problems that need out of box thinking, but in the normal day-to-day work of business programming if extended creativity is required, something else is wrong. Programming games or entertainment software or something where you have wide latitude to make changes, absolutely. Insurance and HR applications? not so much.
Yes, but the programmers working on business applications are already wearing suits or at least business casual. They are service programmers not product programmers which, I think, the piece more accurately targets.
The hordes of engineers working on the latest incarnation of BigRetailBankOnline.com do not produce a product, the banks services are its product.
Comments
The environment that nurtures creative programmers kills management and marketing types--and vice versa
I disagree with this. True, it kills control freaks, but most management doesn't start out out like this. The problem is that when people who expect to be in charge see that they don't have even a minimal level of control, they start to crack down. And that oppressiveness results in the employees (programmers in this case) fighting back, often with passive-aggressive behavior.
Programmers have to accept that they are a part of the problem to start with. The almost instinctive animosity I see towards management is a sign of this.
Look, you're being managed by someone who doesn't really understand what you do. Failing to communicate properly (and yes, the greater onus is on the highly specialized talent to make an effort to communicate with the unspecialized than vice versa!) means that the person attempting to manage you doesn't know what you're doing, when it will be done and what he can do to alleviate problems. Most halfway decent managers just need enough information to manage. If your response to "when will it be done?" is "dunno" or "it's done when we're ready" or "between 5 days to three weeks" then you're not communicating very well and that person is going to think you're deliberately being vague, even if you're just being honest.
Second: "creative?" C'mon gimme a break. Most programmers work on business applications, how "creative" do they need to be in their day to day work? It's plumbing, not much more. Yes, occasionally you do have serious problems that need out of box thinking, but in the normal day-to-day work of business programming if extended creativity is required, something else is wrong. Programming games or entertainment software or something where you have wide latitude to make changes, absolutely. Insurance and HR applications? not so much.
Yes, but the programmers working on business applications are already wearing suits or at least business casual. They are service programmers not product programmers which, I think, the piece more accurately targets.
The hordes of engineers working on the latest incarnation of BigRetailBankOnline.com do not produce a product, the banks services are its product.