"... so now I will jiggle things randomly until they unbreak" is not acceptable' | Hacker News Reader

"... so now I will jiggle things randomly until they unbreak" is not acceptable'

thread.gmane.org

352 pointssigna11126 comments

It gets better later in the thread:

Yinghai, we have had this discussion before, and dammit, you need to understand the difference between "understanding the problem" and "put in random values until it works on one machine".

"There was absolutely _zero_ analysis done. You do not actually understand WHY the numbers matter. You just look at two random numbers, and one works, the other does not. That's not "analyzing". That's just "random number games".

I always get a kick out of how Linus talks to people. It's so direct and he never coats his arguments to make them easier to swallow. You could learn a lot about not bullshitting from that guy.

It's strange isn't it? When people do the same in places like this community (and other communities) they're immedietly downvoted or dismissed, unless they're someone held in similar esteem to Linus.

I think even here, where politeness is one of the stated goals of the community, people will forgive someone for being very direct (but not mean) if they're also insightful. My gut feeling says that if this conversation happened here and both parties were unknown people, Linus' posts would have gotten voted way up, because he's just so right.

But an attitude combined with less than excellent technical insight is, of course, going to get posts downvoted into oblivion. Well, -4, anyway.

I feel his raw response is reasonable there: the submitted patch stands against what has been tried and discussed for years. Developers ought to know the turf they tread on, instead of second-quessing.

On the other hand, I've seen him trying to strong-arm his view in another case in just the same manner. Only here he had no technical (nor organizational) argument, beyond, ``it's easier to hack glibc than make Adobe fix Flash Player and make developers read man pages of memmove(3) and memcpy(3)''.

Oh well.

https://bugzilla.redhat.com/show_bug.cgi?id=638477

I remember reading parts of that thread at the time, and being impressed at Linus standing up for end users. The background is important to understand his point of view: glibc was changed to in theory improve performance, but it broke flash audio and Linus couldn't see any performance improvement when he benchmarked it. So, his stance was to revert back to the working code. (Which come to think of it, is a very similar stance to this article.)

No he did not benchmark. Thus my remark on no technical argument.

Linus stipulated that the number of CPU instructions retired stays the same, so there will be no sizeable improvement of performance. That's hand-waving, not a benchmark. Somebody else posted a micro-benchmark showing better performance in his particular case.

((in the glibc discussion)) Linus stood for users in the short term (works here and now). Not for good development practices (read manuals, fix bugs, use modern hardware facilities -- here HAS_FAST_COPY_BACKWARD CPU feature).

EDIT:

nb., the ratio of instructions retired to CPU clock ticks depends on caching issues & such -- thus a particular memory access pattern will perform better than other. That's indicated by the HAS_FAST_COPY_BACKWARD CPU feature.

EDIT 2:

I'm aware I'm making risky remarks here; Linus have worked at Transmeta for several years, so he knows way more about CPU design and internals than I do.

>((in the glibc discussion)) Linus stood for users in the short term (works here and now). Not for good development practices (read manuals, fix bugs, use modern hardware facilities -- here HAS_FAST_COPY_BACKWARD CPU feature).

If you're creating an API(i.e. glibc) that everyone and their brother uses, it's a bad idea to break binary comparability in an update. You might be able to get away with it for a full version number change, but for point updates, it's a bad idea. If you're going to change it, add a new function.

You don't break binary compatibility in a major component without an extremely good reason(i.e. it doesn't work anymore). Forcing everyone to recode or even recompile to work with an OS-level component is just idiotic.

> If you're creating an API(i.e. glibc) that everyone and their brother uses, it's a bad idea to break binary comparability in an update.

Nobody argues for breaking binary compatibility. Because that's not the case there. Both functions remain perfectly compatible with client applications -- unless those apps are buggy themselves.

What got changed was an implementation detail -- order of bytes copying. Think of it as of a private member or method of an object, if you're an OOP head. Must be untouchable by outer code, and the outer code must not rely on its internal behavior.

Certain applications were making a silent assumption about the internal workings of the function -- and they used the wrong function. Working around that is not keeping binary compatibility; that's promoting bugs. [0]

