Ask HN: How to sell a PI class C network? - <AUTHOR>

There had been no 192.168/16, 10/8 or 172.16/20 private networks, when I joined the internet ages ago. Instead the RFCs told, that one must register a provider independent class C network before. So I did.
A provider independent (PI) network means, that I own it forever, that I do not need to pay any (annual) fee for it. But also that I can not force any provider to route this network. Unfortunate my network is no longer routed, since I moved housing, even if I stayed at same provider, as the routing of the network was informal done by a friend working for that provider. So I'm using it like a better private network at home and for OpenVPN.
The network is now part of AS20676 university autonomous system, when classless IP became common, so it requires just a mail to UniDo to switch routing to any place in Germany and perhaps even Europe. And a provider willing to accept that route.
My questions:
- What is a provider independent class C network worth? - Is there any market for class C networks? <comment><USER2> Check out ipv4marketgroup.com. I've used them in the past. There is a market but you need to be the registered POC (all communications will go through the POC your RIR has on record) to get anything going.

Assuming you have rights to transfer the block, the current going rate for RIPE addresses is between 10 and 20 dollars per IP, depending on the size of the block and the buyer (e.g. APNIC buyers have a higher level of demand than ARIN, and an inter-RIR transfer to either is about the same amount of hassle).

Minus side is that a broker will take 25% of the cut at least. There's a smaller market for non-brokered transaction, but you'll need help navigating those waters.

Let me know if you have any more questions. Also, this is just a /24, yes? Just want to make sure I'm not misinterpreting 'class C', it's been a long time since I've heard that term and I'm way used to CIDR now. At the moment a /24 might not be worth the hassle of selling, leasing it out for temporary profit on a month by month basis and then selling when the market gets even tighter might be a better option.

<comment><AUTHOR> _thanks_! Yes, Class C = /24\. So a class C is only $2500 to $5k, minus 25% is not worth the work of selling it.

I think I'll continue using it for OpenVPN, where its nice that my real IP addresses never conflict with any private network, and keep my network for a few more years.</comment></comment>


Ask HN: What is your system for organizing your daily tasks? And feature ideas? - <AUTHOR>

Hi! I'm working on a startup and I have a lot of tasks of various types that need organizing.
Especially - list of features to build, bugs to fix, ideas to consider.
I'm wondering which tools do you use for organizing that?
What in your opinion is the best system? <comment><USER2> I haven't found any particular online tools that have helped. I think this is mainly because online tools aren't always in front of you, so they don't tend to push you in the right direction when you're looking for stuff to do. Same with journals, if you don't flip through them regularly. My personal backlog is an array of sticky notes along the bottom of my monitor, and I've found this works better than anything else I've tried. Longer-term stuff goes in a text file.

</comment><comment><USER3> Have you tried out Trello, it could be the best tool for you if you are needing a fast and easy kaizan system to organize your information.

If you are looking for a way to organize the development of your product while being sure that the team is connected and communicates about who are doing what and when then my startup TimeBlock and the app we are building might help you as much as it has helped my consultancy and the 10+ customers already onboard.

It's a methodology that is based on kaizan, scrum, taoism and other input from entreprenuers and customers, the main objective of the method is to help the Makers, Managers and Customers be a little more happy in their daily lives.

