Sådan får du et udviklerjob, når du er blind: Råd fra en blind udvikler, der arbejder sammen med et synet team

Jeg er hollandsk udvikler, og jeg er for nylig uddannet med en bachelorgrad i it. Jeg er helt blind og bruger en skærmlæser til at udføre mit arbejde.

Jeg går den forræderiske sti for den blinde udvikler - en sti, jeg vil beskrive, såvel som de forskellige fælder, den indeholder.

Jeg har arbejdet for forskellige virksomheder som en back-end webudvikler, der langsomt men sikkert også migrerer til mere og mere front-end-arbejde, hvor det teknologiske landskab er, hvad det er.

Jeg har arbejdet med en række forskellige teknologier, fra c # til Python og fra Rails til JavaScript.

Jeg er også en tilgængelighedsekspert, der er fortrolig med de sædvanlige mistænkte som WCAG, ATAG og venner. Hvad jeg mener med dygtige i dette tilfælde er, at jeg har brugt disse færdigheder i en professionel indstilling ved at udføre tilgængelighedsrevisioner på websteder, webapplikationer og desktopapplikationer.

Jeg har også samlet teoretisk viden ved at gennemgå Deque University-træningsprogrammet, som jeg meget kan anbefale, hvis du vil have en fast forankring i grundlæggende tilgængelighed.

Denne færdighed med tilgængelighedsregler er hovedsagelig en konsekvens af det faktum, at jeg selv kræver indhold for at være tilgængeligt for at være i stand til at bruge det.

Denne beskrivelse vil til tider være faktisk, til tider meningsbaseret. Det meste af tiden vil det være oplevelser fra et enkelt individ, der skriver kode for at leve uden at bruge øjnene til at hjælpe ham med at se, hvad han laver.

Jeg håber, at denne fortælling vil kaste lys over min arbejdsgang og de ting, jeg er nødt til at beskæftige mig med for at holde arbejdsprocessen i gang regelmæssigt. Endelig vil det være et øjebliksbillede af alle de ting, jeg har lært og stadig lærer om denne proces.

Start din rejse: få en fod ind døren

For at arbejde for et dev-team med seende kolleger skal du naturligvis først ansættes. At få det til at ske betyder, at du er nødt til at hoppe over nogle interessante gotchas, der muligvis ikke er umiddelbart synlige, hvorfor jeg dedikerer et afsnit af artiklen til det her.

Jobjagt som blind udvikler er en interessant aktivitet. Ligesom alle andre, der ansøger om ethvert job nogensinde, starter det med et CV og i de fleste tilfælde et følgebrev.

Et spørgsmål, jeg oprindeligt stod over for, var, om jeg straks skulle underrette virksomheden om min blindhed eller ej. Jeg har fundet ud af, at det generelt er bedre at ikke gøre det på grund af den enkle grund, at du lægger unødvendig vægt på blindhed, hvis du gør det.

Jeg er en udvikler med kvalifikationer, erfaring og færdigheder, jeg har tjent og arbejdet hårdt for, og det er fordelene, jeg ønsker at blive ansat til.

At være blind er for mig en ubetydelig ting ved siden af ​​disse færdigheder, medmindre det på en eller anden måde kan være et aktiv for positionen. Dette vil for eksempel være tilfældet for en tilgængelighedsrelateret position.

Dette har ført til nogle ret interessante situationer, fra forvirret blik på min hvide stok eller senere førerhund til hastigt udtænkte undskyldninger for at afslutte jobinterviewet for tidligt.

Selvom det er ulovligt at diskriminere nogen med et handicap, er det til tider ret let at forklæde sig som noget andet. Dette er noget at passe på. Heldigvis sker dette ikke så ofte, men at ikke nævne det her ville spille hurtigt og løst med sandheden.

Det er en omhyggelig afbalanceringshandling i de bedste tilfælde. Disse dage har jeg en tendens til at nævne min blindhed i sidste øjeblik, hvor jeg forhandler et jobinterview over telefonen ved at sige, at jeg vil bringe en hund med på kontoret og spørge, om nogen er allergiske over for hunde. Normalt er det næste spørgsmål et meget forståeligt "hvorfor?" og først derefter vil jeg nævne det og minimere det så meget som muligt. For det meste har denne tilgang givet mig i det mindste en chance for at komme ind til et første interview.

