Я давний читатель HABR‑а (кажется, с 2011 года), хотя читатель пассивный: даже не был зарегистрирован. Мне казалось, что сотрясать воздух — занятие достаточно бессмысленное, а сказать что‑то новое мне особо и нечего. Но последние пару лет на HABR‑е появляется все больше и больше статей, которые условно можно охарактеризовать фразой «как вкатиться в IT». Возможно, я необъективен, но меня не покидает ощущение, что почти все статьи по этой тематике похожи друг на друга. Не дословно, конечно, но общим направлением мысли. Очень редко встречаются статьи где есть конкретика; все больше общие избитые банальные рецепты, которые, надо признать — чересчур универсальны и не могут служить руководством. Особенно для тех, кто живет в провинции, где нет серьезных разработчиков и где, увы, негде получить необходимый опыт. Можно я расскажу о себе? Мой опыт не универсален, но это реальный опыт. Я не строю иллюзий, что это кому‑то пригодится, но если кого‑то хотя бы подбодрит — уже неплохо.
Чтобы не мусолить и не создавать ненужной интриги, скажу сразу: мне 62 года. Профессиональный стаж программиста 37 лет (с 1987 года). Вероятно, половина читателей HABR‑а младше 37 лет, с чем я их искренно поздравляю — у вас еще много времени. Образование — высшее техническое (с углубленным изучением математики). По основной специальности, правда, работал не долго.
Компьютеров в те годы было немного. Да, были «Синклеры», «БК» и еще целый ряд других. Народ вовсю паял свои машины, но у меня руки всегда росли не из того места, так что это увлечение прошло мимо. Тем не менее, мне повезло: КБ, где я работал по распределению, получило машину СМ-4 (клон PDP-11).
Кроме меня и еще одного парня примерно моих лет в КБ не нашлось никого, кому это было интересно. Правда, парню все это быстро надоело и я остался один на один с этим чудом техники позднего Советского Союза.
Компьютер (тогда их повсеместно называли «ЭВМ») был вполне ничего. Точных характеристик его я не помню, но в память врезалось то, что на борту у него было целых 256 килобайт памяти. Скажу сразу — по тем временам это было реально много. Сколько‑то килобайт занимала операционка (кстати, можно было работать на «голой» машине, без операционки), сколько‑то ассемблер, сколько‑то трансляторы Pascal и C и при этом половина памяти оставалось в распоряжении программиста.
Начинал я с ассемблера. Документация, что шла с машиной, была так себе (за исключением небольшой брошюры полностью посвященной программированию ввода/вывода), но зато был издан ряд переводных книг по PDP-11. Этого было достаточно и через пару месяцев я вполне прилично делал всякие небольшие программки учебного характера, благо меня в этом КБ загружали не сильно и времени было достаточно.
Потом я освоил Pascal и чуть позже C (компиляторы для них шли в составе ПО, прилагаемого к машине). Была еще экзотика в виде языка Focal (сильно кастрированный Fortran), но он был слишком примитивен и годился только для несложных численных расчетов. Книги Н.Вирта и знаменитая K&R были настольными.
Слухи о моих «достижениях» дошли до остальных инженеров и ко мне пришли с вопросом: «А можно ли создать каталог используемых нормативных документов (ГОСТ‑ы, инструкции, отраслевые стандарты, руководства и т. п.)»?. Никто (и я в том числе) не понимал как с таким каталогом потом работать: машина‑то одна на всех и быстрее поискать в бумажной документации, чем ожидать в очереди доступа к ЭВМ. Забегая сразу скажу: так оно и вышло. Каталог все время надо было пополнять и исправлять, что само по себе занимало много времени. Но задача, что ни говори, была достаточно интересной. Тем более, что ни о каких DBase/Paradox/Clipper и тому подобных системах управления БД я слыхом не слыхивал.
Не подозревая о предстоящих сложностях, я, конечно, взялся за работу. Пришлось придумывать все: от структуры хранения информации, до интерфейса (разумеется — консольного; ни о каких GUI тогда речь не шла). И ведь получилось! Криво, глючно, убого — но получилось. Три или четыре месяца я портил глаза и стирал пальцы, но задачу решил. Позже, в 1990 годы была издана книга Джеффри Ульмана «Базы данных на Паскале» и я с удовольствием обнаружил, что в целом я решал проблему верно, хотя за некоторые куски кода и алгоритмы мне было откровенно стыдно (хотя никто кроме меня этого не знал). Конечно, эта разработка была выброшена, но главное — опыт — я получил ценный.
В те годы среди расчетчиков был популярен метод конечных элементов (МКЭ). Издавалось много книг; в основном теоретического характера. Тут мне пригодилась моя математическая подготовка, т.к. МКЭ — это, фактически, решение систем дифуров в частных производных. Считать их на калькуляторах занятие бесперспективное из‑за чудовищного объема входной информации, малых объемов памяти и низкого быстродействия. С появлением СМ-4 это стало возможным (конечно, с массой ограничений, особенно в части представления информации), но я решил попробовать. Это была та еще работа — куда сложнее каталога о котором я писал выше. Но молодость все преодолевает и примерно через полгода я научился считать простые стержневые конструкции. Главная сложность была в представлении этих самых конечных элементов. Математика была относительно простой, хотя пришлось углубиться в методы вычислений, чтобы не терялась точность от накопления ошибок. Чуть позже я расширил программу так, чтобы можно было считать на прочность простые оболочки.
Из того, что я делал в те годы вспоминается программа расчета зарплаты. На исходе развитого социализма была придумана прогрессивная методика расчета — т. н. «бригадный подряд» на базе расчетного коэффициента трудового участия (КТУ). На самом деле методика здравая, позволяющая начислять зарплаты не просто согласно штатному расписанию, но и с учетом выполненной работы и ее сложности. Алгоритм был непростой, постоянно менялся, но в целом был понятным и, главное, давал вполне адекватные результаты. Инженерам это нравилось (начальству — не очень) и в дни расчета я был священной коровой — мне приносили заполненные от руки таблицы, которые я переводил в данные для программы и запускал расчет. Это имело свои издержки — я должен был планировать отпуск так, чтобы последнюю неделю каждого месяца быть на месте. Впрочем, это, конечно — сущие пустяки.
Да, вспомнил еще одну задачу, которую я решал — расчет теплопередачи для гидросистем. В общем, эта задача примерно такого же характера, что и МКЭ, но в ней было гораздо больше всяких справочных данных и жуткая нелинейность параметров в зависимости от температуры и рабочих жидкостей. Правда, особой точности тут не требовалось — надо было убедиться в том, что температура рабочей жидкости не превысит допустимый предел и средства охлаждения (такие как вентиляторы или радиаторы) будут эффективно выполнять свою работу.
А потом Союз развалился. КБ стало никому не нужным. Инженеры постарше вмиг обеднели. Молодняк, вроде меня, стал искать другую работу. Так я попал в банковскую автоматизацию. И это было настоящее Эльдорадо. Банки плодились на зависть кроликам и надо было как‑то вести бухгалтерский учет. Программ не было (что‑то более‑менее достойное стало появляться где‑то с 1995 года). Так что большинство банков создавали свое ПО сами. Тут я впервые столкнулся с настоящими БД (это был Informix) и Unix (да‑да, именно Unix, т.к. Linux тогда был в зародышевом состоянии). Нашу программу мы втроем написали на жуткой смеси C и Prolog (последний был тогда невероятно популярен). И она, черт побери, работала! Причем достойно работала. Конечно, из редактора и компилятора мы не вылазили года полтора (часто задерживались в офисе до 2–3 часов ночи и оставались там ночевать), никаких выходных и тем более — отпусков, но молодость все преодолевает.
Потом были другие банки. Примерно до 2005 года в них была интересная работа для программистов: валютные операции, пластик, потребительское кредитование. Потом эти ниши постепенно заполнились поставщиками и вендорами и работа программиста в банке стала сводиться к поддержке и мелким допискам. Одним словом — скукота и рутина.
Хвала небесам, я это понял быстро и примерно с этого времени стал развиваться вширь. К этому моменту я профессионально владел SQL, C, вполне сносно C++ и Perl, знал UNIX (и уже пробовал Linux) плюс всяко‑разно (Delphi, JS и проч.) по мелочи. О Java, конечно, слышал и даже пробовал, но не погружался. Что‑то мне подсказывало, что Java — самое то. Так я стал переходить на Java. Не скажу, что это был простой опыт. Со сказочкой о том, что «если знаешь C++, то Java залетит на раз» я быстро распрощался. Тут косяком пошли фреймворки, бизнес стремительно двигался в WEB. Одним словом фронт работ был обширный и не вскочить на этот поезд было бы крайне неразумно. С тех пор я в основном пишу на Java и его производных (Scala, Groovy). Тогда же мне попался на глаза Python и чем‑то зацепил. Не скажу, что у меня на Python есть серьезные проекты, но я его не бросаю и продолжаю поддерживать необходимый уровень: периодически делаю небольшие проекты утилитарного характера. По роду моей нынешней работы я много пишу для BigData (Spark, Aitflow и т. п.) — тут, я надеюсь, Python когда‑то мне сильно пригодится и не исключено, что я окончательно на него мигрирую.
Стыдно сказать, но вот Golang мне не зашел. Почему — не могу объяснить: не тащит и все тут. Не иначе — какой‑то дефект ДНК. Зато зашел Rust. Впрочем, это как раз и понятно — любой (ну ладно — почти любой) C‑шник так или иначе видит в Rust «родственную душу». Пока, к сожалению, ничего сколько‑нибудь похвального я на нем не сделал, да, по правде говоря — вряд ли и сделаю. Времени у меня не так и много: могу и не дождаться его истинного расцвета (который может и не случиться, что тоже не исключено). Так что зарабатываю пока старой‑доброй Java и всем тем, что вокруг и около: Spring, Spark, Kafka...
Теперь, возвращаясь к тому, с чего я начал: вкатывание в IT. Универсальных рецептов — нет. Я по крайней мере их не вижу. И сам ничего не подскажу. Я просто описал свой опыт и единственная, в сущности, мысль заключается в одном: если вам это интересно — рискните. Если не интересно — даже не пытайтесь. Прежде чем нести деньги на курсы, откройте YouTube — там полным полно обучающих материалов. Начните с Python, не трогайте Java, C++ или Go. Просто попробуйте повторить какой‑нибудь pet‑проект. Один в один, без фантазий. Заставьте его работать. Если на этом этапе вас не стошнило, то шанс есть.
У меня нет формального образования в области IT. Увы, конечно, но так сложилось. Однако, это ни в коем случае не препятствие — в этом я уверен.
К курсам я отношусь скептически. Там люди хотят заработать денег и привлекают наивных Буратин, предлагая зарыть свои денежки под деревом. Законно, но все‑таки аморально. Дерево само не расцветет, сколько денег под ним на зарывай. Дереву нужно другое — полив, обрезка, защита от вредителей. Корень проблемы, мне кажется в том, что программирование, как и любая другая творческая деятельность (живопись, литература, архитектура, музыка) не всем доступна. Нужен интерес, обусловленный не уровнем оплаты, а любовью к тому, чем занимаешься. Если ориентироваться только на то, что в IT много и хорошо платят, то это заблуждение. Да, платят хорошо, порой — даже много. Но в IT полным‑полном рутины. Программисты с опытом подтвердят: порой днями и неделями приходится искать почему программа не работает так, как надо. Можно десятки раз перечитать код, выучить его наизусть, но не видеть ошибки (как правило, элементарной и глупой). С этим сталкивались все профессиональные разработчики, даже самые‑самые. Мы всего лишь люди. Начинающему разработчику с вероятностью близкой к 1 достанется поддерживать т. н. legacy код. Это — отличная школа. Без иронии и издевательства. Посмотрите изнутри как все устроено, ужаснитесь, успокойтесь и засучите рукава. Старого кода на порядки больше нового и он должен работать. В процессе этого вы непременно найдете более аккуратные и элегантные решения. Обсудите их с коллегами, взвесьте риски и, если нет веских возражений, реализуйте их. Будьте готовы к тому, что вы допустите ошибку и не одну. И вас за это не похвалят. Может быть, ваши ошибки придется исправлять другим. Вы готовы краснеть и держать удар? Готовы неофиты пройти эти грабли? Способны ли они пару лет поработать за еду? Вот то‑то. Возражения я знаю: семья, маленькие дети, кредиты и далее по списку.
Не готовы рискнуть — не лезьте вообще. Не обманывайте себя. Найдите себя в другом.
Я с удовольствием работаю с начинающими. И сразу вижу — будет толк или нет. Это определяется в течение одного‑двух часов, не более. Курсы или дипломы значения не имеют от слова «совсем». Если человек способен, то это видно да и он сам, почуяв «запах», будет рвать когти и развиваться. Читайте. Много. Очень много. Собирайте библиотеку. Да, далеко не всегда переводы иностранных книг выполнены качественно, увы. Чтобы меньше от этого зависеть — читайте в оригинале. Английский (а именно он основной язык программиста) не так сложен, как кажется. Технические тексты на нем вполне доступны, а большего вам и не надо (пока, во всяком случае). Моя норма чтения — от 20 до 50 страниц в день (зависит от сложности материала). Процесс не должен прерываться, ни в выходные, ни на отдыхе. Нет возможности читать — думайте, решайте в голове, благо проблем — не перечесть. Делайте пометки, наклеивайте стикеры. Обязательно заведите репозиторий; не обязательно общедоступный, достаточно на первых порах и локального. Научитесь основным приемам работы с системой контроля версий. Вне зависимости — будете вы работать с базами данных или нет — изучите SQL. Не обязательно до тонкостей. Но изучите непременно.
Освойте Linux. Это несложно. Скачайте образ той же Ubunta и потренируйтесь. Опять же, нет необходимости быть гуру (если, конечно, вы не планируете быть системным администратором), но основные вещи знать и уметь необходимо.
Последний совет — самый трудновыполнимый: найдите наставника. Найдите человека, готового уделить вам минут 15 в день, не более. При возникновении проблем, не бегите к нему — потратьте день/другой на самостоятельный поиск решения. Если окончательно застряли — спросите. Повторюсь — этот способ обучения самый трудновыполнимый, но и самый эффективный. Хороший наставник не даст вам залезть в дебри или пойти не в ту сторону. С ним вы сэкономите массу драгоценного времени, а время — ресурс невосполнимый.
Удачи вам, коллеги!
Автор:
atues