> If you're going to change it, add a new function.

That's the current state of affairs. The memmove(3) vs. memcpy(3) distinction was created decades ago for this very reason. memcpy(3) may take extra optimization, because it makes no assumption about relation of source & target memory regions. memmove(3) may be easier to use, because it performs the right thing if the source & target memory overlap. The developer picks either. There's no other difference between them -- especially in the API. The best thing is, replacing one with another takes nothing -- you just change function name; arguments are exactly the same. Perhaps for the very reason of ease of replacing one with another.

From the man pages:

  The  memmove()  function  copies  n bytes from memory area src to memory area dest.  The memory areas may overlap:

  The  memcpy()  function  copies  n bytes from memory area src to memory area dest.  The memory areas must not overlap.

See? Nothing confusing there.

----

[0] A few years ago everybody and their brother were deriding Microsoft for pushing hacks into Windows XP to remain backward compatible with selected application -- like memory allocation workaround for the SimCity game. They did unsound engineering for business reasons -- increasing adoption rate of Windows XP. Now don't ask us to backpedal on that, and push bug compatibility into opensourece software. Don't ask for cart before the horse -- Flash Player before any non-buggy program. Don't ask Linux to follow in every footstep of Microsoft -- let's learn from mistakes.

(a note about that SimCity matter is here: http://www.joelonsoftware.com/articles/APIWar.html )

EDIT:

please also note, the memcpy(3) and memmove(3) functions aren't glibc's invention. They aren't specific to GNU, Linux or glibc. You'll find the functions in every modern UNIX and similar OS, no matter if based on glibc or some other system libraries.

Again, from the man page:

  CONFORMING TO
       SVr4, 4.3BSD, C89, C99, POSIX.1-2001.

Maintaining Bug for Bug compatibility is a critically important part of maintaining binary compatibility in minor version API updates.

Grossly breaking sound for end-users in order to adhere to an ideologically rigorous reading of a man page isn't a win for anyone except pedants.

>A few years ago everybody and their brother were deriding Microsoft for pushing hacks into Windows XP to remain backward compatible with selected application -- like memory allocation workaround for the SimCity game. They did unsound engineering for business reasons -- increasing adoption rate of Windows XP. Now don't ask us to backpedal on that, and push bug compatibility into opensourece software. Don't ask for cart before the horse -- Flash Player before any non-buggy program. Don't ask Linux to follow in every footstep of Microsoft -- let's learn from mistakes.

You do realize that the reason MS was derided for that is because MS doesn't believe in backwards compatibility at all, right? They updated their API completely, which broke Simcity, then they went and added hacks to make it run. They had two more correct options. Either tell Maxis that it's their problem and that they needed to fix it, or actually maintain backwards compatibility.

Linux strives to maintain backwards compatibility, unless they absolutely must break it. This means that you maintain buggy behavior if it's used commonly. I work on multiplatform code, and moving to new Linux versions is almost trivially simple for us-99% of the time, we just have to turn on the new compiler and OS combination, and just build it. Most of the time, any actual porting efforts are done because there are new OS features that we can leverage for performance.

You have completely misstated the problem with SimCity.

"I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows"

http://www.joelonsoftware.com/articles/APIWar.html

Linus did do the benchmark (see Comment #46).

Thanks, I stand corrected.

Still, the benchmark was for one particular case, and inconclusive (as in, ``testing can show X, but not lack of X'' ). Doesn't invalidate the finding of Ma Ling, comment #99, who got improvement in another testcase.

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c99

That was discussed here also, http://news.ycombinator.com/item?id=2372096

It's not strange at all. Linus has earned his credibility. Some people in this community have too (pg, joshu, patio11, it's a long list). But people are downvoted when they act like they've earned credibility when they haven't.

It seems you've missed my point. I don't doubt everyone you've listed has earned their credibility. What I'm trying to ask is "Why do you need to have earned credibility before you can be brutally honest with people?"

Because various forms of textual peacocking are frequently used by people who have no status, or knowledge, in a particular domain to try and appear as if they do.

This is part of what a system like karma tries to address, if you see a comment that seems accurate, but is delivered in a very direct or even slightly annoyed tone by a user with high karma, you assume that this user is held in high esteem by others and while their comment may not be elegant, it should be taken to heart.

Additionally, in the hacker sphere, it seems that many of the top hackers are also VERY busy with their projects. Thus, they may have less time to spend prettying up a comment. The goal is to share knowledge or information in the most efficient manner. Not to share knowledge without worrying about hurting feelings.

Meanwhile, a direct comment from a new user with no standing in the community is likely to be met with some distrust or skepticism, even if wholly accurate. That user has not earned a status in the community. They have two options: 1) be brutally direct with all their comments and wait for people to realize they are frequently right, just inelegant. 2) start at least initially with more of a 'hearts and minds' campaign with their comments and build status in a more traditional method, slowly letting more of their actual personality come through in their comments.