Read more at [http://timeblock.com](http://timeblock.com) or email me at firstname.lastname@example.com

</comment><comment><USER4> [http://taskwarrior.org/](http://taskwarrior.org/)

Command line, so easy to integrate into other systems.

If you finish a non-important task, it yells at you and says, dude, you had more important tasks, do them first.

Also auto-orders them.

<comment><USER4> Copy from web site:

Taskwarrior is open in as many ways as it can be:

        It is free and open source, using the MIT license
        It uses human-readable text files for storage. It imports and exports JSON, so your data is never held captive
        There is DOM access and a Hook script API
        There are many available free and open extension scripts
        There is Vit, a curses-based UI
        There is FreeCinc, a free online sync service
        There is Inthe.AM, a free online sync service, web UI and iOS client
        There is Mirakel, and Android syncing client app
        There is BugWarrior, so you can import your bug issues from a dozen different bug systems

</comment></comment><comment><USER5> We are using trello. Our startup is a travel planning & tracking app with web and mobile apps. Two of us are building it so we have kept it very simple. We have a "features" track/list, 3 tracks for API server/Infrastructure TODO, Web APP TODO and Mobile TODO, and two tracks for "Doing" and "Done". We are still developing so no bug management yet but in future I would keep it separate from trello. Maybe google docs for simplicity initially.

</comment><comment><USER6> JIRA / Agile board.

I love JIRA and I've never had a problem with it. It's mobile interfaces could be improved upon, but developers shouldn't be checking work from their phones in my opinion anyway.

</comment><comment><USER7> Trello.com + reportsfortrello.com

</comment><comment><USER8> Workflowy. It matches my mind so wonderfully, it's frightening.</comment>


Ask HN: Looking to make a switch. Should I worry about age discrimination? - <AUTHOR> I am a 60 year old backend developer in SV working in Node JS and PHP.
I have been in the same job for the last few years and would like to make a switch to a new role. I keep hearing about age discrimination which worries me. What are my chances of getting a new job?
I thought I would ask for some thoughts and advice from the HN community. <comment><USER2> I've worked at a variety of companies, large, small, tech, and non tech. On a professional level, I've never seen my older coworkers be treated any differently from the younger ones.

I'm sure age discrimination does exist on some level, but I don't think it's the complete showstopper that some would have you believe. From talking to my friends from various companies, it seems that competent developers with some experience still have an easy time finding jobs in the bay area regardless of age, sex, or educational background.

</comment><comment><USER3> Secure the next one before jumping.

Probably the most common discrimination would be some people assuming you are not up to date with new technologies so find a way to demonstrate that you are up-to-date.

<comment><AUTHOR> Thank you!</comment></comment>


My favorite way to TDD - <AUTHOR> http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html <comment><USER3> Why is this post so popular?

[https://news.ycombinator.com/item?id=10203474](https://news.ycombinator.com/item?id=10203474)

[https://news.ycombinator.com/item?id=10203442](https://news.ycombinator.com/item?id=10203442)

[https://news.ycombinator.com/item?id=10203425](https://news.ycombinator.com/item?id=10203425)

[https://news.ycombinator.com/item?id=10203410](https://news.ycombinator.com/item?id=10203410)

So many submissions, so few votes, zero discussion.

<comment><AUTHOR> Weird. I didn't manipulate the URL so I figured if it had been posted before, HN would have just upvoted that post (like it usually does with dupes).

My mistake. I should have searched first.

<comment><USER3> (a) HN no longer results in a dupe upvoting the original.

(b) If the first submission (or obviously submissions, plural) don't see any action, it looks like the dupe is now allowed.

(c) No one else seems to search first, so I don't see why you should. My question is genuine: suddenly this is being submitted lots of times - <USER2> are people getting the feed from?

I get frustrated with the number of dupes on HN, there has to be a better way of dealing with the way they take up space. Still, I have not better suggestions.

<comment><AUTHOR> That's good to know. Thanks for the information.

(c) The person who posted this does a lot of blogging / public speaking about software. He tweeted that he published this. He posted 2 of the links you posted. See: [https://twitter.com/@searls](https://twitter.com/@searls)</comment></comment></comment></comment>


Facebook groups/privacy control - <AUTHOR> http://manishmideas.blogspot.com/2010/09/social-network.html?spref=bl

<comment><AUTHOR> I kind of agree with the earlier post on FB, I just use it to share once a week or so..Its true that FB is running at the cost of our personal relationships. I have had friends who had serious trouble just due to Facebook and pictures. Myself I think twice before sharing it with people as who knows where the relationships overlap...Facebook is good but is there something that can be made better than facebook which solves all the problems facebook has? Think it like this..We had Landline phones...but it had problems..we came up with mobile phones...and now we hve smart phones...My thinking is facebook is way too good but something better can be made..hopefully one of the hackers here come with a brilliant idea which solves a problem..is viral and gets a new revolution...</comment>


If the Declaration of Independence was written in Word 2010 - <AUTHOR> http://www.youtube.com/user/officevideos?blend=1&ob=5#p/u/0/xw_1I1oYApw

<comment><AUTHOR> Actually creative and engaging marketing idea from Microsoft.</comment>


Expensive Placebos Work Better - <AUTHOR> http://pipeline.corante.com/archives/2015/01/29/expensive_placebos_work_better.php

<comment><USER2> I am very much not convinced of the interpretation of the placebo effect as "the fact that just thinking that you're getting some treatment of benefit can have actual benefits." The placebo (and corresponding nocebo) effect is completely intuitive when you think of it as a measurement artifact. It's strongest in self-reported outcomes, it goes away or is massively reduced the better your blinding - all exactly what you'd expect from a combination of confirmation bias and expectations (both on the part of the person receiving the treatment and doing the study).

Even to the extent that there are placebo effects in clearly quantifiable outcomes (e.g. blood pressure, etc) it's _still_ way more plausible that these are due to nonspecific treatment effects (e.g. taking a pill every day for your blood pressure reminds you of your problem with blood pressure and so you take the stairs instead of the elevator or you don't have a second serving of steak) than that there's a way for your mind to just cause arbitrary positive or negative effects above and beyond your normal immune system - but only if it's tricked into it.

<comment><USER3> It's reduced by blinding because both groups think they're getting treatment - that is, they both get the placebo effect, and the test group _also_ gets the benefit of the actual treatment.

Edit: It's not really reduced by blinding, it's removed as a variable because both groups have the placebo effect.

<comment><USER2> I suppose the fact that it's reduced by blinding the patient is a wash (consistent with both theses), but now you need to add _two_ new causes to explain why single and double blinding work, whereas none of the observed phenomena are inconsistent with other well-known research biases.

<comment><USER4> Single blinding spreads the placebo effect to both groups since both groups think they're getting the treatment.

Double blinding reduces the placebo effect, since the researcher can't imply to the patient which treatment is actually real and which is placebo since they don't know.

</comment></comment></comment></comment><comment><USER5> Extending this a bit further, I think this applies to things like cars or cosmetics or fashion or wine. Pretty much any consumer good actually.

I remember a study (might be from the Ariely book) where they took wine from the same bottle, put it into two decanters, and said one was way more expensive than the other. People were asked their impressions of the two wines. The more expensive wine received rave reviews while the supposedly cheaper one was marked only passable.

Interesting on one level, sad on another. And exploitable for profit, as some smart marketers have been doing for a while.

<comment><USER6> Isn't this true for mobile app pricing. I've heard stories where people raised prices and app sells increased. I found one article that supports this claim: [http://autosend.io/blog/should-my-app-be-free-or- paid/](http://autosend.io/blog/should-my-app-be-free-or-paid/)

<comment><USER7> It applies for computer services as well. You're more likely to be abused by your clients (blamed for problems unrelated to you, called at odd hours of the night for no good reason, yelled at, etc.) or fired in favor of somebody else if you give them your services for cheap or free than if you charge a lot.

</comment></comment></comment><comment><USER8> This idea was covered in Dan Ariely's book "Predictably Irrational". Glad to see more scientific data backing up the claim.

<comment><USER9> Loved that book...highly recommended!

</comment></comment><comment><USER10> Speaking of expensive placebos, how is selling oscillococcinum legal? I can't imagine how many well-intended people mistakenly buy these sugar pills believing it is efficacious medicine.

<comment><USER11> Well, it can be efficacious, right? I mean, the placebo effect is a real thing.

<comment><USER10> I guess. And if you disclosed what it was on the packaging then it goes away.

<comment><USER7> It does disclose it, it's just that most people don't know that "homeopathic" means "this is just water."

<comment><USER12> Lots of people do know that homeopathic means it is just water. They believe there is an imprint of the molecule left in the water. Some believe the imprint works as well as the original molecule. Others believe that imprint is how the molecule actually works, so getting rid of the molecule is healthier.

Never underestimate pseudoscience.

<comment><USER10> I'll tell you how i bought it in 2005. My boss's wife recommended it to me so i went out and got it. Then my symptoms went away and i thought OK i should do that again.

I trusted the recommendation and presumed the pharmacy wouldn't be selling actual sugar pills so I didn't investigate it at first. Then when I saw it labeled with the homeopaths a year later somewhere else, I looked into it and was like "oh...".

I think my experience is probably 97% of the stories with or without the realization. The other 3 percent is like " oh homeopaths, gee isn't this stuff great? What a wonderful science."

<comment><USER7> Stuff like this is why I never buy or take any medicine until I know what's in it and do some brief research to see how it works and what effects it might have.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The title could be straight out of The Onion.

</comment><comment><USER14> Instagram generation could cure them self just by eating melted money.

<comment><USER15> How about eating actual gold? [http://luxurylaunches.com/other_stuff/delafees_chocolate_wit...](http://luxurylaunches.com/other_stuff/delafees_chocolate_with_24_karat_edible_gold_flakes.php)</comment></comment>


I was hacked this morning - <AUTHOR> https://m.facebook.com/story.php?story_fbid=10100320757815923&id=36200401 <comment><USER2> What are the takeaways? Best practices that can be learned from this and applied? Two factor, unique passwords, Google Authenticator, what's else?

<comment><USER3> If you lose your two factor, most places have a backup strategy of "we will email you" or "send text to ____1234". Even banks.

<comment><USER2> Are you saying that's good or bad?

<comment><USER3> As in, phone or email and you're dead. Most email is backed by another email or phone. Targeting a phone like this is probably the sturdiest foothold if you get it right.</comment></comment></comment></comment>


Kalimba - Embedly Colored Glasses for Hacker News - <AUTHOR> http://hn.embed.ly/ <comment><USER4> On Mac OS X, spacebar means "page down" in web browsers. I was pretty surprised when I couldn't use it on this site.

<comment><AUTHOR> That's a bug. I will fix.

UPDATE: fixed

</comment></comment><comment><USER5> Wow. The stuff that Embedly is doing is all kinds of awesome. I just wish Twitter would buy them so I didn't have to resort to manual hacks to actually use them.

</comment><comment><USER6> Ironically, the one entry it completely fails at is this one.

</comment><comment><USER7> Very nice. My only feature suggestion would be a way to hide articles, something I wish HN itself could do but perhaps more important when articles take up more vertical space.

</comment><comment><USER8> This is gorgeous, nicely done. I find myself wanting a better way of going to the next story, because some articles are very long. Maybe you could add controls? For example, keyboard shortcuts or a floating "next" button (anchored with fixed position CSS).

<comment><AUTHOR> Great idea. I was also thinking of a way to collapse articles, but I think I like your idea better! I'll work on it.

UPDATE: try j and k

</comment></comment><comment><AUTHOR> I just added two more hotkeys. Here's what we have:

      j or right-arrow - <USER2>
      k or left-arrow - <USER3>
      c - toggle top comment
      d - toggle article content
      enter - follow article link
      shift+enter - open article link in new tab

Enjoy!

<comment><USER9> The hotkeys aren't working for me, and I get two errors on Chrome 10:

\- Unsafe JavaScript attempt to access frame with URL <http://hn.embed.ly/> from frame with URL <http://www.youtube.com/embed/yoqsZvSQSTs>. Domains, protocols and ports must match.

\- hn.embed.ly:3Uncaught TypeError: Object #<an Object> has no method 'shareaholic_publishers'

<comment><AUTHOR> Try now.

<comment><USER9> Hotkeys working, thanks!

</comment></comment></comment></comment><comment><USER10> VERY NICE!

Any way to make it wider or is it optimized for mobile viewing?

Voting maybe?

Regardless, cool way to look at the top links / questions.

<comment><AUTHOR> I'll be glad to add features if it gains any traction. The only reason I kept it thin was to prevent having to read long lines of text. I hate that. Maybe I can split it into columns or something.

<comment><USER11> I agree with you on this - long lines of text are hard to read and break the reader's concentration. Narrow is good for reading. Maybe you could have another column where people could choose the content that they wanted to see? ie, the "Comments" or "Ask" pages?

</comment></comment></comment><comment><USER12> I really like the clean design, but part of what i love about HN is the fact that you can quickly scan 20+articles just by reading single sentences of text. I would like this format better if it had some type of flipbook functionality mapped to the left and right arrow keys, so I can quickly run through more content.

<comment><AUTHOR> Try j and k. If you insist on arrows I can do it, it's just that they already do something(scroll if you have a really thin browser window).

</comment></comment><comment><USER13> Could not figure what this site is about in 30 seconds, lost interest

<comment><USER14> This is what I see in Chrome 8 on a Mac:

<http://cl.ly/0U3d2B0E3y431s1C270X>

<comment><AUTHOR> Strange. I can't reproduce. It should look like this:

<http://www.webpagescreenshot.info/img/2476-129201145015AM>

I'll see if any mac friends can reproduce. It may have been a temporary outage or something.

UPDATE: I think my parser was breaking on something. I've added begin;rescue to tighten things up.

</comment></comment></comment><comment><USER15> I hear about embedly more and more. Good job, guys!

</comment><comment><USER16> This is great, could see it be a good alternative if on another person's touch device.

At first I thought, "Why would I want to bother with this?" but a few minutes later I realized I was ten articles down having read more than usual for one visit.

</comment><comment><USER17> Looks nice...

But I prefer the actual text based one, more info per pixel.

But keep it up.

</comment><comment><USER18> Then, what is Tokyo Cabinet?

</comment><comment><USER19> Nice job. Looks awesome</comment>


Technical debt: probably the main roadblack for machine learning to medicine - <AUTHOR> http://andrewtmckenzie.com/2015/12/14/technical-debt-probably-the-main-roadblack-in-applying-machine-learning-to-medicine/ <comment><USER2> another barrier is that clearcut value-generation or employment opportunities don't exist. you say that you'd like to see open source software- how is that profitable? by the way, check out the latest kaggle competition: "Transforming How We Diagnose Heart Disease"

<comment><AUTHOR> Great point -- there's a huge disconnect between what is needed in terms of the data and algorithm development and the profit motive. This is why I think some portions of this, especially the data generation and curation portions, may need to be driven by non-profits and/or the government.</comment></comment>


Technology Holy Wars Are Coordination Problems - <AUTHOR> https://www.gwern.net/Holy-wars <comment><USER2> The platform thing is an interesting take. If you're invested in a platform, you really really don't want it to turn out that it's not the winner. Then you have to throw away all the sunk cost and learn a new platform - suddenly all your investment counts for nothing. So you defend it - out of fear that your investment might be irrelevant.

I read a few years ago "under all anger is fear". I'm not sure if that's completely true (hanger is a thing), but I think it's right most of the time. I've found it very useful when I feel angry about anything to take a step back and think about what I'm afraid of - that's usually the thing that really needs to be addressed.

<comment><USER3> I'm pretty sure people get angry about being taken advantage of and treated unfairly, I suppose that can also be ascribed to fear but I think you have to do too many rhetorical tricks to make it work.

<comment><USER2> It's not much of a rhetorical trick - anger for unfair treatment is driven by a fear of loss of power, status and control.

<comment><USER3> yeah if someone is passed over at work for a promotion they've earned making the fear argument is possible (that they fear they will lose status as you say, or maybe get fired) - but really at that point it's in the past. Fear is a future directed emotion.

It seems to me that the anger is not driven by fear of loss of power it is driven in a case like this by envy of the reward one lost out on. by envy of lack of access to more power.

I am in a very unfair relationship right now and my anger is not fear driven, as in what will happen in the future, it is generally anger at what is the current situation. Thoughts of - If they had not done X I would not be in condition Y.

To turn that into a fear situation you have to ignore what I say is the cause of my anger, then postulate something like "he fears condition Y being permanent, or condition Y turning into condition Z" when condition Y should provide ample grounds.

Actually the more I think of this fear thing as the root of anger the more messed up it seems to me, because it seems structured around people never caring about their current or past situations but only about the future, and I don't think real people act like that.

somewhat facetiously - Are you sure this fear theory wasn't created by an economist?

<comment><USER4> I think anger is a human response to unfairness, its function is signaling and calling attention to a willingness to escalate.

Animals have similar emotions. Bruce Shneier has written a great book "liars and outliers", which talks about how we maintain the trust society needs to operate.

Studies it cites have shown that people are willing to take a loss to punish others who they perceive are cheating and breaking rules, especially if they do it all the time.

Anger is often the response by those affected, and to a lesser extent those who enforce norms, to systematic rule breaking, and accomplishes the two things:

1) Unmistakably calling attention to the issue and oneself

2) Signaling a willingness to escalate to mutual loss if need be, if the behavior persists

So, to say it's driven by fear is too reductionist! It serves a major function in human interactions. Consider Steve Jobs' reaction when Google was going to go ahead with the Android.

Finally, if you want to avoid anger in your own relationships, the key is to hold people to a lower standard and expect less of them as ethical and rational human beings. People find it hard to do because, to stop fighting with someone, you have to greatly lower your respect them in certain areas. But the funny thing is, they will often appreciate you for doing this, and never wanted that respect! Not really, anyway.

<comment><USER5> As to relationships, consider that sometimes anger comes from others' expectations of you. That isn't something easily changed, and accepting their demanding ways may just enable bad behavior.

</comment></comment></comment></comment></comment></comment><comment><USER6> > The difference is that holy wars are always about _platforms_ with network > effects, and the indirect second-order effects are much more important than > the first-order changes.

That is a _really_ insightful point. One think gwern doesn't dive into is that someone _closer_ to one can cost one _more_. I get more annoyed when someone tries to rewrite Emacs in Scheme than in Rust. The Rust programmer would probably never have written Lisp code, but the Scheme programmer might have. Likewise, someone who writes a neat extension for vim might have been willing to write the same functionality for Emacs — but someone who extends Eclipse would probably never have spent any time on Emacs.

It goes in the other direction in both cases, too!

<comment><USER7> The main reason vim users aren't writing elisp is mostly because they don't want emacs.

Sure, they might really like the underlying functionality emacs has, but even evil-mode can't completely hide emac's UI.

I wish there was an emacs with a totally user-defined UI, so some people could configure their UI to feel like Vim, others like emacs, and others as something completely different.

Sure, you can replace the default keymaps, but that only gets you so far. If you go down this road (I have), it quickly becomes a futile effort to remove the emacsness from your UI.

</comment></comment><comment><USER8> Software is over coupled. Everything tries to be the platform and split the user base, so it control the tribe, the resources of the tribe and the focus of the tribe and most of the time, not intentionally.

<comment><USER9> Making things compatible without a common standard also has a cost. If everything is text optimized for appearance in a terminal, then how do you parse out the data to be used by a script?

The unix solution is offloading the complexity on the script, which makes all scripts more difficult to write.

<comment><USER10> The solution is to have more common standards, make standards more accessible, and use existing standards whenever possible.

<comment><USER11> _> The solution is to have more common standards, make standards more accessible, and use existing standards whenever possible._

"The great thing about standards is that there are so many to choose from. "

<comment><USER10> We don't need more interchangeable standards. We need standards for different things.

The point in having standards is not to have the one ultimate standard that everyone uses, but to have a documented way to interoperate at all without interrogating the author or reverse-engineering.

</comment></comment></comment></comment></comment><comment><USER12> In addition, I've realized a big blind-spot in these holy wars is the 'familiarity' aspect:

\- Users of one platform have gotten used to it, have gotten over, or adapted to some of the pain points, and/or have developed effective workarounds. Having passed all those stages, their day-to-day interaction with that platform is a state of comfort-zone. Call this mental state A.

\- When those users attempt to analyze or review a competing platform (which is new to them since they haven't spent time using it), not only are they uncomfortable with the overwhelm that comes from getting inundated with new information, and having to process all of it, they're also keenly perceptive of every "dot", "comma", "cross" that is, metaphorically, misplaced in that competing platform, i.e., any deficiencies of the competing platform jump out at them like a sore thumb. Call this mental state B.

Holy wars occur when users of two competing platform argue in favor of their own platform from a mental state A, while attack the competing platform from a mental state B.

<comment><USER13> Additionally, in "mental state B" it (the fresher/hipstery the project the more) often appears that the documentation is either non existing or horribly outdated, and same for any code samples on Stackoverflow.

</comment></comment><comment><USER14> > People have ceased to debate Emacs vs vim not because any consensus was > reached or either one disappeared, but because both are now such exceedingly > niche editors that they are far more threatened by the giants like Visual > Studio Code or Eclipse or Sublime Text.

Citation needed. From the latest Rust survey [1], Vim was in second place at 23.6%, behind only VS Code at 34.9%. Emacs was lower at 7%, but still beat Sublime at 4.3%, and Eclipse doesn't even show up on the list. Not that Rust is representative of programming as a whole, but its results are still probably more accurate than what seem to be anecdotal impressions of editor popularity.

[1] [https://blog.rust- lang.org/images/2020-03-RustSurvey/31-edit...](https://blog.rust- lang.org/images/2020-03-RustSurvey/31-editor-using.svg)

<comment><USER15> Check the editor stats for C, C++, Java, Python. Rust is a niche language today.

<comment><USER16> OK I did. Results:

[https://i.imgur.com/D128c3T.png](https://i.imgur.com/D128c3T.png)

For developers who responded "I am a developer by profession" and used C, C++, Java, and/or Python in their dev environment, VSCode tops VIM, which tops Sublime, which tops Emacs. Every time!

Source: StackOverflow survey results from 2019. Looking at 65,679 responses marked as "I am a developer by profession" [https://insights.stackoverflow.com/survey](https://insights.stackoverflow.com/survey)

<comment><USER17> ...people write java in vim?

<comment><USER18> Some do, I know two people who write everything in vim and do so also when working on Java code.

</comment></comment></comment></comment></comment><comment><USER19> What exactly is the author trying to explain? If he tries to explain _why_ these holy wars happen, his explanation is very lacking. He doesn't seems to consider the psychology and emotions of the human participants. It's rather strange trying to explain a human social phenomena without considering humans. If he just tries to talk about how platforms compete and effect each other, as abstract entities, i.e. a non social phenomena, then the title does not fit at all.

<comment><USER20> OP is not trying to comprehensively explain the dynamics behind holy wars, but simply to figure out why there are holy wars about some things and not others. OP's answer (holy wars are about 'platforms' with sizeable network effects) makes at least some kind of sense.

</comment></comment><comment><USER21> I think dominance and control do play a part in tech holy wars but it's not everything.

Power structures within tech communities ossify and the community itself can regress in their abilities. And so this means that technologies can sometimes get worse over time.

So that can create conflicts between old tech which is proven and reliable and new tech which is not proven and can be unreliable.

</comment><comment><USER22> Hey, if gwern swings by to see this discussion, fyi there is a small formatting issue.

If you click the fnref for one of the footnotes[0] the quote it is referencing gets cut off and isn't readable anymore (but is correctly formatted beforehand).

[0] [https://www.gwern.net/Holy-wars#fnref2](https://www.gwern.net/Holy- wars#fnref2)

<comment><USER23> It might be worthwhile to shoot Gwern an email: [https://www.gwern.net/Links#contact](https://www.gwern.net/Links#contact)

</comment></comment><comment><USER7> Platform is one major problem space.

Another is interface. There are plenty of people who would love to use Vim, but simply don't like the keybindings. Same for emacs, every window manager/desktop environment, etc.

For no reason in particular, we tend to very tightly couple functionality to interface. We could avoid an awful lot of duplicated work if we factored UI out of tooling, and made it more user-definable.

</comment><comment><USER24> Is this not a brand loyalty thing ?

<comment><USER25> It is more than brand loyalty. Technologies (particularly programming languages) shape your thoughts and the way your mind structures solutions. This makes it particularly hard to admit when your pet technology is lacking; you are also disparaging yourself! It is tough (impossible?) to be detached in such technical discussions unless you are very familiar with neither or both of the alternatives being considered.

<comment><USER26> that's very true, a programming language you've mastered begins to influence the way you think and becomes part of your identity. A criticism of the language becomes a criticism of yourself which is very uncomfortable. The only other thing I can think of, off the top of my head, that gets ingrained the same way is politics.</comment></comment></comment>


Salesforce CEO reminds employees of workplace drinking ban: 'Alcohol is a drug' - <AUTHOR> https://www.cnbc.com/2017/11/01/salesforce-ceo-marc-benioff-reminds-employees-of-no-drinking-policy-alcohol-is-a-drug.html <comment><USER2> It's a bit boring movement.. work, work, no fun</comment>


Perception: Our useful inability to see reality: Nature: Nature Research - <AUTHOR> http://www.nature.com/nature/journal/v544/n7650/full/544296a.html?WT.mc_id=FBK_NA_1704_FHBOOKSARTSPERCEPTION_PORTFOLIO <comment><USER2> People have reality-dampers.

It's a popular fact that nine-tenth of the brain is not used and, like most popular facts, it is wrong. Not even the most stupid Creator would go to the trouble of making the human head carry around several pounds of unnecessary grey goo if its only purpose was, for example, to serve as a delicacy for certain remote tribesmen in unexplored valleys.

It is used. And one of its functions is to make the miraculous seem ordinary and turn the unusual into the usual.

Because if this was not the case, then human beings, faced with the daily wondrousness of everything, would go around wearing big stupid grins, similar to those worn by certain remote tribesmen who occasionally get raided by the authorities and have the contents of their plastic greenhouses very seriously inspected. They'd say "Wow!" a lot. And no one would do much work.

Terry Pratchett - "Small Gods"

</comment><comment><USER3> The interesting question is: given the information available to the organism in the moment and the organism's previous experience, what sort of reality _can_ be perceived? This book sounds to me like Bad Philosophy of Mind if it can't answer more coherently than "not reality".</comment>


FILSH.net - Free online clipconverter entirely written in Node.JS - <AUTHOR> http://www.filsh.net

<comment><USER2> hm, i like it. incredibly fast conversion. can anyone tell me details about the architecture of the service?

<comment><AUTHOR> yup, filsh.net is entirely written in node.js, using express.js and jade. using redis as a database and ffmpeg for video conversions. running on 40 high-end servers.

</comment></comment><comment><USER3> w00t 40 servers - 100% node.js? So you've got one of the largest node installations out there, right?

<comment><USER4> I bet only Joyent has as much node.js servers as you ^^

</comment></comment><comment><USER5> perfect platform to get videos/music from youtube to your pc at home! i love it!</comment>


Open source large scale IPv4 full PCAP capturing, indexing and database system - <AUTHOR> https://github.com/aol/moloch <comment><USER2> This uses elasticsearch on the backend. The frontend is ugly, but this is great softeare</comment>


Yahoo and FreeBSD (1997) - <AUTHOR> http://zer0.org/daemons/yahoobsd.html <comment><USER3> This story reminds me of Jan Koum (of Whatsapp) when he donated a million dollars to FreeBSD: "one of the main reasons I got a job at Yahoo! is because they were using FreeBSD, and it was my operating system of choice. Years later, when Brian and I set out to build WhatsApp, we used FreeBSD to keep our servers running. We still do." ([https://www.facebook.com/jan.koum/posts/10152852986375011](https://www.facebook.com/jan.koum/posts/10152852986375011))

</comment><comment><USER4> It would be interesting to read about their experiences over the last 18 years.

I recently installed FreeBSD on a home server and was very pleased both with the process and the result. Also, the documentation is just impressive (that goes, in my experience, for all the BSD systems).

<comment><USER5> They're still using FreeBSD, and happy with it as far as I know.

<comment><USER6> Completely not true. Around 2008ish there was a big migration towards using RHEL. There's still some FreeBSD boxes, but the vast majority have been switched at this point to Linux.

I don't completely agree with the reasoning, but it mainly came down to driver support, maintenance cost, and debugging tools.

<comment><USER7> Note that we didn't run stock freebsd. It was a custom freebsd4 with a custom gcc 2.95 toolchain. I don't remember all the mods, but migrating from 4 to 6 was a nice undertaking, and it was done in parts. People who worked there will remember the term "4 on 6". After the migration, the kernel was 6 (and you got the latest drivers) but we were still running those weird 4 user-land binaries.

Inktomi (YST) was acquired in 2003, later Overture (YSM) and both were linux shops. YST was the biggest property by far and we didn't have any kernel developers. We were doing just fine with stock debian, then stock RHEL. (I did a few very minor patches for 32-bit, like splitting user-space/kernel to 3.5/0.5G instead of 3/1G, and some caching improvements for /proc, but I wasn't a kernel developer). Linux just worked. Drivers were available and supported for the HW we needed. Oprofile, systemtap worked fine for the most part. We later hired one kernel developer to help Mail move to linux, but we always had more freebsd kernel developers.

For freebsd you needed to write the drivers and the tools. That took time and money. The community was also smaller and it was harder to hire people with experience. Acquisitions were running on linux too.

The decision was not easy. Y! already had _great_ freebsd engineers. By announcing that linux would be the supported platform going forward it was a given that many of them wouldn't be happy and leave. Fortunately not all of them left. For example Peter W. still works there.

In any case I don't think there was really an alternative.

</comment></comment></comment></comment><comment><USER8> We used FreeBSD exclusively at my first startup in 1999 (flashbase), partially because of Yahoo's success with it (I was at Stanford). We found the base OS to be very stable and the networking stack to be especially robust. But, the mysql port was not that stable and drivers for proprietary products, like Oracle, were hard to come by.

Back in the day, Oracle did a freebsd driver partially for Yahoo. The Oracle drivers were not open source and hence there were few options to connect without Oracle's help.

I worked in the kernel networking group at SGI in the 90s and there was a lot of freebsd loving there. Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications.

Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows (for SQL server support) the next time around in 2004.

</comment><comment><USER9> FreeBSD has been my server platform since early 2000's, chosen for reliability and relative ease of configuration (vs. Linux, etc.). The primary server for my business was running FBSD since 2005, stopping only for of power outages, or periodic maintenance. (Still works too.) I have used FBSD on desktop systems too, though that has significant limitations.

It's my impression that the pace of FBSD development has been increasing in the last couple of years, hardware/driver compatibility included. As well, it seems recently there's been more "cross fertilization" among the BSDs, and Linux to a lesser extent, signs of health and vigor for these projects.

While there are former FBSD users deciding to go with a different OS, such switching is not new or a one-way thing. I think it's a safe bet some enterprises are choosing FBSD over something else, anyway there's little risk any major FOSS OS project will soon disappear.

</comment><comment><USER10> Fun fact: Russia loves FreeBSD. ([https://www.google.com/trends/explore#q=freebsd](https://www.google.com/trends/explore#q=freebsd))

</comment><comment><USER11> I tried both as a teenager. At the time I ended up sticking with Linux, but even in retrospect it's hard to quantify why. I remember though that it felt more understandable and "approachable" somehow. It was little stuff like bash vs csh or the presence of ever so slightly more modern editors and utilities.

I think if FreeBSD would have put a bit more effort into modernization and community in the early to mid 90s we'd all be using it more now. It's guts were superior at the time and in a few ways still are.

<comment><USER12> There's not being modern, and then there's not chasing every rabbit down every hole. Right now I feel like FreeBSD is a wonderful mix of advanced, modern tech like ZFS and bhyve, married with an absence of "oooo-shiny!" misadventures like PulseAudio and systemd.

And in particular, right now I'm grateful that the BSDs are small enough to be ignored by the herds of people migrating away from Windows and bringing their mindsets with them - that all seems to be landing on Linux.

<comment><USER13> I wonder how much the reason they are landing on Linux is that there are multiple companies actively trying to pitch Linux to existing Windows users.

RH for instance seems to be heavily pitching RHEL (never mind Fedora and CentOS) towards corporate and the Military-Industrial complex. The latter in particular are interested in RHEL after some poor experience using Windows on warships and similar.

But at the same time there is a pile of MSCEs running around in these organizations, and so there is a incentive to make daily Linux management at least superficially similar to reduce retraining costs.

</comment></comment></comment><comment><USER14> In the early 2000's i almost exclusively used FreeBSD. The hardware i used were always a bit behind the curve, and still i could max my network connections.

What made me move to Linux eventually, was the ability to keep all my software easily updated, including the kernel.

<comment><USER15> I've tried FreeBSD on occasion and that's exactly what kept me away from it. Keeping (multiple) systems current is always where most of the work is (if you do keep them current, that is), not on initial installation/configuration.

Honestly, I don't know if this is still the case.

<comment><USER16> FreeBSD has made leaps and bounds with this.

You can use `freebsd-update` to update the OS itself from binaries instead of having to build world. [https://www.freebsd.org/doc/en/books/handbook/updating- upgra...](https://www.freebsd.org/doc/en/books/handbook/updating-upgrading- freebsdupdate.html)

You can use also `pkg` to install/upgrade software packages like `apt-get` on Debian derived distros. [https://www.freebsd.org/doc/handbook/pkgng- intro.html](https://www.freebsd.org/doc/handbook/pkgng-intro.html)

<comment><USER17> freebsd-update still implies semi-manual /etc/* merge. Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades' feature.

<comment><USER18> > freebsd-update still implies semi-manual /etc/* merge

freebsd-update.conf

> Both freebsd-update and pkg are no way close to apt-get and more importantly > Debian 'unattended upgrades

Exactly, it's better.

</comment></comment></comment></comment></comment><comment><USER17> No [proper] NUMA -> no go for my tasks. I was downwoted for that not long time ago, but again, NUMA ... Source [https://wiki.freebsd.org/NUMA](https://wiki.freebsd.org/NUMA)

</comment><comment><USER19> In 1996 I began working at a very bootstrapped Internet Service Provider (ISP). Some of you younger people might not even know what an ISP is - <USER2> used to be companies other than Verizon and AT&T that you could get Internet access from.

Any how, aside from an NT server or two, and a Sun IPX box, our servers were generally Linux (Slackware and Debian) and FreeBSD. Mostly FreeBSD.

FreeBSD had a lot going for it. A lot going for it over Linux at the time, for our company. Often we would get our hands on an x86 box of one type or another and have to make it into a server. These boxes usually had no CDROM, and usually we installed network cards, which themselves were coming in randomly, on their bus (usually ISA, sometimes PCI).

To get the latest version of Slackware, we'd have to download all five of the Slackware base "A" disks. Then the compiler was on the 10 "D" series of disks. Then the 4 "N" disks would have networking. Plus more if you want ghostscript (another set) or emacs (another set), or God help you, a workstation with X-windows running fvwm...

FreeBSD was two disks - boot and root. Then you go into ports and install from there. Because boot and root were enough to get your network card working - when Slackware and Debian often did not have those cards working at all. Many a time I was going to install Linux, couldn't get the network card working, put in the FreeBSD boot/root disks, got the network card working with no problem, and the would-be Linux box became a FreeBSD box.

It was not just network cards - these two disks had a great system for not just recognizing all Ethernet cards and getting them to work, but being able to install a full-out system over a modem and 56k (or 28.8k, or 14k) baud POTS connection. FreeBSD just made it real easy to install itself.

This was not just my opinion, others I knew thought the same thing. Not until Ubuntu did I find a Linux system that worked to make installing it easy. When wireless ethernet cards became more ubiquitous, I had left FreeBSD behind years before, but most Linuxes had trouble with every other card out there, even Ubuntu initially. FreeBSD never seemed to have these problems, being able to install easily was something they prioritized - and I think it helped them.

Also, our Linuxes at the time were vulnerable to the "ping of death" and these sorts of security problems. I still know companies which use FreeBSD. They started years ago and never changed.

I'm not sure when and why Linux started overtaking FreeBSD. Linux had this pre-GRUB boot loader called LILO which was horrible, but it did allow people with Windows boxes to be able to turn their desktop or laptop into a dual boot machine on which they could play around with Linux. Linux was more advanced on the multi-boot front if I recall, and that was probably one of the reasons it got ahead.

Also another mentioned reason is commercialized BSD like BSDI was under a cloud of lawsuits in the early 1990s, whereas commercial Linux companies like Red Hat were free of all of this, and this served to help Linux as well.

<comment><USER20> Well, you have a very different memory of the era than I do. I never had any problem getting an ethernet card working on Linux: there was never any work to do! They just worked out of the box.

I believe it was almost entirely due to the work of Donald Becker. I don't know anything about the guy, other than he had a NASA email address, but I kept seeing his name mentioned when looking for anything network card related.

I remember the floppy disk pain though. Few machines had CD-ROMs so basically it was copying 30 images overwriting Microsoft Windows & Office floppy disks (they were better quality than the cheap 3.5" disks you generally got supplied with and there were always spare ones) and then swap, swap, swap...

</comment></comment><comment><USER21> It's interesting that because the OS was ahead in one key area, probably only for a couple of years, they spent 18 years using it.

<comment><USER22> That's why Apple chose FreeBSD to base OSX off and Juniper chose it for JunOS, because of something 18 years ago...

Or maybe BSD has maintained its technical superiority in some areas for some users.

<comment><USER23> Actually, those choices were for licensing, not necessarily technical superiority, but nevertheless FreeBSD does maintain technical superiority in some areas and falls behind in a few others. It still has a great firewall, for instance.

</comment></comment></comment><comment> X-Factor After installed several linux distros, I decided to try my chance with free BSD. I still remember how I suffered to setup my ADSL. But It was 10 years ago. I am sure the installation process is easier compared to the past but I am not that brave anymore.</comment>


Giving Back to the Developer Community as a Junior - <AUTHOR> http://blog.johncapecelatro.com/post/76028983825/giving-back-to-the-developer-community-as-a-junior

<comment><USER2> Quite a lot of projects are following LibreOffice's lead and setting up lists of "easy hacks" \- simple bugs, cleanup work, etc. It's a good way to get useful work into a project and be able to put it on your resume.</comment>


Improve SEO: How we increased search traffic by 2600% - <AUTHOR> http://www.tintup.com/blog/improve-your-seo-how-we-increased-search-traffic-by-2600/

<comment><USER2> This is a great post. I sure hope patio11 chimes in here.</comment>


Facebook's David Marcus on Brian Acton's Departure - <AUTHOR> https://www.facebook.com/notes/david-marcus/the-other-side-of-the-story/10157815319244148/ <comment><USER2> >the people and company that made you a billionaire

Way to try to take credit for all the value the WhatsApp founders created. I think this FaceBook guy has got a new winner in his own boasting game about having found a new level of low class.

</comment><comment><USER3> >> And Facebook is truly the only company that's singularly about people. Not about selling devices. Not about delivering goods with less friction. Not about entertaining you. Not about helping you find information. Just about people.

That statement shows how far leaders at Facebook have disassociated themselves with what's really happening and the negative impact the cause. It was about the people, like 10 years ago. Now it's all about ads! Ads! People are just a tool to sell more ads.

</comment><comment><USER4> David Marcus is trying you to forget the facts: Whatsapp should stay without ads and Acton left because this did not happen. It already has been announced that whatsapp will have ads, so Acton said the truth and David Marcus is a BS spreader.</comment>


Cape Adare - <AUTHOR> http://idlewords.com/2016/10/cape_adare.htm <comment><USER2> Ah, great. I always look forward to Maciej's pieces / essays. It's just such a great, dry, observant, yet humorous and playful writing style.

</comment><comment><USER3> I like Maciej's writing a lot. Always engaging and interesting, especially in the longer reads. I'm perfectly happy to chip in a bit of money on Kickstarter or the like for a quality read.

</comment><comment><USER4> Maciej is one of my absolute favorite writers. I'm so envious of his ability to craft sentences like:

        > When I get down to the floor, the metal chair rushes over
        > to greet me. We have a brief and painful reunion before I
        > can imprison it under the desk.

</comment><comment><USER5> Tourism on steroids...

<comment><AUTHOR> DFW-esque gonzo journalism on kickstarter.</comment></comment>


EM Midori – High Performance EventMachine-Based Web Framework in Pure Ruby - <AUTHOR> <comment><AUTHOR>
      Performance:

      Following benchmark results are for em-midori-benchmark,
      testing {msg: "Hello"} JSON response by visiting GET / with a single-core, 4GB memory, UCloud instance.

      framework	version	req/s

      Rails (Thin, Ruby)	220.127.116.11	473.34
      Rails (API Mode, Thin, Ruby)	18.104.22.168	630.47
      Sinatra (Thin, Ruby)	1.4.7	1757.26
      express.js (Node.js)	4.14.0	3748.93
      em-midori (Ruby)	0.0.9	4306.63

</comment><comment><USER2> What about benchmarks for the more complicated scenarios they call out as the reason the built it for?</comment>


Brand walks into a bar and Meets a Blogger www.instahype.it - <AUTHOR>

My new meetup for Brands and bloggers / influencers. Input is directed into an email where the spark between a brand and blogger could make magic happen. Any thoughts on the site? no logins and really no platform. <comment><USER2> swipe right</comment>


"Just remove the duck" (2013) - <AUTHOR> https://rachelbythebay.com/w/2013/06/05/duck/ <comment><USER3> A story from the time recounts that Piero Soderino, the head of the powerful Florentine Republic, even told the famously irascible Michelangelo that David's nose was much too large. Michelangelo then hid some marble dust in his hand, climbed back up his ladder and pretended to do some more "chiseling" on the offending proboscis. While he did so, he let some marble dust fall from his hand. The pompous Soderino was fooled – he examined the unchanged nose and announced it was much improved and far more "life-like."

[http://www.globusjourneys.com/travel- stories/italy/michelang...](http://www.globusjourneys.com/travel- stories/italy/michelangelos-david/)

<comment><USER4> Not a huge Steve Jobs fan, but I had a professor who had worked as a designer under Steve Jobs and tried something similar. Steve insisted that a new mouse needed to be just a fraction of a millimetre slimmer so a person's palm was lower and closer to the work surface. They figured he was being an unreasonable "delicate genius" and returned a few days later with the identical mouse and claimed they had reworked it to be a little slimmer. He held it and immediately said they had done nothing and the size was identical to before. They took it and reworked it to actually be about half a millimetre slimmer, showed it to him, and he said it was perfect.

<comment><USER5> There is a similar story about Larry Page when Gmail was being developed:

      Before Google launched Gmail in 2004, its creator, Paul Buchheit, brought it to
      Page's open cubicle office for a review.

      As Buchheit called the program up on Page's computer, the boss made a face.

      "It's too slow," Page said.

      Buchheit disagreed. It was loading just fine, he said. No, Page insisted.
      It had taken a full 600 milliseconds for the page to load.

      "You can't know that," Buchheit said. But when he got back to his office,
      he looked up the server logs. It had taken exactly 600 milliseconds
      for Gmail to load.

[http://www.businessinsider.com/larry-page-the-untold- story-2...](http://www.businessinsider.com/larry-page-the-untold- story-2014-4#ixzz3TLJzGy9x)

It is quite plausible for people who being to obsess over a certain aspect to become overly sensitive to it. In my case, a lifetime of playing high speed video games makes it possible to notice things that others miss when it comes to things like framerates and microstutter in computer graphics. I find it likely that Jobs and Page were able to pick up on millimeter & millisecond defects.

<comment><USER6> Great story, I hope that Larry loads drive.google.com sometime this week and orders that the loading time has to improve as well

<comment><USER7> I thought you were being hyperbolic, but Drive really does take second god damn seconds to load.

<comment><USER6> Indeed, it takes multiple seconds, I have a drive tab pinned permanently to avoid it (actually two tabs, one for each google account I use)

</comment></comment></comment></comment></comment></comment><comment><USER8> I'm reminded of a blog post by an old govvie that hated this approach. His argument was that every time we work around a problem in our process, whether it was a bad system or an incompetent co-worker or manager, we became the problem. Every time we added a duck or built a workaround we were building frameworks that would hold a bad policy in place for longer than if we just stopped and said "that's stupid". Adding the duck binds your co-workers and successors to a life of misery.

There's a real risk (of course) to killing the duck. Your client or your boss may hate you, and that's never healthy in the short run, but they also may come out of the interaction a wiser and better person. Or you may find yourself not working for an idiot, and be happier in the long run anyways. Keeping the duck alive is a bigger long-term risk for everyone.

Kill the duck.

<comment><USER9> There's merit to this position. You can think of this as the process/organization equivalent to technical debt. Every problem that you introduce a hacky work-around, that root problem sticks around and keeps generating more and more hacks and work-arounds. The end result is incompetent management.

That doesn't mean it's _always_ the wrong decision, though. Sometimes, technical debt is the right trade-off. Sometimes the trade-off of teaching your boss just isn't worth the effort, and getting the job done quickly works out.

And, just like technical debt, doing this results is more problems for other people (including future-you) as your bad boss looks good and calcifies his bad habits and rises in the ranks.

Personally, my preferred solution is malicious compliance. If someone makes a stupid decision, they have them suffer the consequences of that stupidity rather than covering for them and letting them delude themselves that their bad decision was good. This only works on new decisions, though; if you try to remove existing work-arounds for old bad decisions, you're the one that looks bad.

<comment><USER10> This is how corporate life works & it took five years for me to come to terms with it. However, I have done much better as an Employee (in the eyes of my Manager/Company) ever since.

Once you develop a good reputation by playing the game, you can always fix old bad decisions & at that point, your superiors would actually encourage you to do so.

</comment></comment></comment><comment><USER11> I hate this story.

I think it's important to differentiate between people who have the right knowledge to request a change and those that think they have the right solely because of seniority; but it's also rather disrespectful to 'cheat' and make fake changes just to make the someone happy. No-one deserves to be treated like a 'mark' for our tricks.

My experience has been that being honest, polite and knowledgeable is a much better approach.

<comment><USER12> I would guess you've never browsed through clientsfromhell.net.

Being honest, polite, and knowledgeable doesn't change the fact that the person who hires you may be ignorant, too busy, dead set on cheating you, or needs to assert his/her sense of control by insisting on changing _something_ you considered finished.

<comment><USER13> that may be so, but tricking them into making the right decision is not a good long term decision. If they can't respond to reason perhaps changing teams and companies is a better approach.

<comment><USER7> "Quit your job" is not a reasonable solution to intractable problems. The duck isn't either, but the change jobs mentality is even more damaging than a duck.

</comment></comment></comment></comment><comment><USER14> Putting on my client/product manager hat for a moment, this is incredibly annoying. You are putting me in the position of either (a) fixing the obvious ducks and not looking closely at the real problems, or (b) having to micromanage you and scheduling another review to make further changes. Maybe you get your desired result (a), but my opinion of your work is going to be much lower since you are making obvious duck-sized mistakes.

If you are a developer who takes this approach, you may want to consider whether the short-term benefit of avoiding criticism is worth the long-term downside of having me think you are incompetent.

<comment><USER15> I think you're missing the point. The point here is that some PMs feel that if they're not demanding changes, they are not necessary / not doing their job / etc. If there's nothing wrong with the completed work, such a PM will demand unnecessary changes, in order to justify themselves.

The duck is a passive counter to the PM's pathological behaviour: ensure there's always some easily-fixed fault, so the PM can feel like they're doing something, without forcing unnecessary high-effort changes. Since the duck is obviously bad and easily removed, it shouldn't prevent the PM from noticing real issues, or detract from fixing real issues.

If you feel the need to add ducks, the real problem is that you have a bad PM. But if you're a dev and have no good way to solve the real problem...

<comment><USER16> The problem is that it's not uncommon for a dev/designer/etc. to not understand some of the reasoning for why a PM is requesting changes be made. We all snicker at the incompetent PM who just wants to "make their mark" on a project, but very often the demand that may appear that way is motivated by entirely legitimate concerns. (And yes, the PM should bring the dev along with them, etc.) If you "add a duck" and the PM ends up missing the legitimate concerns as a result, everyone loses.

The add-a-duck attitude fundamentally assumes that the dev/designer knows what's best for the end product and the customer, and while that happens some of the time, the reason the PM role exists in the first place is because that's not always true. :)

</comment></comment></comment><comment><USER17> I once talked to an SAP consultant, and he told me he would often make some part of his code painfully slow on intention. So during review meetings, rather than endlessly discuss minute details and demanding arbitrary changes, people would complain about how slow it was. "I'll see what I can do", the guy would sigh, go to his office, remove the offending code, and voila - <USER2> was happy.

I haven't had the opportunity to try this technique, but I have been waiting ever since for the moment where this might come in handy.

</comment><comment><USER18> This is classic military when presenting anything to an officer for review. I've definitely read references of it going back to WWII (intentional, obvious oil smudge on otherwise pristine rifle). It was frequently stated that no officer could leave a document unedited after review, so an obvious misspelling or two would be added. It's a way of life on the military, really.

<comment><USER19> Client services, as well. I was Director of a partnership marketing agency that had blue chip clients (IBM, FedEx, etc.). Any time we presented concepts/ideas to our clients we ALWAYS 1) included a few "easy no's" and 2) held back one or two good ones (most times). I have a quote hanging on my wall that reads: "Ideas are 1%, execution is 49%, getting people to own the idea is 25%, making those people heroes is 25%" (Chris Brogan). I think that's a positive way to spin this situation.

</comment></comment><comment><USER20> I worked at a deli during college, and people did this same type of thing on slices. By default, I'd always pick a pretty thin slice. Most people really like thinly sliced meats. The first thing you do is slice once and show them the slice, making sure it fits what they wanted. 99% of the time, people would say "thinner," I would pretend to fiddle with the knob, slice the same thickness, and they'd say "perfect!"

I think it gives them some sort of feeling of control and ownership over what is happening.

<comment><USER21> or maybe they don't want to appear rude or finnicky by pointing out that it looks the same?

<comment><USER22> This was my thought too. I've already asked you to "fix it for me" once. I feel to do so again would just be rude (and wasteful as now 2 slices would have to be put aside for another person, or thrown out)

<comment> swagasaurus-rex By extension, asking for a change in itself is presumptuous, so coming back with the same product is returning the favor.

</comment></comment></comment></comment><comment><USER23> Funny how she mentions dogs.

In Dutch it is a common expression to say something like "And then of course he has to pee on it a bit". (Hij moet daar nog even een plasje over doen) to indicate exactly this behaviour.

<comment><USER24> Ha, I thought this was some abstract joke my friends and I make when we see this type of behavior. Funny that it's apparently universal.

</comment></comment><comment><USER25> Dilbert has this covered: [http://dilbert.com/strip/2007-02-02](http://dilbert.com/strip/2007-02-02)

<comment><USER26> An older Dilbert on the same theme: [http://dilbert.com/strip/1997-07-12](http://dilbert.com/strip/1997-07-12)

<comment><USER27> younger _

<comment><USER26> something from 18 years ago is older than something from 8 years ago.

<comment><USER28> Dilbert (the character) was younger 18 years ago comparted to 8 years ago.

</comment></comment></comment></comment></comment><comment><USER29> I guess this is probably the story she's referring to: [http://blog.codinghorror.com/new-programming- jargon/](http://blog.codinghorror.com/new-programming-jargon/)

</comment><comment><USER30> There was a similar story, that I can't now find a source for, of an advertising company that regularly added a 'helicopter' into their customer quotes for video shots. As well as being superfluous it was massively expensive. So the customers say 'we don't need a helicopter', strike that out and feel good that they've done their cost cutting. The rest of the plan makes it through unscathed.

<comment><USER31> The "helicopter" may also be related to the "anchoring effect" [1], where adding such an expensive item with inflate the final cost of the project. That final cost will be the starting point, or "anchor", for clients to evaluate the true value and appropriate price of the project.

[1]: [https://en.wikipedia.org/wiki/Anchoring](https://en.wikipedia.org/wiki/Anchoring)

<comment><USER32> This hooks nicely back into the world of software development, and the anecdote about the senior game dev deleting a secret static 1MB buffer when their team hit their memory ceiling - [http://www.dodgycoder.net/2012/02/coding-tricks-of-game- deve...](http://www.dodgycoder.net/2012/02/coding-tricks-of-game- developers.html)

</comment></comment></comment><comment><USER33> NPR had a story about this in graphic design where it has the term "Hairy Arms": [http://www.npr.org/2014/11/17/364760847/whats-with-all-of- th...](http://www.npr.org/2014/11/17/364760847/whats-with-all-of-the-hairy- arms-in-graphic-design)

<comment><USER34> I've heard about this before. The person who was telling me about it said that in almost all cases the C-level person they were dealing with would choose the "hairy arm". Had an unintended way of backfiring frequently.

<comment><USER35> The "hairy arm" in this case isn't an alternate version, it's an obvious error added to the design so that the manager can tell you to remove it.

Though I've definitely also heard of people making a deliberately terrible alternate design and having a client pick it.

<comment><USER34> Yes. That is where the term comes from... but it encompasses the practice of using an intentionally "wrong" option.

From the linked article:

"FREASE: Exactly. And it's funny I'm saying this but yeah. You know, it happens. Everybody does it. Like, for example, I worked with - 10 years ago - I worked - we did these logos for a famous musician. And they had a lot of people working for them and a lot of voices. And after working with them for a couple weeks, we realized that they hated the color blue. So if we showed them three logos, we would show the ones we loved. And then, we'd do one that they wanted, but we'd put it in the color blue."

</comment></comment></comment></comment><comment><USER36> There's a certain tone in this article that bothers me a bit.

At least in software engineering, the idea of reviews is to find errors in code or design how ever small they are. When inspecting any code, we almost always find at least something, regardless of the level of quality. It's not about being fair, it's not personal, and it probably isn't even dependent on the reviewers personality. It's just that when the goal is to find deviations, that's what happens. It's just a process. The errors may be small or big, it doesn't matter, we just need to find them.

Some inexperienced developers often find the code review process intimidating and unfair. They take it personally. That's a wrong attitude.

<comment><USER37> About a year ago I had the misfortune of working with a program manager. He asked me to create a PowerPoint presentation on something totally unimportant and irrelevant. After failing to explain this to him, I decided to accommodate him figuring that he would become more reasonable once he knew a bit more.

After emailing him the presentation, he called and asked me to switch the 2nd and 3rd bullet on one of the slides and then send him the revision. Our relationship went downhill from there. Finally I had no choice but to marginalize him.

I don't think the author of the article had code reviews in mind; she's alluding to this sort of nonsense when you sense her negative tone.

<comment><USER36> You're probably right she didn't have code reviews in mind. Perhaps I was just worried that someone takes this as an example and will do some crazy unnecessary tricks in software.

Also, I don't have any experience of such absurd situations despite my experience working with dozens of teams. Maybe that's because I'm from Northern Europe where professionals don't take such bullshit from anyone. Oops... perhaps slightly strong wording. Well, I guess you get the point.

</comment></comment></comment><comment><USER38> Battle Chess was a great game. I believe I recall the rook eating the queen as well.

<comment><USER39> [https://www.youtube.com/watch?v=QM3InfEH- cU](https://www.youtube.com/watch?v=QM3InfEH-cU)

<comment><USER40> >> "From the PC game Battle Chess (Enhanced) by Interplay. The reason I discovered I was into vore."

I really, really shouldn't read even the _descriptions_ on YouTube videos.

<comment><USER41> I would also advice not going to the user's Google+ account. I was curious, and I regret it.

</comment></comment></comment></comment><comment><USER42> This is also great parenting advice. Give your kid the feeling of having chosen to eat their vegetables, and they'll devour an entire plate of them.

<comment><USER43> Agreed. Our son always "decides" what he's having for dinner and what to do during the weekends, for example.

Only he decides by choosing between 2-3 options we've selected in advance to match what we want the outcome to be.

Similarly it's always bedtime before his actual intended bedtime so he can negotiate some extra time. It avoids so many conflicts when he smugly believes he has gotten exactly what he wanted out of us.

I think works on pretty much anyone, you can just be more blatant about it with some people than others.

<comment><USER44> I like giving him different veggie options for the illusion of choice.

I don't like letting him "get one over" on bedtime. When he's old enough to know the difference, then what? You'll have to take away those wins. Same goes for basically everything else he'll want from you.

At least he'll (hopefully) negotiate well!

<comment><USER43> I figure when he's starting to realise that the wins are not really wins, he will also realise he's not been "getting one over" on us.

At the same time, there are always things you can negotiate on. E.g. I don't care if he's up until 10pm if he can prove to me that he will consistently get up on time and do well at school despite staying up late.

We're already playing that with him: We point out in the mornings if we notice he's tired that he seemed to have gone to bed too late, and we "trade" going to bed earlier on school nights against staying up later during the weekend. As a result he sometimes tells us he wants to go to be before the agreed bedtime.

And I'm willing to be flexible about all kinds of things as long as he's giving us something reasonable in return. E.g. he gets weekly home work, and so I'm willing to skip on doing it one evening if I can trust that he will stick to an agreement of more than making up for it the following evening (and if he doesn't, he knows the consequence is much less freedom for a long time).

I've no doubt I'll still have plenty of challenges down the road.... And he is already a master negotiator, though sometimes he's trying to be too wily for his own good and sometimes ends up talking himself out of a good deal because he doesn't yet understand all the options well enough. So he gets maths lessons this way too...

</comment></comment></comment></comment><comment><USER45> I'm guilty of doing this quite often. My boss wants to make some amends everytime we review my task. Earlier I used to try to make the result as perfect as possible which resulted in him asking me to make significant changes which are unwarranted. Now I intentionally leave a minor correction which I'm sure he will notice. So now he gets the satisfaction of finding something in review while I still get to maintain the application the way I wanted it to be. Win-win?

</comment><comment><USER46> I have routinely left known performance optimization tasks to be done after the initial review of a product's MVP features. It just seemed better to get the first cut out to people to review in case significant refactoring occurred in response to the first round of feedback.

The unintended consequence of this approach is that changes in response to feedback appeared to have much more impact on the overall UX experience. It increased reviewers' feeling of ownership of the product and they were more likely to become product champions and evangelists.

</comment><comment><USER47> You'd be surprised how many standards are made like this. Companies adding useless stuff due to political reasons, appending obfuscating things so that somebody can claim credit for that part of the standard, hiding the real agenda they want to pass, proposing exact opposites to what they want so that others stop their (ridiculous) idea in order not to give them any advantage that sometimes backfires and ends up in the standard anyway (but they would do it even for reasonable idea as they don't want to make life easy for a competitor), other companies blocking anything they consider a strategic threat to the way they do their business, and you'll end up with a horrible standard full of ducks and hairy hands... Add to it occasional groupthink and dyslexia and then wonder why most software standards are so horrible...

</comment><comment><USER40> I've never intentionally added something that I used as a distraction from the rest of the work, but I have added requested features--that I thought were poor design--in a way that would be very easy to remove. Later, when the client finally agrees that it is a bad feature, it's no trouble to remove it.

I've also just hidden things that the client has asked removed if I thought they would eventually ask for it again, once they got to using the software. They usually do, and they think I'm a "genius" when I can make these "big" changes in such short periods of time.

Hell, I even tell them I'm going to do it. I'm always very forthright with my clients. But they never remember. They always think I do everything from scratch. I guess because their own developers do, they think we all work the same way.

<comment><USER48> I think most freelancers do this. I have done it my time.

</comment></comment><comment><USER49> Similarly, always give options, subtly worse than the one you want to see picked. See Dan Ariely's books.

<comment><USER50>
      Bernard Woolley:      What if he demands options?

      Sir Humphrey Appleby: Well, it's obvious, Bernard. The Foreign Office will
                            happily present him with three options, two of which
                            are, on close inspection, exactly the same.

      Sir Richard Wharton:  Plus a third which is totally unacceptable.

      Sir Humphrey Appleby: Like bombing Warsaw or invading France.

_Yes, Minister - A Victory For Democracy_

<comment><USER51> Wish I could upvote this twice, "Yes, Minister" is full of stuff like this.

</comment></comment></comment><comment><USER52> An electrical engineer I worked with told me about a similar situation he had encountered at a previous job.

He would design a circuit only to have another engineer (responsible for cost cutting), remove or modify a component. The resulting design would not work as well.

To get around this, he would add some sacrificial extra component like a resistor. The cost cutter would remove this leaving the original design intact.

</comment><comment><USER53> I think a lot if this effect is just that people think differently from each other.

Eventually, someone is going to see something you did, where they would have done it a different way. If that person is your manager, not only do they see lots of things you are doing (and thus plenty of things they might have done differently) they also have the power to compel you to do it their way.

If you're the boss, presumable you think you are the boss because someone higher up still thinks you do a good job, which is a sort of implicit endorsement for you doing things your way, instead of your subordinates way.

</comment><comment><USER54> I have thought about the same tactic if you are selling your house, and the potential buyer is bringing an inspector.

"Break" three things in your house, e.g., remove the cover from a bathroom exhaust fan, loosen a faucet so that it rattles, and remove all of the light bulbs from an overhead fixture. The inspector will find these, the buyers will require that they be fixed, and it will be easy for you to do so.

If you don't do this, the inspector will find three other things.

Of course this would only work if your house doesn't need any significant work done in the first place.

<comment><USER55> Just to provide a counterpoint, I had a master sergeant who would flip the fuck out if he saw obvious problems. The idea was that if he could find obvious problems, then his juniors don't give a fuck at all, and there are going to be a lot more not-so-obvious problems. This was a cue for him to go on a rampage through the section and cause pain and hardship for everyone.

</comment></comment><comment><USER56> We, as engineers, should also resist the temptation to leave our own mark when we're reviewing products designed by others. I don't work in management, but I've been in review meetings and I have made suggestions that worked their way into the final product. I like to think that my own suggestions were helpful, but it is gratifying to see one's own suggestion implemented. The temptation to leave one's mark just for its own sake is something we should all be aware of.

</comment><comment><USER57> Similar thing was often done by writers in the Eastern bloc to fool the censors. They left some obviously bad things in the material to be censored, so the censor could complain about something, and they would leave more subtle references intact.

</comment><comment><USER58> For lawyers drafting contracts, there's a quite-legitimate, signaling-related reason for "doing the duck." By giving the other side's contract reviewer something to object to and revise, _it lets her demonstrate to her boss that she did her job competently._ For example, she can then report to her boss (or client), "they wanted net 15 days payment terms but I made them change it to net 30; otherwise it was an OK contract." That in turn can help get the contract out of legal review, and into the signature process, more quickly.

This is sort of related to the story about Van Halen's concert contract that required a bowl of M&Ms in the dressing room with all brown M&Ms removed. [1]

[1] [http://www.snopes.com/music/artists/vanhalen.asp](http://www.snopes.com/music/artists/vanhalen.asp)

</comment><comment><USER59> How much of our work in this business is just useless theater?

I couldn't stand working in a place where it was a significant portion of work. But it is probably unavoidable to some degree.

I see that code reviews for newcomers' commits often have these elements:

First review: "you did X. That's not smart. Do Y instead."

The new employee goes back to rework their commit.

Second review: "you did Y. That's not smart. Do X instead."

After a few weeks / months it starts getting reasonable. It's not as extreme, and it's well disguised in friendly demeanor, but there's still some similarities to what it was like in the army "boot camp".

</comment><comment><USER60> It's not about leaving your mark, it's about posturing. I used to work in a kitchen. At the end of the night the manager would do a walk through and always find something not to their liking that needed to be finished before you went home. Sometimes it would be simple, sometimes it took a long time. I got in the habit of leaving something simple and obvious, like a splotch of mayo on the counter, and it resolved the issue.

</comment><comment><USER61> It's not uncommon, in business dealings or in legal contracts, to put things in that you know the other side will remove just in order to make them feel as if "money hasn't been left on the table" or that they have done their job for their client. You almost have to do that as part of negotiation to get what you want and to satisfy all parties many times.

</comment><comment><USER62> [Here's the link to the Stack Exchange post]([http://programmers.stackexchange.com/questions/122009/develo...](http://programmers.stackexchange.com/questions/122009/developing- a-feature-which-sole-purpose-to-be-taken-out)) (on the Programmers site) that's reverenced in the blog post.

</comment><comment><USER63> This reminds me of "How a Web Design Goes Straight to Hell" [1] by The Oatmeal. It's a different moral, of course; basically, don't trust the client more than you need to.

[1] [http://theoatmeal.com/comics/design_hell](http://theoatmeal.com/comics/design_hell)

</comment><comment><USER4> >> The sacrificial duck kept the meddling manager away from the stuff that was important.

The territorial dog analogy is perfect. I've seen parks where they put fake fire hydrants and other features in the dog area so they can feel satisfied without leaving their designated area.

<comment><USER49> I'd love a exhaustive course on this kind of fakery.

<comment><USER64> How about buttons by crosswalks that don't do anything?

<comment><USER49> Can't say, my driving instructor told me to pay attention to people near them because it does affect traffic lights (and even sequences of them). Other than that, it's pretty possible it's just a decoy to trigger pedestrians patience because they think lights are about to switch.

</comment></comment></comment></comment><comment><USER65> Nice story. I'm disappointed that it didn't end with some helpful tactics for ducks you could put in your own projects, though. I also would be interested to hear the real story of what happened to the author to inspire this writeup.

</comment><comment><USER66> My company just doesn't have product or project managers and it's wonderful. Fewer meetings, no intermediaries, more agility. It could only work in practice, it could never work in theory.

<comment><USER67> As someone who is responsible for 10-15 concurrent IT projects across numerous teams, many of whom I don't manage, this sounds terrible. I think the "no PMO' approach may work for homogenous groups whose focus is one project, but for a large organization, effective project management is a must.

<comment><USER66> That's maybe true, and also a good reason I wouldn't work for a large company again.

</comment></comment></comment><comment><USER68> I've heard of (but never tried) a similar thing done when showing design concepts to a client. Usually several variations are prepared, and if you're any good they will all be viable options. When presenting to a client they will normally want to try and critique something regardless of how good the designs actually are.

The story goes that you are supposed to make an obvious mistake, like a spelling error, on purpose. This will fulfill the clients' need to provide a critique and allow good designs to remain an option.

<comment><USER69> The variation on this that I'm familiar with relies on our perception of three as a magic number for choices: two options doesn't feel like a real choice, four feels like _too many_ choices, but three is perfect. So when you're presenting design concepts, you show three: the one you want the client to pick, another that's very similar to the one you want the client to pick but with some obvious glitch in it, and a third that's so atrociously ugly nobody would choose it. The client goes for the one you want them to go for every time.

<comment> swagasaurus-rex Ah, the apple pricing model

</comment></comment></comment><comment><USER70> >It's almost like they want to be able to point at any given part and say "I'm the reason that happened".

I suspect this is done by people that feel like they will need to justify their job later. Having something to say when your manager (or others) inevitably ask "So, what exactly is it that you do here?"

This seems to be also prevalent in the movie and tv industry. (Though I wouldn't COMPLETELY disparage the usefulness of studio/executive notes; see: Star Wars)

</comment><comment><USER71> I used to work with a very wise and experienced designer who referred to this as the "zinc" (after the "sacrificial protection" used on the hulls of ships)

</comment><comment><USER72> Doesn't this become self reinforcing? As long as the developer keeps adding silly things to his work the PM will be forced to ask for them to be removed, thereby reinforcing the developer's mindset that the PM always asks for changes. The PM is put in a position where he has to okay something unusual in order to stop the Dev from adding little unusual things.

</comment><comment><USER73> Sounds like the duck is a fingerprinting honeypot.

</comment><comment><USER74> I heard a similar story (a joke from the communist era) around 1995 from a Czech colleague. It was about an artist whose works were never censored.

When the other artists asked him how he did it, he replied: "I always add a little white dog in my paintings. When the censor asks 'What is this dog?' I quickly remove it and he's satisfied."

</comment><comment><USER75> This reminds me of some contracting work I did for a company that billed the Federal government. I was told that the final invoices sent to them had some obvious and intentional accounting errors such that these would be "caught", thus satisfying whomever was in charge of approving the invoices on the government's end.

</comment><comment> vezzy-fnord This is virtually the same as what is more often called "bikeshedding", though with a different (just as famous) story: [https://en.wikipedia.org/wiki/Parkinson%27s_law_of_trivialit...](https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)

<comment><USER76> no, it isn't bikeshedding at all.

<comment><USER77> It's related, though -- it's a process you can do to help minimize the impact of bikeshedding by baiting it with something innocuous.

E.g., you design your awesome nuclear power plant, and put a REALLY ugly bikeshed, so that the reviewers will feel compelled to expend their change- requesting energy on that, rather than on changing something that might affect the important stuff.

</comment></comment></comment><comment><USER78> Reminds me a little of the Declaration of Independence where the famous line would have been "We hold these truths to be sacred and undeniable" if Thomas Jefferson hadn't been "touched" by Benjamin Franklin with his edit to "self- evident".

</comment><comment><USER79> Another version of this story that I love uses the Russian Navy:

[http://blogs.msdn.com/b/brada/archive/2005/05/12/417064.aspx](http://blogs.msdn.com/b/brada/archive/2005/05/12/417064.aspx)

</comment><comment><USER80> I'm sure I've been on the receiving end of this from the guy who does my graphics work. I mostly find it amusing but a it is bit annoying when there is a deadline. I won't let on that I know though.

</comment><comment><USER81> It is called bikeshedding. People have been using "bike sheds" in software development for years to get project managers off their back about the important stuff.

<comment><USER82> No, bikeshedding is something completely different.

[http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality](http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)

This is about how some managers feel they have to suggest a change, any change, to justify their position.

Bike shedding is excessive discussion in committees/group emails about trivial matters because everyone feels they understand the issue, unlike more complex issues up for discussion.

<comment><USER83> Correct, but a similar cause underlies both. From PHK's email on bikes-heds, "somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is _here_."

The project manager needs to show that's he's here and actually doing things, and so decrees changes like getting rid of the duck or changing the color of the buttons from taupe to mauve. In bikeshedding, all the people commenting need to prove that they're there and contributing, so now everyone is suggesting color changes. It seems to me that the main difference is the number of people involved.

<comment><USER81> Yep - you offer up a sacrificial bikeshed/duck for management to meddle with, whilst the important stuff is left alone. Could be one person or a committee/group - its the same thing.

<comment><USER84> Or, as Thomas Jefferson did, you overwhelm them with excessive preparation, so that they are reduced to making minor suggestions and your vision goes through.

[http://www.johndcook.com/blog/2011/03/03/thomas-jefferson- me...](http://www.johndcook.com/blog/2011/03/03/thomas-jefferson-meetings/)

</comment></comment></comment></comment></comment><comment><USER85> "What is the difference" I could go on for days about the differences between dogs and humans, if only the author had permitted comments to be left on the page.

</comment><comment><USER86> I've always thought the "just remove the duck" story was a condemnation of the artist, not the manager.

If your work is so crappy that you know you have to add something even crappier to distract the reviewer, what does that say about your competence? Maybe I'm just jaded from years of reviewing awful code. But if someone put an obvious compiler error into their code in hopes that it would distract me and keep me from seeing their memory leaks, off-by-one errors, and mis-spelled variable names, I'd be wondering if they're qualified to be on the project.

<comment><USER45> I think you missed the spot. "Just remove the duck" is a pattern not an anti- pattern. What it addresses is the urge of some supervisors to ask for some change just to show that they have done a thorough review, while the said change are actually detrimental to the product.

> memory leaks, off-by-one errors, and mis-spelled variable names

The above don't fall into the review comments that are being avoided as these are valuable suggestions.

<comment><USER86> No, I get the _intended_ meaning of the story, putting a decoy in for that meddlesome boss. But I think it can be interpreted both ways. For every manager out there who, out of hubris, needs to "leave their mark," you can find an artist or craftsman who, out of the same hubris, believes their work is beyond criticism.

<comment><USER45> I agree with your above comment while the previous comment was leaning towards one side.

> story was a condemnation of the artist, not the manager

</comment></comment></comment></comment><comment><USER87> More amusing than the article itself are several stories recounted here.

</comment><comment><USER88> "Too many notes."

</comment><comment><USER89> Wonderful game, I played it on Amiga. Beautiful post.

</comment><comment><USER90> I just want to point out that yes, the rook eats the queen, but at some point, some piece has its manhood removed in a most grisly fashion. Surprised the PM didn't have any feedback on that bit.

<comment> swagasaurus-rex If this were reddit, somebody would already have the video link handy

</comment></comment><comment><USER91> I wonder how much refactoring is done in this vein!

</comment><comment><USER92> Great story. even better game...i miss it :(

</comment><comment><USER93> Humans or animals, it's natural to want to leave a mark. The article is pointless.

</comment><comment><USER94> In the SCRUM shop I used to work, I did this all the time for our QA dept when the sprint was fairly trivial. If I didn't the PMs and the BAs would start breathing down their necks like they weren't working.

</comment><comment><USER95> This is the origin story of Richard Stabone (RIP) also. Originally named to be used as a sacrificial bargaining chip with the standards board, he was somehow never cut, leaving Kirk Cameron stuck with a Boner for four years.

</comment><comment><USER96> Commonly known as a 'red herring'.</comment>