Yvision.kzYvision.kz
kk
Разное
Разное
399 773 постов41 подписчиков
Всяко-разно
2
08:11, 16 апреля 2014

Devушки-программисты Казахстана. Часть 3 — Танец на питоне

Свободного времени у меня практически нет, и материал, который я начала готовить в октябре 2013-го, пришёл к своему завершению только сейчас. Месяц назад думала, что опубликую к 8 марта - типа даже символично как-то, но не вышло.

Не хотелось мешать свои мысли с результатами опроса, поэтому выделила их в отдельные статьи. Расскажу о себе, своём видении сферы ИТ и присутствия девушек в ней. А также попытаюсь осветить явления и стереотипы айтишного мира с разных сторон.

Образование

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

Закончила алматинский политехнический колледж и гуманитарно-технический университет, который за время моей учёбы дважды менял название. С полной уверенностью могу сказать, что в колледже получила гораздо более качественное образование, чем в вузе. Возможно, это даже логично, ведь обучение с чистого листа кажется богатым на знания. Но стоит также отметить, что преподавание в АПК было действительно на высоте. И было смешно, когда в универе преподавали то же, что и в колледже (DOS, Delphi и т.п.). Преподаватели прогуливали уроки либо вели их на отъебись - две пары тупого конспектирования. Универ дал небольшую подработку и некоторые интересные темы для изучения, в остальном был почти бесполезен. Хотя, в общем-то, было в кассу то, что он не требовал слишком много времени, потому что в то время я уже работала по специальности.

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

Если говорить о качестве образования, то процесс обучения на 100% зависит от препода. Думаю, моя школьная тяга к математике, геометрии, информатике - заслуга женщины-преподавателя, которая привила любовь к этим предметам. Факультатив её был интересен неординарными задачами и темами и отличался от по-своему скучной школьной программы.

Люблю учителей, которые не отбывают срок на кафедре, а помогают учиться и решать конкретные задачи. Особенно нравится, когда лекции строятся по свободному формату - громкие уроки, где никто не стесняется спрашивать, и всё обсуждается открыто. На некоторых технических предметах в вузе (например, БД или ИБ) бывала жуткая скукота, на философии и то интересней. Помню, на всякие гуманитарные предметы ходили чисто для разрядки - реально были преподы, с которыми можно потрещать и узнать что-то интересное.

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

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

Самообучение

Свои первые программы я писала на Delphi по самоучителям и электронным книжкам. Что интересно, Delphi хоть и объектно-ориентированный, нас в основном учили использовать его как конструктор интерфейсов, а потом уже прикручивать к ним функционал, как правило, основанный на процедурах. По долгу службы я занялась Java, и ООП открылся мне во всей красе! Благодаря Java. Научившись мыслить по-новому, я здорово усовершенствовала и своё Delphi-детище, кучу возможностей научилась использовать, о которых раньше не задумывалась. Этот же подход и в других языках использую (PHP, Python), которые также изучала сама, наряду со всеми остальными веб- и мобильными технологиями, и изучаю до сих пор по мере необходимости.

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

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

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

Благо, сейчас очень много ресурсов онлайн-образования, и они имеют бесплатные курсы, а за определённую плату выдадут вам бумажный сертификат. Отличная альтернатива офлайн-вузам: там и общаться можно с согруппниками, и задачи совместные решать, и учиться в сроки выполнять задания, и "посещать" лекции, когда самому удобно.

Перед поступлением в любой вуз лучше изучать программу обучения, потому что она может вас не устроить в итоге. Хорошо бы и преподавательский состав изучить. Но у нас в основном учебные заведения выбирают не по предпочтению, а по комфорту - дешевле, ближе и т.п. И пофиг, что качество образования не ахти, лишь бы диплом был. Так и остаётся уровень преподавания и организации учебного процесса ниже нормы. Посмотрела я как-то сайты казахстанских технических университетов, такое ощущение, что они (за редким исключением) созданы просто для успокоения и размещения регалий ректора.

