StringConcat - разработка без боли и сожалений

В комментариях к одной из наших заметок упоминали пассажиров. Мол, зачем нам люди, которые просто сидят и машут веслом, как велено. Они же не добавляют команде ценности. Хотелось бы немного развить эту мысль. Мы выделяем три главных качества: адекватность, исполнительность и обучаемость. Есть и четвёртое — инициативность. Но эта не такая инициативность, когда чел всех задалбывает идеями, тащит на себя чужие обязанности и веслает по ночам за интересные задачи. Мы о другом, более комплексном, когда человек самостоятелен, последователен и автономен. Самостоятельность — способность оценить результат своей или не своей работы и улучшить её, не дожидаясь таски. Например, такой человек увидел повторяющуюся проблему, взял — и решил. Или что-то работало на 80%, а он взял — и улучшил до 99%. Последовательность — доведение дел до логического завершения, хотя бы какого-то из этапов. Необязательно своими руками, но чтоб проследил и убедился, что готово. Автономность — способность думать и действовать в меру возможностей без надзора и внешнего импульса. Например, между сервисами нет дырки, а человек взял — и завёл заявки, тегнул нужных людей, организовал дырку. А не сидел и жаловался, что никто этого не сделал вместо него. К сожалению, таких людей хорошо, если 10%. Это не плохо, кому-то нравится просто веслать и в ус не дуть (мы тоже так хотим на самом деле, но не разрешаем сами себе). Но если у вас на проекте одни пассажиры, быть беде. Придётся директивно управлять, решат все проблемы самостоятельно, и вы как руководитель выгорите в угли. Особенно печально, если среди пассажиров окажутся лиды. Такие способны угробить любое начинание. Так что цените инициативных людей, целуйте их в попку, одаривайте плюшками и двигайте вверх. Даже с нехваткой квалификации они быстро прокачиваются и занимают ключевые позиции. Как обычно, это субъективное наблюдение меня, Сережи и других коллег, а поэтому не истина в последней инстанции. Можно приходить в комментарии и накидывать.

Сергей на связи! Не собеседуйтесь в Индию. Там вы будете конкурировать со специалистами по трудоустройству, которые специализируются на прохождении собеседований. Недавно разговаривал с индусом, который собеседует разработчиков из Индии и со всего мира. Он предпочитает нанимать иностранцев, хотя они не очень умеют проходить собеседования. Деревья в уме крутят плохо, строку по полчаса переворачивают и в загадках путаются, зато потом нормально работают.  В Индии же наоборот: все учатся проходить собеседование, а не работать. Количество и качество резюме очень высокое, но по опыту скажу, что всё из индусского резюме можно смело делить на три. Как следствие, требования при наборе в Индии становятся жёстче, чтобы отсеивать Д'артаньянов, которые потом будут SQL-запросы из контроллеров делать.  Вывод. Очевидно, что прохождение таких собеседований и навык работы — две разные вещи. Корреляции между ними интервьюеры не наблюдают, но и менять стиль собеседования не торопятся, так что реальные навыки у вас никто проверять не будет.

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

Ещё один способ оценки квалификации Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке: — В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+ — Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно. — Фреймворками дело не ограничивается, есть ещё аналитическое мышление, знания в определённых предметных областях, конструкторские навыки и всякие там софт-скиллы. Короче, тысячи их: некоторые желательны, некоторые необходимы. Например, без навыков анализа хорошим разрабом не станешь. Квалификацию все описывают в меру фантазии и ресурсов. Обычно получаются широченные таблицы с картами компетенций, которые, по сути, просто описывают подгрейды между базовыми джунами-синьорами. Мы тоже попробовали, но пошли другим путём, от конкретного человека, а не от абстрактного идеала. Вместо этого мы декомпозировали квалификацию на составляющие и оценили каждую по шестибалльной шкале. Получилось так: пример оценки компетенций сферического Олега. Выглядит неплохо, правда, чтобы поддерживать такую систему оценки, потребуется целый отдел. Но вы можете воспользоваться шкалой. Например, пройтись по ветке своей специализации на сайте с роадмапами и оценить свои навыки. Это помогает найти пробелы в знаниях и проблемные места.

Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен. Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂

В продолжение поста Громкому тайтлу можно меньше платить Громкий тайтл может перекрыть разницу в деньгах, так что получать Principal Software Architect & Visionary Technologist может меньше, чем обычный Developer. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер. Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией. И теперь ничего не понятно Нельзя наверняка сказать, чем занимается Senior Staff Software Engineer. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.

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

Для тех кто пропустил или не подписан на наши ютубы - выпустили видосик на тему выбора языка и стека. Попробовали собрать в кучу те критерии, которые считаем важными. Для наших постоянных читателей такая тема может и не совсем актуальна, но вдруг кто хочет поменять стек либо же находится в начале пути ⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать). Приятного просмотра!

Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен. Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же Приятного просмотра!

Мы не знаем кто автор, но это просто шедеврально

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы». К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames. Мы обсудим как Константин внедрял архитектурные подходы и паттерны и узнаем, что из этого вышло. Ссылку пришлем позже, приходите и задавайте вопросы 🙂 Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных». Что внутри: — Какие структуры данных используются для построения СУБД — На каких алгоритмах построены распределённые СУБД — Репликация и бекапы — Журналирование — Управление доступом Для хардкорщиков, сохраняющих петабайты транзакций в наносек, будет не очень интересно, а вот для спецов среднего уровня и выше или для тех, кто хочет систематизировать знания и закрыть пробелы, — самое то. #полезнота

Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг: Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно. В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так. Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение. Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри» Какие темы охватывает книга: — Устройство shared buffer — Как работает WAL — Как выполняются запросы — Зачем нам вакуум — Как работают индексы — Как устроен MVCC — etc Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме Просвещайтесь! #полезнота