Kuinka saada kehittäjätyö sokeana: Näkötiimin rinnalla työskentelevän sokean kehittäjän neuvoja

Olen hollantilainen kehittäjä ja valmistuin äskettäin kandidaatin tutkinnosta IT-alalla. Olen täysin sokea ja käytän ruudunlukijaa työni tekemiseen.

Kävelen sokean kehittäjän petollista polkua - polun, jonka kuvaan, samoin kuin sen sisältämät erilaiset ansat.

Olen työskennellyt useissa yrityksissä back-end-verkkokehittäjänä, joka on hitaasti mutta varmasti siirtymässä yhä useampaan etupään työhön, teknologinen maisema on sellainen kuin se on.

Olen työskennellyt useiden tekniikoiden kanssa, c #: stä Pythoniin ja Rails: stä JavaScript: iin.

Olen myös esteettömyysasiantuntija, joka tuntee tavalliset epäillyt, kuten WCAG, ATAG ja ystävät. Tarkoitan taitavaa tässä tapauksessa, että olen käyttänyt näitä taitoja ammattimaisessa ympäristössä suorittamalla esteettömyystarkastuksia verkkosivustoilla, verkkosovelluksissa ja työpöytäsovelluksissa.

Olen myös kerännyt teoreettista tietoa käymällä läpi Deque University -koulutusohjelman, jota voin suositella, jos haluat vankan pohjan saavutettavuuden perusteille.

Tämä esteettömyyssääntöjen tuntemus on pääosin seurausta siitä, että itse vaadin sisällön saatavuuden voidakseni käyttää sitä.

Tämä kuvaus on toisinaan tosiasia, toisinaan mielipide. Suurimman osan ajasta, ne ovat yksittäisen yksilön kokemuksia, jotka kirjoittavat elinkoodin käyttämättä silmiään auttaakseen häntä näkemään, mitä hän tekee.

Toivon, että tämä tarina valaisee työnkulkuani ja asioita, joita minun on käsiteltävä, jotta työnkulku pysyy säännöllisesti. Lopuksi, se on tilannekuva kaikenlaisista asioista, jotka olen oppinut ja olen edelleen oppinut tästä prosessista.

Matkan aloittaminen: päästä jalka oveen

Jotta voisit työskennellä kehitystiimissä näkövammaisten kollegoiden kanssa, sinun on tietysti ensin palkattava. Tämän tekeminen tarkoittaa, että sinun on hypättävä mielenkiintoisiin gochoihin, jotka eivät välttämättä ole välittömästi ilmeisiä, minkä vuoksi omistan osan artikkelista tälle.

Työnhaku sokeana kehittäjänä on mielenkiintoinen toiminta. Aivan kuten kukaan muu, joka hakee mihin tahansa työhön koskaan, se alkaa ansioluettelosta ja useimmissa tapauksissa saatekirjeestä.

Aluksi kohdasin kysymyksen siitä, pitäisikö minun välittömästi ilmoittaa yritykselle sokeudestani vai ei. Olen havainnut, että yleensä on parempi olla tekemättä sitä yksinkertaisen syyn vuoksi, kun korostat tarpeettomasti sokeutta, jos teet niin.

Olen kehittäjä, jolla on pätevyys, kokemus ja taidot, jotka olen ansainnut ja tehnyt kovasti töitä, ja nämä ovat ansioita, joihin haluan palkattua.

Sokeus on minulle merkityksetön asia näiden taitojen vieressä, ellei se voi jotenkin olla voimavara asemalle. Tämä pätee esimerkiksi esteettömyyteen liittyvään asemaan.

Tämä on johtanut melko mielenkiintoisiin tilanteisiin hämmentyneistä katseistani valkoiseen keppii tai myöhemmin opaskoiraani, hätäisesti suunniteltuihin tekosyihin lopettaa työhaastattelu ennenaikaisesti.

Vaikka vammaisten syrjiminen on laitonta, se on toisinaan melko helppo naamioida joksikin muuksi. Tähän on syytä varoa. Onneksi tätä ei tapahdu niin usein, mutta jos sitä ei mainita täällä, se pelaa nopeasti ja löyhästi totuuden kanssa.

