Elixir, backend и стартапы

Несмотря на то, что компания TSC просто замечательная, задержаться в ней надолго по ряду причин не вышло. Это был один из тех редчайших случаев когда действительно вся команда высоко квалифицирована, не менее высоко мотивирована и ответственна. За прошедшие 7 месяцев мне удалось посмотреть и потрогать руками практически новый для меня мир экзотических языков в prod-е, немного иначе посмотреть на то, какой бывает разработка backend-ов и попробовать на практике что такое стартап.

Elixir

Начнем с самого главного, а именно с Elixir, который до моего прихода был фактически единственным языком используемым в компании для разработки backend-а. На первый взгляд, это был разумный и продуманный выбор – простой и выразительный язык с кучей возможностей, дружелюбное сообщество и BEAM под капотом. Благодаря наличию Ecto и Phoenix разработка backend проходит относительно гладко и быстро, а новичок который до этого ни разу не писал на Elixir ничего сложнее HelloWorld, т.е. я, начинает приносить пользу буквально через неделю, что по моему опыту очень хороший результат.

Но как бы не прекрасен был Elixir, я никогда не возьму этот язык в будущем для разработки чего бы то ни было, так как для этого есть довольно много неожиданных причин. Первая и самая главная – это экзотичность и как следствие нарастание кома проблем по мере движения в сторону от главного варианта использования, т.е. CRUD. Причем проблемы возникают совершенно разной направленности, но с вполне очевидным происхождением в виде экзотичности технологии и маленького сообщества вокруг неё. Так у нас возникали ощутимые сложности с подключением ClickHouse, вылившиеся в решение написать еще один сервис для операций со статистикой на Go, были серьезные сложности с поиском человека мне на замену и т.п. Второй причиной головной боли после экзотичности была динамическая типизация. Высокое покрытие тестами это, конечно, прекрасно, но высокое покрытие с тестами в купе с гарантиями компилятора, что во время выполнения в приложении не возникнет ошибки типа это же куда лучше! Так что если хочется экзотики и/или функциональщины в prod-е, может лучше Haskell? Его и народу побольше знает, значит проще позиции закрывать, и статическая типизация на месте, да и возможностей у самого языка море…

Backend

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

Стартапы

А вот это, наверное, самый интересный для меня момент во всей этой истории. Во-первых, не всякая маленькая компания называющая себя стартапом есть стартап. В понятие стартап закладывается довольно много критериев и скорость роста является одним из основных признаков который позволяет понять что же такое перед вами. Это может быть и здоровый стартап (рост 4%-7% в неделю по ключевому для стартапа показателю), и компания-зомби, да и просто маленькая устойчивая компания на самоокупаемости. Во-вторых, если у вас есть достаточно обширный опыт и вы не против переездов и необходимости ходить в офис, то идти в стартап или маленькую компанию совершенно не целесообразно ни по финансовым, ни по карьерным соображениям. Если уж очень хочется, то, наверное, можно рассмотреть позиции уровня CTO которые являются может быть даже немного упрощенным аналогом тимлида из приличной корпорации, так как интриг и сложностей во взаимодействии ощутимо меньше. И само собой, договоренность о работе должна включать либо долю, либо очень высокую ЗП, ощутимо выше чем в корпорации. Всё остальное – пустая трата времени, которое куда разумнее потратить в среднего размера IT-компании (1-3К человек) либо корпорации. Само собой найдутся какие-то исключения помельче, которые всё еще интересны с точки зрения работы, я тут про общий тренд говорю.

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

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

5 Comments Elixir, backend и стартапы

  1. DMITRY

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

    Reply
    1. Alexander Stavonin

      Я честно не знаю где посмотреть или послушать, так как тема просто огромная и состоит из нескольких частей. Я бы выделил как минимум три: сами процессы, то как бывает в жизни и взаимодействие с людьми. Причем все эти три составляющие практически одинаково важны, может с некоторым перевесом в сторону взаимодействия с людьми. Курса молодого бойца нет и я думаю что быть не может по причине объема, поэтому надо осилить довольно большую кучу книг. Хотя, может где-то такой курс молодого бойца и есть, но это будет сродни “C++ за 21 день” Итак, по всем трем пунктам.

      Сами процессы. Тут вроде всё просто, но понимать какие процессы бывают и почему оно надо. Так что будет полезно выбрать на свой вкус что-то по Agile, по мне это та еще обычно плохо работающая ебанина, но модно и иногда реально полезно, значит знать надо. Потом стоит посмотреть на классику типа RUP, бесплатной информации по методологии тоже очень много. Если увлечет, то можно почитать PMBOK, но меня на этом этапе уже перестало увлекать.

      Про то, как оно в реальной жизни, читать сильно веселее. Тут главное это Демарко с “Человеческий фактор” и “Вальсируя с Медведями”, ну и Брукс с “Мифический человеко-месяц”. Да, тоже гора, но это самая база, без которой никуда.

      Последнее и самое важное – взаимодействие с людьми. Это самое важное потому, что у большинства программистов именно эта часть сильно страдает. Я на эту тему много чего успел почитать начиная от классики типа Фрэйда, Юма которые были интересны, но не шибко полезны в работе, до Берна, который внезапно оказался куда как полезнее. Я говорю про “Игры, в которые играют люди” и “Люди, которые играют в игры”, думаю у Берна еще куча чего, но это реально полезно. Ну а самую полезную книгу по построению процессов и взаимодействию с людьми я прочитал в прошлом году, это был “Государь” Макиавелли.

      Надеюсь поможет. Если что-то неясно – спрашивай!

      Reply
      1. DMITRY

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

        Reply
  2. evgeny

    Компенсация так себе, работа не интересная, долю не дают а работать заставляют Для наёмного сотрудника в малом предприятии, даже если стартапом назвать, это нормально Не всем нравится, ага
    Куда сейчас решил податься?

    Reply
    1. Alexander Stavonin

      > Компенсация так себе, работа не интересная, долю не дают а работать заставляют Для наёмного сотрудника в малом предприятии, даже если стартапом назвать, это нормально

      Только работать в таком месте не нормально, если не основатель или что-то ценное умеешь.

      > Куда сейчас решил податься?

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

      Reply

Leave a Reply