Hmm, I'm somewhat surprised to hear this description of karma. Does this mean people click through on a username to discover their karma score before deciding if they should believe or agree with what has been written?

It seems pretty clear to me that karma mostly measures the amount of time spent commenting. An interesting metric, but not one I would look to to predict comment quality.

There have been times that I personally have seen a less-than-elegant comment from a new (to me) username. So, I check out the persons profile, look at their karma, other comments, submissions, etc., and then reply/vote/whatever.

Not very frequently, but one or two times a month maybe.

Could be just me...

So if they had a lot of karma would you change the opinion you had formed about the idea/whatever?

I tend to maintain a neutral opinion and use additional input to come to an absolute conclusion.

I think the idea is that being curt is a mild evil that is tolerable if the information contained has a high probability of being valuable. But if the person being curt (or even rude) has no particular bearing/merit in the listener/reader's mind, it just comes off as pushy or presumptuous, sometimes to the point where you are tempted to ignore what's being said altogether.

It's not ideal, but I think the basic version is: I trust you enough to put up with your "brutal" honesty, vs. who are you and why are you being a dick?

Because that's how people know that you know what you're talking about. I've seen many factually incorrect, heavily upvoted posts here on HN, and credibility is part of what lets me identify good material. For example, there was a post in the last few weeks about DNS -- I knew that davidu's answer was the one to trust, even though others were more upvoted.

Speaking as a scientist, "don't think about it, don't care about it, just trust someone" is contrary to my nature.

I was born with a burning desire to understand. Everything. I just wish I could locate a group of like-minded people to work with. I've been somewhat dismayed to find that "the real world" consists mostly of people whose sole ambition (or sole reality) is to fulfill their current role, without ever analyzing what it is they are doing or striving to improve the overall project.

Status is very important. I wish it weren't so. At my last job, I was using EC2 to devise solutions to problems that they truly believed were technically unsolvable --- but no one would listen to me, because I was a newcomer. Their faith in the senior technical engineer was absolute and unwavering, and the senior technical engineer believed it was unsolvable, so therefore it was, for all intents and purposes, unsolvable. (After all, nothing ever came of my research, because no one cared enough to listen, or had time to think about something other than their current, immediate goal.)

Worse, they even became offended when I tried to research the "unsolvable" problem in my own spare time. Status really sucks.

I feel the same way about understanding things, but I don't have the time to understand every concept in the world from first principles. Nobody does.

When there's a discussion on DNS, I like to know what's going on, but I can't take 2 years to go learn everything there is to know DNS (Well, I could, but I'm not going to). Luckily I know there is someone here who has done this, and until I have more or better information, I'm going to trust him. It's a necessary shortcut.

Status often does suck, but it's a necessary evil. There is too much information out there -- filters of some kind are necessary, and status is more reliable than most

If you're going to state an opinion, you ought to give some justification. Linus can use as his justification the experience he has gained from running a major open-source project. Someone who has not run a major open-source project cannot use that justification. If pg wants to talk about starting a successful company, he can use as a reference his experience starting that thing he sold to Yahoo! for loadsamoney, et cetera.

This reminds me of this recent HN post: Hacking the status game: http://news.ycombinator.com/item?id=2460233