Parhaimmillaan se on huolellinen tasapainotus. Nykyään minulla on tapana mainita sokeuteni viime hetkellä, kun neuvottelen työhaastattelusta puhelimitse ilmoittamalla, että tuon koiran toimistoon ja kysyn, onko joku allerginen koirille. Yleensä seuraava kysymys on hyvin ymmärrettävä "Miksi?" ja vasta sitten mainitsen sen minimoimalla sen mahdollisimman paljon. Suurimman osan ajasta tämä lähestymistapa on antanut minulle ainakin mahdollisuuden tulla ensimmäiseen haastatteluun.

Muita esteitä ovat pakolliset seulonnat tai arvioinnit, joihin ei ole pääsyä. Nämä ovat yleensä standardoituja testejä, joista ei voida poiketa hakemasi yrityksen mukaan.

Tällä on tavallinen seuraus siitä, että työhaastattelumenettely lopetetaan yleensä siellä. On selvää, että asia voidaan pakottaa, mutta positiivisen työympäristön luomisen takia sitä ei todellakaan voi suositella.

Tämä liittyy edellä mainittuun sokeuden aseman korostamiseen. Mitä enemmän teet siitä kysymyksen, sitä suurempi merkitys se saa henkilölle, joka harkitsee työhakemustasi.

Seuraava on yleensä melkein komentosarjaprosessi. Työhaastattelu menee useimmissa tapauksissa ongelmitta, mutta saa ylimääräisen komponentin, jota haluan kutsua "Monkey show, Monkey do" -osaksi.

Tätä haastattelun osaa edeltää yleensä kysymys, kuten: "Voit luultavasti kuvitella, miksi kysyn, mutta ... miten? Kuinka ohjelmasi ohjelmoidaan katsomatta?"

Tässä vaiheessa selitän näytönlukuohjelmista, räjähtävän nopeasta nopeudesta, johon he sylkivät tietoa, ja pääsen yleensä ulos kannettavastani antamaan vähän esittelyä.

Saan yleensä hämmästyksen tuijotuksia. Kerran ihmiset taputtivat minua.

Vaikka se on tietysti hyvin mairittelevaa, on tuijottamisen ihailu toisenlaisen luonteen tekemisen suhteen taipumus vanhenemaan ajoittain. Tämä ei ole mitään henkilökohtaista. On vain mahdollista, että olet kolmas henkilö, joka tekee niin tänään. Vastaaminen samoihin kysymyksiin yhä uudelleen kuuluu varmasti samaan luokkaan.

Tämän seurauksena kirjoitin artikkelin, ensimmäisenä itse asiassa freeCodeCampissa, vastaamaan joihinkin kysymyksiin, joita saan usein sokean kehittäjän ollessa.

Onneksi sekä tämä mielenosoitus että tämä hetkellinen tuijottamisjakso eivät yleensä kestä kovin kauan. Olen havainnut, että tämän tekeminen tekee paljon helpommaksi selittää, miksi jokin on tai ei ole haaste edelleen tiellä.

Tällainen esittely - vaikkakin joskus epämiellyttävä - on loppujen lopuksi sen arvoinen. Loppujen lopuksi reaktiot ovat ymmärrettäviä. Teen jotain, jota monet ihmiset eivät voi edes kuvitella tekevän ilman näköä.

Työkalujen valitseminen: Jatkuva taistelu jatkuvasta taistelusta

Eri harrastuksiin tarvitaan joukko työkaluja, jotta ne olisivat tehokkaita. Kiipeilijät tarvitsevat köyden, ankkurikoukut jne. Ja ohjelmoijat tarvitsevat työkaluja ohjelmointiin, testaamiseen, yhteistyöhön, tietojen jakamiseen ja etsimiseen jne.

Valitettavasti monet ihmiset lopettavat. Ehkä vielä valitettavasti tämä on täysin ymmärrettävää.

Työmäärä, joka sinun on tehtävä saadaksesi kunnollisen pinon, joka toimii käyttötapauksessasi - normaalin 40 tunnin työviikon lisäksi - voi olla hieman ylivoimainen.

