Какое‑то время назад я опубликовал заметку о своем личном опыте «вкатывания» в IT. Возвращаться к этой теме я не предполагал, считая, что она (для меня, по крайней мере) исчерпана и сказать мне больше нечего, но вот завершающая фраза о преимуществах обучения под руководством наставника.

Хороший наставник не даст вам залезть в дебри или пойти не в ту сторону. С ним вы сэкономите массу драгоценного времени, а время — ресурс невосполнимый

оставляла все‑таки пробел: ничего конструктивного — где найти такого наставника — я тогда так и не предложил, хотя в комментариях эта тема и была поднята. Признаюсь сразу — рецепта и в этот раз не будет; будет опять только мой личный опыт. Этот опыт не показателен, не универсален и точно не «сработает» для всех. Но он, надеюсь, поможет хотя бы расширить круг поисков.

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

Скрытый текст

Для тех, кому некогда читать упомянутую заметку, нужно иметь в виду, что по образованию я не программист (в те годы такой специальности в ВУЗах не было). Однажды и случайно я столкнулся с компьютерами и меня это увлекло. Увлекло настолько, что я «порвал с прошлым» и сменил профессию. Не сразу, но осознанно

В начале был завод

По окончании ВУЗа я работал по распределению в крупном КБ.

Скрытый текст

Кто не в курсе — в СССР была такая форма практически обязательного трудоустройства выпускников ВУЗов; кстати, весьма разумный способ дообучения и приобретения практического опыта. Сейчас, судя по всему, эту практику пытаются восстановить для тех, кто обучается на бюджете

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

Скрытый текст

Кстати, инженерная школа СССР была, насколько я могу судить, вполне конкурентноспособна. То, что т. н. «западная» техника и многие товары (те же легковые автомобили, электроника, бытовая техника, обувь, одежда и даже мебель) были в массе своей лучше отечественной — это отрицать глупо. Промышленность СССР сильно не дотягивала в культуре производства и качестве такой продукции (в отличие от продукции военного назначения). Уровень автоматизации был ниже (или вовсе никакой), элементная база отставала, а ее надежность оставляла желать лучшего. Мало уделялось внимания дизайну (по принципу «и так возьмут — другого все равно нет»), хотя случались и приятные исключения. Но то, что касалось собственно конструирования — вот тут стыдиться было нечего. «Продукция» выходящая из рук конструкторов была нередко очень достойной. Но, увы, от идей, чертежей и прототипов до реальных товаров дистанция немалая, которую наша промышленность преодолевала плохо

Времена, понятно, были «архаичные» и никого, кто хоть что‑то понимал в компьютерах и программировании, мне найти не удалось.

Скрытый текст

На заводе, правда, существовал мутный отдел АСУ ТП, но существовал он для проформы (как тогда говорили «во исполнение исторических решений такого‑то съезда КПСС») и демонстрации как бы намерений, как бы идти, как бы в ногу с прогрессом, как бы в светлое будущее. Никто никуда не шел, да и специалистов там не было; по крайней мере программисты там не значились. Что‑то трогать, исправлять или разрабатывать новое — запрещалось: а вдруг «оно» сломается. Были техники что‑то обслуживающие и операторы ЭВМ. Последние почти все — жены, любовницы и дочери заводского начальства. Чем они должны заниматься они не знали сами. Да и не пытались: стаж идет, обстановка почти стерильная, контингент «интеллигентный» — мечта, а не работа

Поэтому разбираться, как самому молодому в КБ, досталось мне. Поскольку спросить было некого, то единственными источниками информации и знаний оставались любознательность, документация к компьютеру СМ-4 (откровенно говоря — так себе) и книги. Именно книги — почти все переводные — были основным источником сведений. И у меня что‑то даже получалось.

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

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

Первым, о котором я хочу рассказать, был Виталий Николаевич — ведущий конструктор подъемно‑транспортных систем (краны, подъемники, транспортеры, конвейеры, лифты, элеваторы, эскалаторы и т. п.). Для справки: общая длина одних только конвейеров — ленточных, цепных и еще, не помню уже, каких — на заводе была под 200 километров. Хозяйство мало того, что огромное, так еще и относится к категории опасных для жизни. Внешне Виталий Николаевич поразительно напоминал Дон Кихота с иллюстраций Гюстава Доре, разве только без усов и бороды: высокий, тощий, сутулый, не от мира сего. Он органически был не способен подолгу сидеть на одном месте и почти непрерывно прохаживался между столами и отделами (КБ занимало 4 этажа офисного здания), засунув руки в карманы, глядя куда‑то в пространство со спичкой в зубах. Если он не жевал спичку — он курил «Беломор» (это, разумеется, не поощрялось, но и не преследовалось) из‑за чего его рабочий стол стоял немного особняком, что его, безусловно, полностью устраивало.

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

