Development at a speed of 450 words per minute
"Something is missing here." I bet you, this idea will come first to your head, if you see my workplace in the office. There is no monitor and mouse. There is only a guy who threshes on the keyboard, looking as if into emptiness.
It's just me, and my colleagues guarantee you that I'm usually not dangerous. I'm a programmer at the Vincit office in Tampere (Finland). And I'm blind. In this article I want to tell you a little about how I work.
Are you blind in the sense that you are actually blind?
Right. I can perceive the sunlight and some very bright lamps, but that's all. In fact, nothing useful for work.
What are you doing there then?
The same as everything: I do software and I make fun of my colleagues if time permits. I worked on full-stack web projects with a focus on the backend. I also took on the role of a consultant on the general availability of projects for people with disabilities - or the role of the police; depending on how to look.
How do you use your computer?
I have a completely ordinary laptop under Windows 10. All the "magic" in the software. To access the computer, I use a program called a screenreader. He intercepts the picture from the screen and presents information in the Braille alphabet (via a separate Braille display) or synthesis of speech. And this is not the synthetic speech that you hear from current digital assistants. I use a robotic voice that says about 450 words per minute. For comparison, native English speakers usually pronounce 120-150 words per minute. There is one feature in my system: since I need to read regularly in both Finnish and English, I read English with a Finnish speech synthesizer. In former times, screenwriters were not smart enough to automatically switch between languages, so I'm used to this reading. Here is an example of this paragraph as I hear it . And here is the same text via the English-language speech synthesizer .
Naturally, the mouse is not particularly useful to me, so I only work with the keyboard. My keyboard commands should be familiar to everyone who reads this article: arrows, Tab key for navigation inside the window, Alt + Tab to switch between windows, etc. In addition, screen readers have a lot of their own "hot keys", for example, to read different parts of the active window, turn on / off some of their own functions.
Everything becomes a little more interesting when reading web pages and other formatted documents. The screen reader gives this information in pieces. This piece is often a string, but it can be a word, a symbol or another arbitrary fragment of the text. For example, if I press the "down" key on a web page, I'll hear the next line of text. This type of reading means that I can not just scan the contents of the screen in the same way that a sighted person does. I have to read all the piece by piece or skip the pieces that I do not need.
Just speech or Braille does not allow you to accurately convey what the page looks like. All information is given to me in a linear way. If you copy a web page and insert it into Notepad, you will get a general impression of how it looks to me. It's just a bunch of lines on each other with almost no formatting. However, a screen reader can pick up semantics from HTML, so links, headers, form fields, etc. are correctly declared to me. This is so: I do not know that the checkbox is a checkbox if its style is not written that way. However, we will discuss this in more detail later; I will devote an entire article to this topic. Just remember that the example I cited is a crime against humanity.
I spend a considerable part of my time at the command line. In fact, I rarely use any graphic applications, except the web browser and the editor. I found that it is often much faster to perform a task manually on the command line than to use an interface that is designed with the thought of mouse users.
So, given my love for the command line, why am I stuck on Windows, an operating system that is not famous for its command line tools? The answer is simple: Windows is the most accessible system [for people with disabilities - approx. per.]. My favorite NVDA screensaver is free software, it is supported more actively than any other screensaver. If I had the choice, I would use the Mac OS, in my opinion, there is a neat balance between convenience and functionality. Unfortunately, the screen reader for this system VoiceOver suffers from long releases and general neglect, and its navigation model is not very compatible with my specific style of work. There is also a screensaver for the Gnome desktop and although it is perfectly supported for such a small audience of users, there still remained sharp corners, because of what it does not suit me for permanent use. So only Windows. I compensate for the inherent disadvantages of this OS by living inside Git Bash, which comes with an excellent set of GNU and other command-line utilities right out of the box.
How can you code?
It took me quite a long time to understand why this issue is so important for many people. Remember, what did I say about reading the text of the line after the line? So I read the code. I skip unnecessary lines or can listen only half for the sake of context, but if I really need to understand, then I read everything as a novel. Naturally, I can not read in such a way a giant code base. In these cases, you have to abstract parts of the code in your mind: this component takes x at the input and returns y, no matter what it actually does.
This kind of reading compels me to perform some tasks differently than my sighted colleagues. For example, in the process of code inspection, I prefer to look at raw diff output whenever possible. Side-by-side diffs are not very useful to me, in fact, they even distract. Signs of "plus" and "minus" are also much better indicator of changed lines than color selection. Not because I can not read the names of the flowers. Simply "plus" is pronounced faster than the name of some intricate shade of red that is used for the added line. (I'm looking at you, Gerrit).
You may think that indentation and other formatting will remain completely invisible to me, as this is a visual highlight. Wrong: the right indentation helps me in the same way as for a sighted programmer. If I read the code in Braille (by the way, it's much more effective than speech), then it gives a good visual key where I am, just like a programmer who sees. I also get voice messages if I enter a block of text with or without indent. This information helps to draw a code map in the head. In fact, the first real programming language I had was Python (PHP does not count), since then indentation has never been a problem. I strongly advocate a clean and consistent programming style for many reasons, but mainly because it does not complicate my life to the limit.
Which editor do you prefer?
Spoiler: The answer to this question does not begin with the letter V, nor with E. (Of course, I use Vim to compose messages about git commits and other quick notes on the command line.) I am neutral in this particular minefield). A year ago, among all editors, I would choose Notepad ++. It's an easy, well-designed text editor that does its job. However, a year ago I was not working on a large-scale Java project. When it all happened, it's time to choose between Notepad ++ and common sense. In the end, I leaned toward the second (at the time, which I could) and dropped Notepad ++ for IntelliJ IDEA. Since then, this is my elected editor. I have a deep-rooted disgust for all IDEs, because most of them are either impossible or inefficient to use only from the keyboard. Most likely, I would have switched to IDE much earlier, if I had been sighted.
You can ask why I chose Notepad ++. There are also more advanced lightweight editors, such as Sublime Text or Atom. The answer is simple: none of them is available for screen readers. Text editors like Vim are also not an option, because my screensaver has some problems with the support of console applications, because of which these editors can not be used for something larger than the message about the commit. Unfortunately, accessibility [for the blind - approx. This is the main factor for my tools. If I can not use the tool effectively, it is no longer considered.
Have you ever worked with front-end code?
You might think that front-end development is so visual by nature that there is no place for a blind developer, and for the most part it is. I do not create basic concepts myself, because in these projects you basically need to create the right kind, and functionality is added later.
However, I also have a piece of work in Angular and React. How so? In many modern web applications, much of the work is done under the hood in the browser. For example, I once introduced a couple of weeks of internationalization support into a rather complex Angular application. There was not any visual work at all.
I found that libraries like Bootstrap are a real godsend for me. Thanks to the grid system, I can do the basic version of the user interface myself. Despite this, all the interface changes I've prepared pass through a couple of eyes before being delivered to production. So, summing up: I can work with the frontend to a certain extent, at least, not really touching the level of presentation.
What about things you did not tell us about?
Certainly, many things had to be left outside the framework of this article. As promised, I will devote an article to the art of making web pages more accessible, since the lack of correct semantics is my favorite corn. But there is a high probability that I will not stop there. We'll be in touch!
|Vote for this post
Bring it to the Main Page