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: 3, Interesting) by frojack on Monday December 04 2017, @06:12PM (4 children)
TFS/TFA starts from the assumption that you should be accepting of new ideas from the last man hired....
You simply can not survive that way. You can't start taking direction from the last guy who walked in the door.
Every programmer starts from
1) bad mouthing the code quality
2) calling the last guy a clueless idiot
3) starts rewriting everything behind your back, (usually in a programming language your shop doesn't use )
... some time way later
354) finds out the last guy is still on staff
This is an old time worn lament, (screed really), that has been around since dirt. New kid wants to rewrite the world, in this week's language de jour, in fact, he has it 95% done already and its ready for production.
You only asked him to add one data element from existing sources to the bottom of a report, but he wants to parameterize the entire report, build the text and the data extraction from boiler plate text and code snippets stored in a database with a gui drag and drop layout interface, just so that he never ends up doing this menial chore again.
I've seen this dozens of times. I've probably done this when I was green. Once.
Do we really have to replow this field?
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Monday December 04 2017, @08:30PM (1 child)
You're against someone being motivated and then taking the 5% of that outcome that you need, now knowing just how much more the kid can do, even if no one asked?
Most people I work with have a hard time delivering that 5% the kid didn't do, let alone providing 90% more than anything asked of them, and you call it green?
Maybe he's green because he was idealistic. With that kind of output, his ideals seem to be better than most.
(Score: 3, Insightful) by choose another one on Monday December 04 2017, @08:50PM
I think you are missing the point that the 5% he didn't do inevitably comprises:
- 95% of the work
- 95% of the bugs, the testing and the QA
- must-haves for all the top 5% of customers, by account value
This is why knowledge and experience make more money than ideals.
Don't want to make money? - fine, don't take the paid job.
(Score: 4, Funny) by krishnoid on Monday December 04 2017, @10:09PM (1 child)
Well, it's a field, so about yearly, it would seem.
(Score: 3, Funny) by fyngyrz on Monday December 04 2017, @11:18PM
You made me furrow my brow with that one. It was seedy. But now that the idea's been planted, I can't seem to uproot it.