Andre forhindringer er obligatoriske screeninger eller vurderinger, der ikke er tilgængelige. Disse er generelt standardiserede tests, der ikke kan fraviges i henhold til det firma, du ansøger om.

Dette har den sædvanlige konsekvens af generelt at afslutte jobinterviewsproceduren lige der. Naturligvis kan problemet tvinges, men i retning af at skabe et positivt arbejdsmiljø er dette virkelig ikke noget, jeg kan anbefale.

Dette har at gøre med ovennævnte vægt på din status som blind person. Jo mere du laver et spørgsmål om det, jo større betydning får det for den person, der overvejer din jobansøgning.

Det følgende er generelt en næsten scripted procedure. Jobinterviewet går i de fleste tilfælde uden problemer, men får en ekstra komponent, som jeg gerne kalder "Monkey show, Monkey do" -delen.

Denne del af interviewet indledes normalt med et spørgsmål som: "Du kan sikkert forestille dig, hvorfor jeg spørger, men ... hvordan? Hvordan programmerer man uden at kigge?"

På dette tidspunkt forklarer jeg om skærmlæsere, den lynhurtige hastighed, de spytter information ud på, og jeg kommer normalt ud af min bærbare computer for at give lidt demonstration.

Jeg får normalt stirrer af forbløffelse. Engang klappede folk endda for mig.

Selvom det selvfølgelig er meget smigrende, har man en tendens til at blive gammel fra tid til anden at stirre på i beundring for at gøre noget, der er anden natur. Dette er ikke noget personligt. Det er bare muligt, at du er den tredje person, der gør det i dag. Besvarelse af de samme spørgsmål igen og igen falder helt sikkert også i den samme kategori.

Som et resultat skrev jeg en artikel, min første om freeCodeCamp, faktisk for at besvare nogle af de spørgsmål, jeg ofte får, når det kommer til at være en blind udvikler.

Heldigvis varer både denne demonstration såvel som denne øjeblikkelige periode med at stirre på normalt ikke særlig længe. Jeg har fundet ud af, at det gør det meget nemmere at forklare, hvorfor noget er eller ikke er en udfordring længere nede ad vejen.

At blive udstillet sådan - selvom det undertiden er ubehageligt - er det meget værd i sidste ende. Når alt kommer til alt er reaktionerne forståelige. Jeg laver noget, som mange mennesker ikke engang kan forestille mig at gøre uden syn.

Vælg dine værktøjer: Den konstante kamp for den konstante jonglering

For forskellige sysler kræver du et sæt værktøjer for at være effektive. Klatrere har brug for reb, forankringskrog osv. Og programmører har brug for værktøjer til at programmere, teste, samarbejde, dele og slå oplysninger osv.

Desværre er det her, hvor mange mennesker holder op. Måske endnu mere desværre er dette helt forståeligt.

Mængden af ​​arbejde, du skal lægge for at få en anstændig stak i gang, der fungerer til din brugssag - oven på din normale 40-timers arbejdsuge - kan være lidt overvældende.

Operativsystemet er den første forhindring. Mange dev-teams her i Holland bruger Mac'er udelukkende. Desværre er tilgængeligheds-API'erne, der er tilgængelige for MacOS-skærmlæser, Voiceover, i mange tilfælde ringere end dem i Windows.

Mængden af ​​tastetryk, der kræves for at udføre en opgave på Mac'en, er ofte højere end på Windows, hvor MacOS er et meget musorienteret operativsystem.

Endelig mangler skærmlæseren selv mange bekvemmelighedsfunktioner og tilpasningsmuligheder for sine Windows-kolleger.

I en industri, der formodes at være lige så tilgængelig for både blinde og seende, oversættes disse mangler til alvorlige produktivitetshits i forhold til mine seende kolleger. Dette kan være stressende og kræver nogle gange forståelse og fleksibilitet fra mine kolleger.

Når du er fortrolig med en codebase, og værktøjer er blevet ordnet, kan du udføre en masse opgaver lige så hurtigt som seende kolleger.