Скрытый текст

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

Другой инженер — Владимир Петрович, был в известном смысле противоположностью Виталию Николаевичу. Невысокий, крепкий, очень подвижный (в молодости — мастер спорта по гимнастике), азартный. У него была превосходная инженерная выучка и при случае он мог предложить яркое, хотя порой, весьма фантастическое решение. Его специализация — гидро/пневмо/теплотехника. Предмет свой он знал феноменально: однажды я присутствовал при достаточно унизительном разгроме доктора физико‑математических наук, приглашенного в КБ для консультации по расчету какого‑то холодильного оборудования.

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

Третий инженер — Константин Николаевич был в некотором роде синтезом первых двух. Высокий, сутулый, задумчивый и обычно малость отрешенный и в то же время, когда надо, азартный, авантюрный, задиристый. Константин Николаевич был ходячей технической энциклопедией. Все, что касалось машиностроения, металловедения, сопромата и далее по списку было ему не просто знакомо. Казалось, он лично ощупал, обнюхал, обмерил, обследовал каждую деталь, каждый узел, каждый виток резьбы и проч. в любом известном механизме, станке, машине. Он воспринимал картинку целиком и распознавал достоинства и недостатки каким‑то фантастическим чутьем. Если ошибка была элементарной, то Константин Николаевич не останавливался перед язвительным комментарием. Мог (будучи начальником отдела) отобрать проект у одного ведущего конструктора и передать другому, а самого «виновника» сослать на деталировку (почти как в армии: «красить траву зеленкой, отдавать честь столбу и торжественно хоронить окурок»). Статус и должность лица значения не имели: студенческих ошибок он не спускал.

Почему я вспомнил об этих людях и какое отношение они имели к наставничеству и моему становлению как программиста? Прежде всего, и это главное, они — инженеры. Настоящие. Они не чурались общаться со слесарями, токарями, сварщиками, электриками. Они не брезговали увидеть все своими глазами и пощупать своими руками, если надо — спуститься в подвал, если надо — залезть на крышу. Они были и проектировщиками, и внедренцами, и поддержкой. Виталий Николаевич — воплощение инженерного искусства, стремления к совершенству, вдохновения, нестандартного подхода. Владимир Петрович — воплощение надежности, глубокого понимания и практичности. Константин Николаевич — воплощение академизма, но не абстрактного, а действующего. Благодаря им я осознал, что программирование — это тоже инженерное искусство, в котором прекрасно могут (и должны) сочетаться фантазия, вдохновение, твердые основы, внимание к деталям, забота об удобстве, широкое использование надежных и проверенных решений и выполнимость поставленных целей. Все по возможности должно быть простым, безопасным и удобным. Никаких излишеств — функциональность прежде всего. Никаких предположений о безошибочности, квалификации и аккуратности тех, кто будет эксплуатировать спроектированные ими машины. Если последние могли работать без участия человека — прекрасно: человек — самое ненадежное звено. Если без его участия не обойтись, то чем меньше это участие — тем лучше: пусть работает физика, уж она‑то точно не подведет.

Потом были банки

Когда в начале 90-х наступили совсем грустные времена, я уволился из КБ и по протекции школьного товарища попал в банк. Поначалу я занимался черт знает чем (вспоминается исключительно нелогичная эпопея регистрации проспекта эмиссии ценных бумаг). Чуть позже я познакомился с двумя ребятами программистами — Евгением и Андреем, которые «пилили» для банка АБС: Автоматизированную Банковскую Систему. АБС это, по существу, учетная программа вроде бухгалтерской, но, разумеется, с некоторой спецификой. Потихоньку я знакомился с их работой и, наконец, примкнул к компании. Основной код АБС был написан на чистом C. В качестве БД использовался Informix. Все это «крутилось» под Unix. И все было внове — и предметная область, и технологии, и стиль работы.

