When There’s an Audience, People’s Performance Improves | Hacker News Reader

When There’s an Audience, People’s Performance Improves

hopkinsmedicine.org

162 pointsspking46 comments

The research on this is not new, and it’s not as simple as this. If you give people a task that’s well-rehearsed for them, that they’re good at, they’ll tend to do better. But if you give them something less well-rehearsed, something that’s “hard,” they do worse. I wish I had my psychology textbooks on hand for the references, but a lot of this stuff isn’t obvious until after-the-fact.

The full name is the "Yerkes-Dodson Law of Social Facilitation." It's this idea that a task requires an optimal amount of nervous system arousal. Too much and you get jittery, too little and you get lethargic. So it looks like an inverted U with the optimal performance at a middle level of arousal.

Although you're right it's more complicated. If you're an expert at a task, then you do better if you have increased arousal. This is because stress hormones cause new synaptic production to slow down and old networks/circuits to increase in their conduction/strength. So if you're an NBA player, and it's the playoffs, you're going to be better than normal - because you're an expert at the task.

If however the task is 'complex' (like, say, software development) then if you put pressure on people (or if they're putting pressure on themselves), the performance falls significantly. I forgot the name of the study, but this was shown cross-culturally. They gave poor Indian men (in India) 3-months salary to solve a decently straight forward lateral thinking puzzle. The men who got paid performed way worse, then the other men who weren't paid at all.

Sometimes that strikes me as oddly familiar. Paying someone to do something they love and putting too much pressure on them makes their performance degrade.

The highest pressure situation I was in was for fed gov approaching deadlines having missed milestones. The more pressure the put on, the calmer and more relaxed I became. Everything worked out fine in the end because the managers didn't understand investing in developing a framework. When that was done all the apps came together, more or less with outliers needing more exceptional additions.

Is it that simple? It certainly does not fit my experience. I type code for a living and have for 30 years so I'm clearly well rehearsed but I can't type well when being looked at.

This is psychology, there are always exceptions. Personally I don't have problems with the act of typing when being looked at, but I do have a tendency to get nervous to the point I'm having trouble speaking. Only happens with crowds I'm not familiar with though. But I know enough of sociolog/psychology to realize that doesn't mean any of the claims made here are false for the general public, or even for me in certain situations. I do have the impressions I'm sometimes better in sports when people are watching and/or cheering.

Perhaps that is not a performance, in the same sense as other stuff. e.g. do you get a bit of adrenaline kick in, are you motivated to impress them with your keyboard skills, etc?

Makes sense. If you know it you might want to show off. If you don’t know it then you’ll be nervous.

For improving work you're good at - maybe not showing off, maybe people just avoid complacency/shortcuts, double check everything if they know their work will be checked. Like the value of code reviews that don't find any bugs.

Interesting results, though I do wonder if this may be one of those situations where the results depend significantly on the individual and their personality.

Don't like to use anecdotes, but still... I'm definitely someone who has a breakdown whenever having to do something with the possibility of an audience, let alone a live one. Fine doing something off camera, completely screw up whenever a capture card or camers is anyway in the vicinity (and hence end up having to throw out tons of failed recordings).

The results could also depend on the circumstances of having an audience. I would not expect the same processes to govern: 1) Me performing music at a professional level in front of an audience; and 2) having a manager watch over my shoulder while I make mistakes.

There’s actually a gene associated with this very thing.

How in the world did this get downvoted?

I don't fully agree with the article. As someone who has gamed in front of many audiences before, it can absolutely make you screw up. Specifically when it mentions performing well in front of an audience acting as sort of a mental stimulant for reward. I think it also depends heavily on where the audience is. If I'm in say a room with just my team and sound proof headphones, you are way more focused and play more like you normally would. If someone is standing over your shoulder, you start to do things you wouldn't normally do, whether it be to speed up the match to not bore the observer, to try an hit a cool shot, etc. The nature of the action being done has to be one of the most influential factors. In a gaming environment where no two matches are ever the same, you can't go off of rehearsed actions because they won't work in all scenarios. Therefor, when in new situations where you're trying to adapt on the fly, that's when you start trying to get fancy for the audience and ultimately make sloppy mistakes. However, if it were something that you can use rehearsed actions on, like coding, then the pressure might not be as intense as to make you mess up.

> In a gaming environment where no two matches are ever the same, you can't go off of rehearsed actions because they won't work in all scenarios.

Even with routine muscle-memory tasks like combos in fighting games, "tournament nerves" are blamed for errors.

I wonder, could this apply to open source? Do we build better code if it's open source because it has more of an audience?