At opnå denne fortrolighed kan dog tage tid. Især hvis værktøjer ikke er så tilgængelige som de kan være. Du kan miste dyrebar tid med at kæmpe med et værktøj, der skal hjælpe dig i dit arbejde, men snarere forhindrer eller endda blokerer dig helt.

Heldigvis er jeg som regel mødt med forståelse og mange gange nysgerrighed over manglerne fra mine seende kolleger. Dette er dog ikke noget at stole på. Når der skal udføres meget arbejde på kort tid, er hvert produktivitetshit på en måde et for mange.

For at afhjælpe disse problemer så meget som muligt er det altafgørende, at du kender hver eneste lille genvej og trick af handlen med dine valgte værktøjer for at barbere tid, der spildes på handlinger, du gentager hele tiden. Makrotaster, skalaliaser, editorudvidelser, der giver dig flere tastaturgenveje - dette er navnet på spillet.

Men nogle gange vil de værktøjer, der skal hjælpe dig, komme i vejen for dig i stedet. Hvor mine seende kolleger ofte bruger grafiske værktøjer til at styre visse aspekter af deres job, er disse værktøjer ofte utilgængelige. Dette kræver, at jeg - ofte på stedet - finder ud af en slags løsning for stadig at udføre den samme opgave med en vis grad af effektivitet.

For en grafisk applikation kan dette være en ækvivalent kommandolinje. Et websted kan have en API. Nogle gange fungerer et andet grafisk værktøj måske bedre end det de facto. Konstant undrende alternativer til utilgængelig teknologi er en konstant del af jobbet, når du gør det med lukkede øjne. At få friheden til at medbringe dine egne værktøjer er meget vigtigt af den grund.

Jeg har sjældent set værktøjer håndhæves, fordi udviklere generelt har en stærk præference for deres egen arbejdsgang. Men for de job, der insisterede på, at jeg bruger specifikke værktøjer, bliver dette ofte en dealbreaker for eventuelle fremtidige kontrakter, jeg vil påtage mig. Værktøjer er så vigtige.

Din første tanke kan være at bare bruge Windows, hvis MacOS gør dig mindre produktiv. I en ideel verden ville det være en levedygtig løsning. Men især i ældre kodebaser har dev-teams ofte udtænkt små hacks for at få ældre kode til at køre på deres nyere hardware / software, der ikke engang skulle køre mere i første omgang. Disse hacks er OS-specifikke og er ofte svære at replikere på Windows - selv når du bruger Windows Subsystem til Linux. Det kan nogle gange tage uger at arbejde. Det er ofte ikke det værd.

Lige nu kører jeg næsten obligatorisk en Windows 10 virtuel maskine inden for Vmware Fusion på Mac af den grund. Jeg er tvunget til at bruge to operativsystemer på én gang for at få mit arbejde udført. Windows har min webbrowser, min valgte kodeditor og forskellige andre værktøjer, jeg bruger til at øge min produktivitet:

  • Google Chrome
  • VS-kode
  • en anstændig PDF-læser
  • en kontorpakke til arbejde med DOCX- og XLSX-filer

Dybest set kører alle ægte applikationer på Windows VM, hvilket gør MacOS til en del af en server, der bare er vært for applikationskoden.

Dette er et godt eksempel på friheden til at bruge dine egne værktøjer, jeg henviste til. Ingen andre i mit team kører den samme opsætning, som jeg gør. Men at gøre dette er generelt blevet mødt med forståelse og støtte fra mine kolleger, fordi de kan se, at jeg kan få arbejdet gjort på denne måde.

Tilgængelighed, især i dev-værktøjer, kan være utrolig svært at forsvare. Ofte bliver du ikke taget alvorligt, når du beder om, hvad der skal være en grundlæggende funktion. På en måde beder du blot om at kunne bruge applikationen.

Men det er ikke på køreplanen, udviklere kan ikke skånes for at arbejde på det, det har ikke prioritet osv. Er grundene til ikke at rette et værktøjs tilgængelighed næsten som et urværk. Andre gange gives løfter om rettelser, der aldrig bliver til noget.

Jeg ville elske at se dette forbedres og har haft fornøjelsen at se det ske igen og igen. Det er stadig et problem, der stadig kommer tilbage, og som udviklere, inklusive mig, skal vi gøre det bedre.

