Pull to refresh

3 года программирования вслепую. Часть 2

Reading time 8 min
Views 28K

Всем доброго времени суток! Продолжаю свой рассказ о том, как "Войти в IT" без подгляда. Прошлая часть была посвящена, в основном, обучению. В этой больше расскажу о работе.


Поиск и подготовка


Фриланс я рассматривал в основном как простой способ входа в профессию. Так что после начального обучения переключился на поиск постоянной работы. Задачи там казались мне более интересными, а атмосфера основательней и лучше подходящей для развития.


К тому моменту я успел хорошо освоить symfony framework. html и js также не вызывали затруднений. А вот с css был знаком только в теории.


При наличие пары глаз поблизости рано или поздно, безусловно, можно выполнить любую задачу. К тому же для скринридеров существуют плагины, помогающие в позиционировании и не только. Но трудозатраты, в любом случае, были бы неоправданно высоки. Так что я сосредоточился на бекенде — самой доступной части веб-разработки. Где незрячий может выполнять все задачи самостоятельно и наиболее полно себя проявить.


Фокус моего внимания был смещен с фриланс бирж на сайты вакансий. Но после первых же пары откликов высветился маленький нюанс… Стиль в котором был выдержан код моего домашнего проекта, ссылку на который я неизменно прикладывал, оказался абсолютно нечитаем для других разработчиков. Именование переменных в одну-две буквы и отсутствие отступов гарантировали, что такой код положительно оценен не будет.


Еще на первых уроках видеокурсов по php преподаватель перечислил множество редакторов кода, имеющих форматер, подсветку синтаксиса, автодополнение и многое другое. Но они все оказались недоступны. Я ставил и сносил sublime, brackets, visual studio code — ни одна из них не работала со скринридером. Скачивал и PHPStorm, потыкался в неозвучиваемый экран установки, после чего снес и его. Notepad++ вроде бы был доступен, хоть и очень относительно. Еще была visual studio, но она вообще не помогала в работе с php. Так что после долгих поисков я остановился на akel pad. В нем не было ничего. Но он был быстрым. Что ж, этого хватило для обучения, но дальше надо было искать что-то другое.


Я снова прошелся по списку редакторов и обнаружил, что за прошедшее время visual studio code "обрел голос". Ранее фокус скринридера просто упирался в молчащее окно программы, сейчас же интерфейс озвучивался как обычная веб-страница с привычными горячими клавишами навигации.
К тому моменту отступы по всему проекту уже были успешно расставлены с помощью php-cs-fixer.


По окончании рефакторинга я возобновил изучение рынка. Мною рассматривались только удаленные вакансии. Это решало проблему поездок в офис и не ограничивало меня бедным локальным рынком. В итоге через несколько недель откликов и собеседований я получил предложение о работе.


Первая работа


Компания занималась разработкой веб-проектов под заказ. Ей требовался middle symfony разработчик. Миддлом на тот момент я еще, разумеется, не был. Но ключевые слова, перечисленные в вакансии, были знакомы. Да и наниматель готов был пойти навстречу. Трудности, однако, стали возникать сразу...


Первой из них был докер. О нем до того момента я только слышал. Сейчас же наш проект требовалось с его помощью поднять локально. Много ли усилий нужно, чтобы выполнить в консоли docker-compose up? В моем случае это заняло неделю.


Проблема заключалась в том, что у меня стояла windows 7. windows — самая дружественная для незрячих ОС. Она давно и успешно обжита, для нее есть хорошо развитые скринридеры, множество синтезаторов речи и прочей инфраструктуры. Но вот докер на ней работал медленно, глючно и через виртуальную машину. Остальные члены команды, работавшие на маке и линуксе, помочь могли с большим трудом. Но в итоге после долгих задушевных переписок в чате проект все же удалось поднять. По ходу этого процесса я узнал о git autocrlf и yarn --no-bin-links.


В перерывах между сеансами укрощения докера я изучал код проекта. Он был построен на api platform. Сильно отличавшейся от всего, что я видел до этого. Контроллеров, например, в проекте не было совсем. Есть у api platform и свои подводные камни. Разумеется, успешно найденные в ходе первых же задач.


