S0ER

Удивительно, но я согласен с человеком на 100%. Вот было бы здорово, если бы на собесы к дедам приходили только те, кто хочет интеллектуального развития. Ведь вокруг столько компаний куда приходишь со словами "мне нужно чтобы вы кормили меня баблом", а они в ответ "Именно вас мы и искали!". SOER | PRO | Boosty

Всем привет 👋 Вчера случилась странная ситуация с интервью с Сэмом Ньюманом и интервью не состоялось, и его в целом не будет. Наше общение началось 2 месяца назад и было все стандартно: я ему рассказал про проект, скинул 4 записи как пример того что будет, отвечал на его вопросы и мы запланировали дату интервью. Вчера мы начали собираться в зум для тех чека, Сэм подключился на 3 минуты и после ушел ничего не сказав. Мы с Колей подумали что у него технические проблемы, но позже я получил от Сэма письмо. Жаль что так получилось, вроде ничего не предвещало беды. Книга мне понравилась и я был бы рад ее обсудить. Надеюсь на ваше понимание, спасибо вам за поддержку ❤️ И я верю что это скорее исключительная ситуация, чем стандартная.

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

Часы идут - программист работает Как вы относитесь к системе контроля времени? Вот раньше, до ковида, это делалось очень просто: приложил пропуск - таймер запущен, вышел из офиса и таймер остановился. По итогу суммы часов нахождения в офисе должно накапать 40 часов в неделю. Если меньше - звоночек. Если систематически меньше, то подключаются HRы и руководитель. Если после нет изменений - на вылет с пляжа. После ковида ситуация резко изменилась. Сейчас многие работают из дома и что только не придумывает бизнес чтобы "отслеживать" работу сотрудников на нематериальном производстве. Ведь посчитать кол-во произведенных молотков просто, а посчитать производительность программиста уже куда сложнее. А если их 50 человек? Но бизнес всегда хочет контроллировать работу айтишников. Это аксиома. Если вам говорят обратное - вам врут. Как и на любом рынке, если есть спрос - будет и предложение. И тогда в ход идут скриншотилки экранов, система учета времени активности компа\монитора, кол-во часов в зуме, время подключения к корп VPN и прочий мусор, который хакается на раз - два. Я слышал множество историй, как люди сидели в зуме в одиночку, чтобы капала активность, пока они играют в дотку. Я читал про стрелку часов под лазером мышки чтобы мышка двигалась по экрану. Люди перестали выключать рабочие ноутбуки чтобы шло время подключения к VPN. И в итоге бизнес и IT играет в игру, кто кого обманет. Одни говорят - мы вам доверяем, а вторые - мы работаем. И пытаются на этой почве выстраивать доверительную культуру внутри. Ужас. Лично мне уже давно все равно где программист находится, что он делает в 12:27 и сколько часов он просидел на созвонах. Важно только кол-во выполненной работы за временную итерацию. И общекомандный зачет. И да, при таком подходе хорошо заметно лоуперформеров.  А играть в игру про доверие в коллективе, когда у тебя огромный слон в комнате в виде систем контроля времени - это расписаться в том, что по другим параметрам разработку вы замерить не можете. И вам почему - то нравится быть обманутым (а это так). И это печально.

Опубликовал статью Как определить какая доля багов/ошибок допустима и является следствием сложности программного кода? Несколько основных мыслей (полный текст см. в статье): - Борьба с багами возможна, но создание и контроль непродуманными метриками может увеличить их количество, а не уменьшить - Основная проблема заключается в создании нездорового климата внутри коллектива, что приводит к увеличению цены ошибки и замедлению работы; - Качество программного продукта не следует связывать только с количеством багов, так как это сильно замедляет выход на рынок и развитие продукта, что тоже важно; - Оптимизация показателей надежности и покрытия тестами кода является лучшим способом борьбы с багами, чем введение метрик, разрешающих определенное количество ошибок на определенное количество кода. - Нужно различать задачи, где стоимость ошибки велика (медицина, финтех и т.д.) и где ошибки проще списать на убытки (интернет магазины, развлекательные и обучающие платформы и т.д.) SOER | PRO | Boosty

Пассивный заработок программиста Расскажу личный опыт по следующим вопросам: - Сбережения - Блоги/Влоги/Информационные ресурсы - Крипта/Валюта - Недвижимость (сдача в аренду) И, конечно же, послушаем ваши истории SOER | PRO | Boosty

Переношу на boosty архив стримво с soer.pro сегодня перенс Проектирование API SOER | PRO | Boosty

Фото заряжено на импортозамещение!

Набор в NarisApp Всех кто хочет принять участие в разработке проекта NarisApp приглашаю принять участие. Если коротко: - участие бесплатное - делаем платформу обучения и развития - в этом наборе решаем два эпика: "интеграция с бусти" и "интеграция с телеграм" - как принять участие написано в конце статьи (см. ссылку выше) Подробное описание смотри по ссылке выше.