Mine seende kolleger tager meget værktøj for givet. I et .NET-team er det for eksempel sjældent at se en udvikler, der ikke bruger Resharper til at øge deres produktivitet.

Ironisk nok bruger denne udvidelse til Visual Studio, i sig selv ganske tilgængelig, mange tastetryk til at gøre, hvad den gør. Du ville tro, at det ville gøre det til et ideelt værktøj til en blind udvikler, der kun bruger et tastatur til at kode. Outputtet fra denne udvidelse er dog ofte utilgængeligt, hvilket gør værktøjet mere til hinder end et hjælpemiddel.

Jeg har jagtet Jetbrains i årevis for at få dem til at rette dette værktøjs tilgængelighed, hvilket selv på tidspunktet for denne skrivning er uhyggeligt. Jeg er uhøfligt afskediget, ignoreret og endelig afgivet løfter til, indtil videre uopfyldt. Denne uvillighed til at rette op på det, der naturligvis er et problem, der har været der i årevis, gør mig tøvende med at forpligte mig til en .NET-baseret position. Selvom problemerne løses mirakuløst, vil track record med at lade det være løst så længe få mig til at undre mig over, hvornår det går i stykker igen.

I et af de første dev-teams, jeg arbejdede med, blev Postman brugt meget til at teste API-slutpunkter, som back-end-udviklerne oprettede. Postbrevet har en række skarpe tilgængelighedsproblemer, der gør det svært at bruge med en skærmlæser. For et perfekt eksempel på uopfyldte løfter, se på dette GitHub-emne. Vær opmærksom på, at spørgsmålet stadig er åbent efter næsten 2 år, og at der gives løfter, men ikke bliver holdt.

Tilgængelighed er ofte en eftertanke, noget der utvivlsomt bevises igen og igen. Slap er desværre et godt eksempel på dette. Tilgængeligheden af ​​dette nu næsten uafviselige værktøj var uhyggelig, skærmlæserbrugere kunne simpelthen ikke arbejde med det.

Vi ser bestemt forbedringer i det rum, noget denne artikel passende viser. Men den tid, alt dette tager, er utrolig høj - måneder, til tider år, hvor folk, der bruger en skærmlæser, ikke har tilstrækkelig adgang til ressourcer, som deres kolleger har adgang til. Denne form for mangel kan og får folk til at miste deres job, fordi de bare ikke kan følge med i kommunikationen inden for det firma, de arbejder i.

De ovennævnte værktøjer (Resharper, Slack, Postman osv.) Er nøgleaktører i deres valgte felter. Ikke at have adgang til disse værktøjer hindrer dig som udvikler og tvinger dig til at bruge cyklusser, du skal bruge på at få arbejdet udført på at finde løsninger og alternative værktøjer i stedet. Dette er spild, trættende og burde ikke være nødvendigt, men det er, og det er en af ​​de grundlæggende færdigheder, jeg har haft til at blive meget god til at holde trit.

Efterhånden som jeg går, vil jeg sige, at der dog synes at være en nedadgående tendens til, at dette er nødvendigt. Indsats fra Microsoft, Apple, Google og andre store aktører gør flere og flere mennesker opmærksomme på denne næsten konstante kamp for lige adgang til produktivitet. På ingen måde er vi dog ude af skoven, noget der blev tydeligt demonstreret af Gutenberg WordPress-debacle, der i øjeblikket raser gennem tilgængelighedsfællesskabet.

Blinde mennesker er et nichemarked for software og webudviklere. Blinde udviklere er et nichemarked inden for et nichemarked.

Blinde udviklere, der holder fast ved det, bliver produktive og har et fuldtidsjob, er desværre endnu mere sjældne. Dette kan og bør ændre sig, men indtil det sker, er kampen for tilgængelig udviklerværktøj en, du kæmper alene. Jeg håber, det er en kamp, ​​som vi ikke bliver nødt til at kæmpe i fremtiden, jeg vil gøre mit bedste for at bidrage til dette mål.

Odds og ender

