Hogyan lehet fejlesztői állást szerezni vakon: Tanács egy vak fejlesztőtől, aki látó csapat mellett dolgozik

Holland fejlesztő vagyok, és nemrég szereztem diplomát informatikából. Teljesen vak vagyok, és képernyő-olvasót használok a munkám elvégzéséhez.

A vak fejlesztő alattomos útját járom - egy utat, amelyet leírom, valamint a benne található különféle csapdákat.

Különböző vállalatoknál dolgoztam háttér-webfejlesztőként, akik lassan, de biztosan egyre több front-end munkára is áttérnek, a technológiai háttér az, ami.

Különböző technológiákkal dolgoztam, a c # -től a Pythonig és a Rails-től a JavaScript-ig.

Emellett akadálymentességi szakértő vagyok, ismerem a szokásos gyanúsítottakat, például WCAG-ot, ATAG-ot és barátaimat. Azt értem ebben az esetben, hogy jártas vagyok, hogy ezeket a készségeket professzionális körülmények között használtam fel akadálymentességi ellenőrzések elvégzésével weboldalakon, webes alkalmazásokban és asztali alkalmazásokban.

Az elméleti ismereteket is felhalmoztam a Deque Egyetem képzési programjának elvégzésével, amelyet erősen ajánlani tudom, ha szilárd alapokra vágyik az akadálymentesség alapjaiban.

Ez a hozzáférhetőségi előírásokkal való jártasság elsősorban annak a következménye, hogy magam is megkövetelem, hogy a tartalom hozzáférhető legyen annak használatához.

Ez a leírás időnként tényszerű, időnként véleményalapú lesz. Legtöbbször egyetlen egyén tapasztalatai lesznek, akik a megélhetéshez kódot írnak anélkül, hogy a szemükkel segítenék látni, mit csinál.

Remélem, hogy ez a mese rávilágít a munkafolyamatomra és azokra a dolgokra, amelyekkel foglalkoznom kell annak érdekében, hogy a munkafolyamatot rendszeresen folytassam. Végül pillanatkép lesz mindenféle dologról, amit megtanultam és még mindig tanulok erről a folyamatról.

Az utazás megkezdése: betenni az ajtót

Ahhoz, hogy látó kollégákkal dolgozhasson egy dev csapatnál, nyilván először fel kell vennie. Ennek megvalósítása azt jelenti, hogy át kell ugrania néhány érdekes gácsán, amelyek nem feltétlenül nyilvánvalóak, ezért a cikk egy részét itt szentelem neki.

Az álláskeresés vak fejlesztőként érdekes tevékenység. Csakúgy, mint bárki, aki bármikor jelentkezik bármilyen állásra, ez önéletrajzzal és a legtöbb esetben kísérőlevéllel kezdődik.

Az a kérdés, amellyel először szembesültem, hogy azonnal értesítenem-e a céget vakságomról, vagy sem. Megállapítottam, hogy jobb, ha ezt nem teszem meg, annak az egyszerű oknak az oka, hogy felesleges hangsúlyt fektet a vakságra, ha mégis.

Fejlesztő vagyok, olyan végzettséggel, tapasztalattal és készségekkel, amelyeket megszereztem és keményen dolgoztam, és ezek az érdemek, amelyekért fel akarok venni.

Vaknak lenni számomra jelentéktelen dolog e képességek mellett, hacsak nem lehet valahogyan eszköz a pozíció szempontjából. Ez igaz lehet például egy akadálymentesítéssel kapcsolatos pozícióra.

Ez meglehetősen érdekes helyzetekhez vezetett, kezdve a fehér vesszőm vagy a későbbi vakvezető kutyám elképedt pillantásaitól kezdve a sietve kitalált kifogásokig az állásinterjú idő előtti befejezéséhez.

Bár a fogyatékossággal élő személyek megkülönböztetése illegális, időnként meglehetősen könnyű másnak álcázni. Erre kell figyelni. Szerencsére ez nem történik meg olyan gyakran, de ha nem említem itt, az gyorsan és lazán eljátszana az igazsággal.

A legjobb esetben ez egy gondos egyensúlyozási intézkedés. Manapság hajlamos vagyok megemlíteni a vakságomat az utolsó pillanatban, amikor telefonon tárgyalok egy állásinterjúról, kijelentve, hogy kutyát hozok az irodába, és megkérdezem, nem allergiás-e valaki a kutyákra. Általában a következő kérdés egy nagyon érthető "Miért?" és csak ezután említem meg, a lehető legkisebbre csökkentve. Legtöbbször ez a megközelítés legalább lehetőséget adott arra, hogy bejöhessek egy első interjúra.

