Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hopkinsmedicine.org

Post reply on HN
Print view View original

21–30 of 47 posts

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

#21

Post by stordoff »

chrismcb wrote: post #8
blakesterz wrote: post #2

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?

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.

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

#22

Post by codetrotter »

lambdasquirrel wrote: post #9

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.

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

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

#23

Post by wpietri »

blakesterz wrote: post #2

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?

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.

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

#24

Post by wolf550e »

codetrotter wrote: post #22
lambdasquirrel wrote: post #9

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.

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.

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

#25

Post by bajablast »

combatentropy wrote: post #6
blakesterz wrote: post #2

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

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

#26

Post by pavelromashkin »

blakesterz wrote: post #2

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?

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.

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

#27

Post by jimmies »

blakesterz wrote: post #2

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 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.

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

#29

Post by montecarl »

jimmies wrote: post #27
blakesterz wrote: post #2

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 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 h…

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

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

#30

Post by jimmies »

montecarl wrote: post #29
jimmies wrote: post #27

Earlier quoted context omitted.

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 h…

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... :)

Post reply on HN