Для тех кто пропустил или не подписан на наши ютубы - выпустили видосик на тему выбора языка и стека. Попробовали собрать в кучу те критерии, которые считаем важными. Для наших постоянных читателей такая тема может и не совсем актуальна, но вдруг кто хочет поменять стек либо же находится в начале пути
⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).
Приятного просмотра!
⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).
Приятного просмотра!
YouTube
Какие языки УГРОБЯТ твою карьеру? ПОЛНЫЙ гайд по выбору языка
💻 Наш курс по карьере: https://howto.stringconcat.ru/career?utm_source=youtube&utm_medium=video&utm_campaign=lang
🎯 Телеграмм-канал с кучей полезной информации: https://www.group-telegram.com/stringconcat
Разбираем значимые критерии при выборе языка программирования и стека.…
🎯 Телеграмм-канал с кучей полезной информации: https://www.group-telegram.com/stringconcat
Разбираем значимые критерии при выборе языка программирования и стека.…
Инфляция тайтлов: 18-летние синьоры уже реальность
(*пост не ставит целью оскорбить или унизить кого-либо)
И к сожалению эта напасть касается нас всех.
Инфляция тайтлов — это когда компании громко называют обычные должности. У всех, например, уборщица, а у нас — операционный менеджер мануального клининга, в этом духе. Такие должности по названию не соответствуют реальным обязанностям, уровню старшинства, да и заработной плате. Иначе зачем всё это, вообще?
(Продолжение ниже)
(*пост не ставит целью оскорбить или унизить кого-либо)
И к сожалению эта напасть касается нас всех.
Инфляция тайтлов — это когда компании громко называют обычные должности. У всех, например, уборщица, а у нас — операционный менеджер мануального клининга, в этом духе. Такие должности по названию не соответствуют реальным обязанностям, уровню старшинства, да и заработной плате. Иначе зачем всё это, вообще?
(Продолжение ниже)
В продолжение поста
Громкому тайтлу можно меньше платить
Громкий тайтл может перекрыть разницу в деньгах, так что получать
Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.
И теперь ничего не понятно
Нельзя наверняка сказать, чем занимается
Громкому тайтлу можно меньше платить
Громкий тайтл может перекрыть разницу в деньгах, так что получать
Principal Software Architect & Visionary Technologist
может меньше, чем обычный Developer
. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер.Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.
И теперь ничего не понятно
Нельзя наверняка сказать, чем занимается
Senior Staff Software Engineer
. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer
. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President
, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.Перед вами карьерная лестница разработчика в одном из банков Сингапура. Где Intern Developer – самый низ пищевой цепочки. Предположите, на каком уровне от разработчика не требуется писать код, а нужны только менеджерские скиллы.
Final Results
2%
Intern Developer
1%
Junior Developer
2%
Developer
10%
Senior Developer
40%
Associate Vice President
12%
Vice President
4%
First Vice President
2%
Senior Vice President
27%
Executive Director
Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен.
Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂
Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂
Ещё один способ оценки квалификации
Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке:
— В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+
— Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно.
— Фреймворками дело не ограничивается, есть ещё аналитическое мышление, знания в определённых предметных областях, конструкторские навыки и всякие там софт-скиллы. Короче, тысячи их: некоторые желательны, некоторые необходимы. Например, без навыков анализа хорошим разрабом не станешь.
Квалификацию все описывают в меру фантазии и ресурсов. Обычно получаются широченные таблицы с картами компетенций, которые, по сути, просто описывают подгрейды между базовыми джунами-синьорами.
Мы тоже попробовали, но пошли другим путём, от конкретного человека, а не от абстрактного идеала. Вместо этого мы декомпозировали квалификацию на составляющие и оценили каждую по шестибалльной шкале. Получилось так: пример оценки компетенций сферического Олега.
Выглядит неплохо, правда, чтобы поддерживать такую систему оценки, потребуется целый отдел. Но вы можете воспользоваться шкалой. Например, пройтись по ветке своей специализации на сайте с роадмапами и оценить свои навыки. Это помогает найти пробелы в знаниях и проблемные места.
Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке:
— В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+
— Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно.
— Фреймворками дело не ограничивается, есть ещё аналитическое мышление, знания в определённых предметных областях, конструкторские навыки и всякие там софт-скиллы. Короче, тысячи их: некоторые желательны, некоторые необходимы. Например, без навыков анализа хорошим разрабом не станешь.
Квалификацию все описывают в меру фантазии и ресурсов. Обычно получаются широченные таблицы с картами компетенций, которые, по сути, просто описывают подгрейды между базовыми джунами-синьорами.
Мы тоже попробовали, но пошли другим путём, от конкретного человека, а не от абстрактного идеала. Вместо этого мы декомпозировали квалификацию на составляющие и оценили каждую по шестибалльной шкале. Получилось так: пример оценки компетенций сферического Олега.
Выглядит неплохо, правда, чтобы поддерживать такую систему оценки, потребуется целый отдел. Но вы можете воспользоваться шкалой. Например, пройтись по ветке своей специализации на сайте с роадмапами и оценить свои навыки. Это помогает найти пробелы в знаниях и проблемные места.
roadmap.sh
Developer Roadmaps - roadmap.sh
Community driven roadmaps, articles and guides for developers to grow in their career.
Сергей на связи! Не собеседуйтесь в Индию. Там вы будете конкурировать со специалистами по трудоустройству, которые специализируются на прохождении собеседований.
Недавно разговаривал с индусом, который собеседует разработчиков из Индии и со всего мира. Он предпочитает нанимать иностранцев, хотя они не очень умеют проходить собеседования. Деревья в уме крутят плохо, строку по полчаса переворачивают и в загадках путаются, зато потом нормально работают.
В Индии же наоборот: все учатся проходить собеседование, а не работать. Количество и качество резюме очень высокое, но по опыту скажу, что всё из индусского резюме можно смело делить на три. Как следствие, требования при наборе в Индии становятся жёстче, чтобы отсеивать Д'артаньянов, которые потом будут SQL-запросы из контроллеров делать.
Вывод. Очевидно, что прохождение таких собеседований и навык работы — две разные вещи. Корреляции между ними интервьюеры не наблюдают, но и менять стиль собеседования не торопятся, так что реальные навыки у вас никто проверять не будет.
Недавно разговаривал с индусом, который собеседует разработчиков из Индии и со всего мира. Он предпочитает нанимать иностранцев, хотя они не очень умеют проходить собеседования. Деревья в уме крутят плохо, строку по полчаса переворачивают и в загадках путаются, зато потом нормально работают.
В Индии же наоборот: все учатся проходить собеседование, а не работать. Количество и качество резюме очень высокое, но по опыту скажу, что всё из индусского резюме можно смело делить на три. Как следствие, требования при наборе в Индии становятся жёстче, чтобы отсеивать Д'артаньянов, которые потом будут SQL-запросы из контроллеров делать.
Вывод. Очевидно, что прохождение таких собеседований и навык работы — две разные вещи. Корреляции между ними интервьюеры не наблюдают, но и менять стиль собеседования не торопятся, так что реальные навыки у вас никто проверять не будет.
В комментариях к одной из наших заметок упоминали пассажиров. Мол, зачем нам люди, которые просто сидят и машут веслом, как велено. Они же не добавляют команде ценности. Хотелось бы немного развить эту мысль.
Мы выделяем три главных качества: адекватность, исполнительность и обучаемость. Есть и четвёртое — инициативность.
Но эта не такая инициативность, когда чел всех задалбывает идеями, тащит на себя чужие обязанности и веслает по ночам за интересные задачи. Мы о другом, более комплексном, когда человек самостоятелен, последователен и автономен.
Самостоятельность — способность оценить результат своей или не своей работы и улучшить её, не дожидаясь таски. Например, такой человек увидел повторяющуюся проблему, взял — и решил. Или что-то работало на 80%, а он взял — и улучшил до 99%.
Последовательность — доведение дел до логического завершения, хотя бы какого-то из этапов. Необязательно своими руками, но чтоб проследил и убедился, что готово.
Автономность — способность думать и действовать в меру возможностей без надзора и внешнего импульса. Например, между сервисами нет дырки, а человек взял — и завёл заявки, тегнул нужных людей, организовал дырку. А не сидел и жаловался, что никто этого не сделал вместо него.
К сожалению, таких людей хорошо, если 10%. Это не плохо, кому-то нравится просто веслать и в ус не дуть (мы тоже так хотим на самом деле, но не разрешаем сами себе). Но если у вас на проекте одни пассажиры, быть беде. Придётся директивно управлять, решат все проблемы самостоятельно, и вы как руководитель выгорите в угли. Особенно печально, если среди пассажиров окажутся лиды. Такие способны угробить любое начинание.
Так что цените инициативных людей, целуйте их в попку, одаривайте плюшками и двигайте вверх. Даже с нехваткой квалификации они быстро прокачиваются и занимают ключевые позиции.
Как обычно, это субъективное наблюдение меня, Сережи и других коллег, а поэтому не истина в последней инстанции. Можно приходить в комментарии и накидывать.
Мы выделяем три главных качества: адекватность, исполнительность и обучаемость. Есть и четвёртое — инициативность.
Но эта не такая инициативность, когда чел всех задалбывает идеями, тащит на себя чужие обязанности и веслает по ночам за интересные задачи. Мы о другом, более комплексном, когда человек самостоятелен, последователен и автономен.
Самостоятельность — способность оценить результат своей или не своей работы и улучшить её, не дожидаясь таски. Например, такой человек увидел повторяющуюся проблему, взял — и решил. Или что-то работало на 80%, а он взял — и улучшил до 99%.
Последовательность — доведение дел до логического завершения, хотя бы какого-то из этапов. Необязательно своими руками, но чтоб проследил и убедился, что готово.
Автономность — способность думать и действовать в меру возможностей без надзора и внешнего импульса. Например, между сервисами нет дырки, а человек взял — и завёл заявки, тегнул нужных людей, организовал дырку. А не сидел и жаловался, что никто этого не сделал вместо него.
К сожалению, таких людей хорошо, если 10%. Это не плохо, кому-то нравится просто веслать и в ус не дуть (мы тоже так хотим на самом деле, но не разрешаем сами себе). Но если у вас на проекте одни пассажиры, быть беде. Придётся директивно управлять, решат все проблемы самостоятельно, и вы как руководитель выгорите в угли. Особенно печально, если среди пассажиров окажутся лиды. Такие способны угробить любое начинание.
Так что цените инициативных людей, целуйте их в попку, одаривайте плюшками и двигайте вверх. Даже с нехваткой квалификации они быстро прокачиваются и занимают ключевые позиции.
Как обычно, это субъективное наблюдение меня, Сережи и других коллег, а поэтому не истина в последней инстанции. Можно приходить в комментарии и накидывать.
Telegram
StringConcat - разработка без боли и сожалений
Наше ретро. Вопрос к читателям: а вы его проводите? ИМХО лучше проблемы фиксировать и решать по мере поступления, а не устраивать сеанс групповой психотерапии на котором все поноют и разойдутся с нулевым результатом
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Ну что, признавайтесь, у кого так же на работе?
И это было бы смешно, если бы «скрам мастера» не считали что это действительно так и должно работать
И это было бы смешно, если бы «скрам мастера» не считали что это действительно так и должно работать
На этой неделе, примерно в четверг вечером хотим разобрать одну известную статейку про тестирование микросервисов. Посмотрим, актуальна ли она на текущий момент и как все это работает на практике. Ссылку пришлем чуть позже
martinfowler.com
Testing Strategies in a Microservice Architecture
The microservice architectural style presents challenges for
organizing effective testing, this deck outlines the kinds of
tests you need and how to mix them.
organizing effective testing, this deck outlines the kinds of
tests you need and how to mix them.
StringConcat - разработка без боли и сожалений
На этой неделе, примерно в четверг вечером хотим разобрать одну известную статейку про тестирование микросервисов. Посмотрим, актуальна ли она на текущий момент и как все это работает на практике. Ссылку пришлем чуть позже
Стрим будет сегодня в 18:30 мск, ссылку пришлем перед началом
StringConcat - разработка без боли и сожалений
Стрим будет сегодня в 18:30 мск, ссылку пришлем перед началом
YouTube
Разбираем Testing Strategies in a Microservice Architecture - актуально и применимо?
Разобрали статью Мартина Фаулера Testing Strategies in a Microservice Architecture и проверили, насколько она актуальна сегодня. Какие из описанных стратегий тестирования микросервисов всё ещё работают, а какие устарели? Обсудили компонентные и интеграционные…
StringConcat - разработка без боли и сожалений
https://youtube.com/live/NUBvpA1Dqjo?feature=share погнали!
На стриме обещал поделиться статистикой и анализом по багам. В итоге, в нашем проекте типовой баг на бекенде стоит примерно 6,5 часов работы команды - описать баг, назначить исполнителя, поправить, перепроверить, etc. Добавьте сюда время на коммуникацию, переключение контекстов и выйдет почти один рабочий день. При этом тест, который бы предотвратил появление бага пишется/дорабатывается максимум 30 минут (конкретно в нашем проекте). Вот такая интересная математика
StringConcat - разработка без боли и сожалений
https://youtube.com/live/NUBvpA1Dqjo?feature=share погнали!
На стриме был вопрос — можно ли заменить в e2e-тестах реальную зависимость на двойника (заглушку, мок и т.д.). Видимо, мы недостаточно подробно объяснили свою позицию, потому что от главного QA шлюпки, где я гребу пришел комментарий, что такой подход — харам. Давайте разбираться.
E2e-тесты действительно лучше проводить с реальными зависимостями, но в жизни бывают разные ситуации, например:
- Тестовых подключений может не быть. Провайдер не предоставляет такую возможность. Обычно демо-аккаунт существует, но не всегда. Приходится выводить в прод под фиче-флагом и отлаживаться на месте.
- Нет доступа к тестовым подключениям. Это подвид предыдущего случая. Бывают ситуации, когда тестовый контур изолирован от интернета, и вызовы вовне невозможны.
- Тестовые подключения нестабильны, и получить “зеленые прогоны” затруднительно. Иногда для демо-стенда выделяется слабый сервер, который подходит только для отладки подключения, но не для постоянного тестирования.
- E2e-тесты можно разделить на уровни. На одном уровне проверяется взаимодействие микросервисов А, Б и В, на другом — взаимодействие системы с внешним сервисом Д. Набор сценариев будет различаться между уровнями. Делается с целью возможности запуска тестов например на локальной машине, где внешние сервисы по какой-то причине недоступны
- Сложность или невозможность приведения внешней системы в нужное состояние. Например, для подтверждения заказа во внешнем сервисе требуется ручное воздействие оператора, а API для изменения состояния отсутствует.
- Высокая стоимость запросов к API. Тестовые запросы тоже могут тарифицироваться. В таких случаях можно разделить тесты на уровни и в некоторых сценариях использовать заглушки.
И в этих случаях использовать реальные подключения затруднительно. В идеале надо тестировать всё вместе, но если это невозможно, то можно использовать двойника. Его нужно поддерживать и дорабатывать, что требует затрат, но это лучше, чем ничего. Обычно двойник представляет собой отдельный сервис, который можно создать самостоятельно или использовать инструменты вроде Wiremock Standalone.
E2e-тесты действительно лучше проводить с реальными зависимостями, но в жизни бывают разные ситуации, например:
- Тестовых подключений может не быть. Провайдер не предоставляет такую возможность. Обычно демо-аккаунт существует, но не всегда. Приходится выводить в прод под фиче-флагом и отлаживаться на месте.
- Нет доступа к тестовым подключениям. Это подвид предыдущего случая. Бывают ситуации, когда тестовый контур изолирован от интернета, и вызовы вовне невозможны.
- Тестовые подключения нестабильны, и получить “зеленые прогоны” затруднительно. Иногда для демо-стенда выделяется слабый сервер, который подходит только для отладки подключения, но не для постоянного тестирования.
- E2e-тесты можно разделить на уровни. На одном уровне проверяется взаимодействие микросервисов А, Б и В, на другом — взаимодействие системы с внешним сервисом Д. Набор сценариев будет различаться между уровнями. Делается с целью возможности запуска тестов например на локальной машине, где внешние сервисы по какой-то причине недоступны
- Сложность или невозможность приведения внешней системы в нужное состояние. Например, для подтверждения заказа во внешнем сервисе требуется ручное воздействие оператора, а API для изменения состояния отсутствует.
- Высокая стоимость запросов к API. Тестовые запросы тоже могут тарифицироваться. В таких случаях можно разделить тесты на уровни и в некоторых сценариях использовать заглушки.
И в этих случаях использовать реальные подключения затруднительно. В идеале надо тестировать всё вместе, но если это невозможно, то можно использовать двойника. Его нужно поддерживать и дорабатывать, что требует затрат, но это лучше, чем ничего. Обычно двойник представляет собой отдельный сервис, который можно создать самостоятельно или использовать инструменты вроде Wiremock Standalone.
WireMock
Running as a Standalone Process
The WireMock server can be run in its own process, and configured via the Java API, JSON over HTTP or JSON files.