További akadályok a kötelező szűrések vagy értékelések, amelyek nem hozzáférhetők, ezek általában szabványosított tesztek, amelyektől nem lehet eltérni a jelentkező cég szerint.

Ennek az a szokásos következménye, hogy az állásinterjú-eljárást általában ott fejezi be. Nyilvánvaló, hogy a kérdést erőltetni lehet, de a pozitív munkakörnyezet megteremtése érdekében ezt nem igazán tudom ajánlani.

Ez ahhoz kapcsolódik, hogy vakon státusza fent említett. Minél többet adsz ki belőle, annál nagyobb jelentőséget kap az a személy, aki fontolgatja az álláspályázatodat.

A következők általában szinte szkriptelt eljárások. Az állásinterjú az esetek többségében gond nélkül zajlik, de megszerez egy extra komponenst, amelyet a "Monkey show, Monkey do" résznek hívok.

Az interjúnak ezt a részét általában egy olyan kérdés előzi meg: "Valószínűleg el tudod képzelni, miért kérdezem, de ... hogyan? Hogyan programozhatsz anélkül, hogy megnéznéd?"

Ezen a ponton elmagyarázom a képernyőolvasókról, annak a lángolóan gyors ütemnek, amire kiköpik az információkat, és általában kiszedem a laptopomat, hogy bemutassak egy kicsit.

Rendszerint csodálkozom. Egyszer az emberek még tapsoltak is értem.

Bár ez természetesen nagyon hízelgő, csodálattal bámulják, hogy valami olyasmit cselekszenek, ami második természetű, időnként hajlamos megöregedni. Ez semmi személyes. Csak lehetséges, hogy ma te vagy a harmadik ember. Az ugyanazokra a kérdésekre adott válaszok minden bizonnyal ugyanabba a kategóriába tartoznak.

Ennek eredményeként írtam egy cikket, az elsőt a freeCodeCamp-ról, hogy megválaszoljam azokat a kérdéseket, amelyeket gyakran kapok, amikor vak fejlesztő vagyok.

Szerencsére ez a demonstráció, valamint a bámulás pillanatnyi ideje általában nem tart sokáig. Megállapítottam, hogy ezzel sokkal könnyebben meg lehet magyarázni, hogy miért jelent valami kihívást vagy sem a továbbiakban.

Ilyen kiállítás - bár néha kényelmetlen - végül nagyon megéri. Végül is a reakciók érthetőek. Olyat csinálok, amit sokan el sem tudnak képzelni látás nélkül.

Eszközeinek kiválasztása: Állandó küzdelem az állandó zsonglőrködésért

Különböző tevékenységek elvégzéséhez számos eszközre van szükség a hatékonyság érdekében. A hegymászóknak kötélre, horgonyhorgokra stb. Lesz szükségük. A programozóknak pedig eszközökre van szükségük az információk programozásához, teszteléséhez, együttműködéséhez, információk megosztásához és megkereséséhez stb.

Sajnos itt sok ember kilép. Talán még inkább sajnos ez teljesen érthető.

Annak a munkának a mennyisége, amelyet be kell töltenie ahhoz, hogy egy rendes verem alakuljon ki, amely megfelel a használati eseteknek - a normál 40 órás munkahéten felül - kissé elsöprő lehet.

Az operációs rendszer az első akadály. Nagyon sok dev csapat itt Hollandiában kizárólag Mac-eket használ. Sajnos azonban a MacOS képernyőolvasó, a Voiceover számára elérhető akadálymentességi API-k sok esetben alacsonyabb rendűek, mint a Windows-ban.

A Mac számítógépen egy feladat végrehajtásához szükséges billentyűleütések száma gyakran magasabb, mint a Windows rendszerén, a MacOS pedig nagyon egérorientált operációs rendszer.

Végül maga a képernyőolvasó nem rendelkezik sok kényelmi funkcióval és testreszabási lehetőséggel, mint a Windows társai.

Egy olyan iparágban, amely állítólag egyaránt elérhető a vakok és a látók számára egyaránt, ezek a hiányosságok komoly termelékenységi találatokat eredményeznek a látó kollégáimmal szemben. Ez megterhelő lehet, és néha megértést és rugalmasságot igényel a kollégáktól.

Miután megismerte a kódbázist, és az eszközöket rendezték, sok feladatot ugyanolyan gyorsan elvégezhet, mint a látó kollégák.

Ennek az ismeretnek a megszerzése azonban időbe telhet. Különösen, ha az eszközök nem annyira elérhetőek, mint amennyire csak lehet. Elveszítheti a drága időt a birkózásban egy olyan eszközzel, amely állítólag segít a munkájában, de inkább akadályozza vagy akár blokkolja is teljesen.