Радует хотя бы то, что какой-никакой отбор в учебные заведения присутствует, а не только бабло всё решает. Хотя последний фактор всегда можно ставить под сомнение. Для меня было удивительно, когда один мой знакомый (весьма талантливый человек) не смог поступить в казахстанский университет - не прошёл конкурс, и не приняли его даже за деньги. Возможно, переоценил себя или недостаточно внимательно отнёсся к заданию. Но разве желание - не главный стимул учиться? Тем более если человек готов платить. В Германии, кстати, в прошлом году высшее образование стало полностью бесплатным, но там процесс поступления сложен и имеет несколько уровней.

Работа на других

Я начинала как техник-программист и большую часть времени, как и многие, была на побегушках (в основном обслуживание корпоративной сети и софта). У нас понятие "программист" резиновое, и все в порядке вещей занимаются настройкой доменов, сетей, серверов, установкой софта, написанием документации, настройкой железа, а иногда и рисованием в фотошопе для начальства. Для стажёра любая работа хороша. Ну, а потом чем сложнее, тем интереснее.

Несмотря на привлекательные проекты и коллективы работа в компаниях в итоге не приносила удовлетворения. Работы было очень много, всё было здорово, но баги в планировании и управлении, текучка, а также вынужденное общение с заказчиками приносило много стресса. Было не по себе, когда мы столько делали, столько старались, но в итоге пользователи не могли полноценно использовать наши продукты. То денег у предприятия не было всё это развивать, то мотивация постепенно падала от систематического вранья со стороны начальства и долгов по зарплате, то в момент, когда продукт уже был готов, выяснялось, что никто им пользоваться не будет, потому что затеяли проект, чтоб просто бабло отмыть...

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

Работа на себя

Только организовав собственное дело, я поняла, что можно работать в кайф от старта до внедрения. Свои проекты лучше развиваются, остальное лишь приносит пользу (в виде опыта, заработка и т.п.). Единственная трудность работы на себя - стабильность зависит только от усилий твоей команды. Наш самый крупный на данный момент проект полтора года развивался на чистом энтузиазме, но были чёткие цели, огромное стремление и надёжные звенья, отвечающие за свой сегмент эффективности - всё это позволило сделать конкурентоспособный продукт, который в итоге стал приносить деньги.

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

Работа на себя эффективна потому, что нововведения внедряются очень быстро, - цепочка согласований минимизирована. А ещё ты не занимаешься левыми делами, в то время как в компании так и норовят пригрузить какой-нибудь хренью. Должностная обязанность программиста - автоматизировать процессы производства, внедрять технологии, обеспечивать работоспособность программ и (иногда) обучать пользователей работе с ними. Не имею ничего против разработки документации, но всё, что не касается специальности, - фтопку! Занятия ниже имеющейся квалификации считаю неприемлемыми, они отнимают драгоценное время и убивают мотивацию работать.

В штатных задачах, думаю, у каждого тоже есть предпочтения. Ни у кого ведь не получается любить работу безраздельно от видов работ? Всегда есть то, что нравится больше или меньше. Я, например, ненавижу заниматься вёрсткой, хотя и этот процесс иногда удаётся организовать хорошо.

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

Для меня работа без планов, задач, спринтов - просто кайф. Люблю спонтанность, испытываю невероятное наслаждение от свободы, потому что делаю всё по настроению. И по графику я гораздо менее продуктивней, сроки только угнетают и вгоняют в напряжение. Да и не встречала я на практике ни одной эффективной системы планирования. Кроме одной: меньше народу - больше эффективность =)

Кайф, драйв, трудоголизм

Мне нравилось и бегать с отвёрткой по этажам, и кодить, и админить. Часто засиживалась допоздна, а иногда и до утра, чтоб завершить какую-то задачу или изучить прикольную фичу. Помню, начальник поражался, как быстро я работаю. И не знал он, что, придя с работы домой, я опять бралась за проект, потому что была сильно увлечена, да и сроки, как всегда, поджимали. Иногда мы и в офисе ночевали, хотя и понимали, что всё это недоработки менеджмента. Нам просто нравилось работать.

Частенько думаю: "Как жаль, что у меня нет полноценного клона, и в сутках так мало часов... И что за жизнь такая, когда стока проектов и каждым интересно заниматься!" =) С чужими проектами в этом плане легче - энтузиазма меньше, хотя покреативить тоже получается.

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

Работа в команде

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

