Blind and Visually Impaired Community
↑
13
↓
Blind programmers, how do you find your work rate compares to your sighted peers, do you have any strategies to program faster with text to speech? (self.Blind)
submitted by IcedMelt
Hi, I recently started learning to program with Visual Studio Code and Python. Unfortunately, I have retinal problems and my eye health is not the best, so my eyes don't tolerate strain well. In the beginning I was using my good eye to program, but I've been having some concerning symptoms due to overuse. I have since switched to NVDA and learned this way, but I've found the rate at which I can program is about 10% of what I can do sighted. Of course, with practice I expect this to improve, and I know the quality of the code will be the same, it's just that for now it takes longer to do.
I was wondering how people who are more experienced with NVDA and other text to speech programming have found their work rate compares to their sighted peers? If I'm being totally honest, I'm concerned that even if I become an expert at programming with NVDA, my work rate will still be slower than conventional programmers. If this is true, what would you say the work rate comparison is in general between text to speech and conventional programmers? 50%, 75%, 125%? My main concern is that it could potentially have a negative impact on me in the workplace if I do pursue programming, and the rate is slower. For example, if my work rate was 50% of my sighted peers even though I had become experienced with text to speech programming, I feel like that might put me in a difficult position. I'd also love to hear advice you have with programming faster using text to speech. Thanks.
I was wondering how people who are more experienced with NVDA and other text to speech programming have found their work rate compares to their sighted peers? If I'm being totally honest, I'm concerned that even if I become an expert at programming with NVDA, my work rate will still be slower than conventional programmers. If this is true, what would you say the work rate comparison is in general between text to speech and conventional programmers? 50%, 75%, 125%? My main concern is that it could potentially have a negative impact on me in the workplace if I do pursue programming, and the rate is slower. For example, if my work rate was 50% of my sighted peers even though I had become experienced with text to speech programming, I feel like that might put me in a difficult position. I'd also love to hear advice you have with programming faster using text to speech. Thanks.
codeplaysleep 12 points 1y ago
Everyone is slow when they're learning. Just practice, mostly, and your speed will improve. At this point, I don't think my productivity is affected much at all. I don't use text to speech all the time, but have started using it some. When I'm not, I'm using a screen magnifier and large fonts, but I've been programming for decades at this point.
Here's a secret, though: the more senior you are, the less code you write. I don't think I touched a single line of code last week other than to review someone else's work, but I was busy as hell the entire time.
You can start doing this earlier in your career and doing so will only help your growth.
So if you're feeling like you're slow and you ned to compensate for that somehow, focus on becoming really good at architecting solutions and solving engineering problems. Focus on learning about things like scalability and security. Get really good with your test suite and become the automated testing expert that everybody goes to (almost no company out there tests their code as much as they should or as much as they wish they did). Get your PSM1 certification and act as a scrum master for your team, be their support person for deploys, code reviews, etc.
There are so many other ways you can contribute that go beyond lines of code just by accumulating and sharing knowledge, facilitating people and processes, and really understanding and aligning yourself with business goals and moving things toward those.
Here's a secret, though: the more senior you are, the less code you write. I don't think I touched a single line of code last week other than to review someone else's work, but I was busy as hell the entire time.
You can start doing this earlier in your career and doing so will only help your growth.
So if you're feeling like you're slow and you ned to compensate for that somehow, focus on becoming really good at architecting solutions and solving engineering problems. Focus on learning about things like scalability and security. Get really good with your test suite and become the automated testing expert that everybody goes to (almost no company out there tests their code as much as they should or as much as they wish they did). Get your PSM1 certification and act as a scrum master for your team, be their support person for deploys, code reviews, etc.
There are so many other ways you can contribute that go beyond lines of code just by accumulating and sharing knowledge, facilitating people and processes, and really understanding and aligning yourself with business goals and moving things toward those.
No-Satisfaction7842 2 points 1y ago
Are you performing code reviews using a screen reader or with the limited vision it sounds like you have? I am exclusively a screen reader user and would welcome any tips for improving my code review experience from an accessibility standpoint. Thanks!
No-Satisfaction7842 5 points 1y ago
With time and continued practice you will become proficient using a screen reader. I don’t know that anyone can tell you the exact difference in rate of speed, and I’m also not sure that’s really the right thing to focus on either way. In my experience, there are some things that we are just going to be a little slower at because of screen reader usage and that’s unavoidable, but on the other hand, there are things we can do faster because we are screen reader users, so I like to think it all balances out.
I’m a working software engineer who has been in the field for five years and I’ve never felt like my blindness has prevented me from hitting deadlines and doing Quality work. The best piece of advice I can give you is to master your tools. This includes your operating system, your software development environment and your accessibility tools. Shortcut keys are your friend! Operating systems have shortcut keys, applications have shortcut keys and of course the screen readers do too. Memorize them all and get extremely fluent with them.
I’m a working software engineer who has been in the field for five years and I’ve never felt like my blindness has prevented me from hitting deadlines and doing Quality work. The best piece of advice I can give you is to master your tools. This includes your operating system, your software development environment and your accessibility tools. Shortcut keys are your friend! Operating systems have shortcut keys, applications have shortcut keys and of course the screen readers do too. Memorize them all and get extremely fluent with them.
IcedMelt [OP] 3 points 1y ago
>I’m a working software engineer who has been in the field for five years and I’ve never felt like my blindness has prevented me from hitting deadlines and doing Quality work
Good to hear, I'll definitely become proficient with shortcuts. I saw in your other post that you exclusively use a screen reader to program, I was curious what software you use? I use Visual Studio Code, Python, and NVDA. Started off using a middling rate of speech, but a few days ago turned it up to max, and am getting used to that. I'll try rate boost once I get used to this.
Good to hear, I'll definitely become proficient with shortcuts. I saw in your other post that you exclusively use a screen reader to program, I was curious what software you use? I use Visual Studio Code, Python, and NVDA. Started off using a middling rate of speech, but a few days ago turned it up to max, and am getting used to that. I'll try rate boost once I get used to this.
CloudsOfMagellan 1 points 1y ago
I strongly suggest trying emacs with emacspeak, it's fully customisable so completely accessible
ukifrit 1 points 1y ago
If you're gonna try Espeak's speed boost, lower your speech rate to 20 or so, then go up as you get used to it.
No-Satisfaction7842 1 points 1y ago
I mostly use Visual Studio as my team works primarily in the C# / asp.net stack but do also use VS code for front end work. I also use NVDA. Best of luck and feel free to hit me up if you have any other questions
ukifrit 1 points 1y ago
You always can create more shortcuts with programs designed for that.
Fridux 5 points 1y ago
I've only worked on personal projects since going totally blind, and since most of the time I spend is spent thinking about elegant solutions rather than writing, blindness barely affects my productivity. If I had a job, however, things would likely be different, because at work time is money, and since I'm not a very efficient screen-reader user, I'd probably have to work longer hours to produce the same I'd produce if I still had sight.
zersiax 4 points 1y ago
As for speeding up, there's certainly ways. Speech rate is a no-brainer, faser you can parse, the faster you will know what's happening onyour screen. Shorten long symbol names (I have laren and raren for left paren and right paren for example). Get really good at hotkeys; use your goto symbol, goto definition etc. without going for your mouse, keep your hands on the keyboard and keep NVDA in focus mode for 90% of the time.
arond3 2 points 1y ago
Does someone have a treak for the UI of gitlab when you do code review ?
More precosemy the fact that the file use to review use like 30-40% of the screen.
More precosemy the fact that the file use to review use like 30-40% of the screen.
SticksAndDrones 2 points 1y ago
I download the diff and only use the gitlab UI for entering comments if needed.
CloudsOfMagellan 1 points 1y ago
I believe there's some stuff to do it through emacs although I'm not sure if it's fully usable yet
Shadowwynd 2 points 1y ago
Couple things:
1) Measuring programming output by "work rate" or "lines of code" or something similar is a very poor metric. Programming (done right) involves much more percolating and pondering than it does pushing buttons on a keyboard. Some of my most brilliant code has been attending a football game (obviously not watching the game), on walks, in the shower, in my dreams, etc. If you know the language you can step through it in your head, you don't even need the computer.
2) The biggest problems are going to be things like mismatched braces and parentheses or forgotten semicolons; in python the biggest problem is the whitespace and indentation. Look for ways to write macros (most editors have some sort of macro function) that can automate your modules/function definitions and block out a lot of code in advance.
1) Measuring programming output by "work rate" or "lines of code" or something similar is a very poor metric. Programming (done right) involves much more percolating and pondering than it does pushing buttons on a keyboard. Some of my most brilliant code has been attending a football game (obviously not watching the game), on walks, in the shower, in my dreams, etc. If you know the language you can step through it in your head, you don't even need the computer.
2) The biggest problems are going to be things like mismatched braces and parentheses or forgotten semicolons; in python the biggest problem is the whitespace and indentation. Look for ways to write macros (most editors have some sort of macro function) that can automate your modules/function definitions and block out a lot of code in advance.
ukifrit 2 points 1y ago
NVDA has a setting to anounce indentation via sound. I don't use it much as I'm not a programer, but it's there.
mush4242 1 points 1y ago
I am not a professional programmer, but I spent a good deal of time on programming open source projects. For me personally, I use notepad plus plus and I find it more productive than visual studio code. For testing, debugging, building etc I use the command line. Also, a computer with plenty of RAM and a high-end processor will help you along the way.
As others mentioned, programming is not about spitting out code, it is about solving problems. As you gain more experience, you'll be worried about what to write, more than, how to write it.
As others mentioned, programming is not about spitting out code, it is about solving problems. As you gain more experience, you'll be worried about what to write, more than, how to write it.
This nonprofit website is run by volunteers.
Please contribute if you can. Thank you!
Our mission is to provide everyone with access to large-
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
©2023 HumbleCat Inc • HumbleCat is a 501(c)3 nonprofit based in Michigan, USA.