Путь разработчика

    Привет! Меня зовут Алексей Скоробогатый. В 2015 году я пришел в Lamoda на позицию разработчика. Сейчас я системный архитектор e-commerce платформы и по совместительству Technical Lead команды CORE. В этой статье хочу поделиться инсайтами, которые получил за эти 5 лет — в формате takeaways, с историями, мемами и ссылками на литературу.

    image

    Буду рад любой дискуссии в комментариях под статьей: вопросы, мнения, опровержения!

    There are known knowns


    В Lamoda я пришел в команду, работающую над поддержкой и развитием системы обработки заказов. Ничего не понятно, но жутко интересно.

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

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

    Тишина в логах и мониторингах скрывала страшный баг: запрос к базе данных возвращал некорректное число строк. Итоговая сумма к возврату в несколько раз превышала реальную… Но об этом мы узнали только в понедельник. До сих пор помню, как устало и укоризненно смотрел на меня техлид, пока мы ехали в офисном лифте на следующее утро. Он до трех часов ночи отлавливал баг и готовил фикс для релиза. А компания понесла некоторый импакт от моей ошибки. Это был мой первый критичный баг, но далеко не последний. Люди ошибаются, и делают это постоянно.

    Takeаway #1: Бизнес-процессы и данные на первом месте. Важно внимательно относиться к тем данным, с которыми работает система. Определять, с чем имеешь дело перед внесением изменений. Понимать контекст, в котором вносятся корректировки. Всегда рассматривать решаемую задачу с позиции контекста выше уровнем. Другими словами, ясно понимать, что происходит с точки зрения бизнес-процесса и кто является потребителем затрагиваемых моделей. Структура приложения может иметь сколько угодно слоев абстракции и разную степень качества самих абстракций, но это совершенно ничего не значит, если нарушена модель или бизнес-процесс в целом.

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

    Конечно же я заблуждался.

    Никогда не стоит недооценивать сложность больших систем. Очень хорошо про это сказал американский политик Дональд Рамсфельд:
    image… как мы знаем, есть известные известные; Есть вещи, которые мы знаем, что мы их знаем. Мы также знаем, что есть известные неизвестные; то есть мы знаем, что есть некоторые вещи, которые мы не знаем. Но есть и неизвестные неизвестные — те, которых мы не знаем, что мы их не знаем. И если взглянуть на историю нашей страны и других свободных стран, то последняя категория, как правило, является трудной.

    Takeaway #2: Работая со сложными системами, важно понимать что мы знаем о них, чего мы не знаем, а о каком их поведении даже не догадываемся. И это не просто про инструментарий и следование тренду “Monitoring towards Observability”, но также про управление зависимостями и оценку рисков при проектировании. Например, прежде чем решить использовать крутую трендовую базу данных для критичной системы, очень советую залипнуть вот на этом сайте boringtechnology.club

    Everything is broken


    Через два года работы с системой обработки заказов я мог сказать, что уверенно знаю примерно 80% приложения. То есть про каждый модуль системы понимаю, как он устроен, и могу внести изменения. Знаю, какие бизнес-процессы отражены в той или иной модели, как они взаимосвязаны и влияют друг на друга. Провел интеграцию с системой процессинга платежей, которую спроектировала соседняя команда. Помимо интеграции, нужно было избавиться от наследия старого кода, так как раньше платежи были частью нашей системы — эта задача стала моим последним и самый масштабным рефакторингом крупного модуля. Все прошло настолько гладко, что даже неинтересно.

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

    Размышляя над всем этим, я наткнулся на статью Everything is broken, в которой автор пишет о той же проблеме, но еще более масштабно (и еще про то же, но под другим углом — Software disenchantment). Каждый раз меня будоражит, когда я нахожу со стороны подтверждение своим внутренним ощущениям — вот и в тот раз, прочитав статью, я наконец почувствовал, как мое смутное недовольство превратилось в яркий и явный инсайт:
    Software is so bad because it’s so complex.

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

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

    Takeaway #3: При проектировании систем важно учитывать их когнитивную нагрузку. Она складывается из сложности технических решений, а также моделей и процессов предметной области. Хорошо спроектированные системы имеют высокую когнитивную нагрузку предметной области и низкую — технических решений.В идеале отдельная система должна иметь когнитивную нагрузку, которую может обработать один человек.

    Окей, проблема понятна. Но предположим, у нас есть возможность переписать слишком сложную и потому плохую систему, упростив ее. На что еще нужно обратить внимание? В кибернетике есть теорема Конанта — Эшби:

    Хороший регулятор системы должен располагать моделью этой системы. Good regulator

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

    Думаю, мало кто не согласится, что все наши сервисы — это модели. Но что мы моделируем? Очень важно уделять внимание бизнес-процессам, моделировать не только состояние, но и поведение.

    В конце 2017 года я перешел в новую команду CORE. Эта команда была сформирована тогда специально для выполнения задач IT — стратегии по декомпозиции монолитных систем. Основной целью мы ставили распил той самой большой, но хрупкой системы обработки заказов (закадровый голос: тогда самурай еще не знал, что у этого пути есть начало, но нет конца!).
    Для меня это был новый опыт. Команда с совершенно иными принципами и образом мысли. Решения принимались быстро, были эксперименты и право на ошибку. Баланс вышел идеальный: мы пробовали и откатывались там, где импакт был минимален, но детально прописывали каждый шаг для критичных моментов.

    Мы написали новый сервис создания заказов с нуля на другом языке (будучи php разработчиками, перешли на golang). Оценили первый результат и переписали еще раз. Упор был сделан на простоту и надежность. В центр поместили модель данных, а всю архитектуру построили вокруг. В итоге получился надежный и отказоустойчивый сервис. Нам удалось ввести его в эксплуатацию без отказов, используя механизм экспериментов. Со временем построенная система показала свою состоятельность не один раз.

    image

    Takeaway #4: All models are wrong but some are useful. Для построения корректных и устойчивых систем недостаточно моделировать состояния. Необходимо смотреть на поведение: паттерны коммуникации, потоки событий, кто ответственен за те или иные данные. Следует искать связи между данными и обращать внимание на причины этих связей.

    It's all about the dum dum da da dum dum


    У меня в университете был курс математического анализа, который вела доцент и к.т.н. Елена Николаевна. Она была очень строгой, но справедливой. На зачетах то и дело попадались задачи, для решения которых приходилось немного “покрутить” лекции — сделать самостоятельный шаг в сторону понимания материала. И на итоговом экзамене, который, к слову, я сдал со второго раза, пришлось проявить гибкость мышления и применить интуицию, чтобы решить задачу на “хорошо”. Вот правило, о котором Е.Н. твердила нам весь курс, и которым я пользуюсь и через десять лет:
    Когда не знаешь, что делать — делай что знаешь.

    Вот почему я гордился, что знаю матан на “хорошо”. Потому что по стандартам Е.Н. мало знать материал, но важно еще и понимать его, уметь синтезировать новое.

    Takeaway #5: Чем дальше ты двигаешься, тем большую ответственность приходится брать и тем больше решений приходится принимать. В определенный момент абсолютная уверенность пропадает, как категория, но взамен приходит искусство баланса вслед за смелостью делать шаг.

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

    Во второй половине 2018 года наша команда лидировала проект “Подарочные сертификаты”. Вначале я отвечал за разработку в процессинге и вокруг него. Позже, к концу года, ко мне перешло техлидство всего проекта вместе с задачей восстановить баланс сил после ухода части команды.

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

    image

    Takeaway #6: Синдром самозванца. А что если меня разоблачат? Конечно разоблачат, если ничего не делать. Если делать важное, то через время замечаешь, что разоблачать тебя уже некому.

    Divergence and Convergence


    В соответствии с хронологией моего “Пути разработчика” здесь должна быть интересная с технической стороны история про проект персональных политик. В этом проекте мы реализовали обработку данных в реальном времени, и “на лету” изменили сами принципы архитектуры системы, перейдя к Events Driven Architecture. Но про это у меня уже есть отдельный доклад с конференции Хайлоад ‘19 (и статья тут на Хабре). Поэтому лучше я расскажу про “высокие материи” технического и не очень менеджмента.

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

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

    В чем боль тимлида? Разве не в том, что инженер занимается менеджментом?! Нет, почему так происходит, понятно — школы технического менеджмента у нас нет как таковой, и предполагается, что инженер в ИТ — это супермен, который может разобраться во всем, включая и такую “простую” вещь, как менеджмент.

    Но я решил пойти другим путем и в качестве следующей карьерной ступени выбрал позицию техлида. Как архитектор, я работаю с командами разработки, и теперь от ребят слышу то, о чем еще год назад сам говорил менеджерам:
    Почему требования так плохо проработаны? Решения костыльные! Какие две недели?! Тут работы на месяц.

    Но эхехей, теперь это моя задача решать такие проблемы. Но как только ты переводишь свое мышление в парадигму cost & benefit, то понимаешь, что все эти проблемы невозможно решить — you bout dat life!

    Takeaway #7: Открытие! Менеджеры не занимаются решением проблем, они управляют беспорядком.

    Моя задача, как технического лидера, это снимать неопределенность для команды разработки. Требования не проработаны? Решения костыльные? Архитектура не предусматривает? Это все сигналы хрупкости системы и расходимости.

    Допустим, постановка задачи в сервис создания заказов выглядит так:
    Необходимо добавить поле X и поле Y. Требуется, чтоб значение в поле Y’ на выходе равнялось значению Z, если X равен 1.

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

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

    image

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

    Архитектор должен понимать единство социотехнической системы. Уметь координировать процессы выше линии представления, чтоб системы ниже линии представления отвечали ограничениям по корректности, устойчивости и адаптивности.

    image

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

    Soft is simple, people are hard!


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

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

    Простые в реализации алгоритмы более успешны, чем математически точные. Paxos математически точен, но только с описанием протокола Raft, который проще в реализации, практическое применение алгоритмов консенсуса получило развитие.
    Язык Golang ругают за его излишнюю ограниченность. Но именно на нем написаны Docker, Kubernetes и многие другие распределенные системы. Корректно выстроенная система ограничений служит фундаментом для успешных систем.

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

    И тут возникают технологии на стыке software & people, призванные структурировать хаос и описать сложные взаимодействия. Domain Driven Design, Microservices, Agile — все они создают ограничения, в которых описываются принципы и правила взаимодействия. Появляются структуры, с которыми понятно, как работать. Но далеко не всегда с приходом таких технологий становится лучше. Нередко получается наоборот — What Money Cannot Buy.

    Takeaway #9: Программы могут и должны быть простыми. Для этого нужно прикладывать силы к формированию инженерной культуры. Именно она в конечном итоге определяет работоспособность сервисов.

    image

    Reading list


    Books

    The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, Camille Fournier — ссылка

    The Elegant Puzzle: Systems of Engineering Management, Will Larson — ссылка

    Team Topologies: Organizing Business and Technology Teams for Fast Flow, Manuel Pais and Matthew Skelton — ссылка

    Righting Software, Juval Lowy — ссылка

    Thinking in Systems: A Primer, Donella Meadows — ссылка

    Articles

    Mental Models, Fernam Street — ссылка

    Complexity Bias: Why We Prefer Complicated to Simple. Fernam Street — ссылка

    What Money Cannot Buy, LessWrong — ссылка

    Becoming Unusually Truth-Oriented, LessWrong — ссылка

    Programming Laws and Reality: Do We Know What We Think We Know? — ссылка

    No Silver Bullet Essence and Accidents of Software Engineering — ссылка

    The Art Of Troubleshooting — ссылка

    From Fragile to Antifragile Software — ссылка

    Computers can be understood — ссылка

    Tuckman Was Wrong! (About teams) — ссылка

    How to fail at almost everything and still win big — ссылка

    Simplicity Before Generality, Use Before Reuse — ссылка
    Simplicity, Please — A Manifesto for Software Development — ссылка

    Software Design is Human Relationships — ссылка
    Lamoda
    Russian Fashion Tech

    Комментарии 20

      0
      Спасибо, приятно читать. И интересные выводы.

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

      Синдром самозванца. А что если меня разоблачат? Конечно разоблачат, если ничего не делать. Если делать важное, то через время замечаешь, что разоблачать тебя уже некому.

      Эта похожа на «если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага». :)
        0
        Эта похожа на «если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага». :)

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

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

          Звучит как "я крутой, сейчас все понимаю и пронесло что мне ничего не сделали".
          Перевожу что я сказал — а по русски? )


          Программы могут и должны быть простыми.

          +100500. Ошибка новичка — перенаворотить код, чтобы его похвалили )
          Сам страдал таким (да и все наверное).
          Если дальше поддерживаешь свой код, начинаешь понимать простую мудрость — чем проще, тем лучше.
          2+2 намного понятней чем 2+2*2-6+1+1*2+1


          PS. А компания крутая, был у них по результатам пхп квеста )

            0
            Звучит как «я крутой, сейчас все понимаю и пронесло что мне ничего не сделали».
            Перевожу что я сказал — а по русски? )


            Англицизмы непростая тема :) стараюсь их использовать когда нужна определённая коннотация, как в данном случае с «импактом» – отрицательные последствия ошибки. Мы с такими ошибками работаем и стараемся копать глубже человеческого фактора. Что нам нужно поменять в нашем процессе, чтоб такого не происходило. Но в тот момент моя ошибка оставила эмоциональный отклик. Что конкретно я могу сделать, чтоб минимизировать со своей стороны такие ошибки.
            0
            Мы с такими ошибками работаем и стараемся копать глубже человеческого фактора

            Хм, а как это? Чаще всего фактор и есть же. Или это про "настраиваем права", тогда понимаю )

              0

              Хотяяяяяя, накосячивший сотрудник и понявший свою вину намного ценнее накосячевшего просто так )
              В IBM вроде говорил тип "я только что заплатил 1 лям долларов за твое обучение" )

              +1
              Может кто-то знает в чем проблема внедрить в фильтры возможность выбора одежды не только по одному размеру, а и с разбивкой обхват груди/талии/бедер?

              Многим очень сильно помогло бы подобрать одежду, и коэффициент возврат сократило.
                0
                Это зависит от того насколько проблематично складскому отделу сделать инвентаризацию всего китайского хлама в ассортименте, и вручную собрать все необходимые для фильтрации параметры. А так одно поле в номенклатуру и одну доп табличку, в 1с так вообще и стандартным использованием характеристик обойтись можно.
                  +2

                  Мне нравится ваш ответ, он кратко и ясно описывает всю проблематику данной задачи. Я работаю с Лешей, но в подразделении, как раз занимающимся добавлением колоночек в таблички хранения номенклатур.
                  Если Леше достаточно расширить индекс эластика и нарисовать пару UI элементов в интерфейсе desktop\mobile приложений, то другим людям потребуется подготовить данные для фильтрации. И тут уже надо понимать всю глубину проблематики унификации этих данных.


                  Вот взять тот же размер. Каждый бренд хоть и шьет свои вещи примерно в одинаковых азиатских странах, но крепит на вещи размеры в соответствии с размерными сетками (например, обувь 40, 41, 42 размер), где эта вещь будет продаваться. Если вещь шилась для Америки, а носить хочется где-то в России (например, найки), то при закупке надо обязательно не забыть переклеить этикетку и сконвертировать размер с американской размерной сетки на российскую. Проблема множится тем, что размерных сеток тьма, плюс каждый из брендов может иметь свое чувство прекрасного и рассчитывать размер относительно своих показателей, страны продажи. Дополнительно, у тех же рубашек есть еще такая характеристика, как силуэт (classic fit, slim fit, super slim fit), которая зависит от размера талии. А у футболок нет, для каждой категории одежды дьявол кроется в мелочах.


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

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

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

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

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

                  Справедливости ради отмечу, что часть команды ушла каждый по своим обстоятельствам. И с каждым мы общаемся и до сих пор.
                    0
                    Это про то, что люди вокруг не знают больше
                    Тогда вы переросли команду, и стоит найти ту, где есть у кого поучиться.
                    И если начать разбираться, то через время становишься таким же экспертом.
                    Но суть в том, что именно работа с экспертами показывает в чем стоит начать разбираться
                    Я хотел сказать, что не нужно бояться что чего-то не знаешь, ведь этому можно научиться.
                    Главное что бы не переросло в подтверждение этому
                    В любой иерархической системе каждый служащий стремится достичь своего уровня некомпетентности.
                      0
                      Тогда вы переросли команду, и стоит найти ту, где есть у кого поучиться.

                      Это очень хорошая мысль и я не мало думал как решать такую проблему. Со временем понял, что пора снова сесть за учебники (только теперь совсем сам и чаще за научные статьи). Т.е. опыт уже есть, главное приложить услиля чтоб его натягивать на правильную матчасть.
                        0
                        Если нет желания рисковать с поиском другого коллектива, то да, учебники и курсы единственная соломинка. Согласен в том, что навык самообразования играет огромную роль, только беда в том что учебники, и уж тем более научные статьи это бесполезная макулатура:
                        Пергаменты не утоляют жажды.
                        Ключ мудрости не на страницах книг.
                        Кто к тайнам жизни рвется мыслью каждой,
                        В своей душе находит их родник.


                        По личному опыту могу сказать, увидеть на практике что и зачем сделано в работающей системе, и работа с ней дают реальное осознание сути дел. Также вполне реально в процессе разработки и самообучения дойти до прописных истин и самому, но это процесс гораздо длительнее и совершенно не способствует карьере.
                          +1
                          Не только самообучение. Вокруг, в коллективе я постоянно чему-то учусь. Менторство. Выступать ментором как самому, так и искать ментора внутри или снаружи. Для себя слежу за несколькими инженерами / менеджерами / архитекторами зарубежными. Они очень много делятся опытом и матчастью. Lamoda достаточно крупная компания со сложными процессами, чтобы на её базе учиться. Пока мне хватает =)
                            0
                            Тогда вы переросли команду, и стоит найти ту, где есть у кого поучиться.

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

                            а сейчас говорите
                            Вокруг, в коллективе я постоянно чему-то учусь.

                              0
                              Да, тут нужно прояснить свою мысль. Есть такой бед-паттерн «Ivory Tower» у архитекторов, когда перестаёшь что-то делать «руками». Одна из моих задач это держать свои навыки актуальными. И тут я многому учусь у своей команды. С другой стороны, работодатель ожидает от меня проработки высокоуровневых решений с заданными ограничениями. И тут нужны совершенно другие навыки и знания, которые я заимствую из вне. Просто потому что у меня есть задача и мне её нужно решать.

                              Мне нравится как в этой статье написано про the five responsibilities of architects.
                  0
                  А какие могут быть советы в рамках «Путь разработчика» для кардинальной горизонтальной смены предметной области, в которой работаешь, при этом учитывая что в текущей предметной области у тебя уровень Senior. Например, сейчас у тебя Mobile Development или Desktop Apps, а хочется уйти в Backend Highload, но при этом опыта в последнем у тебя нет конечно, а Junior'ом не хочется получится быть.
                    +4

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


                    • степень самостоятельности
                    • знание языка и его экосистемы
                      Причем первое скорее имеет приоритет над вторым.

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


                    С точки зрения языка и экосистемы надо смотреть на варианты либо с переходом на тот же язык, что у вас уже есть (например, андроид разработчик на Java-бекенд), либо активно учить язык в свободное время (это не так сложно обычно).


                    Ещё вариант перейти внутри своей компании, если есть такая возможность. Это самый простой путь, так как вас уже знают.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое