My counter-argument to voice-driven coding has been primarily around the input bandwidth and the fact that you must work from home with that kind of setup.
I guess the presenter conducted the "faster than the keyboard" test under very controlled circumstances (e.g. only working on his own code, so one doesn't have to deal with non-english-word variables/functions).
I don't mean to be a hater, because that was an _amazing_ demo, but I don't believe it's the holy grail the title implies it is.
It is a limitation, but when your other choice is "not working at all, pain, depression, despair" having to work at home is the least of your problems.
I have a grimmer point to make: Working out of crappy half-assed "startup incubators" with lousy desks, lousy seating, and an atmosphere flavored with stress was a direct contributor to my own RSI problems. You might not want to wait until you have symptoms to conclude that having an actual desk and some quiet is a good idea.
A high-quality headset, maybe even with some noise-canceling features should work okay, too. It wouldn't be that much different from a call center, and those don't usually get their own offices, either.
Sure, not the ideal, distraction-free environment, but neither is a cubicle farm.
Really, Dragon can't cope with someone sitting ten feet away and speaking at the same time? So I guess no listening to radio, either. Is it just the specifics of speech or is it that noise sensitive.
Maybe someone should do some kind of voice rec "groupware" then, where the relatively louder results of the other person are used to filter out false positives on my end...
The mic I used in the video can actually cope with very noisy environments. With lesser mics, speech recognition is useless with even mild background noise.
Mentioned this on HN previously but as a nearly 40 year old developer who has been developing professionally for nearly 20 years -- it used to be the norm for programmers to get their own offices, even just the regular joe programmers... Places really tight for space might put two guys in a very spacious shared corner office...
A few years into my career the idea of cubicles caught on and quickly became the norm, and now of course we're stuck with these horrible open offices that are, in my experience, just absolutely dreadful for productivity; but since everyone is doing it nobody really notices anymore.
> A few years into my career the idea of cubicles caught on and quickly became the norm, and now of course we're stuck with these horrible open offices that are, in my experience, just absolutely dreadful for productivity; but since everyone is doing it nobody really notices anymore.
You can largely thank Jim McCarthy of Microsoft fame for that, who in the mid 90s coined the concept, "beware of a guy in a room":
it's funny. The place i'm at now, in the valley and a successful post IPO SaaS company, management believes that open space and engineers running around, yelling and waving hands is sign or productivity.
I have to escape to the kitchen to get anything requiring the tiniest level of concentration.
Yep. The difference in one role (management) the conditions you're describing read as signals of activity. In the other role (development) it reads as noise interfering with the activity you're working on.
A "successful" company probably already has a culture that's going to be hard to change, but where management is trainable, you can sometimes improve things by giving them something else like else to focus on, like commit logs, test suites, or ticket updates.
Glad you bring that up. I'm a manager. I do mostly the things you mentioned to give my team some breathing room, and have to WFH when i want anything serious done.
As you can imagine if the ambience is bad for me, it is horrible for my team. I try to help with some WFH days here and there. But it is a culture thing. It's in the freaking DNS of the place. Only so much i can change.
>My counter-argument to voice-driven coding has been primarily around the input bandwidth and the fact that you must work from home with that kind of setup.
I wonder how long it will take for reliable subvocal speech reading a-la [1] to become available in consumer products. It could potentially solve not only this problem but a lot of problems related to the use of cell phones in public spaces.
I guess the presenter conducted the "faster than the keyboard" test under very controlled circumstances (e.g. only working on his own code, so one doesn't have to deal with non-english-word variables/functions).
I don't mean to be a hater, because that was an _amazing_ demo, but I don't believe it's the holy grail the title implies it is.