Привет, Хабр! Меня зовут Анна Стремилова, в MWS я занимаюсь продвижением приложения Clatch. Хоть я и училась на биолога (история об этом тут), в ИТ я практически с пеленок. Моя мама — программист старой школы, и самыми первыми моими «буквами» были нолики и единички, а рисовать я училась на бумаге для ЭВМ.

В 80-е годы мама вела проект с роботизированной столовой в Минске — это было огромное помещение, где люди выбирали еду по кнопкам, а роботы выдавали и забирали тарелки. Так что я уже привыкла к ситуациям, когда рассказываю маме про очередное айтишное «ноу-хау», а она скептически замечает, что в 80-х это уже было. 

И вот, ко Дню программиста у меня родилась идея: а почему бы не рассказать о профессии глазами специалистов старой и новой школы? С представителем первой я жила под одной крышей, а с представителями второй работаю каждый день. 

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

Машина времени на ON: каким было программирование в 80-х

Неизведанная область притягивала

В моей молодости программирование было новым веянием в науке и технике. Я училась на физическом факультете в Саратовском государственном университете, и вдруг стране понадобились электроники (тогда говорили именно так) и программисты. Половину студентов с нашего курса по желанию перевели на отделение АСУ — автоматизированные системы управления. Я тоже была в их числе. 

После университета нас определили на завод электронной техники в Саратове, где мы занимались автоматизированными системами управления технологическими процессами, или АСУ ТП. Нас было 22 человека — в основном из одной группы. Но наш выпуск был уже третьим, так что мы пришли, скорее, на подхват: основными разработками занимались предыдущие выпускники, а мы помогали им развивать и внедрять технику. 

Нолики и единицы превращаются в ток

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

Работало это так. Мы писали нолики и единицы, они преобразовывались в аналоговую величину (например, в напряжение), а дальше она подавалась на стенд управления. Потом запрос поступал назад, снимались сведения. Допустим, напряжение у нас — 120 вольт. Оно идет по проводам на адаптер, преобразовывается в нолики и единички, и я получаю величину именно в них. Так я анализировала поведение прибора и управляла им: при необходимости прибавляла или убавляла напряжение.

Когда мы внедряли такие процессы в наших цехах, к нам приходили на экскурсию целыми группами. Мужчины-наладчики, которые вплотную работали с оборудованием, удивлялись: как это, технологический цикл идет почти три с половиной часа, и электронная вычислительная машина управляет процессом?

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

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

За 20 лет сфера сильно изменилась

Мне повезло своими глазами увидеть, как быстро прогрессирует вычислительная техника. Сначала я работала на мини-ЭВМ «Электроника-100», которые выпускали в Калининграде:

Еще у нас была управляющая машина «Днепр» — допотопная даже по тем меркам. Рядом с пультом управления стояло несколько тумбочек, блоков, латы, диоды, триоды. Интегральных схем тогда еще не было.

Потом появились ЕС-1020 — огромные шкафы:

И тяжелые диски диаметром 50 сантиметров, на которые записывались программы:

А потом в качестве носителей информации в нашу жизнь пришли перфокарты:

Мини- ЭВМ были непрерывно заняты технологическим процессом. Уже не хватало времени что-то разрабатывать и отлаживать программы, и мы создали систему имитации. Тогда я стала заниматься моделированием программирования. Приходили на ЕС, писали программы при помощи Фортрана, отлаживали, а потом они переводились в коды мини-ЭВМ и шли на них. Если было нужно, мы их дорабатывали.

В 1980-м у нас появился ЭВМ ЕС-1060. Чтобы научиться с ней работать, я трижды ездила на курсы по повышению квалификации в научный центр «Алгоритм» в Минске.

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

В конце 80-х у нас появились черно-белые компьютеры. Мои рабочие задачи не были с ними связаны, но я ходила на обучение из интереса. Техника продолжала развиваться, но на этих компьютерах моя, так сказать, профессиональная эпопея уже заканчивалась.

Мне был интересен каждый мой проект

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

Еще занималась разводкой плат. На столе закреплялся ватман, а сверху бегал ползунок, заправленной черной тушью. Он рисовал плату, транзисторы, резисторы. Я сидела за ЭВМ, нажимала на клавиши и управляла им — ползунок двигался горизонтально, потом вертикально, вырисовывал разъемы и платы. Потом их относили в цех, а там уже работники собирали платы и паяли транзисторы.

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

