Cómo conseguir un trabajo de desarrollador cuando eres ciego: consejo de un desarrollador ciego que trabaja junto a un equipo vidente

Soy un desarrollador holandés y recientemente me gradué con una licenciatura en TI. Soy completamente ciego y uso un lector de pantalla para hacer mi trabajo.

Camino por el camino traicionero del desarrollador ciego, un camino que describiré, así como las diversas trampas que contiene.

He trabajado para varias empresas como desarrollador web de back-end que, lenta pero seguramente, también está migrando a más y más trabajos de front-end, siendo el panorama tecnológico el que es.

He trabajado con una variedad de tecnologías, desde c # hasta Python y desde Rails hasta JavaScript.

También soy un experto en accesibilidad, familiarizado con los sospechosos habituales como WCAG, ATAG y amigos. Lo que quiero decir con competente en este caso es que he utilizado estas habilidades en un entorno profesional al realizar auditorías de accesibilidad en sitios web, aplicaciones web y aplicaciones de escritorio.

También he acumulado conocimientos teóricos al pasar por el programa de formación de la Universidad de Deque, que puedo recomendar encarecidamente si quieres una base sólida en los fundamentos de la accesibilidad.

Este dominio de las normas de accesibilidad se debe principalmente al hecho de que yo mismo exijo que el contenido sea accesible para poder utilizarlo.

Esta descripción será a veces fáctica, a veces basada en opiniones. La mayoría de las veces, serán las experiencias de un solo individuo que escribe código para ganarse la vida sin usar sus ojos para ayudarlo a ver lo que está haciendo.

Espero que esta historia arroje algo de luz sobre mi flujo de trabajo y las cosas con las que tengo que lidiar para mantener ese flujo de trabajo de forma regular. Finalmente, será una instantánea de todo lo que he aprendido y todavía estoy aprendiendo sobre este proceso.

Comenzar su viaje: poner un pie en la puerta

Para trabajar para un equipo de desarrollo con colegas videntes, obviamente necesitará ser contratado primero. Hacer que eso suceda significa que debe saltar sobre algunas trampas interesantes que pueden no ser evidentes de inmediato, por lo que le dedico una sección del artículo aquí.

La búsqueda de empleo como desarrollador ciego es una actividad interesante. Al igual que cualquier otra persona que solicite un empleo, comienza con un currículum y, en la mayoría de los casos, una carta de presentación.

Una pregunta a la que me enfrenté inicialmente fue si debía notificar de inmediato a la empresa sobre mi ceguera o no. He descubierto que, en general, es mejor no hacer eso por la sencilla razón de que, si lo hace, pone un énfasis innecesario en la ceguera.

Soy un desarrollador con calificaciones, experiencia y habilidades que me he ganado y por las que he trabajado duro, y esos son los méritos por los que quiero que me contraten.

Ser ciego, para mí, es algo intrascendente junto a esas habilidades, a menos que de alguna manera pueda ser una ventaja para el puesto. Esto sería cierto, por ejemplo, para un puesto relacionado con la accesibilidad.

Esto me ha llevado a situaciones bastante interesantes, desde miradas desconcertadas a mi bastón blanco o, más tarde, a mi perro guía, hasta disculpas apresuradas para terminar prematuramente la entrevista de trabajo.

Aunque discriminar a alguien con una discapacidad es ilegal, a veces es bastante fácil disfrazarse de otra cosa. Esto es algo a tener en cuenta. Afortunadamente, esto no sucede con tanta frecuencia, pero no mencionarlo aquí sería jugar rápido y sin rodeos con la verdad.

Es un acto de equilibrio cuidadoso en el mejor de los casos. En estos días, tiendo a mencionar mi ceguera en el último momento cuando negocié una entrevista de trabajo por teléfono, diciendo que llevaré un perro a la oficina y pregunto si alguien es alérgico a los perros. Normalmente, la siguiente pregunta es un "¿Por qué?" Muy comprensible. y solo entonces lo mencionaré, minimizándolo tanto como sea posible. La mayoría de las veces, este enfoque me ha dado al menos la oportunidad de asistir a una primera entrevista.