Кроме выше указанного на проекте присутствовало много того, что я видел впервые: функциональное тестирование, git flow, code review, ci/cd. Работали мы по скраму, спринтами по 2 недели с ежедневными митингами, управление задачами и учет времени шло в jira, переписка осуществлялась в slack. Освоить это и многое другое нужно было еще вчера.


Тут стоит упомянуть, что ознакомление с новыми инструментами с помощью скринридера в среднем занимает больше времени, чем обычно. Представьте человека, заходящего в новое для себя помещение. Ему достаточно взгляда, чтобы понять, что в центре комнаты стоит стол, справа — шкаф. А в дальнем углу находится большая ваза с цветами. Незрячему для получения этой информации придется обойти всю комнату и, возможно, не раз. Так и с освоением новых инструментов. Через какое-то время он запомнит горячие клавиши программы. Узнает, что на этой веб-странице удобнее перемещаться по заголовкам или ссылкам. А вторая по счету неподписанная кнопка в jira открывает нужное меню. Но на все это требуется время. Так что более-менее освоиться у меня получилось только к концу первого месяца. За него я закрыл несколько небольших задач, начал понимать скрам и прочие процессы, брать чуть больше ответственности и не писать по каждому поводу прикрепленному ментору.


По прошествии первого из трех месяца испытательного срока были подведены итоги. Ментор обозначил все положительные и отрицательные стороны моей работы, HR сказал, что через два-три дня они все проанализируют и примут решение о формате дальнейшего сотрудничества. Я воспринял это как полезную в плане обратной связи формальность. Таких было много в компании. К бюрократии мне тоже нужно было привыкать. Например, отпроситься на два часа в течение рабочего дня с гибким графиком у ПМ было нельзя. Для этого требовалось заполнить специальную форму на корпоративном портале, после чего один из менеджеров должен был заявку утвердить. Но через пару дней HR связался со мной и уведомил, что компания больше сотрудничать не планирует. Работодатель ожидал от меня большего, к тому же в тот момент у меня возникли проблемы со здоровьем. Вообще я чувствовал, что после первоначальных трудностей начинаю выходить на нормальную продуктивность. Но риски для компании перевесили потенциальные преимущества. А значит, у меня оставался всего месяц на то, чтобы впитать в себя как можно больше знаний из этой среды.


В этом плане второй месяц прошел куда более гладко, чем первый. Задач было выполнено больше. По моим ощущениям я вышел процентов на 80 продуктивности среднего члена команды. И целенаправленно работал над тем, чтобы без самой крайней нужды не отвлекать никого из коллег. Что за первый месяц успело сильно утомить ментора.


Работа над ошибками


Опыт первого трудоустройства давал обильную пищу для размышлений. Я приобрел большое количество знаний. Но были и проблемы. В частности, я был не доволен visual studio code. Кроме автодополнения переменных оно практически ничем не помогало при повседневной работе. Большинство разработчиков на предыдущем проекте использовало PHPStorm. И мне сильно не хватало его возможностей. Но в очередной раз установив его, я снова уткнулся в неозвучиваемый экран. После чего написал гневное письмо в поддержку о том, что неплохо бы обеспечить хоть какую-нибудь доступность их продуктов. Однако в ответном письме указывалось, что они вполне доступны уже сейчас.


В итоге я нашел на сайте jetbrains неочевидно расположенную страницу, посвященную accessibility, по инструкциям с которой установил java access bridge и IDE, наконец, заговорила.


Что ж, это и впрямь был качественный шаг вперед по сравнению с visual studio code. Вероятно с помощью плагинов и можно довести функциональность редактора кода до уровня IDE, но для php у меня и близко это не получилось.


Быстрая навигация по всей кодовой базе, очень мощное автодополнение, множество встроенных рефакторингов. Все это давало ощущение полета от процесса разработки. Вот разве что подсветку синтаксиса скринридер у меня так и не озвучил.


Следующие несколько месяцев я снова посвятил своему домашнему проекту, просто наслаждаясь тем, как быстро и легко пишется код.