I saw it happen to me. At work I wrote some libraries, which would be seen by just a couple of coworkers, and I thought I worked hard on them. Years later I wrote a small JavaScript function to put on Github, and I just couldn't leave it alone, cleaning it up, tweaking it here and there, knowing that smart people from all around the world might see it and judge me by it.

Half of my personal projects are set as private because I am afraid the code is not worthy

I have an open source project that got quite popular lately, and I can tell you that I just spent 100+ hours to add 2 lines of "code." No, they were not code, they are two lines of configuration to make a piece of hardware work. 100+ hours. Two episodes of headaches. Two new pieces of hardware purchased out of pocket. Two weeks of waiting. From kernel driver code, dkms to ALSA. Pages and pages of manuals. Asked for help on tons of places from forums, reddit, github, emailed, only a few suggested what I already knew. No one knows the answer. Two lines made it work, and I had to figure it out on my own.

That's the level of optimization that I have been doing with a project that has only hundreds of users but are building momentum for something I believe in. I know people will need it, use it, and enjoy it, and it teaches me things.

I certainly wouldn't have done so if I knew it only affects one or two users.

This is fascinating! Would you please share the link to your project and the 2 line commit?

Here is the project: getcrankshaft.com

It makes a Pi an Android Auto head unit. Google expects the head unit to have a microphone to support voice input. Although technically the phone can use its microphones, but we can't expect Google to help us lifting that (artificial) limitation. It's a RE'd protocol and app. What will we say to them? We made this Frankenstein totally-unauthorized reverse-engineered distro that sorts of encouraging people to DIY their car hardware so they can use Android Auto and it totally won't cause you troubles if anything happens to the users. Please help us by allowing the phone to take microphone input for OK Google on Android Auto?

So, in short, we need a microphone for the head unit. The Pi doesn't have built-in support for microphones. So I wanted to support the Adafruit MEMS mic which is a very simple and cheap mic that works on the I2S bus. Otherwise, we would have to buy a USB microphone/an expensive DAC and waste another USB port to achieve the "OK Google" functionality.

Using the USB mic/dac means we can't realistically use a Raspberry A+ and Zero either, because we have to use the only available port for the phone connection, not the mic. That I2S mic is $6, the BOm is perhaps $2 and thus can be easily integrated into other boards.

The problem: Low volume. It needs something called the ALSA softvol which boosts the volume level for it to work. But I couldn't figure out how to implement a volume boost for the mic. I have documented the behavior here: https://github.com/htruong/snd-i2s_rpi. Adafruit's solution to boost the volume for ALSA programs: https://learn.adafruit.com/adafruit-i2s-mems-microphone-brea.... Too bad it doesn't work with applications that expect the microphone to work out of the box, and anything that uses pulseaudio doesn't work either. Without a configuration that works out of the box for Pulse, we can't say we support that configuration. We can't design a cheap hardware that will have the mic integrated.

I have tried to look at the kernel module code and see what I could do. I have looked at a number of other sound cards to see how they implemented it to fix it from the source -- and still got stuck. Along the way, I made the module DKMS-compatible, planning to push the code upstream to the RPi kernel. I have bought additional DACs to see if I could learn anything from them, and see if is there any way I could come up with a simpler/cheaper DAC hardware. I have asked for help. I have emailed people to see if anyone knows the answer.

I tried fixing ALSA.conf for like 10 hours to make it take the "boosted microphone" as the default mic. It sort-of worked for ALSA programs, but it broke Pulse. Which means I got back to square 0.

Turns out I can neither easily fix the hardware nor the kernel driver nor ALSA.conf. It's just Pulseaudio that needs two lines of code for it to use the mic with boosted volume.

2-lines solution: https://github.com/htruong/crankshaft/blob/master/hardware_s...

Looking back, fixing Pulse seems like the obvious solution to take, but somehow it didn't seem that way to me when I faced it. For me, to discover every single paragraph I wrote above, it took me at least 5-10 hours each. The hindsight is 20/20, and you can say someone who knows Pulse would know that's the obvious answer. But I didn't know Pulse - I needed to learn linux driver, i2s, rpi, alsa, kernel, pulse all at the same time to come up with that answer.

If I ever get to 1000 people on this planet to adopt my software, then I think that'd be somewhat worthy. I'd argue that I will save each of them at least $4 compared to buying a USB DAC+mic, so that's $4000 saved. Which gets me to $40/hour rate... :)

Yes, but for different reasons. If I write a small tool for myself, I'm willing to live with some idiosyncrasies. But if I'm Going to release it to the siteId, then I need to fix those issues. It is the 80-20 rule. I'm willing to do the 80% for myself, but a release takes the other 20%. I don't think this has anything to do with open source. Just whether you will release the product to the world.