Otros obstáculos son las pruebas de detección obligatorias o las evaluaciones que no son accesibles, generalmente son pruebas estandarizadas que no pueden desviarse según la empresa a la que se postule.

Esto tiene la consecuencia habitual de terminar el procedimiento de entrevista de trabajo allí mismo. Obviamente, el problema puede ser forzado, pero en la línea de crear un ambiente de trabajo positivo, esto realmente no es algo que pueda recomendar.

Esto tiene que ver con el énfasis mencionado anteriormente en su condición de ciego. Cuanto más lo hagas, más importancia gana para la persona que está considerando tu solicitud de empleo.

Lo que sigue es generalmente un procedimiento casi escrito. La entrevista de trabajo transcurre sin problemas en la mayoría de los casos, pero gana un componente adicional que me gusta llamar la parte "Monkey show, Monkey do".

Esta parte de la entrevista suele ir precedida de una pregunta como: "Probablemente pueda imaginarse por qué pregunto, pero ... ¿cómo? ¿Cómo se programa sin mirar?"

En este punto, explico sobre los lectores de pantalla, la velocidad increíblemente rápida a la que escupen información y, por lo general, saco mi computadora portátil para hacer una pequeña demostración.

Normalmente recibo miradas de asombro. Una vez la gente incluso me aplaudió.

Aunque eso es, por supuesto, muy halagador, ser observado con admiración por hacer algo que es una segunda naturaleza tiende a envejecer de vez en cuando. Esto no es nada personal. Es posible que usted sea la tercera persona que lo haga hoy. Responder a las mismas preguntas una y otra vez ciertamente cae en esa misma categoría.

Como resultado, escribí un artículo, mi primero en freeCodeCamp de hecho, para responder algunas de las preguntas que a menudo recibo cuando se trata de ser un desarrollador ciego.

Afortunadamente, tanto esta demostración como este período momentáneo de ser mirado generalmente no duran mucho. Descubrí que hacer esto hace que sea mucho más fácil explicar por qué algo es o no un desafío en el futuro.

Ser exhibido de esa manera, aunque a veces sea incómodo, al final vale mucho la pena. Después de todo, las reacciones son comprensibles. Estoy haciendo algo que mucha gente ni siquiera puede imaginar sin ver.

Escoger tus herramientas: la lucha constante por el malabarismo constante

Para diversas actividades, necesita un conjunto de herramientas para ser eficaz. Los escaladores necesitarán cuerdas, ganchos de anclaje, etc. Y los programadores necesitan herramientas para programar, probar, colaborar, compartir y buscar información, etc.

Desafortunadamente, aquí es donde mucha gente deja de fumar. Quizás aún más desafortunadamente, esto es totalmente comprensible.

La cantidad de trabajo que debe realizar para obtener una pila decente que funcione para su caso de uso, además de su semana laboral normal de 40 horas, puede ser un poco abrumadora.

El sistema operativo es el primer obstáculo. Muchos equipos de desarrollo aquí en los Países Bajos usan Macs exclusivamente. Lamentablemente, sin embargo, las API de accesibilidad disponibles para el lector de pantalla de MacOS, Voiceover, son en muchos casos inferiores a las de Windows.

La cantidad de pulsaciones de teclas necesarias para realizar una tarea en Mac suele ser mayor que en Windows, siendo MacOS un sistema operativo muy orientado al ratón.

Finalmente, el lector de pantalla en sí mismo carece de muchas de las características de conveniencia y opciones de personalización de sus contrapartes de Windows.

En una industria que se supone que es igualmente accesible tanto para ciegos como para videntes, estas deficiencias se traducen en serios impactos de productividad en comparación con mis colegas videntes. Esto puede ser estresante y, en ocasiones, requiere cierta comprensión y flexibilidad de mis colegas.

Una vez que esté familiarizado con una base de código y se hayan resuelto las herramientas, puede realizar muchas tareas tan rápido como sus colegas videntes.

Sin embargo, lograr esa familiaridad puede llevar tiempo. Especialmente si las herramientas no son tan accesibles como deberían. Puede perder un tiempo precioso luchando con una herramienta que se supone que lo ayudará en su trabajo, pero que lo obstaculiza o incluso lo bloquea por completo.