С проблемой принятия на работу никогда не сталкивалась, потому что начинала в техническом отделе, а в дальнейшем устраивалась только по рекомендациям. За всё время работала с одной женщиной (руководителем ИТ-отдела) и четырьмя девушками-программистами. В коллективе никогда не видела проявлений дискриминации, спрос со всех был и есть одинаковый. А вот среди подрядчиков встречались кадры, которые открыто сомневались в моих способностях. Опыта и знаний мне по первости не хватало, но я это всегда признавала и всему училась. Как и другие сотрудницы-прогеры.

В рабочем коллективе никто никогда не сомневался в наших способностях, и байки о дискриминации для меня - не больше, чем миф. Когда проект запущен, к программированию относятся, как к ремеслу: дают задание - делаешь и при необходимости изучаешь что-то дополнительно, согласовываешь, модифицируешь и т.п. По моему опыту, у руководителей и сотрудников, которым довелось работать с женщинами-программистами, вообще не вызывает сомнений, что девушка умеет программировать и выполнять технические задачи любой сложности. Как говорит Анна Пекарская: "Женщина-айтишник удивиляет только тех, кто не сидит в этой отрасли. Нас всё больше и в фирмах, и в университетах".

Я поддерживаю своих коллег-девчонок и считаю, что "способность программировать, как и любая другая способность творить, от пола не зависит. Всё зависит только от желания". Если сомневаетесь, то "вместо того, чтоб судачить и тратить время на предположения, возьмите на работу девушку-программиста и убедитесь, насколько она справляется. Есть дамы, которым не надо ничего доказывать, они умеют работать самостоятельно. Девушки, которые могут проявить себя в деле, никогда не боятся этого".

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

И комментирует она всё, к чему прикасается...

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

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

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

У креатива есть обратная сторона, из-за которой многие парни любят писать софт только с нуля, не умея при этом разбираться в уже существующем коде, даже если он документирован. Конечно, никто не любит рыться в чужом коде (это и результаты моего опроса подтверждают), но поднимите руки те, кого он хоть чему-нибудь полезному научил? Лес рук. Но некоторые всё же настырно пытаются изобрести очередной велосипед вместо того, чтоб использовать "написанные непонятно кем наработки". В итоге код клонируется, а в больших проектах дублируется по нескольку раз. Некоторые не только брезгуют копаться в чужой писанине, но даже ленятся изучить фреймворк и делают всё по старинке в обход правил того же фреймворка. Например, используют нативные методы вместо ООП. А потом в команду приходит новый прогер, понимает, что быдлокод в компании - норма, и продолжает наследовать чужие ошибки.

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

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

Ещё есть любовь к костылям, особенно в наших условиях, когда всё надо делать срочно. Оттого пишут тяп-ляп, лишь бы работало. Частый подход среди парней-программистов. Заниматься исправлениями и оптимизацией они не любят, так что чаще всего код остаётся в своём первозданном быдловиде.

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

Всё это обыденные вещи, и, конечно, не только они являются источником багов. Кодинг стал уже целой наукой, и он требует изучения и понимания, особенно если дело касается масштабных проектов, где люди постоянно приходят и уходят. А приходят иногда те, кто даже основ не знает. И таких основ.

Командная работа - краеугольный камень любого проекта, в котором задействовано более трёх человек. И чаще всего именно слабые командные качества разработчиков мешают проекту быстро развиваться и быть минимально трудоёмким. Кодинг - существенная часть командной работы, но есть ещё бизнес-процессы, котрые можно внедрять на любом уровне бизнеса (хоть дизайн, хоть администрирование, хоть маркетинг, хоть отдел кадров). Знаю лишь пару-тройку организаций, где это работало на практике, и граблей просто не было! Неимоверно экономило время. И нового сотрудника обучить процессам компании - раз плюнуть. Хорошая практика - даже для относительно мелких проектов использовать средства проектирования (хотя бы самые примитивные), благодаря этому не тратится куча времени на то, чтобы разобраться в структуре проекта.

Изменилось бы что-нибудь, если б среди разработчиков было больше женщин? Спорный вопрос, потому что подход к работе зависит от характера человека, личных целей и степени вовлечённости. Хотя, даже мужчины согласны с тем, что наличие женщин-сотрудников даёт свои плюсы. Об этом далее.

2
650
3