Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес. Без какого-либо понимания, что я делаю и куда меня это приведёт.

Я никогда не считал это чем-то серьёзным, но был уверен, что в случае чего смогу этим прокормиться — так по итогу и вышло. Хоть я и усердно убегал от «бездушных железок» (как же я заблуждался, что IT — это про железки). Даже успел закончить факультет психологии, параллельно поддерживая сайт кафедры на PHP+HTML, почему бы и нет — «ты же программист» надолго закрепилось за мной, мне было не сложно, даже приятно.

Забавно, но именно в ту веб-студию я устроился на пятом курсе, рассылая максимально несерьёзные резюме (осторожно: Twitter Bootstrap) — с одной-единственной целью: сделать всё, чтобы не найти работу, хе-хе. Потому что — ты же программист, выпускник психфака, с корочкой специалиста по связям с общественностью и дипломом о том, как работает невербальная коммуникация в интернете — я, если честно, вообще не представляю, как можно было найти работу.

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

Ох, были времена, стомегабитная локалка на весь город, никакого внешнего интернета, а угроза «я тебя вычислю по IP» реально пугала, за сообщением «го коннект» стояла настоящая встреча на лагерном.

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

На собеседовании я честно заявил, что пришёл ненадолго — просто хочу понять, как работает бизнес, и открыть своё юзабилити-агентство

К тому моменту я уже засмотрел до дыр все ролики UsabilityLab, а идея eye-трекера будоражила мой тогда ещё неокрепший мозг.

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

Надо ли говорить, что я там проработал 5+ лет. Я сильно вырос за это время — и вместе со мной выросла и сама веб-студия. Она трансформировалась из компании, делающей проекты за 10 тысяч рублей, в серьёзную фирму, разрабатывающую миллионные системы. К тому моменту меня уже сильно интересовало: а что вообще происходит с проектами после того, как мы отдаём их заказчику?

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

Кстати, помните про юзабилити и «секретный секрет бизнеса», который я должен был украсть за годик-другой и стать миллионером? Барабанная дробь, ? тр-р-р-р, этого не произошло. Ни через год, ни через пять.

А я не забыл. Иногда вспоминал в шутку. А потом — как-то уже не в шутку — я нашёл ответ. И он меня испугал до кончиков пальцев. Он лежал на поверхности, но был… некрасивый.

А бизнеса-то и нет

Или, точнее, он есть — но совсем не в том виде, как я его себе представлял, будучи программистом.

Вся эта куча людей работала по какой-то неведомой силе. Проекты горели. Иногда приходил наш крутой босс (здесь я бы вставил ссылку на его доклад, но не нашёл, так что просто оставлю великую цитату: «дизайнерское др*чиво») — разруливал конфликты, наказывал плохих и в целом держал всю эту штуку на плаву.

А я мечтал о системе. А потом пришло неминуемое осознание: система — это не обязательно что-то детерминированное.

Мир может просто как-то работать — и при этом работать.

Это пошатнуло мою программерскую реальность, заронив первое зерно сомнения:

А не фигню ли я делаю каждый день, создавая “идеальные” программы?

Но вся грусть составления портфолио быстро развеивала эти абстрактные мысли о всём сущем: вроде бы столько крутых проектов — а показать-то и нечего.
Тут сделали редизайн, там компания закрылась, где-то всё перевёрстали.
Это что же, мне и внучке нечего будет показать?
Вот, мол, смотри, какие сайты под IE6 верстал твой дед — 404.

Мне повезло: портфолио и не понадобилось

К нам пришла странная компания и заказала большой проект. Что она странная — я понял позже. Странная она была тем, что заплатила трём подрядчикам за одну и ту же разработку ?. Меня, как ведущего разработчика, конечно же, поставили на этот проект — а то мало ли что.

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

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

С эйфорией и мотивацией я ушёл в процессы: помогал внедрять скрам, OKR, дизайн-системы (Может быть я даже когда-нибудь возрожу проект, хе-хе). Мотивация была шкурной: я хотел писать классный код. Но понял, что кода недостаточно. Дизайнеры должны понимать, что делают. Бэкендеры — дружить и писать API. QA — не мешать релизам. В итоге мы делали по два релиза в день и показывали недосягаемый перформанс.

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

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

Тогда я ещё не понимал, к чему это в итоге приведёт. Я просто делал то, что считал нужным и полезным. Но с каждым разом я всё больше и больше ломался как разработчик.
Этот капкан стягивался всё сильнее — и в какой-то момент должен был стрельнуть.

Так и произошло

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

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

Отложив свое техническое эго подальше, к тому моменту это было уже не так и сложно сделать. Мы начали общаться. Я был искренне любопытен. Мы говорили полчаса, час. И вдруг… идея-то не такая уж и бредовая. Да, слова не те, да, нюансы. Но по сути — эту будет работать, и это не плохое решение.

Как так? Час назад — бред, сейчас — рабочее решение? Сколько раз ещё такое бывало? А я вообще профессионал? Хм, может так нужно делать всегда...

Капкан захлопнулся. Обратного пути не было. Мир стал другим

Список книг и траектория того, чем я зачитывался взахлёб, были предопределены ещё задолго: Голдратт, Канеман, Талеб, Фромм, Сазерленд — да чего там только не было.
Я читал примерно всё, до чего мог дотянуться и что хотя бы в отдалённой степени могло помочь.

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