Afortunadamente, por lo general me han encontrado con comprensión y, muchas veces, curiosidad por las deficiencias de mis colegas videntes. Sin embargo, esto no es algo de lo que depender. Cuando se necesita hacer mucho trabajo en poco tiempo, cada impacto de productividad es, en cierto sentido, demasiado.

Para aliviar estos problemas tanto como sea posible, es primordial que conozca cada pequeño atajo y truco del oficio en sus herramientas de elección para ahorrar tiempo perdido en acciones que repite todo el tiempo. Teclas de macro, alias de shell, extensiones de editor que te brindan más atajos de teclado: estos son el nombre del juego.

Pero a veces las herramientas que se supone que deben ayudarlo se interpondrán en su camino. Donde mis colegas videntes a menudo usan herramientas gráficas para administrar ciertos aspectos de sus trabajos, estas herramientas a menudo son inaccesibles. Esto requiere que, a menudo en el lugar, encuentre algún tipo de solución para seguir realizando la misma tarea con un mínimo de eficiencia.

Para una aplicación gráfica, esto podría ser un equivalente de línea de comando. Un sitio web puede tener una API. A veces, una segunda herramienta gráfica puede funcionar mejor que la de facto. Descubrir constantemente alternativas para la tecnología inaccesible es una parte constante del trabajo cuando lo hace con los ojos cerrados. Obtener la libertad de traer sus propias herramientas es muy importante por esa razón.

Rara vez he visto que se apliquen herramientas porque los desarrolladores generalmente tienen una fuerte preferencia por su propio flujo de trabajo. Pero para los trabajos que sí me insistieron en usar herramientas específicas, esto a menudo se convierte en un factor decisivo para cualquier contrato futuro que acepte. Las herramientas son tan importantes.

Tu primer pensamiento podría ser usar Windows si MacOS te hace menos productivo. En un mundo ideal, esa sería una solución viable. Sin embargo, especialmente en las bases de código más antiguas, los equipos de desarrollo a menudo han ideado pequeños trucos para hacer que el código más antiguo se ejecute en su hardware / software más nuevo que ni siquiera debería estar ejecutándose en primer lugar. Estos trucos son específicos del sistema operativo y, a menudo, son difíciles de replicar en Windows, incluso cuando se usa el subsistema de Windows para Linux. A veces, pueden tardar semanas en hacer efecto. A menudo no vale la pena.

En este momento, por esa razón, estoy ejecutando casi obligatoriamente una máquina virtual con Windows 10 dentro de Vmware Fusion en la Mac. Me veo obligado a utilizar dos sistemas operativos a la vez para realizar mi trabajo. Windows tiene mi navegador web, mi editor de código de elección y varias otras herramientas que uso para aumentar mi productividad:

  • Google Chrome
  • Código VS
  • un lector de PDF decente
  • una suite ofimática para trabajar con archivos DOCX y XLSX

Básicamente, todas las aplicaciones reales se ejecutan en la VM de Windows, lo que hace que MacOS sea más parte de un servidor que solo aloja el código de la aplicación.

Este es un buen ejemplo de la libertad de utilizar sus propias herramientas a las que me referí. Nadie más en mi equipo ejecuta la misma configuración que yo. Pero hacer esto generalmente me ha contado con la comprensión y el apoyo de mis colegas porque pueden ver que puedo hacer el trabajo de esta manera.

La accesibilidad, especialmente en las herramientas de desarrollo, puede ser increíblemente difícil de defender. A menudo, no te toman en serio cuando pides lo que debería ser una característica básica. En cierto sentido, simplemente está pidiendo poder utilizar la aplicación.

Pero no está en la hoja de ruta, los desarrolladores no pueden dejar de trabajar en él, no tiene prioridad, etc. Son razones para no arreglar la accesibilidad de una herramienta casi como un reloj. Otras veces, se hacen promesas de arreglos que nunca se materializan.

