Как да получите работа на разработчик, когато сте сляп: Съвет от слеп разработчик, който работи заедно с зрящ екип

Аз съм холандски разработчик и наскоро завърших бакалавърска степен по ИТ. Напълно съм сляп и използвам екранен четец, за да си върша работата.

Вървя по коварния път на слепия разработчик - път, който ще опиша, както и различните капани, които той съдържа.

Работил съм за различни компании като back-end уеб разработчик, който бавно, но сигурно също мигрира към все повече и повече работа отпред, технологичният пейзаж е такъв, какъвто е.

Работил съм с различни технологии, от c # до Python и от Rails до JavaScript.

Освен това съм експерт по достъпност, запознат с обичайните заподозрени като WCAG, ATAG и приятели. Това, което имам предвид под опитен в този случай, е, че съм използвал тези умения в професионална обстановка, като съм извършвал одити за достъпност на уебсайтове, уеб приложения и настолни приложения.

Също така натрупах теоретични знания, като преминах през програмата за обучение на Deque University, която мога горещо да препоръчам, ако искате стабилна основа в основите на достъпността.

Това владеене на разпоредбите за достъпност е главно следствие от факта, че аз самият изисквам съдържанието да бъде достъпно, за да мога да го използвам.

Това описание понякога ще бъде фактическо, понякога основано на мнение. По-голямата част от времето ще бъде опитът на отделен човек, който пише код за препитание, без да използва очите си, за да му помогне да види какво прави.

Надявам се тази история да хвърли малко светлина върху работния ми процес и нещата, с които трябва да се справя, за да поддържам този работен процес редовно. И накрая, това ще бъде моментна снимка на всички неща, които научих и все още уча за този процес.

Започване на вашето пътуване: стъпване във вратата

За да работите за екип за разработчици с зрящи колеги, очевидно първо ще трябва да се наемете. Това да се случи означава, че трябва да прескочите някои интересни неща, които може да не са очевидни веднага, поради което тук посвещавам част от статията.

Търсенето на работа като сляп предприемач е интересна дейност. Както всеки друг кандидатстващ за някоя работа някога, той започва с автобиография и в повечето случаи мотивационно писмо.

Въпрос, с който се сблъсках първоначално, беше дали трябва незабавно да уведомя компанията за слепотата си или не. Открих, че като цяло е по-добре да не го правите поради простата причина, поради която поставяте ненужен акцент върху слепотата, ако го направите.

Аз съм разработчик с квалификация, опит и умения, които съм спечелил и съм работил усилено, и това са достойнствата, за които искам да бъда нает.

Да бъда сляп за мен е несъществено нещо до тези умения, освен ако по някакъв начин не може да бъде от полза за позицията. Това например би било вярно за позиция, свързана с достъпността.

Това доведе до някои доста интересни ситуации, от объркани погледи към бялата ми бастун или по-късно куче водач, до набързо измислени оправдания за преждевременно прекратяване на интервюто за работа.

Въпреки че дискриминирането на някой с увреждане е незаконно, понякога е доста лесно да се прикрие като нещо друго. Това е нещо, за което трябва да внимавате. За щастие, това не се случва толкова често, но ако не го споменем тук, ще си поиграем бързо и небрежно с истината.

Това е внимателен балансиращ акт в най-добрите случаи. В наши дни съм склонен да споменавам слепотата си в последния момент, когато договарям интервю за работа по телефона, като заявявам, че ще доведа куче в офиса и ще попитам дали някой е алергичен към кучета. Обикновено следващият въпрос е много разбираемо "Защо?" и едва тогава ще го спомена, свеждайки го до минимум, доколкото е възможно. През повечето време този подход ми дава поне шанс да вляза на първо интервю.

Други пречки са задължителните прожекции или оценки, които не са достъпни, това обикновено са стандартизирани тестове, от които не може да се отклонява според компанията, за която кандидатствате.

Това има обичайните последици от обикновено приключване на процедурата за интервю за работа точно там. Очевидно проблемът може да бъде принуден, но в духа на създаването на положителна работна среда, това наистина не е нещо, което мога да препоръчам.

Това е свързано с гореспоменатия акцент върху вашия статус на сляп човек. Колкото повече го правите, толкова по-голямо значение той придобива за човека, който разглежда кандидатурата ви за работа.

Това, което следва, обикновено е почти скриптова процедура. В повечето случаи интервюто за работа протича без проблеми, но получава допълнителен компонент, който обичам да наричам частта „Monkey show, Monkey do“.

Тази част от интервюто обикновено се предшества от въпрос като: „Вероятно можете да си представите защо питам, но ... как? Как програмирате, без да търсите?“

