IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Here's the thing:
Toxic workers may be highly productive, but that doesn't mean that highly productive workers are toxic.

I've worked with one of the toxic, highly productive ones. The negative, poisonous effect of these people on the other people in the company cannot be overstated, but they're loved by management because of the apparent productivity.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
New had one of those at a previous place, my last job as an FTE
Great programmer, toxic as fuck had glaring ignorance about pieces of stuff that cost the company but shouted heartily and beloved by the management clique. I could deal with him but a lot of equally good people left because of him.
always look out for number one and don't step in number two
New There is a connection, though
An overabundance of confidence leads to productivity, and to being an asshole. Most of the managers I've worked with prefer "decisive and frequently right" to "methodical and rarely wrong".

I'd like to say that's the wrong choice, but how do I know I'm not just favoring my own personality?

[edit: tyop]
--

Drew
Expand Edited by drook Dec. 20, 2015, 08:26:32 PM EST
New team the two tegether, that gets all of the I's dotted and leaps of faith dissected
always look out for number one and don't step in number two
New I know more highly productive people who aren't toxic, however.
I've just worked with the one, but he was enough to give me PTSD for years afterward.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
New Think about it from management's side
They only deal with developers at the beginning and end of a project. In the beginning one guy sounds confident and decisive, the other keeps talking about problems and challenges. Some time later the first guy says it's ready for pilot and the second guy says he still has questions about requirements.

I really don't need to flesh this out any more to make the point, do I?

What I can't decide is whether the first guy might be right. Fail faster ... Release early, release often ... Minimum viable product ...

We talk about doing the smallest thing that could possibly work, but when someone tries to go faster than we're comfortable with, they're reckless and overconfident.
--

Drew
New Different situation with this guy
He wouldn't work with anyone unless they did exactly what he told them to, started major projects completely by himself without the Chief Software Architect (me) even knowing about them, and so on.

Fail faster at this place meant hours of downtime on a Monday where each hour had at least 7 digits attached to it.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
New But what about small teams?
Remember I started this from Joel's post about getting the best developers at a very small company, where each person might be working on a project solo. In those cases maybe you don't care so much about personality and teamwork.

As for always doing things his way, which is better: a half-dozen people spending several days trying to reach a compromise on the best direction, or that same group all going in a reasonable direction set down by the most forceful personality?

Obviously someone should see those expensive Mondays you describe and do something about it. But with enough prior reputation someone could survive one or two of those as the cost of being aggressive.
--

Drew
New You do care about it.
Because small companies become (hopefully) big companies, and by that time the asshole is too deeply ingrained to get rid of. And now that the company is big, his asshattery is causing bigger, more expensive problems, and he isn't (supposed to be) working on solo projects any more.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
New One could argue that you should care *more* in small company cases.
While the potential damage may be greater in a larger company, in that case you have the potential to "route around the damage" by, say, getting other managers involved. When the company is small, each piece has relatively more of the company resting on it.

Cheers,
Scott.
     Grub2 zero day bug - Hit backspace 28 times... - (Another Scott) - (20)
         if they can get to your console you have more problems than that - (boxley) - (3)
             Been there for a while longer than 2012 - (scoenye) - (2)
                 Red China is behind it. - (a6l6e6x) - (1)
                     Well, Netscreen was Chinese. Maybe someone got creative with git... -NT - (scoenye)
         Well, damn! - (a6l6e6x) - (15)
             Somebody needs to pay for it. :-( -NT - (Another Scott)
             ESR was wrong - (pwhysall) - (13)
                 It's the high notes - (drook) - (12)
                     Yeahbut... - (Another Scott) - (11)
                         Some insight, some questionable strategy - (drook) - (10)
                             Here's the thing: - (malraux) - (9)
                                 had one of those at a previous place, my last job as an FTE - (boxley)
                                 There is a connection, though - (drook) - (7)
                                     team the two tegether, that gets all of the I's dotted and leaps of faith dissected -NT - (boxley)
                                     I know more highly productive people who aren't toxic, however. - (malraux) - (5)
                                         Think about it from management's side - (drook) - (4)
                                             Different situation with this guy - (malraux) - (3)
                                                 But what about small teams? - (drook) - (2)
                                                     You do care about it. - (malraux) - (1)
                                                         One could argue that you should care *more* in small company cases. - (Another Scott)

I'm glad I didn't have to explain it to you.
126 ms