Me encantaría ver esto mejorar, y he tenido el placer de verlo suceder de vez en cuando. Sin embargo, sigue siendo un problema que vuelve a aparecer y, como desarrolladores, incluido yo, deberíamos hacerlo mejor.

Mis colegas videntes dan por sentado muchas herramientas. En un equipo .NET, por ejemplo, es raro ver a un desarrollador que no esté usando Resharper para aumentar su productividad.

Irónicamente, esta extensión para Visual Studio, en sí misma bastante accesible, usa muchas pulsaciones de teclas para hacer lo que hace. Pensaría que eso lo convertiría en una herramienta ideal para un desarrollador ciego, que solo usa un teclado para codificar. Sin embargo, la salida de esta extensión suele ser inaccesible, lo que hace que la herramienta sea más un obstáculo que una ayuda.

He estado acosando a Jetbrains durante años para que arreglen la accesibilidad de esta herramienta, que incluso en el momento de escribir este artículo es abismal. Me han despedido descortésmente, me han ignorado y finalmente me han hecho promesas, hasta ahora incumplidas. Esta falta de voluntad para solucionar lo que obviamente es un problema que ha estado allí durante años me hace dudar en comprometerme con una posición basada en .NET. Incluso si los problemas se resuelven milagrosamente, el historial de dejarlo sin resolver durante tanto tiempo me haría preguntarme cuándo volverá a romperse.

En uno de los primeros equipos de desarrollo con los que trabajé, Postman se utilizó mucho para probar los puntos finales de API creados por los desarrolladores de back-end. Postman tiene una serie de problemas evidentes de accesibilidad que dificultan su uso con un lector de pantalla. Para ver un ejemplo perfecto de promesas incumplidas, eche un vistazo a este número de GitHub. Observe que el tema sigue abierto después de casi 2 años y las promesas se hacen pero no se cumplen.

La accesibilidad es a menudo una ocurrencia tardía, algo que innegablemente se prueba una y otra vez. Slack, lamentablemente, es un buen ejemplo de esto. La accesibilidad de esta herramienta ahora casi imperdible era abismal, los usuarios de lectores de pantalla simplemente no podían trabajar con ella.

Definitivamente estamos viendo mejoras en ese espacio, algo que este artículo demuestra acertadamente. Pero la cantidad de tiempo que lleva todo esto es increíblemente alta: meses, a veces años, que las personas que usan un lector de pantalla no pueden acceder adecuadamente a los recursos a los que tienen acceso sus colegas. Este tipo de deficiencia puede hacer que las personas pierdan su trabajo porque simplemente no pueden mantenerse al día con las comunicaciones dentro de la empresa en la que trabajan.

Las herramientas mencionadas anteriormente (Resharper, Slack, Postman, etc.) son jugadores clave en sus campos elegidos. No tener acceso a estas herramientas lo paraliza como desarrollador y lo obliga a gastar ciclos que debería dedicar a hacer el trabajo para encontrar soluciones y herramientas alternativas. Esto es un desperdicio, cansancio y no debería ser necesario, pero lo es y es una de las habilidades básicas en las que he tenido que ser muy bueno para mantener el ritmo.

Sin embargo, a medida que pasa el tiempo, diré que parece haber una tendencia a la baja de que esto sea necesario. Los esfuerzos de Microsoft, Apple, Google y otros grandes actores están haciendo que cada vez más personas sean conscientes de esta batalla casi constante por el acceso equitativo a la productividad. Sin embargo, de ninguna manera estamos fuera de peligro, algo que quedó claramente demostrado por la debacle de WordPress de Gutenberg que actualmente está arrasando en la comunidad de accesibilidad.

Las personas ciegas son un nicho de mercado para los desarrolladores de software y web. Los desarrolladores ciegos son un nicho de mercado dentro de un nicho de mercado.

Los desarrolladores ciegos que se mantienen en ello, se vuelven productivos y tienen un trabajo de tiempo completo, lamentablemente son aún más raros. Esto puede y debe cambiar, pero hasta que eso suceda, la lucha por las herramientas de desarrollo accesibles es algo que usted lucha por su cuenta. Espero que sea una pelea que no tendremos que pelear en el futuro, haré todo lo posible para contribuir a ese objetivo.