Задача: выбрать способ передачи сообщений в API для сервисной архитектуры Обычно выбор делается из двух решений: - REST - gRPC это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор: - использование HTTP/2 - обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными) - кодогенерация - RPC ориентированность (в том числе stream-based) Со стороны REST кроме требований самой архитектуры обычно выделяют: - простота - текстовый формат обмена (удобство) Таким образом gRPC отлично подходит для организации взаимодействия внутри сервисной (микросервисной) архитектуры, а для внешних API хорошо подходит REST стиль. Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами. SOER | PRO | Boosty

Пятница 15:00 техток по теме валютной удаленки Поговорим про ваши истории, рассмотрим вопросы: - насколько крутой английский нужен - как выводить средства - какие риски с позиции законодательства - как ищут работу - как оформляют отношения SOER | PRO | Boosty

Завтра стрима не будет. Отдыхаю, набираюсь сил для новых дел и свершений. 💡

Ребята, хочу сделать честный стрим про валютную удаленку с реальными людьми, которые в теме. Если вы работаете (или пробовали устроиться) на валютной удаленке, то расскажите о своём опыте в комментариях. Интересно узнать следующее: 1. Уровень английского 2. Сколько времени искали, сколько собесов прошли, прежде чем нашли 3. Как оформлены (ООО/ИП) 4. На какой схеме налогообложения (патент, упрощёнка и т.д.) 5. Как работаете с валютным контролем 6. Как сейчас выводят деньги в РФ 7. Пенсионные/ больничные 8. Кредиты/ипотеки насколько просто получить 9. Мысли от себя Если не хочется отвечать, то можешь просто проголосовать поставив эмоджи на пост ❤️ - работаю в РФ 😎 - работаю на валютной удаленке Если наберём интересный материал, то проведём стрим со всеми желающими выступить.

На boosty делаю зеркало записей стримов, размещенных на soer.pro, сегодня перенес запись Реактивная архитектура на уровне кода. SOER | PRO | Boosty

Часто бываю на собеседованиях с техническим персоналом и со временем вывел несколько критических вещей которые решают судьбу кандидата не в его пользу, возможно это кому-то поможет: 1. Нехватка фундаментальных знаний, понимания как устроены технические процессы под капотом. Кандидат в своем опыте где-то и что-то сделал непонятного качества и так теперь везде делает - «оно же работает». Сюда же относится поверхностное изучение фреймворков - нахватался терминов, смог связать их воедино в своем пет-проекте, но объяснить не может, хотя претендует на ‘владение темой’, не может решить известные проблемы. Здесь высокие риски того, что с человеком нельзя сварить каши. 2. Беспорядок в коде и голове, отсутствие документации (и даже иногда воинствующее нежелание писать её), неспособность набросать общий дизайн, план масштабирования, верхнеуровневое содержание итераций. Нет минимального понимания (и желания узнать) архитектурного слоя - зачем мы ту или иную модель эксплуатируем конкретно в этой сфере, какие у этого плюсы/минусы, каких подводных камней ожидать. Это воспринимается как некомпетентность. 3. Гонор, пренебрежение к другим участникам процесса разработки, болезненная самооценка. Не хватает субординации, понимания корпоративной этики. Часто в отечественном рынке вижу ребят которые с трудом мидлы, но позиционируют себя как сеньоры. Это мешает им развиваться и со стороны выглядит непривлекательно - в таких не хочется инвестировать. 4. «Залетные». Человек часто меняет работу, в индустрию пришел ‘ради лучшей жизни’. Резюме в котором нет фактуры, чем именно занимался, человек не может вспомнить чем полезным он занимался или какой фичей гордится, хотя на прошлых проектах «делал все за всех и вообще чуть ли не один там работал». За последний год также сильно выросло количество «волков», которые натаскиваются на прохождение собеседований - врут, увиливают, пытаются манипулировать диалогом, не могут дать конкретный ответ, всегда уводят вопросы в сторону. Сюда же в категорию ребята «я прошел курсы», но на курсах учили не работать, а зарабатывать.

Уже пару лет как найм через собеседование превратился в лютый ад как для новичков, так и для профи. Если раньше мне называли цифры 15-20 собесов до офера на должность джуна, то сейчас это уже 30-50, а завтра, наверное, будет все 100. Причём это кейсы успешного найма, что там у тех кто не прошёл долину смерти я не знаю. После неудачных попыток наверное даже самые упорные опускают руки. В сети много статей про реальное положение дел, не думаю что в ближайшее время что-то изменится. Интересно послушать ваши истории прохождения собесов, насколько мои ощущения совпадают с вашими.