Szerencsére általában megértéssel és sokszor kíváncsisággal találkoztam látó kollégáim hiányosságai iránt. Ez azonban nem múlik rajta. Amikor sok munkát kell elvégezni rövid idő alatt, minden termelékenységi ütem bizonyos értelemben túl sok.

Ezeknek a problémáknak a lehető legnagyobb mértékű enyhítése érdekében kiemelkedő fontosságú, hogy a választott eszközeivel ismerje a kereskedelem minden apró parancsikonját és trükkjét, hogy leborotválja a folytonosan ismételt cselekvésekre pazarolt időt. Makróbillentyűk, héj-álnevek, szerkesztőbővítmények, amelyek több billentyűparancsot adnak Önnek - ez a játék neve.

De néha azok az eszközök, amelyek állítólag segítenek neked, inkább utadba kerülnek. Ahol látó kollégáim gyakran grafikus eszközöket használnak munkájuk bizonyos aspektusainak kezeléséhez, ezek az eszközök gyakran nem érhetők el. Ez megköveteli, hogy - gyakran a helyszínen - találjak ki valamilyen megoldást, hogy továbbra is ugyanazt a feladatot végezzem némi hatékonysággal.

Grafikus alkalmazások esetén ez parancssori megfelelő lehet. Lehet, hogy egy webhely rendelkezik API-val. Előfordulhat, hogy egy második grafikus eszköz jobban működik, mint a de facto. Az elérhetetlen technológia állandó alternatíváinak elgondolása a munka állandó része, amikor csukott szemmel végzi. Ezért nagyon fontos, hogy megkapja a szabadságot, hogy saját eszközeit hozza magával.

Ritkán láttam olyan eszközöket, amelyek kényszerítésre kerültek, mert a fejlesztők általában erősen preferálják saját munkafolyamatukat. Azoknál a munkáknál, amelyek ragaszkodnak hozzám konkrét eszközök használatához, ez gyakran üzletkötővé válik minden jövőbeni szerződésem számára, amelyet vállalnék. Az eszközök olyan fontosak.

Első gondolata az lehet, hogy csak használja a Windows rendszert, ha a MacOS kevésbé produktívvá teszi Önt. Egy ideális világban ez életképes megoldás lenne. Azonban, főleg a régebbi kódbázisoknál, a fejlesztői csapatok gyakran kitaláltak néhány feltörést annak érdekében, hogy a régebbi kódokat futtassák újabb hardverükön / szoftvereiken, amelyeknek eleve nem is kellene többé futniuk. Ezek a feltörések operációs rendszer-specifikusak, és gyakran nehéz őket megismételni a Windows rendszeren - még a Windows alrendszer Linux alatt használata közben is. Néha akár hetekbe is beletelhet a munka. Gyakran nem éri meg.

Most éppen ezért szinte kötelezően futtatok egy Windows 10 virtuális gépet a Mac Vmware Fusion-en belül. Kénytelen vagyok két operációs rendszert egyszerre használni a munkám elvégzéséhez. A Windows tartja a webböngészőmet, a választott kódszerkesztőt és számos más eszközt, amelyeket a termelékenységem növelésére használok:

  • Google Chrome
  • VS kód
  • egy tisztességes PDF-olvasó
  • irodai programcsomag DOCX és XLSX fájlokkal való munkavégzéshez

Alapvetően az összes valós alkalmazás a Windows virtuális gépén fut, így a MacOS inkább egy olyan kiszolgáló része, amely csak az alkalmazás kódját tárolja.

Ez jó példa a saját eszközeim használatának szabadságára, amire utaltam. A csapatomban senki más nem futtatja ugyanazt a beállítást, mint én. De ezt általában kollégáim megértéssel és támogatással érték el, mert láthatják, hogy így tudom elvégezni a munkát.

A hozzáférhetőséget, különösen a dev eszközökben, hihetetlenül nehéz megvédeni. Gyakran nem veszik komolyan, amikor azt kérdezi, hogy mi legyen az alapvető jellemző. Bizonyos értelemben csupán azt kéri, hogy tudja használni az alkalmazást.

De nem szerepel az ütemtervben, a fejlesztőket nem lehet megkímélni attól, hogy dolgozzanak rajta, nincs prioritása stb. Ennek oka az, hogy az eszköz hozzáférhetőségét szinte nem az óraműhöz rendezik. Máskor olyan javításokra ígérnek, amelyek soha nem valósulnak meg.