Käyttöjärjestelmä on ensimmäinen este. Monet dev-joukkueet täällä Alankomaissa käyttävät yksinomaan Mac-tietokoneita. Valitettavasti MacOS-näytönlukijan, Voiceoverin, käytettävissä olevat sovellusliittymät ovat kuitenkin monissa tapauksissa huonompia kuin Windowsissa.

Tehtävän suorittamiseen tarvittavien näppäinpainallusten määrä Macissa on usein suurempi kuin Windowsissa.

Lopuksi, näytönlukijasta itsestään puuttuu paljon sen Windows-vastaavien mukavuusominaisuuksia ja mukautusvaihtoehtoja.

Alalla, jonka oletetaan olevan yhtäläinen sekä sokeiden että näkövammaisten ulottuvilla, nämä puutteet merkitsevät vakavia tuottavuushittejä verrattuna näkemäni kollegoihini. Tämä voi olla stressaavaa ja vaatii kollegoiltani ajoittain ymmärrystä ja joustavuutta.

Kun olet perehtynyt koodikantaan ja työkalut on lajiteltu, voit suorittaa paljon tehtäviä yhtä nopeasti kuin näkökollegat.

Tämän tuntemuksen saavuttaminen voi kuitenkin viedä aikaa. Varsinkin jos työkalut eivät ole niin helposti saatavilla kuin ne voivat olla. Voit menettää kallisarvoisen paineen työkalulla, jonka on tarkoitus auttaa sinua työssäsi, mutta pikemminkin estää tai jopa estää sinut kokonaan.

Onneksi minua on tavallisesti tavannut ymmärtäväinen ja monta kertaa uteliaisuus näkövammaisten kollegojeni puutteista. Tästä ei kuitenkaan tarvitse riippua. Kun paljon työtä on tehtävä lyhyessä ajassa, jokainen tuottavuusosuus on tavallaan liikaa.

Näiden ongelmien lievittämiseksi mahdollisimman paljon on ensiarvoisen tärkeää, että tunnet valitsemiesi työkalujen jokaisen kaupan pienen pikakuvakkeen ja temppun, jotta voit ajaa pois aikaa, joka on hukkaan toistuviin toimiin. Makronäppäimet, kuoren aliakset, muokkauslaajennukset, jotka antavat sinulle enemmän pikanäppäimiä - nämä ovat pelin nimi.

Mutta joskus työkalut, joiden on tarkoitus auttaa sinua, pääsevät tielle. Näkökollegani käyttävät usein graafisia työkaluja työnsä tiettyjen osa-alueiden hallintaan, ja nämä työkalut eivät useinkaan ole käytettävissä. Tämä vaatii minua - usein paikan päällä - selvittämään jonkinlaisen ratkaisun, jotta voin silti suorittaa saman tehtävän jonkin verran tehokkuudella.

Graafisessa sovelluksessa tämä voi olla komentorivivastaava. Sivustolla voi olla sovellusliittymä. Joskus toinen graafinen työkalu saattaa toimia paremmin kuin tosiasiallisesti. Jatkuva hämmentäminen vaihtoehdoista saavuttamattomalle tekniikalle on jatkuva osa työtä, kun teet sen silmät kiinni. Omien työkalujen tuomisen vapauden saaminen on tästä syystä erittäin tärkeää.

Olen harvoin nähnyt työkalujen käyttöönoton, koska kehittäjät suosivat yleensä voimakkaasti omaa työnkulkua. Mutta työpaikoille, jotka vaativat minua käyttämään erityisiä työkaluja, tästä tulee usein kauppias kaikista tulevista sopimuksistani, jotka otan vastaan. Työkalut ovat niin tärkeitä.

Ensimmäinen ajatuksesi saattaa olla vain käyttää Windowsia, jos MacOS tekee sinusta vähemmän tuottavan. Ihanteellisessa maailmassa se olisi toteuttamiskelpoinen ratkaisu. Erityisesti vanhemmissa kooditukikohdissa kehitystiimit ovat kuitenkin usein keksineet pieniä hakkereita saadakseen vanhemmat koodit ajamaan uudemmilla laitteistoillaan / ohjelmistoillaan, joiden ei edes pitäisi olla enää käynnissä. Nämä hakkeroinnit ovat käyttöjärjestelmäkohtaisia, ja niitä on usein vaikea toistaa Windowsissa - jopa Windows-alijärjestelmää Linuxille käytettäessä. Heillä voi joskus kestää viikkoja saada työtä. Usein se ei ole sen arvoista.