Разумеется, поначалу я был «на подхвате». Мне давали исходники и моя задача состояла в их проверке, доработке и отладке. Это не было legacy‑кодом. Это был сырой, недоработанный, недошлифованный код. Часто это были просто заготовки будущих модулей. Авторы сидели рядом и в случае чего я мог спросить их если что‑то не понимал или указать на ошибку. Так я освоил C, а заодно и SQL. В общем‑то, у ребят не было какого‑то очень глубокого опыта программирования. Они, бесспорно, были лучше меня подготовлены теоретически, но они, как и я, относительно недавно закончили университет и до банка ни в каких масштабных проектах не участвовали. Время было жесткое, но динамичное и романтичное. Мы учились друг у друга. Постепенно я освоился и стал полноценным участником. Ребята тоже стремительно набирались опыта и через несколько месяцев у нас сформировался достаточно квалифицированная команда. Все были на равных. Начальника у нас не было (да‑да, тогда это было нормально), архитектуры, техзаданий и аналитики тоже, так что мы были предоставлены сами себе. Задачи сыпались отовсюду, времени хронически не хватало. «Отпуск?» — нет, о таком мы и не думали. Здоровая конкуренция, увлекательные споры, мозговые штурмы, совместное обсуждение, поиски ошибок. Поэтому в какой‑то степени и Евгения, и Андрея я считаю своими наставниками. Они не учили меня, они учились со мной, а я учился у них и с ними. Они дали мне шанс попробовать себя в настоящем деле. От нашей работы зависело многое, очень многое. От нас ждали результатов и мы их давали. Разумеется, мы совершали ошибки, случались аварии и происшествия. Все, в общем, как и у всех.

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

В этом банке тоже была своя АБС, которую — вот совпадение — тоже разрабатывали два человека: Сергей и Владимир. Но это были уже разработчики экстра‑класса. В качестве базы данных использовалась нереляционная СУБД ИНЕС — очень интересная и оригинальная советская разработка конца 70-х годов. Для начала и середины 90-х годов ИНЕС была весьма мощной платформой. Старший из программистов (Владимир) был одним из основных разработчиков ИНЕС.

Скрытый текст

Вообще, в те годы программистам делегировались весьма широкие полномочия. Их не связывали методологиями, мелочным надзором и опекой. Они обычно сами выбирали инструменты и технологии. Сказывалось влияние советской системы образования математиков, физиков и инженеров. Доверие было высоким. Те, кто не «тянул» либо уходили, либо стали выделяться в касту менеджеров от программирования, либо просто паразитирующих на теле IT. Порог входа был высоким; денег программистам, кстати, тогда платили нормально, но не так чтобы очень много. Да и тратить их было порой просто некогда

То, что «творили» Сергей и Владимир — описать невозможно. Я в первый (и боюсь — в последний) раз видел людей, которые мыслили и разговаривали между собой на таком непередаваемом уровне абстракции. Казалось, информация, как в фантастических фильмах, проявлялась из воздуха. Они видели нечто, чего не видел никто. Даже жестикуляция была не столько эмоциональной, сколько функциональной с образами структур данных или кода. Это не передать словами — эта надо было видеть. Поначалу я откровенно «плавал», но потихоньку стал втягиваться.

Кроме того, они феноменально владели прикладной частью, т. е. программированием. Основной код был написан на C. Я, разумеется, считал, что недурно им владею. Напрасно. Владеть синтаксисом, стандартными библиотеками и основными приемами — это пустяки. На языке надо уметь мыслить, а мои навыки в этом напоминали соревнование в сочинении рассказа между первоклассником и, скажем, Чеховым. Не в том дело, что они писали быстро. Дело в том, что они писали просто. Ничего мудреного, абсолютно. Но все уместно, логично, оптимально. Никаких хитрых штучек и приемчиков. Можно было сесть рядом и наблюдать как на экране появляются строки, сразу обретающие смысл. Понятия «чистый код» тогда не существовало, но то, что видел я — было именно чистым кодом.

Типичная картинка: Сергей и Владимир сидят в разных концах комнаты каждый за своим компьютером, да еще и спиной друг к другу. Первый что‑то правит в одном модуле, второй — в другом. Первый модуль импортирует второй. Тут же, не оборачиваясь, в нескольких фразах обговариваются детали и тут же параллельно вносятся изменения в оба исходника. Минут через 20–30 практически одновременно оба говорят «готово», начинается компиляция и проверка. Результат почти всегда положительный. Там же я впервые увидел то, что позже назвали «парное программирование». Конечно, это касалось только критически важных фрагментов: один набирает код, второй смотрит, корректирует, уточняет, подсказывает. Потом они менялись и так до тех пор, пока результат не удовлетворял обоих. Это была самоподдерживающаяся система, аккуратная, пластичная, гибкая, но устойчивая. Ну да, случалось, что и они ошибались, но даже это были ошибки мастеров.