В този момент обяснявам за четците на екрана, невероятно бързата скорост, на която изплюват информация и обикновено изваждам лаптопа си, за да направя малко демонстрация.

Обикновено получавам погледи на удивление. Веднъж дори хората пляскаха за мен.

Въпреки че това, разбира се, е много ласкателно, гледането с възхищение от това, че правите нещо, което е втора природа, има тенденция да остарява от време на време. Това не е нищо лично. Възможно е да сте третият човек, който прави това днес. Отговорите на едни и същи въпроси отново и отново със сигурност попадат и в същата категория.

В резултат на това написах статия, всъщност първата ми на freeCodeCamp, за да отговоря на някои от въпросите, които често получавам, когато става въпрос за сляп разработчик.

За щастие както тази демонстрация, така и този моментен период на гледане обикновено не траят много дълго. Открих, че това прави много по-лесно обяснението защо нещо е или не е предизвикателство по-надолу по пътя.

Да бъдеш изложен така - макар и понякога неудобно - в крайна сметка си струва. В крайна сметка реакциите са разбираеми. Правя нещо, което много хора дори не могат да си представят, че правят без зрение.

Избиране на вашите инструменти: Постоянната борба за постоянното жонглиране

За различни занимания ви е необходим набор от инструменти, за да бъдете ефективни. Алпинистите ще се нуждаят от въже, анкерни куки и т.н. А програмистите се нуждаят от инструменти за програмиране, тестване, сътрудничество, споделяне и търсене на информация и т.н.

За съжаление, тук много хора напускат. Може би още по-голямо съжаление, това е напълно разбираемо.

Количеството работа, което трябва да положите, за да стартирате приличен стек, който работи за вашия случай на употреба - в допълнение към вашата нормална 40-часова работна седмица - може да бъде малко поразително.

Операционната система е първото препятствие. Много разработчици тук в Холандия използват изключително Mac. За съжаление обаче API за достъпност, достъпни за четеца на екрана на MacOS, Voiceover, в много случаи отстъпва на тези в Windows.

Количеството натискания на клавиши, необходимо за изпълнение на задача на Mac, често е по-голямо от това на Windows, като MacOS е много ориентирана към мишката операционна система.

И накрая, на самия екранен четец липсват много удобни функции и опции за персонализиране на неговите колеги на Windows.

В индустрия, която би трябвало да бъде еднакво достъпна както за незрящи, така и за зрящи, тези недостатъци се превръщат в сериозни хитове за производителност в сравнение с моите зрящи колеги. Това може да бъде стресиращо и изисква понякога разбиране и гъвкавост от моите колеги.

След като се запознаете с кодова база и инструментите са подредени, можете да изпълнявате много задачи точно толкова бързо, колкото и зрящите колеги.

Постигането на това познаване обаче може да отнеме време. Особено ако инструментите не са толкова достъпни, колкото могат да бъдат. Можете да загубите ценно време в борба с инструмент, който трябва да ви помогне в работата, а по-скоро пречи или дори ви блокира изцяло.

За щастие обикновено се срещах с разбиране и много пъти с любопитство към недостатъците на зрящите ми колеги. Това обаче не е нещо, от което да разчитаме. Когато трябва да се свърши много работа за кратък период от време, всяко попадение в производителността в известен смисъл е твърде много.

За да облекчите възможно най-много тези проблеми, от първостепенно значение е да знаете всеки малък пряк път и трик от търговията с избраните от вас инструменти, за да избръснете загубеното време за действия, които повтаряте през цялото време. Макро клавиши, псевдоними на черупки, разширения на редактори, които ви дават повече клавишни комбинации - това е името на играта.

Но понякога инструментите, които трябва да ви помогнат, вместо това ще ви пречат. Когато моите зрящи колеги често използват графични инструменти за управление на определени аспекти от работата си, тези инструменти често са недостъпни. Това изисква от мен - често на място - да измисля някакво заобиколно решение, за да продължа да изпълнявам същата задача с известна доза ефективност.

За графично приложение това може да е еквивалент на командния ред. Уебсайтът може да има API. Понякога втори графичен инструмент може да работи по-добре от фактическия. Постоянното озадачаване на алтернативи за недостъпна технология е постоянна част от работата, когато го правите със затворени очи. Поради тази причина е много важно да получите свободата да носите свои инструменти.

Рядко съм виждал да се налагат инструменти, тъй като разработчиците обикновено предпочитат собствения си работен процес. Но за работните места, които настояват да използвам специфични инструменти, това често се превръща в прекъсвач за всички бъдещи договори, които бих поел. Инструментите са толкова важни.