Tällä hetkellä käytän melkein pakollisesti Windows 10-virtuaalikonetta Macin Vmware Fusion -ohjelmassa. Minun on pakko käyttää kahta käyttöjärjestelmää kerralla saadakseni työni aikaan. Windows pitää sisällään verkkoselaimen, valitsemani koodieditorin ja useita muita työkaluja, joita käytän tuottavuuden parantamiseen:

  • Google Chrome
  • VS-koodi
  • kunnollinen PDF-lukija
  • toimistopaketti DOCX- ja XLSX-tiedostojen käsittelyyn

Pohjimmiltaan kaikki todelliset sovellukset toimivat Windows VM: ssä, mikä tekee MacOS: sta enemmän palvelimen, joka vain isännöi sovelluskoodia.

Tämä on hyvä esimerkki vapaudesta käyttää omia työkalujani, joihin viittasin. Kukaan muu joukkueessani ei suorita samaa asetusta kuin minä. Mutta kollegani ovat yleensä tavanneet tämän ymmärtämyksellä ja tuella, koska he näkevät, että saan työn tehdä tällä tavalla.

Esteettömyyttä, etenkin dev-työkaluissa, voi olla uskomattoman vaikea puolustaa. Usein sinua ei oteta vakavasti, kun kysyt, minkä pitäisi olla perusominaisuus. Tavallaan olet vain pyytänyt voidaksesi käyttää sovellusta.

Mutta se ei ole etenemissuunnitelmassa, kehittäjiä ei voida säästää työskentelemällä sen kanssa, sillä ei ole prioriteettia jne. Ovatko syyt työkalun esteettömyyden korjaamiseen melkein kuin kellokoneisto. Muina aikoina luvataan korjauksista, jotka eivät koskaan toteudu.

Haluaisin nähdä tämän paranevan, ja minulla on ollut ilo nähdä sen tapahtuvan yhä uudelleen. Se on edelleen ongelma, joka palaa jatkuvasti, ja kehittäjinä, mukaan lukien minä, meidän pitäisi tehdä paremmin.

Näkökollegani pitävät paljon työkaluja itsestäänselvyytenä. Esimerkiksi .NET-tiimissä on harvinaista nähdä kehittäjä, joka ei käytä Resharperia tuottavuutensa parantamiseen.

Ironista kyllä, tämä Visual Studion laajennus, joka itsessään on melko helposti käytettävissä, käyttää paljon näppäinpainalluksia tehdäksesi sen, mitä se tekee. Luulisi, että se tekisi siitä ihanteellisen työkalun sokealle kehittäjälle, joka käyttää koodaamiseen vain näppäimistöä. Tämän laajennuksen ulostulo on kuitenkin useimmiten saavuttamaton, mikä tekee työkalusta enemmän esteen kuin avun.

Olen houndannut Jetbrainsia vuosia saadakseni heidät korjaamaan tämän työkalun esteettömyyden, mikä jopa tämän kirjoituksen aikaan on kurja. Minut on erotettu mielettömästi, jätetty huomiotta ja olen viimeinkin antanut lupauksia, toistaiseksi täyttämättä. Tämä haluttomuus korjata sitä, mikä on ilmeisesti jo vuosia ollut ongelma, saa minut epäröimään sitoutumista .NET-pohjaiseen asemaan. Vaikka ongelmat ratkaistaisiin ihmeellisesti, kokemukseni sen jättämisestä ratkaisematta niin kauan saisi minut miettimään, milloin se rikkoo jälleen.

