To some extent your effectiveness is going to depend upon the type of development you are doing, the language, IDE and toolchain used or required for that development, and the team practices.

You may find it necessary to adapt your software specialty to be more effective. This may involve learning new tools and more assistive technology. Some jobs are also going to be harder than others with visual impairment.

Some advice that applies to all programmers whether sighted or blind; if velocity is the primary consideration in your work you are probably doing low skilled piece work. You might as well be a tailor running a sewing machine. For harder problems like building protocols, security systems, systems architecture, and a myriad of other areas your "speed" isn't dependent upon how fast you can type, how fast you can use an IDE or editor. The problems involve a lot more context and complexity than "piece work" programming and those are skills you can develop. You can and should still code but your performance won't be evaluated on how fast you can crank out code. Some people might tell you to try to become a manager. You can take that path if you want to but there are also lots of ways to continue to be an individual contributor if that is your preference.

Don't lose hope. There are many blind and visually impaired software developers doing excellent work gainfully employed, contributing to open source, teaching and participating in the software community.

Most blind people don't tab through elements. They use navigation quick keys (H for headings, L for lists, etc.).

You can set your screen readers to announce all punctuation. Some programmers use abbreviations like "lace" and "race" to stop "left brace" and "right brace" from becoming repetitive.

You can also set your screen reader to announce or play a tone to indicate levels of indentation.

Many successful blind programmers use refreshable braille displays, though this is by no means a requirement.

Not a software developer, but an analyst at a FANG company (I write a lot of code in other words lol). I'm legally blind and use a combination screen reader and Braille display--I also have a gigantic monitor that I use on 'good' vision days. I'm tired atm, but am happy to walk you through my setup and how I do things if you DM me. Almost 24 and I've been blind since I was a teen.

To answer some of your questions, yes, it really just is about practice. What you're feeling now sounds no different from how a junior developer feels when looking at a senior developer. What they do almost seems like magic, or at least so hard that you can't ever imagine yourself getting there. But yes, it's totally possible. Here is what has worked for me as a full-time developer:

1. The more you get familiar with your screen reader, the more you will start to crank up the speed of the voice. This will help make up for the extra time it takes to navigate a website. Also, that navigation time will also decrease as you get more comfortable with the tool.
2. Stick with Windows. If you need to access Linux, use PuTTY or another ssh client. Don't throw learning the AT tools of another OS on top of what you're dealing with at this point.
3. If you don't have an IDE, take a look at VSCode.
4. As for how you find missing semicolons, and the rest, well, you do so the same way everyone else does, by looking for them when your IDE or compiler complains. Over time, this becomes less and less of an issue, and most of your time is spent working on logic errors. Again, this is pretty similar to every other developer. Language syntax is a big problem, until one day it isn't. As others have mentioned, changing your screen reader to read more punctuation in certain apps can be helpful here. I personally don't do this unless I'm looking for a particular error that I think might involve a missing bit of punctuation.
5. The use of a screen reader does come with drawbacks; there's no denying that. However, it also comes with some benefits as well. As mentioned, you can probably read faster than most of your peers, and recognizing transposed letters in variable names becomes a lot easier.

At the end of the day, it's rather pointless to compare yourself to other devs. No two devs are alike anyway. Once you gain some experience using alternative techniques, you'll have things you are good at, and things that take you some extra time. Just like everyone else.

Just like very few developers are limited by their typing speed, you are unlikely to be limited by your use of AT after you've mastered it.

I'm reminded of an anecdote I heard from someone who was also dealing with vision loss, and was a relatively slow reader. When he was asked in the interview process if his slow reading speed was going to effect his employment, he responded with something along the lines of "Everyone reads Knuth at the same speed, no matter how fast they read." It probably goes without saying that he got the job.

Good luck. Feel free to post more here or DM me with further questions.

I use Emacspeak and the Terminal in general as much as I can, rather than any IDE, though I know VS Code has become more accessible lately. My day job is QA rather than software development, but I do have a Braille display and am familiar with the toolset at least on Mac and Linux. WINdows should be broadly similar, even if the specific tools available will be different.

> How do you stay enough effective and productive with just using a screen reader? Can you learn to be almost as effective as a sighted person?

Personally I can't, and as a result I do not develop professionally anymore as I'm extremely self conscious about my limitations as a blind developer.

> How do you deal with accessibility issues such as using VoiceOver in Visual Code? Do you just try hundreds of IDEs and programs? VoiceOver is a bit clumsy in my opinion compared to NVDA.

I use Xcode as an IDE for developing apps for the Apple ecosystem and as an editor for developing other kinds of things, which is more or less what I used to do back when I had sight but instead of using Xcode as an editor I used vim on the terminal. The only difference between now and back when I had sight is the way I mark large source files for navigation: Xcode has rotor settings such as jump to next error, jump to next breakpoint, jump to next mark, and jump to next function which are extremely important to me now. You can access these settings by pressing Control+Option+Command+Arrows, where Left and Right moves you to the previous and next rotor setting while Up and Down moves you to the previous and next item. Marks can be added to code by either using `#pragma mark` followed by a description of the mark in the C family of languages or by making a single-line comment with "mark" as its first word.

I also use the terminal a lot, which is an old habit from my sighted days, and that too has extremely helpful keyboard shortcuts such as Command+Arrows where Up and Down moves you to the next and previous marks on the terminal, Command+U drops a mark on whichever line the cursor is positioned, and Command+Shift+A selects all the text between two marks, which by default are dropped on every command line prompt.

> How do you deal with missing semi colons, brackets and indentation when building your code?

Regarding pairs of quotes, parens, brackets, or braces I just type both the opening and closing pair before typing the text inside, and have the option to do that automatically disabled in Xcode's preferences so I know exactly what I type. Regarding semicolons (which I tend to forget after coding in Swift for a while) compilers do a pretty good job at reminding me. Regarding indentation that's something you learn to live without, just like you learn to live without syntax highlighting, but if you truly need either you can press Command+Option+T or CapsLock+T (if you have CapsLock enabled as a VoiceOver key) and it will tell you the color of the text, the line number, and the indentation level including the number of leading spaces and tabs, and to make sure everything is properly indented for the sighted, you can select all the text in a source file by pressing Command+A after making sure that it compiles without syntax errors followed by pressing Control+I to re-indent everything.

I saw this today and it reminded me of this post https://www.reddit.com/r/reactjs/comments/k6gyey/reactaudibledebug_lets_you_hear_react_render_with/?utm_source=share&utm_medium=ios_app&utm_name=iossmf

I'm 20/800 and a programmer and you'd be suprprised how fast I work (faster than a median sighted dev). I use Linux and I've bound a fourth mouse button to read any selected text. I have no central vision but I can detect blocks of text on a web page and know the layout of most commonly visited website well. I just draw a quick selection around the target text and hit my mouse button. If this sounds interesting I could set up a github repo with info on this, I use a short script in bash to read text out loud using Espeak (I like it) and bind the key using xbindkeys. For 20/100 you probably won't need NVDA and something more targeted at low vision / VI probably makes more sense, though NVDA is really useful to know.

I don’t have specific advice, but wanted you to know you aren’t alone. I found your post and the answers people have provided here to be super helpful.

You may also want to check out the $1