SoylentNews is people
SoylentNews
from the it's-easier-to-deal-with-computers-than-with-people dept.
The Do's and Don't's of Managing Programmers:
Why are some programmers such jerks?
Too many managers believe the problem lies with [the disgruntled programmer]. If he was a better employee, dedicated worker, or at least cared more, then this wouldn't happen. Right?
Unfortunately, no.
The first suggestions matter a lot
How you handle ideas from new programmers sends an important signal. Good or bad, it sets the stage for what they expect. This determines if they share more ideas in the future... or keep their mouth shut.Sure, some ideas might not be feasible in your environment. Some might get put on the back burner to be discussed "when we're not busy". Some ideas seem great, but they run against unspoken cultural norms.
No matter what the reason, dismissing or devaluing your programmer's ideas — especially in the first few months — is a bad move.
Damaged by all the naysaying, he'll try a few more times to present his ideas differently, aiming for a successful outcome. If he continues to feel punished, though, he'll realize that the only way to win is not to play.
Which is exactly what you don't want your programmers learning.
He will stop presenting ideas, asking to meet customers, and genuinely trying to understand the business.
Ultimately, it's a lose lose.
If you want programmers to become mere code monkeys, treat them like code monkeys.
(Score: 2) by Thexalon on Monday December 04 2017, @10:13PM (2 children)
Sensitivity training has a point, specifically to help save the company from being sued if you do something you shouldn't.
However, most meetings are pointless:
- You should know where the project stands from the code repository and the ticket tracking system. But if you need an in-person report, you can just go over to their desk and check in quickly.
- Design collaboration is best handled informally.
- Announcements can be an email.
- Praise is best given out informally anyways: Just don't be too quiet in cubicle land when saying things like "Yup, that function was absolutely brilliant and efficient, well done." or "You figured out a bug that had been annoying us for years, thank you!"
The main purpose of most meetings is posturing by people who owe their jobs to posturing rather than productivity.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by bzipitidoo on Tuesday December 05 2017, @04:47AM (1 child)
I'd say you're lucky to have worked for departments and/or companies that actually want to accomplish useful things, and the coders were lucky to have a manger like you. I've often been in situations where there are several hidden agendas, and the office politics was vicious.
Had individual managers more concerned about such anti-social goals as elevating themselves by lowering everyone else, or empire building because they thought that would enhance their own job security. There are the quivering cowards who hate and fear anything they don't understand-- and there's a lot they don't understand. They force everyone to do only those things they understand, in the ways they understand. Closely related are the loudmouth managers who are in over their heads and know it, and are desperately trying to hide their incompetence by spending all day nitpicking about trivial details, thus preventing any discussion or work that is out of their depth, and incidentally making progress slow to a glacial crawl not that they care in the least about that. Another similar sort are the ones who feel threatened, and spend more time undermining the people they see as threats than doing honest work. There are the jealous ones who are fairly competent, but they walk around with a huge chip on their shoulders constantly trying to show everyone those genius engineers aren't so smart after all. There's the slave driving type who doesn't know what good work looks like, but who can tell when the employees look relaxed or stressed, and thinks that if they aren't stressed, aren't sweating blood, then they aren't working hard enough. Then there's the rich brat kind of manager who is super touchy about anything that could be construed as critical of him. Or a different kind of rich brat is the arrogant asshole who really thinks he is the only adult in the room and all the employees working under him are children who would starve if not for his magnanimity in allowing them the privilege of having a job working for his fantastic company, and for which they had better be grateful if they know what's good for them. There's the treacherous backstabber who, behind your back, blames you for every problem, real or imaginary, your fault or not, and makes the blame stick because you're the smart guy who should have known better.
In all those cases, reality eventually catches up with them. Either the dysfunctional people are rendered harmless, maybe kicked out, or maybe even turned around, becoming good employees, or the project ends in a huge, disastrous train wreck. Maybe the entire department is fired. Maybe the whole dang company goes under. If it does turn into a train wreck, "I told you so" will be very cold comfort.
I tried to ignore the politics, tried to let the code speak for itself, and trusted that the most meritorious way, be it mine or not, would win out. But in a dysfunctional office, that doesn't work. Now I think an essential part of the training for all engineers should be a class on office politics. First show them that they can't ignore it, can't expect to rise above it. It's essential to pay attention to the people around you, and learn as quickly as possible who the lying, treacherous, deadbeat fakes are and protect yourself from them before they do you dirty, perhaps frame you for something, or convince the boss you aren't a "team player" or a good fit, or whatever.
(Score: 2) by Thexalon on Tuesday December 05 2017, @10:49PM
Hey now, I wouldn't go that far! Just because I wanted to accomplish useful things didn't mean the company did. However, and this was important for me to notice, if you just quietly went ahead and did the useful thing without being directed to, and the result was that your work was going more smoothly and quickly, nobody was going to complain too successfully. If someone did try to complain, I could say something along the lines of "Yes, on my own initiative I implemented some of the best practices I've learned over my career, and as a result my department is 25% more efficient, allowing the company to complete projects more easily and thus better support the rest of the organization. And all that cost us was 1 sysadmin spending 4 otherwise spare hours. If you don't want me to take such steps in the future, please let me know."
The only thing that stops a bad guy with a compiler is a good guy with a compiler.