Забавно — прошло 13 лет, а я теперь знаю больше того, чего не знаю.
И как будто снова стал тем самым школьником, ковыряющим мапхак для Diablo II через AIDA64, пытаясь исправить баг в ASM, которого я вообще не знал — просто чтобы оно заработало на новой версии клиента.

Только теперь вместо кода — системы. Вместо багов — процессы. А из инструментов — лишь опыт, знание и дикое желание разобраться. Разобраться и сделать так, чтобы невыносимая лёгкость разработки стала не такой уж невыносимой.

Если вам показалось, что история закончилась на самом интересном месте — то да и нет. Эта история — просто жизнь, и она продолжается прямо сейчас.

Но у меня есть еще пара докладов:

  • ? Про уроборос разработки и BIZ+DEV: ссылка

  • ? Продолжение истории и CTO-рефлексия: ссылка

А на этом у меня пока все, такая история!

Комментарии (18)


  1. MEGA_Nexus
    19.06.2025 15:16

    Что стало с той компанией, где начались внедряться идеи Голдратта и его ТОС (теории ограничения систем)? Стало лучше или стало хуже?


    1. DragorWW Автор
      19.06.2025 15:16

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

      Потом было 5 лет CTO — последняя ссылка про это. Но там я довольно быстро пришёл к осознанию: бутылочное горлышко вовсе не в IT, а то, что действительно нужно менять, — за рамками моего влияния.


      А из TOC я забрал логические инструменты. На удивление, всё это очень похоже на архитектурные подходы и принципы проектирования эффективных систем. В общем, тем TOC и занимается — исходя из одного простого постулата:

      Любые модули системы будут стремиться увеличивать свою автономность и достигать своих (локальных) целей, если специально ничего не делать.

      И отсюда следует:

      эффективная система ≠ сумма эффективных модулей — даже наоборот.

      Для общей эффективности может потребоваться локальная неэффективность.


      Так что, к моему удивлению, одна из лучших книг по системному анализу — вовсе не про IT.

      • Грозовая туча — инструмент для решения архитектурных задач.

      • Дерево текущей реальности — способ описания текущей архитектуры.

      • Дерево будущей реальности — способ проектирования новой.

      Инженерная работа — это и есть способ внедрения этих идей в жизнь.


      1. MEGA_Nexus
        19.06.2025 15:16

        Бутылочное горлышко вовсе не в IT, а то, что действительно нужно менять, — за рамками моего влияния.

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

        "одна из лучших книг по системному анализу — вовсе не про IT."

        Там несколько книг в серии Цель. Одна из последних рассказывает про розничный бизнес, т.е. сферу продаж. Книга про проект DevOps показывает как всё это применимо к производству. Так что да, принципы универсальны и их можно использовать не только в IT.

        Дерево текущей реальности и Дерево будущей реальности.

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


      1. punhin
        19.06.2025 15:16

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


  1. Dhwtj
    19.06.2025 15:16

    Видимо, вы дошли до края ограничения в компании или в профессии. И решили сменить одно и/или другое.


    1. vadimr
      19.06.2025 15:16

      До края в профессии людям попроще Тьюринга дойти точно не светит. Тьюринг под вопросом.


  1. kest70
    19.06.2025 15:16

    Серьезная, глубокая статья.. Есть чему поучиться. Я тоже из Томска.


    1. DragorWW Автор
      19.06.2025 15:16

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

      Потому что у всех всё по-разному, а так каждый может подчерпнуть что-то своё.

      Ну и да, Томск это похоже it колыбель Сибири, для меня, не знаю как сейчас, но раньше был очень много it компаний


      1. Femistoklov
        19.06.2025 15:16

        Колыбель? Ну может быть, только ребёночек из колыбели вырос и переехал в Новосиб/Красноярск. В Томске, конечно, есть какое-то кол-во it-компаний, но несравнимое, и это всё уж точно не развивается.


  1. winkyBrain
    19.06.2025 15:16

    Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес

    Так вы для себя эти вещи делали? значит в IT вы вообще не были на тот момент, просто проявляли интерес к технологиям и занимались интересными вам делами. странная тенденция козырять школьными\универскими увлечениями как опытом в IT


    1. cruiseranonymous
      19.06.2025 15:16

      IT это не "строго корочки рабочие с Сеньоро Помодоро Ассемблёро, иначе несчитово и увлечение". Это и вот такие ковыряния тоже.


  1. tryamk
    19.06.2025 15:16

    Всё, что раньше я считал говнокодом — перестало им быть.

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

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


    1. aborigen81
      19.06.2025 15:16

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


      1. Dhwtj
        19.06.2025 15:16

        Видимо, понял что совсем хорошим код не станет. Потому что потому


    1. vadimr
      19.06.2025 15:16

      "Плохой" – оценочное суждение, имеющее различное фактическое наполнение у разных людей и в разных ситуациях.


    1. Lodinn
      19.06.2025 15:16

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

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

      Вообще стараюсь больше хвалить других (и себя тоже). Перфекционизм - зло.


      1. Dhwtj
        19.06.2025 15:16

        Мы просто двигаемся вперёд по этой дороге жизни


  1. Boethiah
    19.06.2025 15:16

    'QA не мешали релизам' - когда цель не поставить качественный продукт, а побыстрее отчитаться о работе