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."
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.
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.
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.
> I find it likely that Jobs and Page were able to pick up on millimeter & millisecond defects.
Quite possible. It's also possible that Jobs & Page made all kinds of more or less random comments, and people remembered and retold the stories about the times they were strikingly correct.
Third plausible option for the Steve Jobs story: he knew his colleagues very well and just guessed what they did through their body-language. If I was going to pull off something like that on my boss I'm pretty sure I'd act differently than usual, and marketing/business-type people tend to be socially hyper-aware.
We could take that idea to the extreme. Perhaps Jobs knew nothing about technology; he was just highly sensitive to the body language of talented engineers. So he hired top-notch people, and then he yelled at them until he could see that the engineers knew they were doing excellent work.
The thing is, 600 milliseconds is a number that comes up often.
You don't have to be precise to the milliseconds, you only have to be able to recognize 100 milliseconds, 500 milliseconds and 1000 milliseconds. The rest is guessing work.
It's the same thing with the width of elements on the web. Know what 10px is, and you will be able to guess anything.
I used to play a racing game called Trackmania; there was no collision, but it was really competitive in that you'd be racing simultaneously networked w/ other players. You could definitely tell when you completed the lab in a time that was say 10ms behind a different time. 600 milliseconds, +- say 50ms, is pretty recognizable.
Top level players will gain ~10ms or more on eachother every other turn. At a level below the very top you're going to see gaps far bigger. With experience, you'll definitely be able to tell which parts of the track you did well or poorly at, but there is no way you're going to be able to get an accurate feel for all of those tiny gains and losses over the course of a 30-60 second track to accurately judge exactly how far ahead or behind another time you are.
OK, I got curious enough I wrote a small console game to test reaction times.
It turns out I'm not nearly as good as I thought. I can nail a delay of 100,200,...,900ms exactly only about 40% of the time, and within +-100ms about 80% of the time.
If anyone else feels like trying, you can do "go get github.com/erinok/howlonghowlong". Hit space to see a flash, and then type 1-9 for how long you think the flash was.
It's surprisingly fun. (At least if you're incredibly weird like me.)
I find I'll have periods of concentration where I can just nail it, and then it'll leave me, and I'll be sloppy.
I think you might be right...maybe I am remembering differences of more like 100ms?
And thinking about it, in Trackmania it was less a perception of time that you noticed, but a sense of how smoothly and perfectly you had hit every turn. You could easily race the almost the exact same time multiple times in a row, and then feel it when you hit a turn more smoothly and shaved a few fractions of a second off your time. (Or similarly feel it when you screwed up and added a few seconds.)
Man, thinking about this is making me miss trackmania :)
Well... I would agree that the Page story is not that impressive. Obviously, most people from the video game generation would be sensitive to a time period greater than 500 milliseconds.
But that misses the point of the Jobs story. Some people really do have sensitivity to things that the vast majority of others have trouble perceiving. Most people would have trouble perceiving a millimeter difference in spatial dimension by touch.
Having said all of that... the likelihood that the Project Manager in the original story... or even that the Project Manager in your workplace for that matter... is the maven that Steve Jobs was is remote in the extreme.
Sen no Rikyu, a tea-master, wished to hang a flower basket on a column. he asked a carpenter to help him, directing the man to place it a little higher or lower, to the right or left, until he had found exactly the right spot. "That's the place," said Sen no Rikyu finally.
The carpenter, to test the master, marked the spot and then pretended he had forgotten. Was this the place? "Was this the place, perhaps?" the carpenter kept asking, pointing to various places on the column.
But so accurate was the tea-master's sense of proportion that it was not until the carpenter reached the identical spot again that its location was approved.
I think this anecdote might help explain Jobs's success.
There is a tendency when one is running or developing a product to convince yourself that your efforts are producing a genuinely good product that your customers will like. Frequently that isn't true, and the product is rightly trashed by the outsiders. The thing is, the people on the inside would have trashed it too if they had not been insiders.
Jobs seems to have had the ability to resist this self-deception. He was ruthlessly honest about how good the things Apple was making actually were and not at all afraid to reject things because some aspect was poor.
Being able to tell the difference between the tiniest of arbitrary changes doesn't mean it's better. The anecdote could equally show how he's pointlessly stubborn.
All the praise in your comment only really works if the change is a clear improvement.
I personally swear by Logitech's trackball mice (the ones where the trackball is operated with the thumb); less wrist movement involved, meaning less strain there.
In contrast, my wrist hurts just thinking about the Mighty Mouse or whatever it's called.
Yes and yes. I hate it when I find a product that's perfect for my needs and then it gets discontinued. The Logitech trackball was one of them. It's one of those tools that (after you get used to it) just becomes an extension of your hand.
The wireless (which is what I'm using at the moment) is okay, but it's not the same.
I've got some dead ones in the junk pile. When I get some time I'm going to see if I can cobble together a working unit from them.
I have both, and I prefer the wireless. No cords, the battery lasts a long time, and I can program it on my Mac so that, when using Chrome, the extra buttons click on a link, open the link in a new tab, and switch to that tab.
When will Chrome offer the option of switching to a new tab when its link is clicked on? Firefox has had it forever.
> When will Chrome offer the option of switching to a new tab when its link is clicked on? Firefox has had it forever.
When will the big browsers be programmable? I'm currently running uzbl[0] because I want to set my own hotkeys in my browser. I tried 4 different 'emacs bindings' extensions for other browsers until I just figured out that none of these is gonna get it completely right.
The good thing in all of this is that I now control the behavior and features of my browser myself. I've made features that wouldn't even be possible in Firefox/Chrome. Not because it should be all that hard, but because they just don't let you actually do anything with them.
Browsers are pretty much like e-mail clients. They all suck. Some suck less than others, but it's actually striking how bad the sum total of all the browsers' usability is. Ironically I had to switch to a browser that wasn't trying to be a modern browser to get the browser experience that I wanted.
With uzbl I can interface with literally any program on my computer capable of text input/output, so I am hard pressed to see how this claim holds up. This means, obviously, that it's mostly trivial to write bash/perl/whatever scripts/programs for useful browser features.
Like I said, I had to turn away from everything that tried to be a modern browser to realize that most modern browsers are shit, FF/Chrome with these extensions included. Browsers have not evolved well and are mostly designed to be huge monoliths with little to no transparency and programmability. Vimperator and pentadactyl don't remedy this.
Also, trackpads encourage good coding hygiene. Which is say continously using them makes a horrific sweaty mess, so you stay with the keyboard and keep coding. (Unless you really really like w3)
Also I thought "hockey puck mouse" was an old DEC mouse. Dec as in, "my Vaxstation is better than your Mac, cause it has a mouse AND it's still a VAX." (I still like saying "VAX" Side-effect: I start SHIFTING INTO ALL CAPS. )
I find that variety helps: Use one thing for a while, then use something else. Right now I love my little notebook computer with a touch screen. That, and a good trackpad, allow me to keep my hands in a neutral position, which is like a loosely closed fist with the index fingers pointing outward.
My other issue is eyestrain. I can type text without looking at the screen, so I tend to prefer text based interfaces. And keyboard shortcuts are a way to rest from overuse of pointing devices. (i.e., overuse of our bodies)
Remember the urban legend about the QWERTY keyboard, that it was designed to slow us down in order to distract us from how slow typewriters were? Sometimes I wonder if the modern GUI has turned into something like that: Simple tasks require us to control the computer's sequence of operations through extensive manual and ocular labor, rather than us just telling it what we want it to do.
There are some people who really love Apple's mice, even the notorious "hockey puck" one. (Which to be fair was actually pretty comfortable to use, assuming you ever got the damn thing pointing the right way.) I'm not one of them, but I'm not really a huge fan of mice, period -- and their current weirdo mouse-with-touch-surface certainly offers a lot of gesture control, and it's not that uncomfortable. (Granted, "The Apple Mouse: Hey, you've used worse" isn't a very compelling slogan.)
The hockey-puck mouse would have been a lot nicer to use had it been wireless. The small, round body didn't provide a good grip for wrestling with that stiff cable.
I've always wondered why people hate on it so much -- even if someone prefers to point with their arm rather than their fingers, surely they can understand the appeal of using fingers to point at things?
Yes it's a move which works when people demand changes in order to leave their mark or to be seen as "doing something"[0], it doesn't work in the case of people demanding changes because they actually want these changes.
[0] an attitude I find myself unthinkingly adopting when doing reviews.
As a non-native English speaker, I can tell you that this is not only perfectly acceptable but actually a good thing.
Naming is important. Bad function names are a bug in the API, just like any other API bug.
Non-native speakers frequently struggle naming things even more than native speakers, especially when they have to deal with a problem domain for the first time.
Just like any other mistake, bad function names usually aren't intentional -- often quite the opposite. I remember struggling with naming business domain related functions and variables in the first booking system I worked on, especially because the UI wasn't localized into English, so I had no direct reference. Should this class be called Invoice or Bill? Are the terms "netto" and "brutto" commonly used in English as they are in German? What's the proper plural of "index"? And so on.
Having tactful help from a native speaker can be a huge advantage.
That's valuable work in my eyes.. a little effort helps a lot when returning to the code (or having someone else use it) later. Bad naming even causes unnecessary confusion once I'm immersed in the code base.. the fifth time or so I have to ask myself "Which one generated the view, 'processAnnotation' or 'handleAnnotation'?", I just spend the time to refactor.
This problem isn't isolated to non-native English speakers. The potential cost of poorly named methods/variables/classes, etc. is high enough on a complex product that it's almost always worth raising the issue in reviews. If your reviews are run positively it really shouldn't be an issue.
As an aside, I recently saw a job listing that included the requirement to be able to "defend your code in reviews" - I would say that's an environment where reviews probably aren't positive experiences.
On the other hand, I could see that as meaning "know what you're talking about so that you can defend the decisions you make."
As an intern, I've had many times where I'd say "I did it this way using A B and C, is that the best way? Are there any improvements you'd suggest?" after completing work. But in a more senior position, you probably don't want people second guessing / not really understanding these decisions.
I have no problem with anyone, from interns on up, constructively criticizing my code/architecture/design decisions. I work for a company with an exceptionally strong engineering culture and no one shies away from expressing an opinion when invited (and sometimes when not invited). That said, "defend" is a poor choice of words for code review. If someone asks me why I did something, I tell them. It's not a defense, it's an explanation. If they have a better way to do what needs to be done that's GOOD. If we disagree, we discuss why we disagree. Defending is what you do when someone's attacking you, not when you're collaborating.
It definitely requires some tact and thought first. The angle I like to focus on is whether something will actively confuse future maintainers. If it's an internal method and the name is odd but not misleading, it's probably not worth raising at a code review or maybe even privately
This is also a good time for many of us to work on social skills: most people like getting help with a second language as long as it's not putting them on the spot & if you have a good relationship with someone you can bring it up at the right time more along the lines of “Isn't English so absurdly arbitrary?” than something to be defensive about.
I think this is being unnecessarily non-confrontational. As long as you explain why the term is wrong or sub-optimal and what it should be called instead, I can't see how any serious programmers should take offence.
Consider it this way: natively speaking English means you have domain knowledge, sharing that domain knowledge should feel no different from pointing out mistakes in other domains. If someone gets English wrong, that's no different from getting, say, VAT calculation wrong.
Maybe I'm just assuming everyone already handles mistakes in other domains with tact and respect.
Also, it's a matter of proportion. If a function name is extremely misleading that's different from a function name just using an awkward synonym, just as a broken piece of code is different from dodgy indentation. You'll want to fix either problem eventually, but the immediate repercussions are quite different (serious bug vs minor annoyance, basically).
> As long as you explain why the term is wrong or sub-optimal and what it should be called instead
I think we're generally in agreement – I was trying to keep the focus on things which can be reasonably be considered objectively wrong and keeping the degree of wrongness in mind when deciding how to handle it. If you're on the low end of that scale, it's probably not a good use for everyone's time in a code-review session unless it happens a lot.
I think there is a more likely, albeight sadder explanation. Steve was simply able to read the faces of the team and correctly guess that they didn't comply. As a compliance professional he was very sensitive to that and immediately reacted.
Or, a more likely and less idiotically cynical explanation is that a man famous for having vision, aesthetic sense and incessant drive for excellence that enabled him to completely revolutionize multiple technology industries ACTUALLY had vision and a sense of aesthetics.
Idiotically cynical? You're getting oddly personal over this. A 'sense of aesthetics' doesn't mean you know the objectively right size to fit the very very different hand sizes of a million people down to the sub-millimeter level.
Not at all personal on my side; hell, the story is probably apocryphal.
I never said he was right or that I agreed with him, in fact I hate Apple Mice and actually find them too small. No idea where you are even getting that.
My point is that Steve Jobs was renowned for an obsessive, manic attention to exactly these kinds of detail and usually knew what he wanted and would blow up when he didn't get it; so it takes a special kind of person to dodge Occam's razor and go looking for some other explanation.
>Not at all personal on my side; hell, the story is probably apocryphal.
You called dchichkov's argument "idiotically cynical". That's a personal attack, even if you didn't mean it that way.
>I never said he was right or that I agreed with him, in fact I hate Apple Mice and actually find them too small. No idea where you are even getting that.
When you say "completely revolutionize multiple technology industries ACTUALLY had vision and a sense of aesthetics" in response to a comment that suggested he was reading expressions, that very heavily implies that Steve was correct. You need to work on wording if you have "no idea" how I got that impression.
>a special kind of person
This sounds like a personal insult again.
I don't know why you're so vehemently against the idea.
> You called dchichkov's argument "idiotically cynical". That's a personal attack, even if you didn't mean it that way.
No, I'll admit I meant it that way and I'll stand by it. What I meant is that it isn't a personal issue for me as I thought you were claiming. Those are different things.
> When you say "completely revolutionize multiple technology industries ACTUALLY had vision and a sense of aesthetics" in response to a comment that suggested he was reading expressions, that very heavily implies that Steve was correct. You need to work on wording if you have "no idea" how I got that impression.
No. I'm saying I believe (assuming the story is true) Jobs correctly detected the 1mm difference. I'm also saying I don't agree that the 1mm difference was the right call, certainly not for me. Jobs sense of aesthetics resulted in many great products but a few duds as well.
My point is that since Jobs is literally (in)famous for attention to small details and being a complete hard ass about seeing those details through to the end product, it is silly to not only question a story about his attention to small details but to offer another option as "most likely".
It does not mean I think Jobs walked on water and was always right.
This has blown up way farther than a quick throw away line.
Take into account that at least some his image was the result of a carefully planned PR. This is a known marketing tool for companies who sell luxury products.
I think you're right here, he did have a sense of aesthetics.
The blog post I think was talking more about people who just have to change something to 'make their mark' and usually the mark makers are the managers, not the doers or the designers, making arbitrary changes so they feel validated, or powerful, or in control, who knows.
Steve knew what was nice though, indisputably, and in Australia we have the saying "Who's rooting this cat?", in Steve's case he was the one rooting it, whereas the PM in the blog post barely even knew the cat.
Which is, of course, absolutely ridiculous if true. Not everyone has the same size and shape hands as Jobs did. I hate all of Apple's mice because they're far too small for me.
There are countless fables about record company executives dropping by the mastering studio to hear the new hit in its finished form. They'd inevitably make some ill-posed request, of the familiar "it needs to pop more!" variety.
The wily engineer directs them towards a large and important looking knob, telling them that they are free to dial in as much "pop" as they think the track needs.
Of course, they screw up their faces and make minute adjustments, and eventually announce that the sound is now perfect. You all know the punchline.
The twist is that every sound engineer also has stories of doing the same thing to themselves by accident.
That sounds like web development. If I had a penny for every time we're asked for more zazz, pop, pow, shazam, zing, shizzle, pizazz, "something", cowbell...
I'd use them to bury the meddling fuckers who ask for this shit.
Back in the days I worked a while as a web designer, spent my days in Photoshop, learned all the shortcuts.
So I was showing the design to this client who always wanted to modify things, and he said he doesn't like the orange a lot and if we can tweak it. I had a red layer, and a yellow layer over it with opacity, so I clicked on the yellow layer, and started pressing random numbers on the numpad (pressing numbers changes the value of the layer's opacity) so the colors were jumping randomly from red to orange to yellow and the hues in between, finally I settled back on the exact value that was before, and that seemed to satisfy the client. The color was now perfect.
Similar thing happened to me - a client didn't like a shade of blue I was using, even though it was the exact shade she had told me to use. She then sent me a PowerPoint file with just a blue box in it and told me to use that blue instead. Of course it was the exact same blue as before. I re-sent her the file, and she immediately transmitted her enthusiastic approval.
It's possible that he didn't actually do that, and was only blogging the fantasy ("Man, I'd love to troll her with increasingly stupid cat posters until she leaves me alone ..."), but it's also possible that we see the response after being frequently asked to do Free Work as a "favor" for coworkers who either won't accept "No" or don't understand that it's inappropriate to depand such work.
If we take this at face value, she could have asked more nicely, and he could also have followed the "F you, pay me" principle, and just quoted her a figure.
Had he said, "I'd be happy to make you a poster for your cat. I will be able to do it with an hour's work, for which I will bill you $80", he would not have wasted her time, and she could have made something herself in her word processor. (Or, she'd have said, "Awesome, here's eighty bucks".)
Not even wrong. Design is defined by making studied choices within the constraints of the need or purpose. Rarely are these emotional, and when they are it is merely because of a successful connection between the people and the ideas that the purpose of the design created. The emotion is a side effect of good design, not the point. Only Marketing people see design as "emotional" because they see the world through a lens of shaping human behavior through our primate genetic programming.
> Only Marketing people see design as "emotional" because they see the world through a lens of shaping human behavior through our primate genetic programming.
The word design literally means 'fate', i.e. the absence of free will. Shaping behavior is the point, making studied choices is only the means to the end.
Evolution doesn't plan. Design that shapes behavior assumes a god-like view of the world which employed by humans always arrogates to the point of overreaching. For design to be humane, it is behavior that shapes design, not the other way around.
So right on about doing the same thing by accident.
Early in my life, I programmed synths in a studio - and I practiced a variation on this. I would listen to what sound they wanted, then I would play them something that was likely pretty close. They they would complain about it not being quite right, so I would play 3 or 4 different sounds that I knew were completely wrong, then return to the first sound. To which they would invariably say "yeah that one - that's perfect!"
>So right on about doing the same thing by accident.
There is nothing that can describe the mixture of confusion, shame, and artistic/technical self-doubt that you feel upon realising that the compressor you just spent half an hour lovingly tweaking, to seemingly great effect, is bypassed.
I could believe that the original sound actually does seem different after the 3 or 4 other sounds were priming the brain. Our senses don't operate in isolation. Just think of #thedress, or a note played in isolation vs played after a sequence of notes in a key in which the original note does not appear.
> There are countless fables about record company executives dropping by the mastering studio to hear the new hit in its finished form.
There are, but equally, there are tales of real genius among record company bosses too. Here's an awesome example, which I read in soundonsound a few years ago. From an interview with Giorgio Moroder on how he created the disco single "Love To Love You Baby", and the instrumental role of record boss Neil Bogart:
> This then provided us with a four‑minute, metronomic beat that had a kind of groove going on, and that really was the origin of drum machines, and the thing that enabled us to stretch it to a 16‑minute version, kept in perfect time, when Neil Bogart requested it.”
> According to Moroder, it was on a Friday that Bogart called him, at about three o'clock in the morning LA time, ecstatic over the number and insisting that it should be extended to cover the entire side of an album. Bellotte fills in the details...
> "Bogart was having an orgy at his house, there was a lot of coke going on and, to use his own language, they were all 'f*cking to this track' and the crowd there had him replay the song over and over again. Suddenly, a 'Eureka' thought hit Bogart; he recalled 'In‑A‑Gadda‑Da‑Vida' by Iron Butterfly, which had taken up a whole side. In a flash he came up with the idea of doing the same with 'Love To Love You Baby' and he needed it within a week. So we just proceeded to get down to it on that weekend, and since things always went very fast back then, within the week he had what he wanted.”
....
> The last song on the album, recorded in two to three hours and designed to transport listeners into the future, 'I Feel Love' would quickly become a gay anthem, not least because of Neil Bogart's astute marketing, while topping the UK singles chart and climbing to number six on the Billboard Hot 100. However, it was considered to be nothing more than a filler when the record was finished.
>"We never thought of it as a stand-out track, we just thought it part of a good album,” Bellotte comments. "However, when we sent the album off to LA, Neil Bogart called back straight away and said, 'The single is 'I Feel Love', it needs three edits and these are the edits.' Doing these immediately improved the fluidity of the track no end. He was that kind of a record man. And, of course, those edits no longer exist, because they would have been sliced from the quarter‑inch master and simply thrown on the floor. That's how it was then. If you ever did any editing, the floor was cluttered with all the stuff you didn't use. We never saved anything, it was just discarded. However, because of his uncanny feel for the music, Bogart knew exactly where the track should be edited and, of course, the improvement was fantastic.”
One of the aircraft in the US Presidential fleet, SAM 970, had a fake temperature control knob on the conference room desk. It was installed for then-VP Johnson, who was something of a control freak and who kept coming up to the cockpit to fiddle with the temperature. (The knob actually sent a signal to the pilots, who would adjust the temperature in the general direction that LBJ had tried to adjust it.)
Not to mention that obviously Johnson was aware of how the knob worked. And I find that it's funny that people think that a Vice President can't get temperature adjusted to his liking and should or would play games with him. "Oh there he goes again" type of thing. I don't think you get to be in a position of being able to fly a President or Vice President of any country by having an attitude and not being fully respectful of those in power.
No, he wasn't. It was intentionally put in place to deceive him, and the deception worked.
> "people think that a Vice President can't get temperature adjusted to his liking"
Most VPs could get the temperature adjusted to their liking. Johnson was a special kind of control freak. He liked to make people uncomfortable by making it extra hot, extra cold, walking around naked (it's why he replaced some of the solid bulkheads with transparent plexiglas), raising the hydraulic table and his hydraulic chair so high that people at the table looked like children who could barely reach, and so on.
The Air Force crew got sick of his being in the cockpit, and they didn't much care for those antics, so they gave him the fake temperature control. No, he didn't know how it worked, and no, they didn't make it as hot or as cold as he wanted it to be, they just went along enough to keep him from making trouble for them.
> "not being fully respectful of those in power"
How many Air Force Colonels do you know? They'll give a guy the respect he earns, but they're not known for their willingness to defer to LBJ-style bullshit.
[One of our volunteers was the plane's crew chief for most of a decade. We got a lot of interesting inside stories on slow days.]
However as another commenter pointed out the "phony" switch worked.
Plus according the the above book not only did the crewman adjust the temperature when he saw the light flash, but Johnson felt the temperature was adjusted.
The idea here is not whether or not Johnson understood the technology. But I find it hard to believe that a man who is vice President of the United States is so easily duped. He asked for a switch to adjust temperature and he got a switch that could adjust temperature.
Despite the fact that "one of our volunteers was the plane's crew chief" do you think that it's at all possible that the story was somewhat embellished for effect? (Not saying it was but we are not talking about sworn court testimony when someone relates something that happened many years prior, right?)
> "I find it hard to believe that a man who is vice President of the United States is so easily duped"
You don't think highly-ranked Air Force officials can pull off a deceptive trick like this? They couldn't give the VP a switch, lie to him about what it did, and then manually mimic what he was trying to do but to a lesser degree? (They would also sometimes start with a large effect and then slowly return the temperature to normal.)
> "do you think that it's at all possible that the story was somewhat embellished"
We had multiple sources for this particular story.
Another version I've heard of this is with film censorship - apparently when Hitchcock made Psycho, the film censor (I think in the UK - the BBFC) wouldn't give the film a certificate because it was too extreme for the era - too much nudity, too much violence - and suggested a few cuts to just trim back some of the offending shots.
Hitchock said of course he would, took the film back, and sat on it for a couple of weeks. He later sent back the 'fixed' version, and the censor was much happier with the 'changes' and certified it for release.
There is a story that when the animators of Avatar The Last Airbender were working on the Beach episode, they knew that if they drew the outfits the way they wanted, they would be told to tone it down. So they drew everyone in outfits far too revealing for a children's program. When, as predicted, they were told to draw something more conservative they went ahead and animated the scenes the way they originally envisioned them. The censors, satisfied that they had done their job, accepted the revised scenes.
Building company wants to build a 12 storey block of apartments somewhere, but the locals will object to pretty much anything.
Initial planning application goes in for 42 storey block.
Locals up in arms demanding it be reduced. Big protest campaign launched.
Delays and then a revised planning application for 28 storeys.
Outrage (but less vociferous).
More delays and eventually a revised planning application for 12 storeys.
Little complaint, planning application successful.
Matt Parker and Trey Stone, the creators of South Park, did the exact same thing when making Bigger, Longer, and Uncut. Put completely ridiculous over-the-top NC-17 stuff in there, get it rejected for those parts, and keep the iffy stuff.
Any stories with this happening? Seems unlikely to me because you can't be sure the same person is reviewing your app. Also developers seem to rarely get specific feedback for a rejection.
This is something my friends did on a software engineering class. They were tasked to draw a set of complicated diagrams modeling a software project. When they gave the assignment, the PhD that was grading them said it's wrong and needs a lot of corrections and told them to come back next week with a fixed version. They didn't change anything and just gave the same version again for grading. Instant A.
I had a teacher telling us to change a 120 pages long document back and forth three times. The third time we showed her the hardcopies with her revisions and hand waved it away, trying to gaslight saying it wasn't her handwriting(!). Same person saying that the hardcopy we had of the OMG.org specs[1] was wrong (same class, I believe it was a different day) because she wanted Use Case Diagram[2] didn't have arrows denoting directionality (Use Case Diagrams do not have directionality, they just represent interactions). It's one of the two teachers I've ever walked out in the middle of a class in my life.
(The other was one in an engineering thesis orientation class where one of the "teachers" said that "everything that could be invented has already been invented". I walked out immediately, followed by a few other people seconds later after some other comment.)
Huh, teachers. I had one teaching computer architecture who treated Linda Null's book as a Holy Bible of the course. She liked to correct students by saying "you're wrong, you haven't read Linda Null, go read the book". It was fine until the point when she disagreed with what someone wrote on the test - and when that person has pointed out that it's straight from the book, she shrugged and said, "well, Linda Null is wrong". sigh
I think it was somewhere in middle school where I had several teachers who insisted that there had to be corrections made between a rough draft and a final draft of a paper, because thirteen-year-olds were obviously incapable of getting anything right the first time. I would write a paper, save it, introduce a few typos, submit that as the first draft, then submit the original a few days later when the final draft was called for.
That reminds me of an English paper I had in freshman year of high school. Final grade on the rubric: 6/6 for each category, but 3/6 for "revisions" because I didn't change anything. Final grade B-.
Or how Hitchcock had the ratings board watch his famous Psycho shower death scene a second time unchanged and get the thumbs-up when it didn't pass the first viewing.
I'm sure history is sprinkled with many such interesting stories.
Trey Parker and Matt Stone did the opposite with the South Park movie. Each time the MPAA objected to specific instances of curse words, they returned another version with those specifics removed but more added elsewhere. The final product was much filthier than even they intended.
This is something I admit to doing while driving with my kids at times, when they ask to e.g. turn the volume of music up/down and I think it's just fine the way it is. I'll turn it down a few clicks, then turn it up to what it was before.
Works for dinner too... tell them you're having something they detest for dinner and then gradually dial it back to things that are less detestable and then cook what you were originally going to cook and they'll accept it without complaint :P
a film editor instructor liked to rag on director's wanting a frame clipped here or lengthened there, arguing they couldn't possibly know when something was a single frame too long or too short. He would solve this by hitting a few keys on the keyboard that effectively did nothing, then show the director the same cut. Inevitably they would always remark how much better it felt, not realizing no change was made.
I forget the name of it, but a pro audio company used to sell a very impressive-looking piece of rack equipment with several imposingly-titled buttons and sliders but which had nothing inside, whose sole function was to serve as a placebo for unwelcome meddlers.
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.
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.
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.
Even if you specifically aren't the idiot (though I often am), never spend your time working around the idiot. Any time you work around an idiot, you've done more work and the idiot will still be there...
I think that you don't really understand the duck until you are unlucky enough to work in a situation that is dysfunctional enough to warrant it. I hope you never do, stranger. I agree with your sentiment as an idealist, but my experience in some deeply deeply dysfunctional situations suggests that the duck can sometimes - when used judiciously - be the tool you need.
I've been in some pretty bad ones (USG software dev) - I agree that sometimes you might need an emergency duck, but that's when you need to start looking somewhere else. If they're crazy or dysfunctional enough for more than an occasional ED, odds are that they'll break you or fire you eventually.
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.
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.
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.
"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.
I'm glad I'm not the only one who found this approach childish. Adding "ducks" has one of two outcomes:
-Best case: Someone sees your duck and you've all wasted time adding and then removing it.
-Worst case: No one notices your duck, or maybe even likes your duck. You now have a sub-par creation.
Instead, try communicating. If you think a change to your work is bad, say so. You might even learn something about a manager/PM's reasons for adding and removing things. They might learn something from you if you communicate your reasoning well. If your managers aren't open to discussing projects, find a different job.
But why does it sound like cheating? If the manager is not susceptible to this phenomenon, then they will let the duck stay. Why does it matter either way? It just makes any revisions easy if the manager is prone to this effect.
We none of us are perfect, we all have our flaws, but being tricky is not something we need to do; at the very least, it's not something I would wish to spend any time in my life doing.
Yes, overall the approach of adding ducks smells pretty passive-agressive. In an ideal world I suppose the "duck-adders" should have enough authority to push back on questionable changes. It is unfortunate that so many people identify with the need for these tactics. I wonder if the "nit-pickers" in authority are just randomly distributed, and we only see the bad instances (i.e. there is no particular selective pressure on them). Or if we're seeing another manifestation of the Peter Principle of those in authority. Or if the duck adders are somehow self-selecting to be in a position of avoiding responsibility by not being assertive enough?
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.
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...
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. :)
> 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.
Is that the point? Or is the point that some developers/designers don't like to get edited, so they tell themselves that their PM is pathological?
There's more than one valid perspective on things, and in my experience professional relationships work better when everyone realizes that.
Nobody is saying to intentionally put things wrong into the software in order to get your attention on the wrong things. They are saying that there are people who will ask for changes when there isn't value to them, but only because it allows them to make a difference.
I've seen cases where people have completely ruined products in ways like this. I don't think that anybody is actually saying that "broken" / "poor" features should be added just to be removed... Possibly unless you have been working with one of the people who require you to change things without unreasonably.
I think the fact that you started off with the assumption that the PM is competent illustrates the inherent entitlement problem with a lot of PMs in the software industry. Yes, PMs are highly important roles when done right. Companies who imitate companies that are successful (and who hires great people) picks up the PM role without picking up the culture of building good products or the hiring practices ends up with PMs who think they're competent and superior by association with the role they're in and that their opinion about who is competent is relevant.
I think that the point is more that everyone has bouts of incompetence now and then. Sure, some more than others, but it happens to the best of us. Doing something intentionally stupid and manipulative in the name of competence seems counter productive if not paradoxical. It also smells of narcissism and an inability to look at what might be a larger picture.
That's my experience with the type of person who tends to pull this sort of thing.
This isn't meant to apply to managers who actually know what they're doing and don't always have to make a change just to look like they're contributing. If you're competent then the developers probably won't feel the need to do this.
If you interpret this to be about "avoiding criticism" instead of as a counter-reaction to meddling, clueless middle management eager to justify their job position at a cost on employee time and product quality, then you're likely to be part of the very problem ducks fix.
There are plenty of incompetent managers and consultants who justify their existence by demanding pointless changes. If one of your subordinates is putting obvious ducks in the product, perhaps you should reflect and decide if you have a history of micromanaging.
The duck is not something that is/should-be used often, and it's not to be used with a competent manager.
It's a last resource action.
It means you as a manager are unqualified to manage the project and any idea you have is perceived as a waste of time by the employees, and you make them lose time, in fact, you probably already have a track record of meaningless changes and many man-hours wasted only to satisfy your tiny ego.
Also, in that case your own opinion is as meaningless as the duck.
Taken literally this is pretty bad. Wasting time to placate hands on incompetent managers is not sustainable. This is also why design by committee fails - everyone wants to seem like they have some input.
The reality is this always exists to a degree. Politics exist. It can be hard to come up with an objective definition of best, especially around usability. (A/B testing helps, but only so far) So one has to learn how to do the politics to get things done.
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 - everyone 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.
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.
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.
Zawinsky's classic quote "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.", was apparently based on military humor where the serviceman thinks to ask an officer...
Reminds me of an application that models program states, looking for deadlocks and stuff. The program had a button which made the entire monitor go black until you pressed a key or something. No value or connection to the programs purpose whatsoever. I guess the author added it as an experiment.
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.
They know. They just think you're bad at working the slicer and don't want to make that interaction an ordeal. That's what I've thought every single time I say "thinner" and they come back and it isn't thinner.
Yup, I like really thinly sliced meat, but I don't want to be a jerk, so if after asking once for thinner I see you've done nothing I'll just ask for half as much and come back later. I might also say something prissy like "that'll have to do" or "I guess", so we both know I know but I'm not gonna call you out on it.
This is what happens to me too. I feel bad for the wasted cold cuts. So I'll give them two tries, one attempt and one adjustment, next time I'll wait for the person who does it better.
Which means less work for wambotron. Assuming that wambotron was paid hourly and not on commission basis, wambotron does less work for more pay, which is effectively a raise.
You (and parent commenters) should keep asking for thinner until you actually get what you want. Yes - let it take 15 minutes, if it has to. You're the one who's paying. The feelings of the employee are irrelevant - he has a job to do. The feelings of the people behind you are irrelevant - you waited your turn, too.
You can call it by some strange name, but I don't call bread "wheat that was harvested" or pie some outrageously long list of ingredients.
I understand your sentiment, particularly in the context of waste. Honestly I think you're probably not correct, anyhow--I imagine GP feeling roughly just as bad if the waste was a non-animal food product. If I were speaking for myself, I can say that I would.
I would imagine most people are either okay with animals living in X condition and then killed, or not okay with animals living in X condition and then killed. Why does it matter what you do with the corpse?
In the same way I think it's not productive to call an animal that will killed "cold cuts", I don't think it's productive to refer to a living animal as a "renewable resource".
Also implying that you can kill and waste as many of them as you like simply because you paid for it is not productive either.
In all honesty, it's disappointing to see people refer to living creatures this way.
I feel like the distinction between active killing and passive killing is overblown. A lot of things die simply because I exist. If it was a top priority to minimize it I wouldn't eat meat at all.
I'm not trying to be insulting by calling things resources. Even the most important things like time are renewable in some important contexts.
Waste is not productive by definition, not sure where you're going with that. It's bad economically but not morally.
To get to the important part, I want animals to live without suffering. But cold cuts can't suffer.
If someone asked me for it to be even thinner, I would change it. The thing is, the default setting is REALLY THIN. If you want it thinner, it becomes transparent. It ends up taking FOREVER to slice because it just shreds to some extent. It's no longer slices, but a pile of shredded meat.
I don't get it. So the total transaction ended up taking as much time as if you had made a thinner slice, but you actually lie to the customer? You haven't trained the customer to stop asking for thinner slices, thereby speeding up the whole process, you've just maintained the outward appearance of the same, inefficient process, while also not really improving the internal efficiency. Why didn't you just start with a thicker slice, if you knew they'd always want thinner? That way, at least you wouldn't be dishonest.
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)
Quite true. Or they may be hesitant to be push too much. Or they might just mentally note to not come this way again. All feedbacks need not be verbal.
In the case of managers I think it reassures them. If the product was good enough before they got involved, that means they weren't actually needed and that's not a cool feeling.
That's another thing I forgot to mention, many people just don't want the first slice because it's been sitting out for a while. I don't fault them for that.
I imagine there's lots of reasons. A girl I dated would only eat very thinly sliced meat or very specific cuts of chicken.
I tried for a long time to come up with a set of rules that would account for her preference, and eventually I came to: no obvious evidence that it was an animal. No bones, veins, ligaments, fatty areas, etc. Also a good texture, no slimy meats.
Her preference was that turkey they cut so thin it's almost fluffy.
I heard she got over that while she traveled, and now eats all manner of meats.
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.
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.
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.
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.
it's real. it usually happens when i working on mobile apps for big companies. apps are comparably new (compared to websites, desktop apps or server software) and for a lot of customers these are the first apps they launch. so new and exciting! they want to be part of it, they have to be part of it. another reason is they're afraid of getting downsized if they're not working on (contributing to) N projects at once.
on a technical level they don't have to add anything to it, so it's mostly visual tweaks they're demanding; usually something they've seen in other apps (no matter if it was something that made sense on ios in a different context and we're working on android).
that's called bikeshedding.
if the project bombs they didn't really have anything to do with it (apart from that one minor change) - if it's a success they were an integral part of the team.
one project, we needed a notification sound. the product owner begged us to keep our mouths shut, take one of the default notification sound files and tell the others custom sounds aren't possible - because if the marketing department got wind of it we'd have to test a boatload of different files for different managers and wait another month for the notification-sound-committees final decision.
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.
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.
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.
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."
In this scenario, the "hairy arm" could also be considered a way of "thinking out of the box", of trying something that's totally outside how you normally create. Maybe the novelty inherent in that was attractive to the clients, if the work really was considered "bad" and not just different.
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.
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.
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...
Essentially, our daughter is much more likely to partake in an activity (be it eating her veggies or anything else) if she feels like it was her idea to do so. I'm not entirely sure if it's the choice aspect, or the preparation aspect (in other words, that she knows in advance what to expect).
We're careful to emphasize the sanctity of personal choice wherever we can, and to encourage her to make her own decisions based on an evaluation of her options (really, we're fine with her picking any of the menu options we give her; if she picks a gross combination it's hers to eat, not ours). The important thing seems to be that once she makes a decision, she becomes invested in it and is much more likely to see it through.
I probably shouldn't discount the preparation aspect, however. She eats much more of her lunch when she helps to prepare it (and thus knows what to expect when she opens it at school). Similarly, we have a countdown for bed ('bedtime in t-5 minutes! Bedtime in t-2 minutes!') that makes the transition to nighttime more or less painless.
My wife and I do something similar. We give our daughter (she's almost three) a few choices with most anything that involves a decision.
A trivial example would be that if we're eating something that is traditionally a finger food and she wants to use a fork. We'll respond "You can use your right hand or left hand, it's up to you." and it avoids the confrontation completely because she gets to decide. She chooses a hand and life goes on.
Another example is sitting in her chair at the table. She'll normally ignore me when I ask her to climb in her chair but the moment I put a decision before her of getting in the chair on her own or I'll do it for her she hops right up.
It becomes second nature after a while and for us it's been a lot less stress and a time saver.
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?
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.
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...
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.
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.
But you have to be very careful not to overestimate the person, and end up having him command you to invade France. Giving an artificial bad option can be a great move, but it's dangerous.
On that occasion the Appointments Committee put forward the names of the
Archbishop of York, the favorite of the church leaders but one who had
ruffled Mrs. Thatcher's feathers on other issues.
To try to encourage his selection, the second candidate was generally
regarded as unqualified. An old line evangelical, who thought the
Bible contained the answer to every question and who was known to speak
in tongues.
The Church leaders thought this candidate, George Carey, was too
bizarre a choice even for Margaret Thatcher. However, the Prime Minister's
anger was such that she decided to teach the Church of England a lesson.
George Carey became the designated Archbishop of Canterbury.
This reminds of a papal election, where all the cardinals voted for one of the least likely candidates in order to see how the other's were voting. The candidate then won unanimously on the first vote
It's often mentioned when extremist parties start to rise. People may vote in anger thinking there will never be enough people for this vote to matter.
That's usually a slightly risky move, but it upgrades to very risky indeed when the choices are presented to an antagonist who may well decide to be wilfully malicious and call you on your bluff.
If you click through to the original source, the Church had deeply angered Thatcher by criticising her policies extensively and finally praying for the argentinian dead during the ceremony celebrating the end of the Falklands war. After the ceremony,
> Prime Minister Thatcher was livid and quite vocal at the door of the Cathedral that day and vowed that she would never let a representative of the church embarrass her again.
I'm not surprised she decided to fuck with them and pick the crazy guy, she wasn't call the Iron Lady because she liked building steel plants (quite the opposite really).
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.
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.
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.
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.
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.
It'll only work if your buyer hires a terrible home inspector.
The last time I bought a house, the inspector worked for hours. In the end, I got a 14-page write-up, plus accompanying photos of any major defects and/or code violations.
This brings up the other problem I have with adding ducks (yes, I'm anti-duck). Humans tend to fixate on the obvious - the more obvious problems you have, the more we'll fixate on them. That's great if people are just meddling, and you want to keep them occupied, but it's horrible if there might actually be flaws of consequence in your work. Given that we often tend to think we're more competent than we actually are, trying to game the review process may keep real, serious problems from being fixed.
With my work, a lot of reviewers do love to hear themselves talk, but every so often they'll come back at you with really good, insightful stuff that I totally missed. I don't dare game them because I don't want to be putting out garbage.
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.
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]
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".
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.
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.
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.
>> 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.
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.
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.
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.
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.
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.
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.
>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)
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)
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.
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."
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.
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.
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".
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
Rough judgement. But given how clunky and janky that animation is, even by the standards of its day (oh yes I was gaming when Battlechess came out), I think in this case you’re right.
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.
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.
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.
http://www.globusjourneys.com/travel-stories/italy/michelang...