Я давно в 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, которого я вообще не знал — просто чтобы оно заработало на новой версии клиента.
Только теперь вместо кода — системы. Вместо багов — процессы. А из инструментов — лишь опыт, знание и дикое желание разобраться. Разобраться и сделать так, чтобы невыносимая лёгкость разработки стала не такой уж невыносимой.
Если вам показалось, что история закончилась на самом интересном месте — то да и нет. Эта история — просто жизнь, и она продолжается прямо сейчас.
Но у меня есть еще пара докладов:
А на этом у меня пока все, такая история!
Комментарии (18)
kest70
19.06.2025 15:16Серьезная, глубокая статья.. Есть чему поучиться. Я тоже из Томска.
DragorWW Автор
19.06.2025 15:16Спасибо, в общем для этого и поделился. Так как заметил что статья о чужом опыте гораздо полезнее чем статьи о том как кто-то пишет как что-то делать правильно.
Потому что у всех всё по-разному, а так каждый может подчерпнуть что-то своё.
Ну и да, Томск это похоже it колыбель Сибири, для меня, не знаю как сейчас, но раньше был очень много it компаний
Femistoklov
19.06.2025 15:16Колыбель? Ну может быть, только ребёночек из колыбели вырос и переехал в Новосиб/Красноярск. В Томске, конечно, есть какое-то кол-во it-компаний, но несравнимое, и это всё уж точно не развивается.
winkyBrain
19.06.2025 15:16Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес
Так вы для себя эти вещи делали? значит в IT вы вообще не были на тот момент, просто проявляли интерес к технологиям и занимались интересными вам делами. странная тенденция козырять школьными\универскими увлечениями как опытом в IT
cruiseranonymous
19.06.2025 15:16IT это не "строго корочки рабочие с Сеньоро Помодоро Ассемблёро, иначе несчитово и увлечение". Это и вот такие ковыряния тоже.
tryamk
19.06.2025 15:16Всё, что раньше я считал говнокодом — перестало им быть.
А как это получилось? Как код со временем становится говнокодом - это понятно. Постоянный, можно сказать, процесс. А обратный случай? Просто я не представляю.
Да, код может работать, но ведь от этого он не перестаёт быть плохим? Да, предположим, в нем может быть заложены выдающиеся паттерны и гениальные идеи... но они могут быть плохо реализованы и плохой код не становится лучше из-за внезапно обнаруженной глубины...
aborigen81
19.06.2025 15:16Всё что ниже это конечно-же ИМХО:
Автор изменил своё отношение к коду, который видит. Или, чуть другая формулировка: своё восприятие результата работы других программистов.
vadimr
19.06.2025 15:16"Плохой" – оценочное суждение, имеющее различное фактическое наполнение у разных людей и в разных ситуациях.
Lodinn
19.06.2025 15:16Я со временем сознательно стал двигаться в сторону меньшей критичности в оценках. Да, архитектура кривая. Да, тестов нихрена нет. Да, вместо нормальной векторизации три вложенных цикла.
Но этот код сделал мир лучше? Помогает ли он реально людям жить и работать, и стоит ли техдолга? Ведь если альтернатива - пять лет медитаций в Шаолине, чтобы построить идеальную абстрактную фабрику - оно точно надо? Ведь программирование - не только (и даже преимущественно не только) про решение хорошо формализованных задач, оно ещё и про понимание устройства самой задачи и мира в целом. Поэтому у всякого кода есть жизненный цикл, и, хотя за кое-какой тяп-ляп всё равно надо руки отрывать, в целом неидеальный код, но быстро, часто лучше, чем хороший, но долго. Нет смысла полгода задрачивать задачу, которая нужна чисто для аналитики/принятия решения и пишется на коленке за вечер. Плохо только, если этот код потом на годы укореняется в продакшне, и за это время не выделяется ресурсов на рефакторинг.
Вообще стараюсь больше хвалить других (и себя тоже). Перфекционизм - зло.
Boethiah
19.06.2025 15:16'QA не мешали релизам' - когда цель не поставить качественный продукт, а побыстрее отчитаться о работе
MEGA_Nexus
Что стало с той компанией, где начались внедряться идеи Голдратта и его ТОС (теории ограничения систем)? Стало лучше или стало хуже?
DragorWW Автор
У той компании, где я увидел её, вроде бы всё хорошо. Кстати, я подсмотрел у них интересную идею: бить бизнес на бизнесы, чтобы внутри компании формировались собственные денежные потоки. Забавная штука — она позволяет привязать всех к цели и видеть реальную эффективность отделов: кто сколько приносит и сколько нам это стоит.
Потом было 5 лет CTO — последняя ссылка про это. Но там я довольно быстро пришёл к осознанию: бутылочное горлышко вовсе не в IT, а то, что действительно нужно менять, — за рамками моего влияния.
А из TOC я забрал логические инструменты. На удивление, всё это очень похоже на архитектурные подходы и принципы проектирования эффективных систем. В общем, тем TOC и занимается — исходя из одного простого постулата:
И отсюда следует:
Так что, к моему удивлению, одна из лучших книг по системному анализу — вовсе не про IT.
Грозовая туча — инструмент для решения архитектурных задач.
Дерево текущей реальности — способ описания текущей архитектуры.
Дерево будущей реальности — способ проектирования новой.
Инженерная работа — это и есть способ внедрения этих идей в жизнь.
MEGA_Nexus
Бутылочное горлышко почти всегда находится в неэффективных бизнес-процессах. Изменить существующий бизнес-процесс достаточно сложно, т.к. требуется изменение поведения большого количества людей, поэтому имеет смысл всё делать постепенно, давая людям время привыкнуть к этим изменениям, после чего можно продолжить внедрять новые изменения. Также надо задавать себе вопрос, а что это изменение даст этим людям. Станет ли им проще работать? Начнут ли они получать больше удовольствия от работы? Польза для компании – это хорошо, но не надо забывать про людей, ведь если они не увидят в изменениях пользы для себя, то будет большое сопротивление любым изменениям.
Там несколько книг в серии Цель. Одна из последних рассказывает про розничный бизнес, т.е. сферу продаж. Книга про проект DevOps показывает как всё это применимо к производству. Так что да, принципы универсальны и их можно использовать не только в IT.
Единственные штуки, которые я так и не осилил. В книге написано нормально, но на практике мне самостоятельно ни разу не удалось их построить. В результате решил их не использовать, т.к. другие практики ТОС и бережливого производства всё равно позволяют добиться выдающихся результатов.
punhin
Если не читали ещё книги Донеллы Медоуз по системному мышлению, почитайте, вам наверняка будет интересна её методология описания систем. На мой взгляд, она дала лучший способ описания бизнес-процессов как цепочек (петель, колец) причинно-следственных связей.