Even worse, there begins to be a notion that hiring someone with a disability is a charitable act, rather than just making a hiring decision based on their competence for the task. It seems like that would be kinda soul-crushing to always wonder if you were chosen for reasons other than your abilities.

I've seen so many interesting/disappointing behaviors from people when it comes to people with disabilities. Once I was helping with an event that was organized and led by a woman with cerebral palsy and in a wheelchair. Media showed up to cover the event...and kept trying to talk to me about it (the able-bodied white guy who was mostly there to handle technical stuff and had very little interesting to say about what the event was about), even when the organizer was right next to me and clearly bossing people, including me, around. She also has had difficulty finding regular work in the past, despite being really impressive in a lot of areas.

I'm kinda just ranting here, as I don't have good solutions, but I do think it'd be cool for folks to stop assuming that just because someone can't work the way most folks work they can't do the same kind of work. There have been blind developers (that I've been aware of) for about as long as I've been using computers (and that's a long time). We should stop being shocked by it; though it's cool and impressive, it tends to lead to thinking they might not be able to do the job as well, just because they're doing it in such a different way.

One of the best choices that we ever made. We spend a lot of time on getting it right in our sites and have spent many hours in NVDA & VoiceOver with our eyes closed.

It's unfortunate how poor the experience still is on most websites and I wish our industry would spend a little more time trying to get this right. If you aren't using Semantic markup and ARIA, please start now.

You can't imagine how much worse the user experience is on mobile vs a computer.

Essentially simulating the screen for the screen reader to work with, but not rendering the output anywhere (or even having the screen hardware to render it on). Just imagine how mind boggling it would be to see someone working at a coffeshop with just headphones on and the bottom part of a laptop, or at a desk with no screen on it!

I get that it probably don't make sense to manufacture a product like this, but still, would be really cool I think! :)

He was a great programmer, and very adept at using his screen reader. As far as I know, it only ever gave him one serious complication: since he was a minor, it was set to safe-for-work mode, and it read his coworker's name, a Mr Livshits, as Livsugars.

Prior to that, I also got 2 disabled interns - they are hard of hearing and verbal speaking. I got them working for 6 months, after which they got full-time jobs elsewhere. They were usually present in the 30+ team workshops and meet-ups that I do. I had to slow down, express more expressively with hands, etc. and things went pretty good. They did always comes back to me at the end, picking on few missing parts that I need to elaborate.

I also had a selfish motive - I wanted to learn sign language. I was able to understand them better but I think I need professional training to be proficient doing the sign language myself.

btw, this is all in India, a place where accessibility, disability-enabled stuffs are an after-thought, sometimes totally ignored.

Seriously? What kind of human beings do you think your readers are? Did anyone here really think about that while reading the story?

Maybe people who work with blind devs could also chime in.

Many blind musicians and artists develop heightened perceptions in their respective art and generate some unique, original works. I wonder if this is true for coders/ mathematicians?

> I wonder if any blind coders could comment on how they see programmatic flow in their minds eye?

It's all about the structure. I think of it like reading a novel with a complex plot - you meet some of the characters, learn facts about them, and then you get introduced to new characters, and later in the book you find out how they relate to each other, and much later on, you may find out through some twist of the plot that the relationship isn't quite what you thought it was, and you have to recreate your mental model.

As a result, I find that sometimes I'm slower at ramping up on complex codebases (especially if it's poorly written with no structure), but once I have my mental model, I'm potentially faster than someone who has to have things in front of them to refer to. This is purely based on my personal experience.

> How do big companies that love doing white boarding interview blind people?

I've always turned up with my laptop, and proposed that I use it, plugged into a monitor the interviewer can see. The interviewer reads me out the question, and I take notes. I always do the coding in Notepad, so I don't have access to code completion or syntax highlighting.

> I think it is totally reasonable that a blind person could code, but how does a blind person learn how to code initially?

The same way a sighted person would - since most information in this field is text-based. Read the tutorials, do the exercises. In fields where mathematical notation or diagrams are prevalent (e.g. machine learning), some sighted help or adapted material is probably required.

> Why the hell would you hire a blind coder to ship your feature by next week when you can find an equal or better (white/Asian male) engineer to do the same thing? By definition, the blind coder is limited compared to non-disabled people. It's a purely business decision. No hard feelings, but I'd rather not have a blind person on my team or organization. Unless it is for PR.

