I thought I'd give my $0.02 worth on some of the questions raised.<p>> I wonder if any blind coders could comment on how they see programmatic flow in their minds eye?<p>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.<p>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.<p>> How do big companies that love doing white boarding interview blind people?<p>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.<p>> I think it is totally reasonable that a blind person could code, but how does a blind person learn how to code initially?<p>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.<p>> 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.<p>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.