The part about people responding strongly to people acting above their status in particular was relevant.

It's not really about credibility, it's about status. Bad behavior -- and being this rude is bad behavior -- is much more tolerated in high status individuals, in every type of community. Just like (extreme example) how senators and Goldman Sachs CEOs can walk away with a slap on the wrist and a little bad press, where you or I would go straight to jail.

If it were just about the value of the information conveyed, people would do their own research when a person is "brutally honest" with them, and decide whether or not that information itself is credible.

The confusion lies in the fact that in a community like HN, that worships logic (and also success), those things that make you "credible" are what make you a high-status individual. That means even the statements those high status people make which are NOT credible themselves will be accepted, or only gently rebuffed. (Which is a big reason why you don't see much criticism of pg here, or when you do, it's very respectful, vs other authors, even when he writes something ridiculous.)

Dead on. I found myself cringing at your suggestion that pg has said something ridiculous, and I like to think I'm less affected by status than most.

I would tolerate it because I think that's how he needs to act to keep the project from becoming a POS. Being nice/courteous often gets you design by committee results.

Also, I might be swayed by his credibility, but what he's saying sounds reasonable.

I don't think anyone has really argued about WHAT he said. It's just a question of how he says it. There are many, much politer (and probably more effective) ways to say the same thing.

Well that was part of what I was saying - being able to reprimand effectively is part of what makes him a good leader for this thing. Being excessively polite and sugar coating everything doesn't instill the same desire to do things right next time. I think he's acting exactly as he needs to.

You're creating a strawman -- there's a big gulf between "being rude" and "being excessively polite." On top of that, I've never seen any proof that suggests that leaders who create shame & embarrassment & anger work better than leaders who inspire.

>"(Which is a big reason why you don't see much criticism of pg here, or when you do, it's very respectful, vs other authors, even when he writes something ridiculous.)"

If you think someone is being ridiculous why don't you say something.

People don't do it because it is counter productive. Respected people have their supporters. Unless you first bury your argument in adequately respectful terms it will get downvoted. Regardless of content.

You cannot say "The Linus rant about C++ is just wrong". You need to first blather on about why Linus is a great guy but has his limited perspective and from that perspective he is correct. However there is a world outside of that perspective where he is wrong.

If I posted the Linus rant on C++ I'd just be called an idiot. Nobody would worry about my perspective because, to my knowledge, I don't have any supporters to appease.

It is just politics. It affects tech communities as much as anywhere else. People get invested in their side. If you challenge their side then you must be sneaky about it.

>You cannot say "The Linus rant about C++ is just wrong". You need to first blather on about why Linus is a great guy but has his limited perspective and from that perspective he is correct.

You may think that you have to appease people.

If you posted "The Linus rant about C++ is just wrong" then I would down vote you. Why is it wrong, why is it a rant, what's wrong about it - that's what gets my vote.

I thought we were building a Brave New World here away from political double-speaking and ass-licking and endless regurgitation of memes. Please don't give in.

I have, often. Why would you think I hadn't? You must not have looked at my comment history.

Here's an example from the first page of my comment history. Me responding to pg: http://news.ycombinator.com/item?id=2342860

>"Why would you think I hadn't?"

You said so.

>>"those high status people make which are NOT credible themselves will be accepted, or only gently rebuffed"

If you spoke up then your story of 'people with particular status not being challenged at all' was lacking. It's probably a form of hyperbole but it was your evidence that I was trusting to make the assumption about your action. I'll try to be more careful.

It's not so much "tolerated" as just a form of abusive willy-waving that powerful people can get away with. If Linus behaved like that in real life with real people he'd likely get punched in the mouth, repeatedly. It's amusing to read him doing it to other people but he is still behaving like a dick.

In real life, he does it with a smile on his face and it's actually quite disarming.

Doubtful. I know people who act much the same way in person, and while tempers occasionally flare, I've never seen it get physical.

>But people are downvoted when they act like they've earned credibility when they haven't.

I downvote when people don't add to the conversation; when I consider them to be wrong or misleading (or when we had comment scores if they're comments seemed over-rated).