Örülnék, ha ez javulna, és örömmel láttam, hogy ez újra és újra megtörténik. Ez továbbra is probléma, amely folyamatosan visszatér, és mint fejlesztőknek, köztük nekem is jobban kellene mennünk.

Látó kollégáim sok szerszámot természetesnek vesznek. Például egy .NET csapatban ritkán lehet olyan fejlesztőt látni, amely nem a Resharper programot használja a termelékenységük növelésére.

Ironikus módon ez a Visual Studio kiterjesztése, amely maga is elérhető, sok billentyűleütést használ arra, hogy mit csinál. Azt gondolná, hogy ez egy ideális eszköz egy vak fejlesztő számára, aki csak billentyűzetet használ a kódoláshoz. Ennek a kiterjesztésnek a kimenete azonban gyakran elérhetetlen, így az eszköz inkább akadályt, mint segédeszközt jelent.

Évek óta verem a Jetbrains-t, hogy kijavítsam az eszköz hozzáférhetőségét, ami még az írás idején is borzalmas. Udvariatlanul elbocsátottak, figyelmen kívül hagytak és végül ígéreteket tettem rá, mindeddig nem teljesítettem. Ez a hajlandóság az évek óta fennálló nyilvánvaló probléma megoldására hajlandóvá tesz engem a .NET-alapú pozíció elkötelezettségére. Még akkor is, ha a problémák csodával határos módon megoldódnak, a sokáig megoldatlanul hagyott események elgondolkodtatnának, hogy mikor fog megint szakadni.

Az egyik első fejlesztői csapatnál, akivel dolgoztam, a Postman-t erősen alkalmazták a háttér-fejlesztők által létrehozott API-végpontok tesztelésére. A Postmannak számos kirívó akadálymentességi problémája van, amelyek megnehezítik a képernyõolvasóval való használatot. A be nem teljesített ígéretek tökéletes példája érdekében tekintse meg ezt a GitHub-kérdést. Figyelje meg, hogy a kérdés majdnem 2 év után is nyitott és ígéreteket tesznek, de nem tartják be őket.

Az akadálymentesség gyakran utólagos gondolat, ami tagadhatatlanul újra és újra bebizonyosodik. A lazaság sajnos erre jó példa. Ennek a ma már szinte elutasíthatatlan eszköznek a hozzáférhetősége óriási volt, a képernyőolvasók felhasználói egyszerűen nem tudtak dolgozni vele.

Határozottan tapasztalunk javulást ezen a téren, amit ez a cikk találóan bemutat. De mindez hihetetlenül sok időbe telik - hónapok, időnként évek, amelyekhez a képernyőolvasót használó emberek nem tudják megfelelően elérni azokat az erőforrásokat, amelyekhez kollégáik hozzájutnak. Ez a fajta hiány miatt az emberek elveszíthetik munkájukat, mert egyszerűen nem tudnak lépést tartani azzal a vállalaton belüli kommunikációval, ahol dolgoznak.

A fent említett eszközök (Resharper, Slack, Postman stb.) Kulcsszerepet játszanak a választott területen. Ha nem fér hozzá ezekhez az eszközökhöz, akkor fejlesztőként hátráltatja Önt, és ciklusok eltöltésére kényszeríti, ezért inkább arra kell költenie, hogy inkább munkát végezzen, és inkább alternatív eszközöket keressen. Ez pazarló, fárasztó és nem szükséges. De ez az, és ez az egyik alapvető készség, amellyel nagyon jól tudtam megszerezni a lépést.

Az idő múlásával azt mondom, hogy úgy tűnik, hogy ennek szükségessége csökkenő tendenciát mutat. A Microsoft, az Apple, a Google és más nagy szereplők erőfeszítései egyre több embert tudatosítanak ebben a szinte állandó harcban a termelékenységhez való egyenlő hozzáférésért. Semmiképp sem vagyunk ki az erdőből, amit egészen egyértelműen bizonyított a Gutenberg WordPress-hiba, amely jelenleg az akadálymentességi közösségen keresztül tombol.

A vak emberek piaci rést jelentenek a szoftver- és webfejlesztők számára. A vak fejlesztők egy niche piac egy niche piacon belül.

A vak fejlesztők, akik ezt tartják, produktívvá válnak és teljes munkaidőben állnak, sajnos még ritkábbak. Ez változhat és kell is, de addig, amíg ez nem történik meg, az elérhető fejlesztői eszközökért folytatott harc önmagában vívja magát. Remélem, hogy ez egy olyan harc, amelyet a jövőben nem kell megvívnunk, mindent megteszek, hogy hozzájáruljak e cél eléréséhez.

Limlom