I've noticed the same. Code for me - if there's a weird bug but there is a workaround, I'll probably just use the workaround. Code that others _might_ use - I'll fix the bug, and often end up with better (structured) code as a result.

I write better open source code because I take as much time as I like to feel satisfied with the result, which isn't an option in a proprietary corporate setting.

Although having an audience also motivates me to keep my standards high for what I'm satisfied with.

Definitely. I spent a while in a context where we did pair programming (with frequent pair rotation) and continuous delivery, so that every commit went live if the tests passed.

I loved both of these. The pairing and collective code ownership helped me keep things in good shape even when tired. Any mess I made wasn't something I could clean up when I got to it; it would quickly become everybody's problem.

The continuous delivery did the same thing on a product level. It eliminated the mystical time of "before release" where in theory something might get fixed. If we committed code, users would see it.

I think the answer to that would be no since we've seen that Open Source projects contain the same amount and type of errors as most proprietary code.

With exception of few large projects, you can be fairly sure no one will look at your code. And in a work, people you do know are pretty much guaranteed to look at your code, one way or the other.

This might however be argument for code review.

It probably does, but to my understanding it’s a QA effect. If you know your work will be reviewed by an “audience” you are likely to deliver better results.

Basically about 75% of being a manager. To be an audience.

On guitar, it's only if I practiced first :D otherwise it seems to have the opposite effect

I think I bombed the first 10 times I was on stage.

On a semi-related note... I started a new instrument this year... I've been taking a video every week. My first video is absolutely hilarious. This method is really encouraging, it's really easy to see progress

I'm a reasonable tennis player. I've noticed, if someone's watching (especially an attractive girl), my effort and concentration seems to increase. Sometimes this results in me playing out of my skin and hitting shots I didn't even know I could make! Same with snooker, at which I'm distinctly average. If someone's watching, I've often knocked in a pot from 3 meters away, but in practice, it's a shot I'd make 1 out of 50 times. Strange!

Reminds me of this (awesome) song..

https://youtube.com/watch?v=SoCn9HBvlJM

I can't play 'cause I need a reason

No one here that I aim to pleasin'

There's a joint next door and I hate to barge in

But I play better with girls watchin'

I've noticed this in real life. If I run in the city I push myself harder than if I run in a more remote park. Further if I run in the city along a route popular with other runners I'll run even harder (the stats provided by my running app also backs this perception up).

On the one hand, writing code on a white board in an interview should be easier, because I have an audience.

On the other hand, I don't normally write code on a white board and I rely on the IDE to correct my syntax (and other) mistakes. So white board coding is a more complex task than my normal coding. So white board coding is harder and I do it more poorly.

On the other hand, if nothing is at stake, if it's just a friendly discussion about how to do something, among friends, I'm less nervous and it's more fun.

But if a potential job is on the line and I'm in front of strangers, it's more stressful and my performance suffers.

I don't know. What's the biggest effect?

With people working remotely and companies abandoning open floor plans, I think a lot of people might disagree. Privacy seems to increase productivity through lower distractions and stress, at least for me.

I think the more important audience for programmers isn't those who see your face but those who see your code.

Audience doesn't necessarily mean "live" and can refer to an understanding that others will be appraising or reacting to your work. There's no measurable external "audience field" generated by groups of humans that other people can detect.

That said, I realized that I tend to model the expectations of those viewing what I produce, known and unknown, and I always get carried away trying to satisfy criteria that I wouldn't if I were just doing a thing for myself. In person, it's more a test of social intelligence where subtle reactions help influence and guide my actions.

In a physical setting, I can work longer and harder without tiring when I'm a part of a balanced team, sort of a time passing more quickly with good company experience. However, I have literally hid in a closet after being surprised in a meeting and failed to play during a solo because I saw someone staring at me in the audience, though, so it's certainly not an absolute effect.

they are not mutually exclusive. you can do pair programming in a quiet private space too.

Related: https://en.wikipedia.org/wiki/Hawthorne_effect from the early 1930s

There are people who live stream their coding sessions on twitch/youtube. Here one talking about it (linked to the relevant part):

http://meow.noopkat.com/lessons-from-one-year-of-streaming-o...

It may still take time for people's notion of performance to gravitate to literal creative energy and to how the audience contributes and co-creates anything on a stage. In pragmatic artistic theories it's an obvious fact and art impossible without this idea.

Possibly related: when you have difficulty being self-motivated.

When you have a deadline, at which time someone will look over your work, it's similar to having an audience.

i think this is a strong case in favor of pair programming.

Is this also the case in the boudoir?

... they clearly did not have people type simple things into a computer with somebody standing over their shoulder.

Reply on news.ycombinator.com