Свободное плавание


Очередная сессия в ВУЗе была позади, а значит пришла пора искать новую работу. Я решил, что на последнем курсе, пусть и заочного обучения, мне понадобится больше времени на учебу. Поэтому я рассматривал вакансии только с частичной занятостью. И в течение нескольких недель нашел, что искал.


Мы связались с менеджером по почте и очень быстро обо всем договорились. У нас даже не было созвона. Вообще так получается, что во всех местах, где я работал, найм проходил в очень простой и деловой атмосфере. От меня хотели узнать, кто я и что умею. Итоговое решение о сотрудничестве принималось быстро.


О том, что у меня проблемы со зрением, разным работодателям я говорил по-разному. Прямое заявление во время интервью, что я слепой, выбивает из колеи большинство интервьюиров. Некоторые люди реагируют в стиле: "Вот это да! Я что-то об этом слышал, можешь объяснить как ты делаешь то и это?" У кого-то возникают опасения по поводу моей работоспособности. Я объясняю, как работаю с компьютером, кидаю ссылки на статьи, где все подробно расписано. Однако на данный момент я стараюсь уведомлять о своих проблемах со зрение в момент, когда мы договариваемся об интервью. Это позволяет всем лучше к нему подготовиться. Еще интервьюиров часто интересует, есть ли какие-то особенности моего взаимодействия с другими членами команды. На что я указываю, что не люблю скриншоты и другую графическую информацию. И обычно прошу передавать ее текстом, хотя с развитием машинного распознавания картинок эта проблема стала менее острой.


Проект, на который я устроился, нужно было реализовывать с нуля. Мы вместе с присоединившимся чуть позже разработчиком создавали систему по ТЗ. Высокая интенсивность работы от нас не требовалась. В целом наш менеджер не был склонен держать процесс разработки под жестким контролем, да и имел постоянную занятость в другом месте. Так что вскоре все технические решения я принимал самостоятельно. Я старался максимально следовать образу разработки, увиденному на предыдущем проекте. CI, code review, функциональное тестирование. Это позволяло нам довольно уверенно двигаться вперед и при этом быть спокойными за тылы.


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


Проект развивался и я развивался вместе с ним. В процессе разработки приходилось решать много интересных задач. Начиная от версионирования полей сущности, заканчивая строительством сложных форм. В приложении было чуть ли не 15 типов пользователей, и для каждого из них админка должна была выглядеть немного иначе.


В процессе я набирался опыта, изучал новые подходы и инструменты. Безусловно, обладая сейчас большими знаниями кое-какие вещи я бы сделал иначе. Сложные расчеты стоимости услуг лучше было сделать по TDD. А спецификации упростили бы работу с множеством типов пользователей. Однако в целом код на всем протяжении проекта был предсказуемым и поддерживаемым. А вот организационные проблемы нам мешали постоянно.


У менеджера совсем не было времени нами заниматься. Раз в месяц он отчитывался перед заказчиком о текущем состоянии проекта. Причем требования заказчика постоянно менялись и, узнавая это за несколько дней до релиза, мы всякий раз работали в авральном режиме.


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


Тем не менее где-то через полгода после начала разработки мы сдали готовую систему в эксплуатацию. Дальше оставалось заниматься ее поддержкой и небольшими доработками. На это двое разработчиков не требовалось. К тому моменту я защитил диплом и решил искать работу с полной занятостью.


В последнее время


Так окончились первые 3 года моей карьеры. Но я так долго собирался с мыслями для этих двух статей, что с тех пор тоже прошло немало времени. Прошлой весной я снова стал изучать рынок вакансий. Он показался мне довольно бедным. Быть может все замерли, наблюдая первую ковидную волну, а может весна — не самое активное время для найма. Так или иначе, где-то через месяц я нашел место, где работаю и сейчас.


За этот год я научился в юнит тесты. Подружился с докером на WSL. Стараюсь больше читать умных книг, пробовать новые инструменты, подтягивать английский, да и в целом двигаться вперед!

Tags:
Hubs:
+94
Comments 33
Comments Comments 33

Articles