Работала столовая так: ты подходишь к стойке, перед тобой дисплей. Выбираешь блюда, идешь к окошку и ждешь, когда на транспортере выедет твой поднос. Потом берешь его, садишься за столик, обедаешь, а после относишь грязный поднос уже на другой транспортер, где его забирает робот-манипулятор. Он поднимает посуду наверх, отвозит в мойку, потом сам высушивается и спускается обратно.

К сожалению, мы успели только построить столовую, но так и не запустили ее. Пришли 90-е, и все рухнуло.

Мы постоянно учили языки

Алгоритмические языки интерпретируют программы в нули и единицы. Из-за ограниченной памяти мини-ЭВМ мы были вынуждены сразу осваивать коды, хотя языков уже было много. Я знала Assembler, Fortran, Pascal, BASIC, C и PL, но использовала их не так часто — опять же, в основном работала с кодами.

Например, на Фортране я писала программу для моделирования ЭВМ «Электроника 100 И» на ЕС-1020. Еще я писала программу для пульта управления, с которого можно было открывать и закрывать двери в автомобильных гаражах. Но написать — еще полдела, потом ее нужно было корректировать, особенно если есть временное ожидание. Я корректировала в кодах. Счетчик считает: один плюс один плюс один плюс один — и ты рассчитываешь, сколько плюсов сделать, чтобы получилась одна секунда задержки.

Сейчас такие пульты есть везде: подъезжаешь на машине — и шлагбаум открылся. Но и в середине 80-х у нас это уже было.

Автоматизация в стиле 80-х

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

А у меня для автоматизации была девочка-оператор на подхвате. Она забивала текст программы в ЭВМ и делала распечатку.

Вместе работали и отдыхали

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

Отношения между сотрудниками были теплыми. Если ты, например, изучал новый язык, всегда можно было обратиться за советом к коллеге, который с ним работает.

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

Помимо работы, мы организовывали собственные олимпийские игры: зимой катались в лесу на лыжах, летом — бегали. Здесь было не важно, кто какую должность занимал — общались на равных. Еще мы устраивали пикники, брали с собой супругов и детей. Часто ходили в театры: стояли в очереди за билетами ночами, потому что их было очень сложно достать. Знали актеров наизусть.В общем, любили вместе и работать, и отдыхать.

Забавно, но мы всегда обращались друг к другу по имени отчеству, даже если несколько лет дружили семьями. Или если пришел совсем молодой специалист, тоже называли его именно так. Эта привычка сохранилась у нас до сих пор: когда общаюсь с бывшими коллегами, они обращаются ко мне только «Любовь Алексеевна».

Главный навык программиста

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

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

Назад в настоящее: программирование 2025

Увлекся программированием в 5-м классе

Тяга к программированию проснулась во мне в пятом классе, когда я посмотрел фильм «Социальная сеть». Я понял, что можно накодить что-то уникальное в одиночку, стал придумывать разные проекты и пытаться их реализовать.

Тогда я жил в общежитии с родителями. Нашими соседями были студенты — однажды они проложили локальную сеть между квартирами, и с той поры все начали шериться друг с другом информацией. Потом я увидел у кого-то инструмент для создания сайта — что-то вроде Тильды. Я попробовал сделать свою страницу и показал результат одному из студентов, который проводил для нас интернет. Неожиданно ему понравилось: «Это круто! Держи диск с обучалкой по HTML, CSS, JS и учись дальше». Тогда я воспринял его слова примерно как джедай наставления Йоды. Мне захотелось связать свою профессию с кодингом.

Дилемма: факультет компьютерных наук или математический

Я поступил на математический факультет в Омском государственном университете им. Ф. М. Достоевского. Сначала сомневался: может, все-таки на факультет компьютерных наук? Но мне больше всего нравились дисциплины от кафедры Прикладной и Вычислительной Математики (ПиВМ), к тому же в приемной комиссии сказали, что на матфаке много внеучебных активностей, — и я сделал свой выбор. А потом… потом начались сложности.

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

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

Вакансий было много, но не хватало опыта

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

Тогда я понял, что в первую очередь мне нужно определиться с направлением и нарабатывать навыки именно в нем. Выбрал fullstack-разработку: тут ты реализуешь и фронтенд, и бэкенд — два в одном. Мне казалось ценным, если специалист может справиться с задачей в разных направлениях. Но когда я устроился на фулстек в свою первую компанию, меня настигло разочарование. Да, я неплохо разбирался в каждой области, но мне не хватало погружения во что-то одно, чтобы отточить мастерство.