Първата ви мисъл може да е просто да използвате Windows, ако MacOS ви прави по-малко продуктивни. В идеалния свят това би било жизнеспособно решение. Въпреки това, особено в по-старите кодови бази, екипите за разработчици често са измисляли малки хакове, за да накарат по-стария код да работи на по-новия им хардуер / софтуер, който дори не би трябвало да работи вече на първо място. Тези хакове са специфични за операционната система и често са трудни за възпроизвеждане в Windows - дори докато използвате подсистемата на Windows за Linux. Понякога могат да отнемат седмици, за да започнат работа. Често не си струва.

В момента поради тази причина почти задължително работя с виртуална машина с Windows 10 в рамките на Vmware Fusion на Mac. Принуден съм да използвам две операционни системи наведнъж, за да свърша работата си. Windows държи моя уеб браузър, избрания от мен редактор на код и различни други инструменти, които използвам, за да повиша производителността си:

  • Google Chrome
  • VS код
  • приличен PDF четец
  • офис пакет за работа с DOCX и XLSX файлове

По принцип всички реални приложения се изпълняват на Windows VM, което прави MacOS част повече от сървър, който просто хоства кода на приложението.

Това е добър пример за свободата да използвате собствените си инструменти, за които споменах. Никой друг в моя екип не изпълнява същата настройка като мен. Но това обикновено се среща с разбиране и подкрепа от моите колеги, защото те виждат, че мога да свърша работата по този начин.

Достъпността, особено при разработчиците, може да бъде невероятно трудна за защита. Често не ви приемат сериозно, когато питате за това, което трябва да бъде основна характеристика. В известен смисъл вие просто искате да можете да използвате приложението.

Но това не е в пътната карта, разработчиците не могат да бъдат пощадени да работят по него, той няма приоритет и т.н. Има причини да не се фиксира достъпността на инструмента почти като часовник. Друг път се дават обещания за поправки, които никога не се реализират.

Бих се радвал да видя това да се подобри и имах удоволствието да виждам това да се случва от време на време. Все още е проблем, който продължава да се връща, но като разработчици, включително и аз, трябва да се справим по-добре.

Моите зрящи колеги приемат много инструменти за даденост. Например в .NET екип рядко може да се види разработчик, който не използва Resharper за повишаване на тяхната производителност.

По ирония на съдбата, това разширение за Visual Studio, което е доста достъпно, използва много натискания на клавиши, за да прави това, което прави. Бихте си помислили, че това би го направило идеален инструмент за сляп разработчик, който използва само клавиатура за кодиране. Изходът на това разширение обаче е по-често недостъпен, което прави инструмента по-скоро пречка, отколкото помощ.

От години преследвам Jetbrains, за да ги накарам да поправят достъпността на този инструмент, което дори по времето на това писане е бездна. Бях уволнено уволнен, игнориран и накрая дадох обещания, досега неизпълнен. Това нежелание да се поправи очевидно проблемът, който съществува от години, ме кара да се колебая да се ангажирам на позиция, базирана на .NET. Дори ако проблемите се решат по чудо, опитът да го оставя нерешен толкова дълго ще ме накара да се чудя кога ще се счупи отново.

В един от първите разработчици, с които работих, Postman беше използван силно за тестване на крайни точки на API, създадени от back-end разработчиците. Пощальонът има редица очевидни проблеми с достъпността, които затрудняват използването му с четец на екран. За перфектен пример за неизпълнени обещания, погледнете този проблем с GitHub. Забележете, че въпросът все още е отворен след почти 2 години и обещанията се дават, но не се спазват.

Достъпността често е последваща мисъл, нещо, което несъмнено се доказва отново и отново. Slack, за съжаление, е добър пример за това. Достъпността на този сега почти неотменим инструмент беше ужасна, потребителите на екранен четец просто не можеха да работят с него.

Определено виждаме подобрения в това пространство, нещо, което тази статия демонстрира подходящо. Но времето, необходимо на всичко това, е невероятно голямо - месеци, понякога и години, за които хората, използващи екранен четец, не могат да получат адекватен достъп до ресурси, до които имат достъп колегите им. Този вид дефицит може и води до това хората да загубят работата си, защото просто не могат да се справят с комуникациите в компанията, в която работят.

Инструментите, споменати по-горе (Resharper, Slack, Postman и др.) Са ключови играчи в избраните от тях области. Липсата на достъп до тези инструменти ви затруднява като разработчик и ви принуждава да прекарвате цикли, които трябва да харчите, за да свършите работа за намиране на заобикалящи решения и алтернативни инструменти. Това е разточително, уморително и не би трябвало да е необходимо, но е и е едно от основните умения, в които трябваше да се справя много добре, за да продължа.