Pozitívan szeretném befejezni ezt a cikket. Az a tény, hogy még mindig ezen a területen vagyok, az a tény, hogy fejlesztőként teljes munkaidőben dolgozom, rengeteg boldogságot jelent számomra az összes látszólag állandó akadályon keresztül is. Örülök, hogy hozzájárulhatok egy nagyszerű kollégacsapathoz, amely egyenrangúként kezel és velem gondol, amikor olyan dologba ütközök, amellyel bajom van.

Szeretném hangsúlyozni, hogy bár az informatika területe nem mentes az akadályoktól, az emberek boldogulhatnak és boldogulnak a CS-hez kapcsolódó munkákban. A fent leírt küzdelmek bizony igazak, de más területekhez képest legalább nagy mértékben kezelhetők. Kétlem, hogy hamarosan írok egy cikket arról, hogy karrieremről sebészre, vadászpilótára vagy profi baseball játékosra váltottam, de akkor a technológia még meglephet. Egyelőre mégis boldog vagyok, ahol vagyok, és nagyszerű csapat áll körülöttem.

Gyakran kérik tőlem a véleményemet, amikor a termék elérhetőségére gyakorolt ​​hatásról van szó. Véleményem határozottan nem mindig fogja megváltoztatni a dolgokat, de örülök, hogy legalább képes vagyok felhívni az emberek figyelmét az akadálymentesség fontosságára és arra, hogy mi fog történni, amikor azt figyelmen kívül hagyják.

Végül is élő lélegző példa vagyok arra, hogy mi történik akkor, amikor egy eszköz nem elérhető, vagy már nem elérhető.

A fent hivatkozott WordPress cikk nagyon egyértelműen elküldi ezt az üzenetet; egy olyan eszköz, amely évek óta nagyon használható és elérhető, ma már az orrba merülés. Ez történhet minden olyan eszközzel, amelyen egy vak fejlesztő függ, úgymond a vállalkozás orosz rulettje.

Ilyen cikkek írásával, előadásokkal, fejlesztők oktatásával és új eszközök, új technikák és új módszerek kísérletezésével remélem, hogy a görbe előtt maradok. Megállapításom megírásával remélem, hogy megtanítom másoknak a szakma trükkjeit, amelyeket próbával és hibával megtudtam, így a képernyőolvasók felhasználói számára csökken a küszöb e területre.

A cikk fő céljai sokhoz igazodnak, ha nem is mindhez. Remélem, bepillantást engedtem mind a vak programozó küzdelmeibe, mind a pozitívumaiba.

Remélem, rámutattam, hogy bár ez lehetséges, a tapasztalatokon óriási mértékben javítani és javítani kell. Remélem, arra késztettem a cikk olvasóit, hogy gondolkodjanak el, valóban gondolkodjanak el az elérhetetlen szoftver következményeiről, és remélem, megmutattam, hogy minden akadályon túl is nagyon jó lehet, akár egyszer is nagyszerű ezen a téren eléri a menekülési sebességet.

Az imént említett pozitív megjegyzés tükrében szeretném befejezni ezt a cikket két hatalmas akadálymentesítési győzelem megemlítésével, amelyek tökéletes példák arra, hogyan teljesítettünk jobban, és mindkettőhöz megtisztelő közreműködő voltam.

A kódolás elsajátításához sok olyan interaktív erőforrás, mint például a Codeacademy, nem túl hozzáférhető. Ennek oka az, hogy az ezekben a projektekben használt különféle összetevők nem érhetők el. Szerencsére ezen már dolgoznak.

Az egyik erőforrás, amely az utóbbi években nagyon vonzóvá vált, a freeCodeCamp. Ennek a kezdeményezésnek korábban meglehetősen súlyos akadálymentesítési problémái voltak, amelyeket a közelmúltban szinte teljesen kijavítottak és átalakítottak, ami a platformot nagyon életképessé tette a képernyőolvasók számára, akik meg akarják tanulni a kódolást.

Ennek sok köze van a Monaco Editorhoz, amely egy nagyon hozzáférhető webalapú kódszerkesztő, és valójában a Visual Studio Code által használt szerkesztő komponens. Ez a szerkesztő, amikor megjelent, szó szerint teljesen hozzáférhetetlen volt. Viszonylag rövid idő alatt azonban ezt nem csak nagy mértékben sikerült kijavítani, hanem az alapértelmezés szerint elérhetővé teszi az olyan projekteket, mint az freeCodeCamp, mert ugyanazt az összetevőt használják. Ennek mindig így kell lennie, ezt remélem, hogy többet fogok látni, miközben ezt tartom. És ezzel azt hiszem, itt az ideje, hogy visszatérjek a programozáshoz.