И Сергей, и Владимир были, разумеется, крайне занятыми людьми и мне даже в голову не могло прийти попросить их понаблюдать за моей работой и направить меня в нужном направлении. Я просто брал исходники, читал и думал. Если что‑то было мне ну совсем не по зубам (это, как правило, касалось специфики работы с ИНЕС), я спрашивал и они с готовностью, не смотря на занятость, отвечали. Причем, ни разу я не услышал и не увидел с их стороны ни тени снисхождения, усмешки, досады или пренебрежения, хотя, подозреваю, поводы я им давал. Никаких «это элементарно», «поищи по исходникам» и им подобных.

Скрытый текст

Помнится однажды, Сергей, будучи занят сверхсрочной задачей, сказал, что объяснит, но позже; это «позже» наступило когда совсем стемнело, мы проголодались и Сергей предложил совместить полезное с приятным и перенести беседу в ресторан, где и состоялось обсуждение

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

Были ли эти двое моими наставниками? Формально — нет. Фактически — да. Тогда я окончательно усвоил: конечно, язык программирования, библиотеки (фреймворки), среда разработки имеют значение, но не определяющее. Это как хороший плотник: он построит дом используя только пилу и топор, а плохого не спасут лучшие инструменты (да‑да, тот самый танцор, которому что‑то мешает). Важнее всего — способность рассуждать, способность искать, способность признавать ошибки, способность — если уверен — убеждать. Если что‑то идет не так — остановись, подумай. Будь честен и перед собой, и перед другими. Лучше выбросить и начать заново, чем городить костыли. Алгоритмы, структуры данных — да, это важно, это — основы. Но не понимая как их выбирать и как применять — все бессмысленно. Именно поэтому многие выпускники, казалось бы — прекрасно подготовленные, с высокими отметками, оказываются в «боевой» обстановке никудышними программистами. И что хуже всего, их профессиональный потолок никогда не поднимется выше тривиальных задач. Это не их вина, это их беда (практически, как в поэзии: рифмовать умеют все, поэтами становятся единицы).

Скрытый текст

И, кстати, именно тогда (кажется, это был январь 1995) я впервые увидел Linux. Показал мне его Сергей. Честно сказать, в тот момент Linux никакого впечатления на меня не произвел. Ну терминал, ну знакомые команды, ну прикольно. Какой‑то недоразвитый Unix. И что? Правда, Сергей был в восторге, которого я тогда не разделял и решил про себя, что Linux не более, чем очередная программистская игрушка: пройдет немного времени и забудется. Сергей оказался куда более прозорливым, он видел (или, быть может, чувствовал) перспективы

Потом были другие места работы, другие люди, другие задачи, другие проекты. Программирование из мало кому понятной, но довольно романтической профессии, где принимали решения и задавали тон относительно немногочисленные профессионалы, постепенно превращалось в быстро растующую отрасль со всеми полагающимися «причиндалами». Роль отдельных личностей падала, роль коллективной работы возрастала. Теперь нередко то, что делали два‑три, от силы — пять человек, стали делать десять‑пятнадцать и более. При этом число действительно работавших и знающих специалистов если и росло, то незначительно. В отличие от управленцев. По моим ощущениям примерно к 2005–2007 годам это стало повсеместным. Стало ли лучше? У меня есть мнение на сей счет, но я не намерен затевать очередную holy war.

И что из этого следует?

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

После всего этого я почувствовал, что действительно стал походить на программиста и могу работать без подпорок. Период моего ученичества (время, проведенное в КБ — не в счет) длился около трех лет. Вряд ли это можно считать оптимальным способом получения знаний, навыков и опыта. Сейчас, вероятно, весь путь можно проделать быстрее. Хотя, честно говоря, не уверен.

Разумеется, на этом мое постижение IT не закончилось. Это было начало. Пришлось изучать и пробовать многое и многое. Что‑то я узнавал из журналов и книг. Еще больше — из бесед и совместной работы с коллегами‑программистами. Несколько позже (году этак в 1997) стал более‑менее нормально доступен Internet и возможности получения информации неизмеримо расширились. Правда, в еще большей степени расширился и поток информационного мусора, так пришлось учиться сепарировать зерна от плевел. Но зеленым новичком я уже не был. У меня была крепкая и надежная база, был практический опыт. Пришли новые языки, технологии, подходы и методики. Не все из них, на мой взгляд, достойны того внимания, что им уделялось и уделяется, но они есть, а уж будущее рассудит — что из этого выживет, а что — нет.

