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

Welcome to IWETHEY!

New Well, damn!
Open source has a serious problem if there is no one doing code review.

"There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that "my ignorance is just as good as your knowledge."

-- Isaac Asimov
New Somebody needs to pay for it. :-(
New ESR was wrong
And this, and heartbleed, and the other long-standing vulns in open-source apps, all prove it.

It's simply not true, for complex systems, that with sufficient eyes all bugs are shallow.

You need the right people looking for the right things.

And yeah, that shit ain't free or even cheap.
New It's the high notes

If your soprano can't hit the high f, you don't solve it by hiring 5 more sopranos who also can't hit the high f.

New Yeahbut...
NPR, a few days ago:

DYLAN MINOR: Thank you for having me.

SHAPIRO: You looked at employment data from more than 50,000 workers across 11 companies. What did you find that toxic workers all have in common?

MINOR: I found several things. So it's not that literally every toxic worker is the same, but there certainly are some command traits. One thing I found is, on average, they tend to be much more productive. I also found that toxic workers tend to be more selfish than the average worker, tend to be more overconfident. And lastly and, I think, interestingly, surprisingly, to me, they also self-profess to follow the rules.

SHAPIRO: So some of those things don't seem to fit with the others - more productive than average, for example. You found that toxic workers are harmful to the workplace. How do you reconcile that with the idea that they're more productive than the average worker?

MINOR: Well, they're - presents itself a trade-off. So one area in particular is overconfidence. It turns out that those workers that are overconfident do indeed tend to be quite a bit more productive. However, those workers that are overconfident also are more likely to be toxic. And so fortunately, in this setting, we actually had the data that we could look at the effects of profits. And if you look at those two features together - that is, increased likelihood of productivity and increased likelihood of toxicity - you're actually still taking on a net thousand-dollar loss per worker that has greater confidence.

I've not read a lot of Joel, but each piece I remember rubs me the wrong way like this one does. He writes as if he has found some great simple truth that the huge successful companies out there don't recognize. But his great simple truth is either a truism or is something that really isn't true in general. His first paragraph doesn't even mention customers for his "software that works". It sounds like supply-side nonsense (and we know how well that worked out for the economy as a whole).

Hiring great productive programmers is fine - who wouldn't want to do that? But if they're all jerks who can't work together or who make lives miserable for people who have to work with them, then it doesn't matter if they write working code 50% faster than their peers - they company will fail anyway. Or if hiring great productive programmers that cost 3x as much as hiring good, productive, flexible people who can learn to be great productive programmers over time - is the most expensive option automatically the best choice, especially long-term?

It must have been nice for him to have the time and freedom to write 15,000+ character posts like this so often. I wonder how he rated its effect on the bottom line...



New Some insight, some questionable strategy
I agree that a pile of mediocre programmers will never do what one great one does. That's the part that applies to security/encryption.

Does that make it the best way to build your software company? Less clear. He wouldn't be the only person, though, saying that starting with great people is the best predictor of the success of a startup.

For large, established companies, the toxic worker is a real problem. When you've only got a half-dozen programmers, and they mostly work independently, productivity probably trumps cooperation.

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.
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]

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.
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.

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.
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.

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.
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.

     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)

You want to debate how many LRPD's fit on the head of the GRR?
112 ms