I respond to this comment purely because, whether I like it or not, such thinking is not uncommon. Let's rephrase the question as "why would you hire a {foo} engineer to ship your feature by next week when you can find an equal or better ({bar}) engineer to do the same thing?". Put this way, I accept that smaller companies who need someone next week will always choose the {bar} engineer, because they're better, not because they're {bar}. But here there is an assumption that every single {bar} engineer is better than every single {foo} engineer, which simply can't be true. Make sure your biases don't prevent you from hiring the awesome {foo} engineer, who out-performs every {bar} engineer. In a larger company, I'd go further and say that you need to have an inclusive work culture, not only because it's the right thing to do, but also because if your customer-base is diverse (which on the internet, it probably is), then a really good way to make awesome products is to have a diverse workforce.

- http://www.dogonews.com/2016/6/9/visually-impaired-srikanth-...

I just finished read all the comments above, and would like to share my story and my thoughts.

But since the comment is too long, I put it on my dropbox, you can found it here :

https://www.dropbox.com/s/h9dxozsrxz7wuqf/mystory.txt?dl=0

Sorry for the inconvenience, and thanks all ;).

Warm regards -- Herwin

To this day, I doubt I'd have the temerity and courage to work in this field as he did, and I have to say that I have immense respect for the disabled who overcome these disabilities and nevertheless remain extremely productive. It says something of a persons resolve that they are willing and able to write and debug kernel code, 1 char at a time .. I really don't think I could do it.

I myself have macular degeneration, which while not disabling right now, has started a bit too early in my life. One day I might be almost blind myself and I will definitely need this.

Does make me wonder about non-text based input / code display methods that can help here.

    Did we underpay him?"

I do take the blindfold off while checking my work an during some parts of debugging.

I wish there is a better solution here, but I don't know what it is. It does offer a good opportunity to make an impact though for any aspiring developers.

IN office, people did used to get curious I think but they mostly preferred not to ask me :)

Even more, some constant robot-like sound (of low volume) coming from the computer make them more curious as I usually do not prefer headphone.

Wut.

One could equally argue "by definition, an ex-vi user is limited compared to an IDE user" (I mean ex-vi.sf.net and that's what I actually use) - so much of development is about thinking, and the interaction method to provide the solution to the computer once you've figured it out is often almost incidental.

(on the upside, it appears the original comment asking that has been flagged to death, but FFS basic logic fail)

Herwin is visually impaired since birth so he definitely picked up coding with a screen reader. I have notified him of the comments here so he can share more of how he initially picked up coding himself. :)

(Discussion: https://news.ycombinator.com/item?id=8965048)

From the comments there, here's a fascinating example of how quickly a blind person can absorb information. 525WPM in this case: https://soundcloud.com/freecodecamp

http://stackoverflow.com/questions/118984/how-can-you-progra...

http://www.calit2.net/newsroom/article.php?id=350

Not to take anything away from this, because it is impressive, but a lot of people overestimate how much you need to look at your code while writing it. That's because we've gotten used to (if we are older programmers) or grown up with (if we are younger programmers) editors on big screens or in big windows that always show us a lot of our code.

There was a time when that was not the norm. Many programmed on teletype terminals or on 24x80 character CRTs that did not have cursor addressing (AKA "glass TTYs"), usually connected to the computer over a slow serial line (300 baud for a hardcopy terminal was typical). Text editors worked a line at a time. You could see whatever previous lines had not scrolled off the top yet. Best case, that would show you the line you were typing and 23 prior lines, although usually some of those lines would be showing editing commands you typed rather than lines of your code. If you wanted to see more lines, you had to type a command to tell the editor to show them, and they would come in from the bottom, scrolling prior stuff off the top.

In that kind of environment programmers tended to do a lot more of their work in their heads than we do now. Not as much as a blind person has to do, of course, but a lot more than seems feasible to the average programmer nowadays. Heck, it often seems infeasible nowadays to many of us who programmed back then. I know I wrote a lot of code in such environments, but nowadays I cannot figure out how the heck I actually was able to do that.

I'm not sure if we are actually better off now or not. We don't have to keep track of us much in our heads because our editors do it for us, so perhaps that frees up some brainpower to concentrate on more important things. On the other hand, maybe by keeping more of our code in our heads back then, we were able to understand it better.

What line did it segfault on, did the tests pass or fail, what state is the program in when it hits this breakpoint?

I suppose I could detect test pass failure with "echo \a" but it's just so terribly simple to view the results.

I rarely go more than 20 minutes worth of coding without recompiling/re-running tests.

Amateur. Real programmers don't even own a monitor.