Yhdessä ensimmäisistä kehitystiimeistä, joiden kanssa työskentelin, Postmania käytettiin voimakkaasti taustakehittäjien luomien API-päätepisteiden testaamiseen. Postmanilla on useita räikeitä esteettömyysongelmia, jotka vaikeuttavat käyttöä näytönlukuohjelman kanssa. Katso täydellinen esimerkki täyttämättömistä lupauksista tutustumalla tähän GitHub-ongelmaan. Huomaa, että asia on edelleen auki melkein kahden vuoden kuluttua ja että lupauksia annetaan, mutta niitä ei pidetä.

Esteettömyys on usein jälkikäteen, mikä on kiistatta todistettu uudestaan ​​ja uudestaan. Valitettavasti löysyys on hyvä esimerkki tästä. Tämän nyt melkein hylättävän työkalun käytettävyys oli kauhistuttavaa, näytönlukijan käyttäjät eivät yksinkertaisesti voineet työskennellä sen kanssa.

Näemme ehdottomasti parannuksia siinä tilassa, mitä tämä artikkeli osaa osuvasti. Mutta kaikki tämä vie aikaa uskomattoman paljon - kuukausia, toisinaan vuosia, jolloin näytönlukijaa käyttävät ihmiset eivät voi käyttää riittävästi resursseja, joihin kollegansa pääsevät. Tällainen puute voi ja saa ihmiset menettämään työpaikkansa, koska he eivät vain pysty seuraamaan viestintää yrityksessä, jossa he työskentelevät.

Edellä mainitut työkalut (Resharper, Slack, Postman jne.) Ovat avainasemassa valitsemillaan aloilla. Jos sinulla ei ole pääsyä näihin työkaluihin, hankaloitat kehittäjää ja pakotat käyttämään jaksoja, joten sinun pitäisi käyttää työtä työn tekemiseen kiertotapojen ja vaihtoehtoisten työkalujen löytämiseen. Tämä on tuhlaavaa, väsyttävää eikä sen pitäisi olla välttämätöntä, mutta se on ja se on yksi keskeisistä taidoista, jotka minun on pitänyt saada erittäin hyvä pysymään mukana.

Ajan myötä sanon, että näyttää olevan laskusuunta, että tämä on välttämätöntä. Microsoftin, Applen, Googlen ja muiden suurten toimijoiden pyrkimykset saavat yhä useammat ihmiset tietämään tämän melkein jatkuvan taistelun yhdenvertaisesta pääsystä tuottavuuteen. Emme kuitenkaan ole missään nimessä metsästä, mikä kävi selvästi ilmi Gutenberg WordPress -häiriöstä, joka parhaillaan kiihtyy esteettömyysyhteisön kautta.

Sokeat ihmiset ovat markkinarako ohjelmisto- ja web-kehittäjille. Sokeat kehittäjät ovat markkinarako kapealla markkinalla.

Sokeat kehittäjät, jotka pitävät sitä, tulevat tuottaviksi ja työskentelevät kokopäiväisesti, ovat valitettavasti vielä harvinaisempia. Tämä voi ja sen pitäisi muuttua, mutta kunnes se tapahtuu, taistelu esteettömistä kehittäjätyökaluista on taistelua yksin. Toivon, että se on taistelu, jota meidän ei tarvitse taistella tulevaisuudessa, teen parhaani edistääksesi tätä tavoitetta.

Sekalaisia ​​asioita

Haluan lopettaa tämän artikkelin myönteisesti. Se, että olen edelleen tällä alalla, se, että työskentelen kokopäiväistä työtä kehittäjänä, tuo minulle paljon onnea myös kaikkien näennäisesti jatkuvien esteiden kautta. Olen iloinen, että voin osallistua loistavaan kollegaryhmään, joka kohtelee minua tasa-arvoisena ja ajattelee kanssani, kun törmään johonkin, mistä minulla on vaikeuksia.

Haluan painottaa, että vaikka tietojenkäsittelytieteiden ala ei ole esteetön, ihmiset voivat menestyä ja menestyvät CS-työtehtävissä. Edellä kuvatut taistelut ovat varmasti totta, mutta muihin aloihin verrattuna ne ovat ainakin suuressa määrin hallittavissa. Epäilen, kirjoitanko pian artikkelin urani vaihdosta kirurgiksi, hävittäjälentäjäksi tai ammattimaiseksi baseball-pelaajaksi, mutta sitten tekniikka saattaa vielä yllättää minut. Toistaiseksi olen kuitenkin onnellinen missä olen ja minulla on loistava joukkue ympärilläni.