Если начинающему доведется попасть в хороший проект — это удача. Платить, скорее всего, будут не много, да еще заставят ковыряться в чем‑нибудь дремучем и нередко весьма пахучем. Может год, может дольше... Как повезет. Хочется все и сразу? Мечтать не вредно. Набирайтесь опыта, впитывайте знания. Даже в древних программах их много (ну, хотя бы потому, что ими продолжают пользоваться и не стремятся заменить новыми, с новыми же ошибками). Не поддавайтесь искушению вайб‑кодинга или подсказкам AI‑чатов, по крайней мере до тех пор, пока твердо не овладеете базой: алгоритмами, структурами данных, навыкам проектирования, анализа и кодирования. Вайбнуться вы успеете всегда, но занявшись этим слишком рано вы рискуете так никогда и освоить того, что составляет сущность программирования. Это как кататься на коньках: либо вы выходите на лед, рискуя упасть (и падая), но все‑таки учитесь, либо постоянно держитесь за бортик, делая вид, что катитесь. Вайб‑кодинг и AI‑чаты это для начинающих — как раз тот самый бортик. Есть риск так никогда и не оторваться от него. И кого вы обманываете?

Я вовсе не против таких инструментов. Человеческая память склонна забывать то, чем давно не пользовались. Но это, как мне кажется, не может служить оправданием собственной лени или желанием побыстрее «срубить бабла». Да, работу вы, возможно сделаете быстрее и заслужите похвалу «эффективных» менеджеров, но что останется в голове, какой запас знаний и навыков вы приобретете? И как надолго? Впрочем, подозреваю, не всем это нужно: как говорится, день прожил и довольно.

Скрытый текст

Небольшая провокация

В августе 2000, в газете The New York Times была опубликована заметка, посященная состоянию дел в разработке ПО (https://archive.nytimes.com/www.nytimes.com/library/tech/00/08/biztech/articles/28code.html). В ней приводится высказывание Билла Джоя — ведущего разработчика BSD Unix, виртуальной памяти, основных сетевых утилит и редактора vi, а также одного из сооснователей Sun Microsystems: «The truth is, great software comes from great programmers, not from a large number of people slaving away».

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

Еще один источник знаний — opensource проекты. Какие именно? Да любые! Они легко ищутся — стоит только захотеть. Вот, например, здесь: https://github.com/practical‑tutorials/project‑based‑learning. Или здесь: https://viewsourcecode.org/snaptoken/similarTutorials.html. Или любой проект из фонда Apache: https://www.apache.org/. Не говоря уж о https://github.com/. Только не говорите, что не можете найти — это значит, что вы не и искали.

Скрытый текст

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

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

Также предлагаю взглянуть на недавнее введение в язык, написанное Ричардом Столлманом с соавторами: https://github.com/VernonGrant/gnu‑c-language‑manual/blob/main/gnu‑c-language‑manual.pdf

И, разумеется, книги. Литература по языку поистине необозрима, так что я не буду даже пытаться что‑то советовать: пробуйте и выбирайте сами. Но книгу Кернигана и Ритчи (второе издание) необходимо изучить непременно. Мне известны по крайней мере три перевода, но больше других нравится перевод 1992 года, опубликованный издательством «Финансы и статистика». Замечание: в те годы русскоязычная терминология только устанавливалась, поэтому некоторые термины переведены непривычно (например, pipe переводится не как «канал», а как «трубопровод», а character не как «символ», а как «литера»), но в остальном и перевод, и редактура великолепны.

Очень эффективный, хотя и самый сложный способ — реализовать свою идею. Не важно — интересна ли эта идея кому‑то еще, есть ли у идеи потенциал монетизации; главное, чтобы она была интересна вам. Один мой приятель выбрал в качестве такой идеи планировщик по типу тех, что входят в состав операционных систем. Ему было интересно как работают алгоритмы планирования, распределение времени и ресурсов, многопоточность. Другой приятель, заинтересовавшийся компиляторами, самостоятельно разобрался с теорией и реализовал C‑подобный язык на котором написал интерпретатор Lisp. Используя этот Lisp он реализовал интерпретатор Prolog. Кто‑то скажет — игрушки! Ну, можно и так, но опыт, который они приобрели — очень даже не игрушечный.

Погружайтесь, пробуйте. И читайте, читайте, читайте. Лучше на английском — это, как никак, lingua franca нашей профессии. Что ни говори, но самообразование — самый важный способ, который доступен всегда.

И, напоследок, простите — ложечка дегтя: успех — не гарантирован, удача — обманчива, везение — сомнительно. Не готовы рисковать? Тогда не обманывайтесь и не тратье жизнь на IT: ищите что‑то другое. В жизни хватает разочарований; не добавляйте новых, если чувствуете, что IT — не ваше.

И все же, желаю удачи! И везения, конечно.

Мои «университеты» и мои «наставники»