С течение на времето ще кажа, че изглежда има тенденция към намаляване на необходимостта. Усилията на Microsoft, Apple, Google и други големи играчи карат все повече хора да осъзнават тази почти постоянна битка за равен достъп до производителност. В никакъв случай обаче не сме излезли от гората, нещо, което беше съвсем ясно демонстрирано от провала на Гутенберг WordPress, който в момента бушува сред общността за достъпност.

Слепите хора са пазарна ниша за разработчиците на софтуер и уеб. Слепите разработчици са пазарна ниша в рамките на пазарна ниша.

Слепите разработчици, които продължават да работят, стават продуктивни и заемат работа на пълен работен ден, за съжаление са още по-редки. Това може и трябва да се промени, но докато това се случи, борбата за достъпни инструменти за разработчици е тази, за която се борите сами. Надявам се, че в бъдеще няма да се налага да се бием, ще направя всичко възможно да допринеса за постигането на тази цел.

Коефициенти и краища

Искам да завърша тази статия положително. Фактът, че все още съм в тази област, фактът, че работя на пълен работен ден като разработчик, ми носи много щастие дори през всички привидно постоянни препятствия. Щастлив съм, че мога да допринеса за страхотен екип от колеги, които се отнасят към мен като към равен и мислят с мен, когато се сблъскам с нещо, с което имам проблеми.

Искам да подчертая, че въпреки че областта на компютърните науки не е без препятствия, хората могат да процъфтяват и процъфтяват в работни места, свързани с CS. Описаните по-горе борби със сигурност са верни, но в сравнение с други области те са поне до голяма степен управляеми. Съмнявам се, че скоро ще напиша статия за преминаването ми към кариера на хирург, пилот-изтребител или професионален бейзболен играч, но тогава технологията все още може да ме изненада. Засега обаче съм щастлив, където съм и имам страхотен екип около себе си.

Често ме питат за мнението ми, що се отнася до ефекта върху достъпността на продукта, по който работим. Мненията ми определено не винаги ще доведат до нещата, които да се променят, но се радвам, че поне мога да осведомя хората за важността на достъпността и какво ще се случи, когато тя бъде пренебрегната.

В края на краищата съм жив пример за дишане какво точно се случва, когато инструментът не е или вече не е достъпен.

Статията в WordPress, свързана по-горе, изпраща това съобщение много ясно; инструмент, който е много полезен и достъпен от години, сега е гмуркане с нос. Това е нещо, което може да се случи с всеки инструмент, от който зависи слепият разработчик, руската рулетка на бизнеса, така да се каже.

Като пиша статии като тази, като изнасям беседи, обучавам разработчици и експериментирам с нови инструменти, нови техники и нови методологии, се надявам да остана напред. Записвайки констатациите си, се надявам да науча другите на триковете на занаята, който открих чрез проби и грешки, така че прагът за това поле е намален за потребителите на екранни четци.

Основните цели на тази статия са в съответствие с много, ако не и с всички тези цели. Надявам се да ви дам един поглед както на борбите, така и на позитивите на сляп програмист.

Надявам се, че съм посочил, че въпреки че това е възможно, ние можем и трябва да подобрим изключително много опита. Надявам се, че съм подбудил читателите на тази статия да се замислят, наистина да помислят за последиците от недостъпния софтуер и се надявам, че съм показал, че дори през всички препятствия е много възможно да станем добри, дори велики в тази област веднъж постигате скорост на бягство.

В светлината на положителната бележка, за която току-що се позовах, искам да завърша тази статия, като спомена две огромни печалби за достъпност, които са идеални примери за това как сме се справили по-добре, за които и аз бях почетен сътрудник.

За да научите как да кодирате, много от по-интерактивните ресурси като Codeacademy не са много достъпни. Това е свързано с това, че различни компоненти, които се използват в тези проекти, не са достъпни. За щастие, по това вече се работи.

Един от ресурсите, който спечели много сила през последните няколко години, е freeCodeCamp. Тази инициатива преди имаше някои доста сериозни проблеми с достъпността, които съвсем наскоро бяха почти напълно отстранени и преработени, което прави платформата много жизнеспособна за потребители на екранни четци, които искат да се научат как да кодират.

Това има много общо с Monaco Editor, който е много достъпен уеб-базиран редактор на кодове и всъщност е редакторният компонент, който Visual Studio Code използва. Когато излезе, този редактор беше буквално напълно недостъпен. Въпреки това, за сравнително кратко време това не само беше фиксирано до голяма степен, но сега прави проекти като freeCodeCamp достъпни по подразбиране, тъй като те използват един и същ компонент. Така трябва да бъде винаги, това се надявам да видя повече, докато продължавам с това. И с това мисля, че е крайно време да се върна към програмирането.