Personally I don't find anything wrong with the comment made there - the chap is just asking that things aren't done without a proper rationale. Doesn't seem brusque, harsh or patronising to me.

Just decide not to be offended, job done.

On the other hand, I bet that same list of people would say that the credibility of the argument is more important than that of the person making it.

Otherwise, you get either self-serving double standards or fawning hero worship (or both). Neither is strange, but neither is healthy.

So in other words, you'll happily down-vote people who aren't on your friend list, even though they are trying to tell you something you need to know.

It is not strange at all. The purpose of kernel hackers is to build best OS possible and communication is a tool. If it has to be blunt and direct so be it.

HN on the other hand is the place where people come for communication and it is primary purpose, or secondary to - you know - news, but still very high on the list.

Actually,

When Zed Shaw says stuff here, I think sometimes it's up-voted and some times it's down-voted. Sometimes the up-voted stuff is good and sometimes times the down-voted stuff is bad.

In ways, I think that relationship is better. Zed has carved-out the position of being celebrity who's not automatically respected. Being a curmudgeon myself, I respect him more for this...

Also, I've seen some high karma folks here still get -4's (back when karm was visible).

The difference with Linus, of course, is that he's so often correct. Its one thing to be a jerk. Its quite another to be a jerk that's right.

I guess people (especially smart ones) don't like being told they're wrong by anyone who they consider inferior even if that person is right. By inferior I mean anyone who can't immediately prove that they're superior by listing a bunch of amazing achievements.

It's because being direct is not the same as being an immense prick.

Most people (including Linus at times, credibility does not make you immune) confuse that issue.

http://en.wikipedia.org/wiki/Meritocracy

It's something of a Finnish trait.

I can't help being reminded of this hacker koan:

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."

Knight turned the machine off and on. The machine worked.

Important to understanding the joke is the fact that Tom Knight designed the processor for the Lisp Machine, and therefore his power-cycling is imbued with understanding.

And this reminds me of the "More Magic" switch on a PDP-10 at the MIT AI lab: http://www.catb.org/jargon/html/magic-story.html

This, in turn, reminds me of a long-shot theory about how the universe works that I sometimes ponder.

I can't think of how many times someone has come to me with a computer problem, or I've gone to a vendor/support chat with a problem that hasn't worked dozens or hundreds of times. Then suddenly, with the guru there, whether it is me or someone else, suddenly the problem evaporates.

I've found myself wondering if this wasn't some illusion, but an actual artifact of the nature of the universe. Think about it: if noob's problems everywhere were actually the universe not letting their shit work, there would be no one to ever notice it; because when the expert comes in and fixes it, it is magic to the noob anyway, and the expert is 100% used to mundanes not having their stuff work for any given reason.

There is already a scientific explanation for this.

It's called "confirmation bias"

We call it "personal entropy". Some people have more of it than others.

Sounds like quantum bogodynamics: http://www.catb.org/jargon/html/Q/quantum-bogodynamics.html

What about the case of a person who, when they show up, magically breaks all technology. I had a friend like that, "I didn't touch it I swear!"

Reading over jwz's travails with computers of various kinds, he seems to have an amazing amount of it for someone who used to be a professional programmer.

I propose we name it the Zawinski Effect.

We call it The Aura. Some people have it and some don't.

I like to call this the Scooby Doo effect. The ghost always appears for Scooby but not for the rest of the gang.

Scooby is just a little psychotic.

At the risk of causing a bunch of you to spend the rest of the day watching the whole 3 seasons of The IT Crowd....The canonical answer to 'Have you tried turning if off and on again': http://www.youtube.com/watch?v=nn2FB1P_Mn8

There are 4 seasons, although I agree that season 2 is worth skipping.

Apart from "The Work Outing" and "Moss and the German" which are two of the best episodes from any season.

Thanks for mentioning, I haven't checked up in a while (obviously). Season 2 definitely was my least fav.

Ah, there are a few good moments in season 2 also.

If your Iphone starts blinking or vibrating randomly or does something weird repeatedly, do you take 10 minutes to understand what is happening or do you just turn it off/on?

