Live data from Hacker News

The Making of Software Engineering Myths

modelviewculture.com

21–30 of 52 posts

Re: The Making of Software Engineering Myths

#21
post #17

Earlier quoted context omitted.

>How does this claim square with sites like the Daily WTF, which provide evidence that many gainfully employed programmers do not, in fact, use their brains very much? With the more or less weekly announcements of "security breaches" caused by people ignoring basic best practice, for instance storing passwords in plain text? I take many people being bad at programming as evidence that programming is hard, not that it…

> I take many people being bad at programming as evidence that programming is hard, not that it's easy. We are in violent agreement. Note that "hard" is not the same as "abstract and intellectually demanding". Running a marathon is hard. Becoming a US Marine is hard. Many things are hard that do not primarily require quasi-mathematical skills. For that matter, finding gravitational waves is hard but may be just as mu…

You didn't just say "highly abstract", you also said "intellectually demanding". You only seem to be addressing the "highly abstract" part now. All of the failure modes you mention sound like failures of intellect to me.

Also, common failure modes of people working as programmers != common failure modes of people trying to become programmers. Even if most people working as programmers understand the abstractions involved well enough to function (and I'm not certain that's actually true), the abstractions may still be too much for many other people.

>In fact excessive or premature abstraction is a widely recognized failure mode of software engineers, and the myth is responsible in good part for that.

Part of really understanding abstractions is knowing when not to use them. And since, as you say, many people have trouble with that, understanding abstractions must be tough.

Re: The Making of Software Engineering Myths

#22
post #18

Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surpri…

"some developers are surprisingly good" must be the weak form of the 10x hypothesis, and to quote someone else on the internet "where there is a strong version and a weak version of a hypothesis, the weak version is usually trivially true". (The strong version is that the weak version is always just trivial and the strong version is never true).

Re: The Making of Software Engineering Myths

#23
post #20

The 10x engineer exist but not because he or she is so great but because they wrote the shitty code in the first place so it takes a new person 10x longer than the author to do anything. the exponential cost thing is probably somewhat true. If the people who come up with the software actually knew what the fuck they wanted they would save the software from having to guess wrong and redo the code. Unless the software…

I don't know why anyone down voted this because there's definitely at least some truth here. A lot of times the stereotypical 10x rock stars in an organization are really smart and productive people who ship features and move on to the next feature, leaving maintenance to the people who are left behind. They get the glory, but in many cases (totally anecdotal of course) they did it by taking all sorts of shortcuts an…

I downvoted it because people will go to any rhetorical lengths, including "un-defining" the very word intelligence to death, just to believe some people aren't more intelligent than others.

Oh, new rule! We can concede there are "10x" devs, but they have to write shit code! Give me a break.

Re: The Making of Software Engineering Myths

#24
post #9

"The trope of 'software as a highly abstract, intellectually demanding, nearly mathematical activity' contributes to a myth of software development as a profession 'naturally' dominated by males: math is the subject of its own interlocking system of tropes, myths and stereotypes that paint it as a manly pursuit." That logic seems to be all backwards to me. Of course developing software is a highly abstract, intellect…

> Of course developing software is a highly abstract, intellectually demanding activity I don't mean to sound harsh, but "of course" and "it's absurd" aren't much of an argument. My advice is to dig into this a bit deeper. What do you think makes software "a highly abstract, intellectually demanding activity"? What would the world look like if that were NOT the case, what would it look like if it WERE the case? How d…

I honestly think a lot of you have gone plainly insane from years of Internet arguing, and can now write verbose devil's advocate arguments for absolutely anything.

Re: The Making of Software Engineering Myths

#25
Software development is a craft driven by heuristics. The conditions for every project are different. It's difficult to identify contributing conditions. These conditions include technologies, abstraction, business factors, trends, development talent, talent of peers, market position, maturity of the market, funding, knowledge of current requirements, mutation of requirements, complexity of the requirements, interacting agents, etc.

I can see why it would be so difficult to find correlations.

Re: The Making of Software Engineering Myths

#26
Well, at least he's doing his best to prove the myth of all programmers being humorless autists who take everything literally to be true...

Yes, sure, we're talking about exactly 10x when we talk about 10x programmers. Etcetera, etcetera.

Even the most fanatical Agile evangelist gets both the tongue in cheek humor (with a serious undertone) of Zed's "programming, motherfucker", but not this guy.

Re: The Making of Software Engineering Myths

#27
The biggest problems is that no "law" or "rule of thumb" of software engineering is always right. So "debunking" by finding an exception isn't really useful. The best answer to most of these questions is: It Depends (tm). There are situations where the right person making the right calls makes a huge difference and there situations where anyone can make a call that would turn out reasonably OK. There are situations where buggy software has little impact on the business and there are situations where it can result in bankruptcy. This is partly why this is difficult to research in any sort of rigorous fashion and why we should definitely maintain some degree of scepticism to any broad claims.

x10. Anyone here do the TopCoder Algorithm SRMs? There's clear evidence of x10-ish performance difference between the "red" coders and the average coders in there. Does that always apply? No. In certain situations can certain developers blow the average away? Absolutely yes. This is true for things other than software development.

The author talks about "engineers of equal experience". No such thing. There are no two single developers with "equal" experience.

Bug fixes. It's a no-brainer to see the cost of fixing an issue by the same dev in reasonable proximity to when the code was written is a lot cheaper than someone else fixing that bug 6 months later. It's also a no-brainer to see that the cost of fixing a bug in nuclear reactor control software that can cause a core meltdown is cheaper before the core actually melts down. In between there is a lot of grey area but I think there's a lot that can be applied while still being safely in the no-brainer region, that is our intuition, that is our learning/pattern recognition over years of software development.

Re: The Making of Software Engineering Myths

#28
post #18

Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surpri…

I think it's important to distinguish 10x "developers" and 10x moments that a given developer has.

It's like 1.000 game, a hat-trick or triple-double - sometimes any given player has the potential (though not all may be given the opportunity) to make their mark.

Re: The Making of Software Engineering Myths

#29
post #18

Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surpri…

I think the 10x label is just something that is easy to say and comprehend. But the real impact of a high-performing developer is probably way more than 10x. It's not really about lines of code. It might be that this person makes a breakthrough which changes your industry. It might be the difference between staying in business or not.

I've had the pleasure of working with very high-performing developers and the positive impact they can have on a team is amazing. I can see how some people don't believe it if they have never worked on a team where one person amazed and inspired them.

Re: The Making of Software Engineering Myths

#30
post #28
post #18

Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surpri…

I think it's important to distinguish 10x "developers" and 10x moments that a given developer has. It's like 1.000 game, a hat-trick or triple-double - sometimes any given player has the potential (though not all may be given the opportunity) to make their mark.

And yet nobody denies there was something highly unusual about Michael Jordan.
Post reply on HN