Retazos

Quiero terminar este artículo con una nota positiva. El hecho de que todavía esté en este campo, el hecho de que tenga un trabajo de tiempo completo como desarrollador me trae mucha felicidad incluso a través de todos los obstáculos aparentemente constantes. Estoy feliz de poder contribuir a un gran equipo de colegas que me tratan como a un igual y piensan conmigo cuando me encuentro con algo con lo que estoy teniendo problemas.

Quiero enfatizar que aunque el campo de la informática no está libre de obstáculos, las personas pueden prosperar y prosperan en los trabajos relacionados con la informática. Las luchas descritas anteriormente son ciertamente ciertas, pero en comparación con otros campos, son al menos en gran medida manejables. Dudo que escriba un artículo en el corto plazo sobre mi cambio de carrera a cirujano, piloto de combate o jugador de béisbol profesional, pero la tecnología podría sorprenderme. Por ahora, sin embargo, estoy feliz donde estoy y tengo un gran equipo a mi alrededor.

A menudo me piden mi opinión sobre el efecto sobre la accesibilidad del producto en el que estamos trabajando. Definitivamente, mis opiniones no siempre van a hacer que las cosas cambien, pero me alegro de que al menos sea capaz de hacer que la gente sea consciente de la importancia de la accesibilidad y de lo que sucederá cuando se ignore.

Después de todo, soy un ejemplo vivo de lo que sucede cuando una herramienta no es o ya no es accesible.

El artículo de WordPress vinculado anteriormente envía este mensaje con mucha claridad; una herramienta que ha sido muy utilizable y accesible durante años ahora es una picadura. Esto es algo que le puede pasar a cualquier herramienta de la que dependa un desarrollador ciego, la ruleta rusa del negocio, por así decirlo.

Al escribir artículos como este, dar charlas, educar a los desarrolladores y experimentar con nuevas herramientas, nuevas técnicas y nuevas metodologías, espero mantenerme a la vanguardia. Al escribir mis hallazgos, espero enseñar a otros los trucos del oficio que descubrí por prueba y error para que el umbral de este campo se reduzca para los usuarios de lectores de pantalla.

Los principales objetivos de este artículo se alinean con muchos, si no con todos, esos objetivos. Espero haberles dado una idea de las luchas y los aspectos positivos de un programador ciego.

Espero haber señalado que aunque hacer esto es posible, podemos y debemos mejorar enormemente la experiencia. Espero haber provocado que los lectores de este artículo piensen, realmente piensen, sobre las consecuencias del software inaccesible y espero haber demostrado que, incluso a través de todos los obstáculos, es muy posible volverse bueno, incluso excelente en este campo una vez logras la velocidad de escape.

A la luz de la nota positiva a la que me refería, quiero terminar este artículo mencionando dos grandes logros en accesibilidad que son ejemplos perfectos de cómo lo hemos hecho mejor, de los cuales he sido un colaborador honrado.

Para aprender a codificar, muchos de los recursos más interactivos que existen, como Codeacademy, no son muy accesibles. Esto tiene que ver con que varios componentes que se utilizan en estos proyectos no sean accesibles. Afortunadamente, esto ya se está trabajando.

Uno de los recursos que ha ido ganando terreno en los últimos años es freeCodeCamp. Esta iniciativa solía tener algunos problemas de accesibilidad bastante graves que recientemente se han solucionado y revisado casi por completo, lo que hace que la plataforma sea muy viable para los usuarios de lectores de pantalla que desean aprender a codificar.

Esto tiene mucho que ver con Monaco Editor, que es un editor de código basado en web muy accesible y, de hecho, es el componente de edición que utiliza Visual Studio Code. Este editor, cuando salió, era literalmente completamente inaccesible. Sin embargo, en un tiempo relativamente corto, esto no solo se solucionó en gran medida, sino que ahora hace que proyectos como freeCodeCamp sean accesibles de forma predeterminada porque usan el mismo componente. Esta es la forma en que siempre debería ser, esto es lo que espero ver más mientras sigo en esto. Y con eso, creo que ya es hora de que vuelva a la programación.