Am I mistaken in thinking that in this case, it might also be a cultural/communication problem?

When Yinghai answers:

  We did do the analyzing, and only difference seems to be:
  good one is using 0x80000000
  and bad one is using 0xa0000000.

he clearly didn't understand what Linus meant by "think and analyze".

I don't know the Chinese culture well enough (assuming Yinghai is from China), but I am under the impression that they would emphasize more on results (fix the problem) than on processes (understand why the fix works, in order to be sure we are not breaking something else).

Am I wrong?

You are wrong, on both individual level and stereotyping to a nation of people.

On the individual level, he did do the debugging and analysis, on a smaller scope. Linus was asking a bigger scope analysis and a lot of work. Some people are willing to spend time to understand and fix problem for free. Some people have better things to do and aren't willing to spend the time to do it. That's their prerogative.

On a nation level, there are Chinese who want to get things done and there are Chinese who want to understand the root causes, just as there are people in other nations/cultures who want to get things done and there are people who want to understand the root causes.

It's not an acceptable approach in kernel development.

A patch like that has zero (actually, negative) value. It simply shouldn't be accepted and regressing to the last "working", most tested version should be the option.

So, all in all, if you are not willing to do your homework well enough, it's better for everybody if you don't bother at all. It wastes both your time and the maintainers' time. Linus' time no less.

Thanks for the explanation on the individual level. Sounds reasonable.

On your second point, yes, you can say of any cultural group that there are people who do X and people who do non-X, but that doesn't proves that there are no global traits and that all cultural stereotypes exists for no reason.

But I understand your point as "you are wrong to try to attribute the behavior of an individual to a stereotype, since they can only be used at a very broad level", and I think you're probably right.

Indeed, those are cultural differences. However, I don't think those are directly linked to nations. Even within a single country like Germany, I'm observing vastly different approaches to software development.

Also, issues like "Why don't you accept my (seemingly) working patch?" appear quite frequently in a lot of Free Software projects, independently of the nations of the people.

I guess this cultural difference has more to do with professionalism and long-term experience on software projects.

I don't know about Chinese culture, but I am always amazed that so few people in software engineering actually understand the difference. I think that's the essence of the "being smart and getting things done" thing of Joel Spolsky. Things which would be obvious to most people here like "profile before optimize", "is this a symptom or the cause of the issue" are actually not that well understood in the large, unfortunately. All those are the symptoms of the same (lack of) skill for a programmer IMO.

Hmm.....the place where i studied cognitive science, one common theme of most experiments were global vs local be it on visual perception/language/etc......Wondering is local being extolled too much nowadays..... reminds me of the other post on "How not to scale?"

"I don't know the Chinese culture well enough (assuming Yinghai is from China), but I am under the impression that they would emphasize more on results (fix the problem) than on processes (understand why the fix works, in order to be sure we are not breaking something else)."

The greatest living mathematician has Chinese origins: http://en.wikipedia.org/wiki/Terence_Tao

If someone 'thinks and analyzes problems' then he does.

I don't like categorization by nation because I am Hungarian and I am afraid a lot of people in the U.S. who don't know me yet thinks something entirely different of my problem solving style than reality.

While Terrence was of Chinese origin, he certainly did not grow up imbued in the Chinese culture. He was more of an Australian. I not saying this to imply Chinese are not deep thinkers. I have worked with Chinese (China bred) engineers who are damn good thinkers. So it is just a matter of personal style and priority(influenced at times by the culture one grows in).

Of course, any nation is able to produce any kind of individual.

I'm a great believer in cultural traits, and I think they are normal. We are not all identical, and we are not all totally randomly different. We all share some cultural background from the country we grew up in, in varying degrees, and it does not prevent any individual from having any specific ability.

Yet, I was wrong to try to correlate a specific behavior of a specific person to his/her culture. That's where my logic was flawed.

If anyone wants more insight on cultural differences, I really recommend "When Cultures Collide" from Richard Lewis, it's a great book.

When I think of Hungarian problem solving I think of Polya's renowned book on proof heuristics, "How to Solve It"[1]. How accurate is that impression?

