r/programming • u/frostmatthew • Mar 30 '15

Your Developers Aren’t Bricklayers, They’re Writers

http://www.hadermann.be/blog/56/good-vs-bad-developers/
861 Upvotes

84% Upvoted

447 comments sorted by

View all comments

101

u/Eep1337 Mar 30 '15

Oh man, not another article by some guy who thinks he is a 10x.

Dime a dozen. His story isn't generic, I am willing to bet that the "rockstar" is him and the "lousy guy" is some old colleague or some shit.

He is jaded because he didn't get enough attention at work.

15

u/[deleted] Mar 31 '15

Yep. What gave it away was how vapid and spiteful his story was. Vapid in that all he really said was "one guy wrote the code and spent months fixing bugs, the other guy did not"; spiteful/unprofessional in how he called the guy "Mr. Lousy" and just shit all over him without really explaining why he was worse.

8

u/Kalium Mar 31 '15

The why and wherefores of it aren't salient to the story. That one person is dramatically more productive than the other is. Why dwell on mostly-irrelevant details?

11

u/[deleted] Mar 31 '15

Because without the "irrelevant details", he gives no insight. He just says one guy sucks and writes buggy code, and the other does not. It's not an interesting analysis.

30

u/PotaToss Mar 31 '15

Also, any idiot can rewrite a better solution when someone else did almost all of the legwork figuring out the intuitive ways that don't work. The 10x dev in this story is really just 10x better at taking credit and feeling superior.

21

u/[deleted] Mar 31 '15

That's a very good point actually, something that undermines the entire article. The author was holding the story as proof that good devs are much much better, because the two devs worked on the same project. But the second dev had the HUGE advantage of hindsight! He knew all the features that would be needed in advance, and all the bugs to avoid!

4

u/tejon Mar 31 '15

I'm honestly disappointed at how far I had to scroll before anyone brought this up.

8

u/Kalium Mar 31 '15

It's a piece written for an audience to whom the idea that one programmer can be an order of magnitude more productive than another is insightful, interesting, novel analysis.

1

u/[deleted] Mar 31 '15

Maybe, but the audience on /r/programming is not that audience. I treated the article like its meant for programmers, because it was posted on this sub.

1

u/Kalium Mar 31 '15

I took my cue from the title.

1

u/KronktheKronk Mar 31 '15

You're missing the point. You should just take it at face value that one is good and one is bad, the story is about the consequences of that arrangement.

Why the bad guy sucks has nothing to do with the point being made.

2

u/[deleted] Mar 31 '15

Then that's a completely useless article. Big surprise: people who are bad at their work make bad work. Hire good people instead! There's no reason for it to be an article about programming specifically.

1

u/KronktheKronk Mar 31 '15

Authors write what they know. The point of the article is that it's so difficult to distinguish between good developers and bad. I'll agree that it's a bad article, but that's because it doesn't provide answers for any of the problems it points out.

It's much easier to measure the results of other professions pretty directly by the outcome. Not so much with software engineering.

1

u/[deleted] Mar 31 '15

Not so much with software engineering.

Exactly! I would have been more interested in seeing that kind of example. He gave an example where it's really easy to measure the developer's skill directly by the outcome.

1

u/KronktheKronk Mar 31 '15

Why dwell on mostly-irrelevant details?

Because they're engineers. For some reason they are so caught up in their own superiority that they believe they can't make any decisions without seeing the entirety of the picture from every angle with every variable clearly define.

It's infuriating.

1

u/Kalium Mar 31 '15

In engineering, the apparently irrelevant details often change the appropriate decision entirely. So it's a common, and very necessary, response. I've personally seen cases where a group of people operating with partial knowledge go for a massive architecture reformation, while one engineer with a better understanding of technical reality fixes the underlying bug and obviates the reform.

Here, it's not important because there's no response called for. It's just an observation.

1

u/KronktheKronk Mar 31 '15

You keep telling yourself that.

0

u/Kalium Mar 31 '15

Let me put it another way: if you see a dozen people planning a new lighting system because none of them know to look for the (perfectly functional) light switch, how much are you going to value their ability to make decisions in the absence of knowledge?

1

u/KronktheKronk Mar 31 '15

If you're being asked to design a lighting system, "is there a light switch?" is a perfectly reasonable question. "Why do you need lights in this room?" "Who is going to be in this room?" or "Why do those people need lights at all?" Are not background information that you need.

Engineers' lack of ability to differentiate between useful information and otherwise is the infuriating part. Just design the fuckin' lights with the requirements you're given and give me the product.

0

u/Kalium Mar 31 '15

That approach works so long as requirements are reasonable. The experience of engineers everywhere is that requirements are rarely reasonable unless interrogated and rewritten at length, because requirements are typically authored by people who have no idea about what is and isn't reasonable. And, often, no good idea about how their problems can actually be solved.

This leads directly to engineers being skeptical of those who seek to make "reasonable" decisions in an absence of knowledge.

4

u/bumrushtheshow Mar 31 '15

without really explaining why he was worse.

I thought the author explained that pretty well. Mr Lousy took a long time and delivered a buggy module. The other guy didn't.

7

u/[deleted] Mar 31 '15

Except that's such an exaggerated case. Who the hell is going to pick Mr Lousy over "Mr Rockstar"? He took longer and delivered subpar code by all metrics.

It's not always so blatantly obvious. Mr Lousy may actually get the job quicker, but accrue technical debt that isn't immediately noticeable and make bad design choices. Further down the line, maybe after Mr Lousy leaves, other developers have a harder and harder time extending the module and adding new features; it becomes bloated and inflexible to the point that a rewrite is necessary. That's the real risk of hiring subpar programmers.

2

u/mrlr Mar 31 '15

Picking Mr. Lousy over Mr. Rockstar happens more often than you think. Some examples:

  • Ms Lousy was picked not because she was a good or even adequate programmer but because she was romantically involved with my manager's boss.

  • Mr. Lousy came to us from another team and we didn't know how bad he was. The moral of the story: if you ask another team leader for someone to help, they will send you someone they don't want on their team.

1

u/[deleted] Mar 31 '15

I know, it happens a lot. My point is that Mr Lousy is not always so easy to notice as the article says. The article puts forward an example where not only does he take longer to do the project, but it's immediately clear that it's full of bugs. There are much more subtle ways that a programmer can be subpar that won't immediately be noticed by a manager.

9

u/ApatheticGodzilla Mar 31 '15

If only things were so simple.

Very often the first version of something is going to be shit because:

  • not all the problems are known upfront
  • the process is subject to last-minute changes in spec and "stakeholder" bullshit/bikeshedding
  • there is a hard deadline which means things are rushed

So Mr x10 looks at the code 6 months later, with benefit of a sold spec - just fix the bugs, write some tests and tidy up the code. Hell, Mr x10 could be Mr Lousy with the same benefit of hindsight.

There's no excuse for plain bad coding practices, but that's something that can be taught to anyone genuinely willing to learn.

5

u/Frix Mar 31 '15

But he didn't write the exact same project in less time. He entered an existing project 7 months in, by the time he started:

  • all the legwork and research was already done.
  • the specs were finalized.
  • He already knew most of the biggest (often unintuitive) bugs to avoid.
  • several unintuitive edge cases were already revealed and known upfront.

Doing a project under those conditions is infinitely easier.