Jeg vil afslutte denne artikel med en positiv note. Det faktum, at jeg stadig er inden for dette felt, det faktum, at jeg har et fuldtidsjob som udvikler, giver mig en masse lykke, selv gennem alle de tilsyneladende konstante forhindringer. Jeg er glad for, at jeg kan bidrage til et godt team af kolleger, der behandler mig som en lige og tænker med mig, når jeg løber ind i noget, jeg har problemer med.

Jeg vil understrege, at selvom computervidenskab ikke er fri for forhindringer, kan folk trives og trives i CS-relaterede job. De ovenfor beskrevne kampe er bestemt sande, men sammenlignet med andre felter er de i det mindste i høj grad håndterbare. Jeg tvivler på, at jeg snart vil skrive en artikel om, at min karriere skifter til en kirurg, en jagerpilot eller en professionel baseballspiller, men så kan teknologien måske endnu overraske mig. For nu er jeg dog glad for, hvor jeg er, og har et godt hold omkring mig.

Jeg bliver ofte bedt om min mening, når det kommer til effekten på tilgængeligheden af ​​det produkt, vi arbejder på. Mine meninger kommer bestemt ikke altid til at få ting til at ændre sig, men jeg er glad for, at jeg i det mindste er i stand til at gøre folk opmærksomme på vigtigheden af ​​tilgængelighed, og hvad der vil ske, når det ignoreres.

Jeg er trods alt et levende vejrtrækningseksempel på, hvad der sker, når et værktøj ikke er eller ikke længere tilgængeligt.

WordPress-artiklen, der er linket til ovenfor, sender denne besked meget tydeligt; et værktøj, der har været meget brugbart og tilgængeligt i årevis, er nu næsedykning. Dette er noget, der kan ske med ethvert værktøj, som en blind udvikler er afhængig af, den russiske roulette for virksomheden så at sige.

Ved at skrive artikler som denne, ved at holde foredrag, uddanne udviklere og ved at eksperimentere med nye værktøjer, nye teknikker og nye metoder håber jeg at være foran kurven. Ved at nedskrive mine resultater håber jeg at lære andre de tricks af den handel, jeg fandt ud af ved prøve og fejl, så tærsklen til dette felt sænkes for brugere af skærmlæser.

Hovedmålene i denne artikel stemmer overens med mange, hvis ikke alle disse mål. Jeg håber, at jeg har givet dig et indblik i både kampene og positive sider fra en blind programmør.

Jeg håber, at jeg har påpeget, at selvom det er muligt, kan vi og bør forbedre oplevelsen enormt. Jeg håber, at jeg har fået læserne af denne artikel til at tænke, virkelig tænke over konsekvenserne af utilgængelig software, og jeg håber, at jeg har vist, at selv gennem alle forhindringer er det meget muligt at blive god, endda stor inden for dette felt en gang du opnår flugthastighed.

I lyset af den positive note, jeg lige henviste til, vil jeg afslutte denne artikel med at nævne to store tilgængelighedsgevinster, der er perfekte eksempler på, hvordan vi har gjort det bedre, som jeg begge har været en beæret bidragyder til.

For at lære at kode, er mange af de mere interaktive ressourcer derude som Codeacademy ikke særlig tilgængelige. Dette har at gøre med, at forskellige komponenter, der bruges i disse projekter, ikke er tilgængelige. Heldigvis arbejdes der allerede med dette.

En af de ressourcer, der har fået meget trækkraft de sidste par år, er freeCodeCamp. Dette initiativ plejede at have nogle ret alvorlige tilgængelighedsproblemer, som for nylig næsten er blevet løst fuldstændigt og revideret, hvilket gør platformen meget levedygtig for brugere af skærmlæser, der vil lære at kode.

Dette har meget at gøre med Monaco Editor, som er en meget tilgængelig webbaseret kodeditor og faktisk er redaktorkomponenten Visual Studio Code bruger. Denne redaktør var bogstaveligt talt helt utilgængelig, da den kom ud. På relativt kort tid blev dette imidlertid ikke kun rettet i høj grad, men gør nu projekter som freeCodeCamp tilgængelige som standard, fordi de bruger den samme komponent. Sådan skal det altid være, det er det, jeg håber at se mere af, når jeg holder på med dette. Og med det synes jeg det er på høje tid, at jeg vender tilbage til programmering.