[1] http://www.math.utah.edu/~pa/math/polya.html

Quite close.:) I've read that book when I was a child.:) I've had some math influence, and I had the luck to be the student of http://en.wikipedia.org/wiki/Lajos_P%C3%B3sa_(mathematician) when I was 13 years old.

When I think "Hungarian problem solving" the first association that comes up is John Von Neumann.

What assumptions do you normally encounter?

I think there is a generic implicit assumption that programmers in less rich countries are lower quality. Of course it is rarely said explicitly but it can be seen from some signs: salaries are so much lower here that I cannot see any other reason why not more development work comes here. When companies do offshoring they bring here only the boring job which does not need much creativity, etc...

Funny, I think Paul Erdős.

Did you just generalise an entire nation of people based on the internet postings of one person with a Chinese name?

Are you implying the "fix it and get it done with" people don't exist in other nations?

Nope, I did the oposite: I already had a generalisation in mind, and used it to try to understand the posting of one persone with a Chinese name.

Mind you, cultural traits of nations are a reality. I'm a Franco/Brazilian guy living in Vietnam, and I have seen it well enough. It doesn't mean that since you're from country X you will do Y, but it helps in understanding general behaviors.

edit: excellent book on this topic: When Cultures Collide, by Richard Lewis

http://www.amazon.com/When-Cultures-Collide-Richard-Lewis/dp...

>I already had a generalisation in mind, and used it to try to understand the posting of one persone with a Chinese name.

So you admit you are just fuelling your confirmation bias.

Forgive me if I'm about to mis-characterize you, but it sounds to me a lot like you've seen one question and decided on that basis that the person in question must be racist. Then it looks like you've cherry-picked what he said in explanation to confirm your own beliefs.

It looks to me like you are more guilty of the charge you are levelling than is the target of your accusations.

I might be wrong, but I'd appreciate a clarification.

First you thought that if one culture has a particular trait, then it implies another cannot share the same trait. Then you changed your position 180º to maintain the same basic premise i.e. that the GP thinks in logical fallacies.

But the GP is simply applying inductive reasoning. That isn't guaranteed to produce a correct outcome, but generalisations from large populations are not inherently flawed. It's indicative of mature thinking; generalisations are part of life and inductive reasoning is part of progress.

If you think the generalisation is deeply flawed, then make your case. That would be an honest discussion. As it is, you're just embarrassing yourself.

The key difference is that the GP asked questions based on a reasonable (although disputable) premise, while you are making conclusive statements based on simplistic (and flawed) logic.

I've seen this behavior many times in 100% US dev teams. This happens because it tends to be the "easy" way out.

Hmm...there's a problem with this code. It looks like changing this index to start at 5 works. OK, bug fixed!

Once again, a great Linus Torvalds statement! I especially like the last paragraph, which has so much truth in it, and can be applied to small as well as large software projects:

Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work.

To be fair, the second case really is just a matter of fossilized random changes.

That is correct, but is based on a philosophy that the longer something has been in use, the less chance it has to demonstrate behavior that has not been previously observed — he even explains that in more detail in further posts where he discusses his desire to not cause regressions.

Linus knows that and says so as well. But that's okay, because that works. Starting down that very same path again without a huge reason to do so would be very painful for any mature product.

Yep, that's how the evolution works. Understanding stuff is how the progress works.

Doesn't that mean that while it's actually happening, it's not, in fact, an acceptable development process?

I've worked with programmers who also would have argued with Linus, but there's no way I would have been able to be as direct as Linus has.

This definitely struck a chord, though, and I have my own saying for silent retorts:

"It's a computer program, not a #$%^ing Advent calendar."

The point being, I want to see analysis and process, not just the right numbers popping up in the right boxes.

Or, in slightly different words, "understand it" or "test the hell out of it".

"Programming by coincidence"

http://pragprog.com/the-pragmatic-programmer/extracts/coinci...

I think Linus forgets that at one point he too was inexperienced and liable to make these hit-and-hope fixes. I agree with his point in general, but the dickish manner in which it's delivered isn't particularly helpful ("Why don't we write code that just works?")