На первой работе основным стеком был PHP и JavaScript. Мы писали не на чистых языках, а на фреймворках: обращались к библиотекам, брали готовые компоненты и пакеты, чтобы ускорить процесс.

Фулстек обязывает писать код на языках, заточенных для бэкенда и клиентской части. Часто синтаксис разный. Бывает и так, что используя один и тот же язык, можно реализовывать сразу две области, но это было не мое. Позже, когда заинтересовался мобильной разработкой, я уже сам выбирал язык и фреймворк: ушел в сторону Dart и Flutter.

«Ленивая» разработка

В MWS я управляю разработкой мобильного приложения, декомпозирую и оцениваю задачи, занимаюсь ревью кода и документации, слежу за аналитикой работы приложения у пользователей, пишу код. Признаться честно, я стал очень ленивым разработчиком: автоматизирую почти все — от планирования задачи до реализации. Сейчас такое время, что информация, которая тебе прилетает, теряет актуальность в тот же момент, когда ты ее прочитал.

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

Еще постоянно использую так называемый IDE — инструмент для написания кода. Он выглядит как текстовый блокнот, но тут много дополнительных функций, которые упрощают работу: подсветка синтаксиса, внутренние анализаторы кода, дополнительные горячие клавиши, которые позволяют быстро навигироваться и смотреть, что происходит. Получается, такой блокнот на стероидах.

На связи с командой каждый день

Я лидер команды мобильный разработки, и мне всегда важно знать статусы наших задач. Каждый день мы с ребятами созваниваемся и обсуждаем, что сделали вчера, что в плане на сегодня, у кого какие блокеры. Это так называемый daily scrum meeting. После фиксируем все в текстовом формате: каждый строит себе план на день и скидывает его в общий чат. Может звучать занудно, но это помогает себя дисциплинировать, плюс все понимают, какие задачи на горизонте.

По средам у нас командная встреча: задаем друг другу вопросы, планируем активности, если есть какие-то проблемы, вместе думаем, как их решить.

Еще одна еженедельная встреча — Flutter Sync по пятницам. На ней мы обсуждаем разработку, фреймворк, языки и технические детали.

Для командной работы используем несколько инструментов. Основной — это таск-трекер Jira. Мы выстроили полную наблюдаемость процессов, организовав работу в три доски:

• Daily — для ведения ежедневных задач с базовыми колонками: «Нужно сделать», «В процессе» и «Закрыто».

• Epics — для планирования задач на спринт, с более вытянутым процессом по SDLC.

• Goals — стратегическая доска для проработки и ведения долгосрочных целей.

И, конечно, общаемся в корпоративной почте и мессенджерах.

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

Меняется уровень ответственности

Сравнивая свой путь в разных компаниях, я понимаю, что мне требовались одни и те же навыки и решал я похожие задачи. А вот что действительно менялось — так это зона ответственности.

Сначала как программист я решал четкую задачу: на вход три элемента, на выход — true или false. Потом как разработчик брал на себя инициативу: предлагал, как решить задачу, рассказывал, какие есть подходы. Дальше стал управлять командой и отвечать не только за свой результат. То есть за годы работы зона ответственности стала значительно шире. А еще с ростом дополнительных софтовых и хардовых навыков начинаешь глубже понимать, где и что может пойти не так.

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

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

Доводить задачи до конца — даже если очень не хочется

Я убежден: чтобы быть успешным программистом, нужно прокачивать навык решения задач и проблем, уметь углубляться в тему и задавать вопросы. Такой solving problem master.

У меня есть любимая фраза, которую часто говорил мой преподаватель: математик — это не тот, кто умеет быстро считать в уме, а тот, кто умеет доводить любую задачу до конца. В этом огромный смысл: в программировании ты сталкиваешься с задачами, которые сначала непонятны. Мы принимаем как аксиому, что не можем знать все. Но мы должны уметь разбираться в задаче и реализовывать ее.

Мастера одного клинка

Я работал с программистами, которые гораздо старше меня, и замечал, что они максимально исполнительны, сконцентрированы, анализируют мельчайшие детали, всегда нацелены на идеальный результат. И это легко объяснить.

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

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

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

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