Minulta kysytään usein mielipidettäni, kun on kyse vaikutuksesta työskentelemämme tuotteen esteettömyyteen. Mielipiteeni eivät varmasti saa aina muuttamaan asioita, mutta olen iloinen, että pystyn ainakin saamaan ihmiset tietämään esteettömyyden tärkeyden ja mitä tapahtuu, kun sitä ei oteta huomioon.

Olen loppujen lopuksi elävä hengitysesimerkki siitä, mitä tapahtuu, kun työkalua ei ole tai ei enää ole käytettävissä.

Edellä mainittuun linkitetty WordPress-artikkeli lähettää tämän viestin hyvin selvästi; työkalu, joka on ollut erittäin käyttökelpoinen ja käytettävissä vuosia, on nyt nenäsukellusta. Tätä voi tapahtua kaikille työkaluille, joista sokea kehittäjä riippuu, yrityksen venäläiseen rulettiin niin sanotusti.

Kirjoittaessani tällaisia ​​artikkeleita, pitämällä puheita, kouluttamalla kehittäjiä ja kokeilemalla uusia työkaluja, uusia tekniikoita ja uusia menetelmiä toivon pysyvän käyrän edellä. Kirjoittaessani havainnot toivon, että opetan muille kaupan temppuja, jotka sain selville kokeilemalla ja erehdyksellä, joten tämän kentän kynnysarvo laskee näytönlukijan käyttäjille.

Tämän artikkelin päätavoitteet ovat linjassa monien, ellei kaikkien näiden tavoitteiden kanssa. Toivon, että olen antanut sinulle vilauksen sekä sokean ohjelmoijan taisteluista että positiivisista puolista.

Toivon, että olen huomauttanut, että vaikka tämä on mahdollista, voimme ja meidän pitäisi parantaa kokemusta valtavasti. Toivon, että olen herättänyt tämän artikkelin lukijoita ajattelemaan, todella ajattelemaan, mitä seurauksia ohjelmistoista on, joita ei voi käyttää, ja toivon, että olen osoittanut, että jopa kaikkien esteiden kautta on erittäin mahdollista tulla hyväksi, jopa suureksi tällä alalla kerran saavutat pakenemisnopeuden.

Haluan vain viitata myönteiseen muistiinpanoon, jonka halusin vain lopettaa tämän artikkelin mainitsemalla kaksi valtavaa saavutettavuutta koskevaa voittoa, jotka ovat täydellisiä esimerkkejä siitä, miten olemme menestyneet paremmin. Molemmat olen ollut kunniajäsen.

Koodaamisen oppimiseksi monet interaktiivisemmista lähteistä, kuten Codeacademy, eivät ole kovin saatavilla. Tämä liittyy siihen, että näissä projekteissa käytettävät komponentit eivät ole käytettävissä. Onneksi sitä jo työstetään.

Yksi resursseista, joka on saanut paljon vetovoimaa viime vuosina, on freeCodeCamp. Tällä aloitteella oli aiemmin melko vakavia esteettömyysongelmia, jotka viime aikoina on melkein kokonaan korjattu ja uudistettu, mikä tekee alustasta erittäin kannattavan näytönlukuohjelmien käyttäjille, jotka haluavat oppia koodaamaan.

Tällä on paljon tekemistä Monaco Editorin kanssa, joka on erittäin helppokäyttöinen verkkopohjainen koodieditori ja joka on itse asiassa Visual Studio Code -sovelluksen muokkauskomponentti. Kun tämä toimittaja ilmestyi, se oli kirjaimellisesti täysin tavoitettavissa. Suhteellisen lyhyessä ajassa tämä ei kuitenkaan vain korjattu suuressa määrin, vaan tekee nyt freeCodeCampin kaltaiset projektit oletusarvoisesti saataville, koska ne käyttävät samaa komponenttia. Tämän on oltava aina, tämän toivon näkevän enemmän, kun pidän tätä. Ja mielestäni on korkea aika palata ohjelmointiin.