The thing is, if you're inexperienced and mistake-prone, work on a pet project to gain experience (like the Linux kernel in 1992, or your flavor of location-based mobile social coupon sharing app today). Don't start pushing magic numbers into a software product that millions of people depend on.

Yep, that'd be an excellent way to word it. As I said I don't disagree with the point, I just dislike how Linus addresses people sometimes.

Why so sensitive? Seriously, when someone criticises your work, do you listen to what they say or do you just listen to their tone of voice?

If all you do is listen to the tone, then YOUR WORK WILL SUFFER. Because if someone comes up to you and says, "you dick! What the fuck were you thinking putting that double dereference there?? There's no way it could ever work!"

If you stop listening after, "you dick! What the fuck were you thinking..." then you will miss out on learning something that you should know. The person is angry BECAUSE you have been stupid. Yes, that sucks, and perhaps they should learn to control their temper. But you can't do that for them. What you CAN do is be less stupid next time!

Well, I always listen to the tone of voice. This gives me a good indication of whether they're worth listening to or not.

Usually, people speaking with a scornful tone of voice (or the written equivalent) are more venting than they are providing useful information. There's no need to pay too much attention to whatever they have to say, because if it's a big deal they'll say it again once they've calmed down.

I've noticed that when programming computers there are very few problems that can be fixed by behaving like a dick. And those that can be fixed by behaving like a dick, can also be fixed whilst behaving in a more gentlemanly fashion. The rest can be left unsolved, politely. There's really no reason not to do this.

I listen to what they say. I just lose respect for the person if they act like a bit of an idiot while delivering it. This is not helpful if the person is meant to be in a supervisory\managerial role.

Confusing downvote, I honestly can't see what could be disagreeable or controversial about this comment (particularly given it's inflammatory parent comment) but never mind!

You got an upvote from me.

But, you seriously think my comment is inflammatory? You don't think that learning to deal with people is an essential part of the job??

I was all set to defend the "jiggle randomly" school of development with something along the lines of "sounds like someone who has never had an external deadline to worry about" but then I got really sad, and didn't.

Well, that approach worked fine for the evolution of complex life-forms.

Yes, but the "we have billions of years to get this right" model generally doesn't apply to software dev. ;)

Unless you're coding Duke Nukem Forever. ;)

That would require they get it right.

With a 99.9999% failure rate.

Why do you think Linux isn't the 0.0001% survived form?

Because I would hope they didn't follow the random mutation and non-random survival method of evolution.

this would be "years and years of testing on thousands of machines," no?

Another aspect of this thread that I find very refreshing is the fact that the previous implementation may have used magic numbers doesn't reduce anyones desire to actually understand what is going on going forward.

The realization that a magic number was already being used could have caused one of two outcomes:

a) justification for replacing one magic number with another

b) realization that more research needed to be done to understand exactly what was going on in the first place

I appreciate seeing (b) as the option chosen. We should all strive to be this diligent.

Programming by coincidence as the PragProg says (someone has already posted the link).It's extremely common here in most Indian companies, especially with freshers.

Also known as shotgun debugging, where you randomly poke at the relevant portion of the source code in the hope that the bug will magically vanish. I think the habit is formed early on, when most of the mistakes are things like syntax errors or off-by-one problems, where certain types of random tweaking actually can be somewhat effective.

Well, there goes my development methodology.

I call this "poke it with a stick" debugging. Let's poke the code like this and see if it works now. This approach is so wrong yet so common it's infuriating.

Linus seems to be (correctly) railing against what is classic cargo cult behaviour.

Making changes until someting seems to "work".

That patch reminds me about a nouveau bug[1] I had a couple of weeks ago. According to one of the developers behind nouveau it was caused by a new memory mapping/allocation scheme that broke things on systems with more than 4 GBs of RAM. Some device memory (registers etc) was mapped above 4 GBs and some of them don't like this. So he built a new kernel which reverted the change and the problem was "miraculously" fixed.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=689825

Reminds me of some of my last work experiences...

Reply on news.ycombinator.com