Вышел CMake 4.0🚀
Релиз вышел 5 дней назад. Release Notes можно почитать тут
Нашли в релизе интересные фичи? Поделитесь ими, пожалуйста, в комментариях🙂
Релиз вышел 5 дней назад. Release Notes можно почитать тут
Нашли в релизе интересные фичи? Поделитесь ими, пожалуйста, в комментариях🙂
🔥4❤🔥3🎉2
Пятничная болтология и никакой технички🍿
Неделя выдалась насыщенной: почти доделал сервис, который формально считался завершённым пару месяцев назад; закрыл поток на курсе в онлайн-школе и сейчас раздумываю, стоит ли вписываться в это снова; плюс продуктивно поработал с менти по вопросам смены работы. Сегодняшний пост как раз будет о работе — точнее, о деньгах, которые нам за неё платят.
Я знаю, в интернете полно обзоров, исследований и аналитики на тему «Сколько зарабатывает C++ разработчик?». Но это по-прежнему один из самых частых вопросов, которые мне задают — и знакомые, и коллеги, и менти. Так что пусть это будет версия
Все цифры указаны чистыми на руки, без учёта премий, и только для удалёнки.
Стажёр
Зарабатывает от 0 до 40к.
Оплачиваемые стажировки — реальность, хоть и вымирающая.
Junior
От МРОТ до 150к. Разброс большой — зависит от города и масштаба компании.
Например, в прошлом году НТР брали джунов после стажировки на оклад 140к. Маленькие компании чаще предлагают около 100к.
Middle
От 150к до 320к.
Разброс ещё больше, чем у джунов. Верхняя граница — это реальные офферы, которые получили мои менти в этом году.
Средняя зп мидла с опытом 3+ лет — около 250к.
Senior
От 250к до 400к.
Это зарплата, которую предлагают разработчикам «с улицы» — то есть тем, кто впервые приходит в компанию, без глубокого понимания домена, но с крепкими хард- и софт-скиллами. Средняя зп — 350к.
Можно ли больше? Можно.
Простой путь — взять на себя менеджерские задачи.
Поверьте, если в резюме появляется строка «Опыт управления командой X лет», собеседования начинают проходить в совершенно ином ключе — уже с прицелом на позицию лида.
Сложный путь — развивать глубокую экспертизу в конкретном домене (учим предметную область и идём к конкурентам) или идти в стартапы. Увы, стратапы с "плюсами" - редкость.
Очень сложный путь — офис и финтех, особенно HFT или крипта.
Ни в том, ни в другом я не разбираюсь, но к HFT хотя бы испытываю технический интерес🙂
Ещё раз подчеркну: это мой взгляд, основанный на личном опыте, опыте коллег и менти.
Если вы знаете, где плюсовики в РФ фармят по $10k в месяц — напишите мне, пожалуйста, в личку😁
Неделя выдалась насыщенной: почти доделал сервис, который формально считался завершённым пару месяцев назад; закрыл поток на курсе в онлайн-школе и сейчас раздумываю, стоит ли вписываться в это снова; плюс продуктивно поработал с менти по вопросам смены работы. Сегодняшний пост как раз будет о работе — точнее, о деньгах, которые нам за неё платят.
Я знаю, в интернете полно обзоров, исследований и аналитики на тему «Сколько зарабатывает C++ разработчик?». Но это по-прежнему один из самых частых вопросов, которые мне задают — и знакомые, и коллеги, и менти. Так что пусть это будет версия
Neverending C++
на 2025 год. Хм, получается, этот пост можно будет рефакторить и выпускать каждый год😄Все цифры указаны чистыми на руки, без учёта премий, и только для удалёнки.
Стажёр
Зарабатывает от 0 до 40к.
Оплачиваемые стажировки — реальность, хоть и вымирающая.
Junior
От МРОТ до 150к. Разброс большой — зависит от города и масштаба компании.
Например, в прошлом году НТР брали джунов после стажировки на оклад 140к. Маленькие компании чаще предлагают около 100к.
Middle
От 150к до 320к.
Разброс ещё больше, чем у джунов. Верхняя граница — это реальные офферы, которые получили мои менти в этом году.
Средняя зп мидла с опытом 3+ лет — около 250к.
Senior
От 250к до 400к.
Это зарплата, которую предлагают разработчикам «с улицы» — то есть тем, кто впервые приходит в компанию, без глубокого понимания домена, но с крепкими хард- и софт-скиллами. Средняя зп — 350к.
Можно ли больше? Можно.
Простой путь — взять на себя менеджерские задачи.
Поверьте, если в резюме появляется строка «Опыт управления командой X лет», собеседования начинают проходить в совершенно ином ключе — уже с прицелом на позицию лида.
Сложный путь — развивать глубокую экспертизу в конкретном домене (учим предметную область и идём к конкурентам) или идти в стартапы. Увы, стратапы с "плюсами" - редкость.
Очень сложный путь — офис и финтех, особенно HFT или крипта.
Ни в том, ни в другом я не разбираюсь, но к HFT хотя бы испытываю технический интерес🙂
Ещё раз подчеркну: это мой взгляд, основанный на личном опыте, опыте коллег и менти.
Если вы знаете, где плюсовики в РФ фармят по $10k в месяц — напишите мне, пожалуйста, в личку😁
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7💯6🔥4
Важное дополнение к предыдущему посту
Некоторые из моих подписчиков указали на критический недостаток вчерашнего поста: с 2025 года начала действовать прогрессивная шкала НДФЛ. Это значит, что теперь зарплата, которую разработчик получает на руки, уже не равна его средней зарплате за год. Средняя зарплата будет меньше🥲
НДФЛ по-прежнему удерживает работодатель, так что никаких дополнительных действий от нас не требуется. Остаётся только наблюдать, как ближе к концу года мы начинаем получать всё меньше и меньше...
Чтобы понять, что произойдёт с зарплатой в этом году, я воспользовался калькулятором отсюда
Результаты
Среднестатистический мидл с зарплатой 250к на руки теряет около 21к в год.
Среднестатистический синьёр с зарплатой 350к на руки — около 49к в год.
Некоторые из моих подписчиков указали на критический недостаток вчерашнего поста: с 2025 года начала действовать прогрессивная шкала НДФЛ. Это значит, что теперь зарплата, которую разработчик получает на руки, уже не равна его средней зарплате за год. Средняя зарплата будет меньше🥲
НДФЛ по-прежнему удерживает работодатель, так что никаких дополнительных действий от нас не требуется. Остаётся только наблюдать, как ближе к концу года мы начинаем получать всё меньше и меньше...
Чтобы понять, что произойдёт с зарплатой в этом году, я воспользовался калькулятором отсюда
Результаты
Среднестатистический мидл с зарплатой 250к на руки теряет около 21к в год.
Среднестатистический синьёр с зарплатой 350к на руки — около 49к в год.
Т—Ж
Калькулятор расчета НДФЛ по новым правилам
Как новая шкала налога повлияет на зарплату
😢3❤🔥2
Разбор вопросов с техсобесов#4
Вопрос
Сколько нужно потоков, что получить dead lock?
Ответ
Один😉 Достаточно повторно захватить в потоке, который уже им владееет.
Формально повторный захват - это , об этом пишется тут
Про dead lock явно говоритсятут
Код для проверки - в комментариях к посту
Вопрос
Сколько нужно потоков, что получить dead lock?
Ответ
std::mutex
Формально повторный захват
std::mutex
UB
The expression m.lock() has the following properties
The behavior is undefined if the calling thread already owns the mutex
Про dead lock явно говорится
A program can deadlock if the thread that owns a mutex object calls lock() on that object
Код для проверки - в комментариях к посту
🔥5👍2😁2
От смертельных объятий до самоблокировки
Первые предпосылки возникновения понятия "deadlock" относятся к работе Dijkstra 1968 года — "Co-operating Sequential Processes"
И deadlock именовался в этой работе как deadly embrace. Изначально речь шла о процессах.
+1 способ удивить интервьюера на собеседовании😎
В классическом понимании deadlock впервые появился в статье Coffman — "System Deadlocks"
В статье определение deadlock даётся весьма широкими мазками (для объяснения deadlock используется термин "задание"). В этой же статье определены условия возникновения deadlock, так называемые "условия Коффмана". Краткое изложение статьи можно прочитать тут
И, наконец, существует частный случай deadlock — проблема self-deadlock или recursive deadlock, о которой я писал в предыдущем посте: поток захватывает мьютекс, который уже ранее был им захвачен. Каких-либо философских статей на эту тему я не нашёл. Упоминания есть вот тут
Первые предпосылки возникновения понятия "deadlock" относятся к работе Dijkstra 1968 года — "Co-operating Sequential Processes"
И deadlock именовался в этой работе как deadly embrace. Изначально речь шла о процессах.
This situation, when one process can only continue provided the other one is killed first, is called "The Deadly Embrace"
В классическом понимании deadlock впервые появился в статье Coffman — "System Deadlocks"
В статье определение deadlock даётся весьма широкими мазками (для объяснения deadlock используется термин "задание"). В этой же статье определены условия возникновения deadlock, так называемые "условия Коффмана". Краткое изложение статьи можно прочитать тут
И, наконец, существует частный случай deadlock — проблема self-deadlock или recursive deadlock, о которой я писал в предыдущем посте: поток захватывает мьютекс, который уже ранее был им захвачен. Каких-либо философских статей на эту тему я не нашёл. Упоминания есть вот тут
👍4❤🔥1🔥1
Разбор вопросов с техсобесов #5
Вопрос
Сколько нужно мьютексов, чтобы получить deadlock?
Ответ
Ноль😁 Я знаю два варианта, не исключаю, что их больше. Код с deadlock без мьютексов ждите в комментариях.
Вопрос
Сколько нужно мьютексов, чтобы получить deadlock?
Ответ
👍6🔥1
Книги, которые вредно читать
Я подписан на канал издательства "Питер", которое выпускает эту книгу. На прошлой неделе там появился пост с книгой для начинающих C++ разработчиков с забавной обложкой с головастиком. "О, ещё одна НОВАЯ книга для новичков", — подумал я. Пробежался глазами по описанию — и был реально шокирован, увидев в описании фамилию автора — Шилдт!
Господа, сейчас 2025 год. Шилдт перестал писать 20 лет назад. Тут даже не нужно иметь грейд мидла, чтобы понять: его книги неактуальны. Советовать их новичку — это либо замедлить его развитие на годы, либо сразу поставить крест на его карьере.
Ну и вишенка на торте: к посту приложен обзор книги на популярном канале по C++ с более чем 8 тысячами подписчиков. Этот "обзор" заслуживает отдельного рассмотрения. Я не буду комментировать поток воды — за текст явно заплатили, объём нужно было соблюсти — остановлюсь только на выводах.
Цитата:
То есть потенциальный покупатель тратит около 2000 рублей, затем полгода на изучение книги, чтобы получить "полноценный фундамент", на котором он "не будет знать, как писать нормальный код?" Предлагаю вам самостоятельно дать оценку этой рекомендации.
Хотите "полноценный фундамент"? Перед изучением C++ — изучите C😉
Что не так с книгами Шилдта
Тема книг Шилдта уже поднималась мной в комментариях. Я не скрываю: сам когда-то читал его книги. Увы, 10 лет назад в интернете не было такого разнообразия ресурсов для изучения C++ с нуля. Не было онлайн-школ, менторов, блогов и каналов. Была парочка токсичных форумов и несколько сайтов. В то время Шилдт действительно был сильно разрекламирован. Хотя Липпман уже активно печатался, почему-то в нашем инфополе он такой поддержки не получил.
Проблема в том, что книги Шилдта написаны очень давно. Например, C++: A Beginner’s Guide датируется аж 2002 годом. А с учётом времени, которое уходит на написание и публикацию, в лучшем случае в них рассматривается стандарт C++98.
Чтобы было понятнее, приведу пример случайного кода из книги. Вся книга примерно в таком стиле:
Этот код даже до C++98 не дотягивает, не говоря уже о "старичке" C++11. Здесь используются сырые массивы, переменные цикла инициализируются в стиле C, переменная цикла вообще не нужна — можно было бы использовать range-based for. Учить C++ на таких примерах — не просто бесполезно, а вредно.
По своему опыту знаю: работа с низкоуровневыми конструкциями вызывает огромные сложности у новичков. Отсюда и бесконечные байки про "сложный C++", "утечки памяти", "падения программ". Увы, эти предрассудки пустили корни в наш прод. Уже выросло целое поколение управленцев, которые не понимают, что язык давно эволюционировал. Современный C++ — это высокоуровневый язык, на котором можно создавать прототипы достаточно быстро, не тратя время на борьбу с бесконечными UB и утечками. И уже при необходимости — можно спуститься до работы с указателями (или даже до ассемблера) и выжать максимум производительсности.
Многие до сих пор выбирают языки с динамической типизацией или автоматическим управлением памятью только потому, что их первое знакомство с C++ выглядело как работа со строками и массивами в стиле книг Шилдта.
Итог
Книгам Шилдта давно пора занять своё почётное место в музее истории C++ или на полках коллекционеров. Но на полках современного C++ разработчика им делать нечего.
Я подписан на канал издательства "Питер", которое выпускает эту книгу. На прошлой неделе там появился пост с книгой для начинающих C++ разработчиков с забавной обложкой с головастиком. "О, ещё одна НОВАЯ книга для новичков", — подумал я. Пробежался глазами по описанию — и был реально шокирован, увидев в описании фамилию автора — Шилдт!
Господа, сейчас 2025 год. Шилдт перестал писать 20 лет назад. Тут даже не нужно иметь грейд мидла, чтобы понять: его книги неактуальны. Советовать их новичку — это либо замедлить его развитие на годы, либо сразу поставить крест на его карьере.
Ну и вишенка на торте: к посту приложен обзор книги на популярном канале по C++ с более чем 8 тысячами подписчиков. Этот "обзор" заслуживает отдельного рассмотрения. Я не буду комментировать поток воды — за текст явно заплатили, объём нужно было соблюсти — остановлюсь только на выводах.
Цитата:
После прочтения книжки вы не будете знать, как писать нормальный код на C++. Но это и не было целью. Цель книги — рассказать про базовые синтаксические конструкции языка. То есть по завершении книги у вас будет полноценный фундамент, чтобы изучать уже более продвинутый C++.
То есть потенциальный покупатель тратит около 2000 рублей, затем полгода на изучение книги, чтобы получить "полноценный фундамент", на котором он "не будет знать, как писать нормальный код?" Предлагаю вам самостоятельно дать оценку этой рекомендации.
Хотите "полноценный фундамент"? Перед изучением C++ — изучите C😉
Что не так с книгами Шилдта
Тема книг Шилдта уже поднималась мной в комментариях. Я не скрываю: сам когда-то читал его книги. Увы, 10 лет назад в интернете не было такого разнообразия ресурсов для изучения C++ с нуля. Не было онлайн-школ, менторов, блогов и каналов. Была парочка токсичных форумов и несколько сайтов. В то время Шилдт действительно был сильно разрекламирован. Хотя Липпман уже активно печатался, почему-то в нашем инфополе он такой поддержки не получил.
Проблема в том, что книги Шилдта написаны очень давно. Например, C++: A Beginner’s Guide датируется аж 2002 годом. А с учётом времени, которое уходит на написание и публикацию, в лучшем случае в них рассматривается стандарт C++98.
Чтобы было понятнее, приведу пример случайного кода из книги. Вся книга примерно в таком стиле:
#include <iostream>
using namespace std;
void display(int num[10]);
int main()
{
int t[10], i;
for(i = 0; i < 10; ++i) t[i] = i;
display(t); // Передаём функции массив t.
return 0;
}
// Функция выводит все элементы массива.
void display(int num[10])
{
int i;
for(i = 0; i < 10; i++) cout << num[i] << ' ';
}
Этот код даже до C++98 не дотягивает, не говоря уже о "старичке" C++11. Здесь используются сырые массивы, переменные цикла инициализируются в стиле C, переменная цикла вообще не нужна — можно было бы использовать range-based for. Учить C++ на таких примерах — не просто бесполезно, а вредно.
По своему опыту знаю: работа с низкоуровневыми конструкциями вызывает огромные сложности у новичков. Отсюда и бесконечные байки про "сложный C++", "утечки памяти", "падения программ". Увы, эти предрассудки пустили корни в наш прод. Уже выросло целое поколение управленцев, которые не понимают, что язык давно эволюционировал. Современный C++ — это высокоуровневый язык, на котором можно создавать прототипы достаточно быстро, не тратя время на борьбу с бесконечными UB и утечками. И уже при необходимости — можно спуститься до работы с указателями (или даже до ассемблера) и выжать максимум производительсности.
Многие до сих пор выбирают языки с динамической типизацией или автоматическим управлением памятью только потому, что их первое знакомство с C++ выглядело как работа со строками и массивами в стиле книг Шилдта.
Итог
Книгам Шилдта давно пора занять своё почётное место в музее истории C++ или на полках коллекционеров. Но на полках современного C++ разработчика им делать нечего.
👍5💯4❤🔥2
Отзывы обо мне #1
Немного выйду из тени и поделюсь отзывами обо мне как о менторе🙂
Апрель оказался щедрым на оферы: трое моих менти получили предложения о работе!
Двое из них оставили отзывы обо мне на площадке "IT менторы". Огромное им спасибо за это🙂
📌 Офер 1: удалёнка + х3 (!) к зарплате — https://t.me/it_mentors/4344
📌 Офер 2: удалёнка + х1.75 к зарплате — https://t.me/it_mentors/4345
Горжусь ребятами и желаю им успехов на новых рабочих местах! 🚀
Хочешь так же? Не стесняйся — пиши мне в личку: @zlobinda
Немного выйду из тени и поделюсь отзывами обо мне как о менторе🙂
Апрель оказался щедрым на оферы: трое моих менти получили предложения о работе!
Двое из них оставили отзывы обо мне на площадке "IT менторы". Огромное им спасибо за это🙂
📌 Офер 1: удалёнка + х3 (!) к зарплате — https://t.me/it_mentors/4344
📌 Офер 2: удалёнка + х1.75 к зарплате — https://t.me/it_mentors/4345
Горжусь ребятами и желаю им успехов на новых рабочих местах! 🚀
Хочешь так же? Не стесняйся — пиши мне в личку: @zlobinda
🔥14🎉4👍3❤🔥2
Найм глазами С++ разработчика "с той стороны баррикад"
Последнюю неделю я опять частично провел в отборе резюме кандидатов на позицию С++ разработчика и последующих технических собеседованиях. За время участия в найме у меня накопилось несколько рекомендаций на тему "как не надо делать", и я хотел бы ими с вами поделиться. Уверен, кому-то из вас они помогут повысить конверсию резюме.
Честно говоря, этот пост дался мне не с первой попытки, потому что при написании определённых частей текст начинал скатываться в критику кандидатов. А моя цель — не критиковать, а указать на ошибки, которые допускают кандидаты, и, по возможности, показать способы, как их можно избежать или исправить.
⛔️ Кому мы отказывали сразу после первоначального ознакомления с резюме
1. Резюме на английском
NB! Вакансия была на русском, размещена на HH в РФ
То есть кандидат в приоритете ищет работу в зарубежной компании, а для рынка РФ поленился создать второе резюме на русском языке. Лично у меня нет никакого желания разбираться в этой "подачке".
2. Нет опыта в C++, есть опыт в других ЯП
Я не знаю, зачем кандидаты с опытом в JS, C#, Python откликаются на вакансию плюсовика. Автокликер? Или надежда, что такого классненького фронтендера возьмут без опыта? Как минимум, сопроводительное письмо могло бы пролить свет на эту тайну.
3. Нет опыта вообще
Пустое резюме, просто пустое😁 Сопроводительное также отсутствует.
4. Меньше 18 лет
Честно, вообще не хочется разбираться, то ли это реальный возраст, то ли попытка скрыть свои данные. Если второй вариант, то выглядит это крайне нелепо.
5. Выпускники онлайн-курсов
Да, они до сих пор есть и пишут всё по методичкам онлайн-курсов😁
❓ Кому отказываем после некоторых раздумий
NB! В вакансии, конечно же, был указан требуемый стек
1. Тотальный опыт с Qt
Тотальный — это значит, что практически на всех рабочих местах кандидат использовал Qt. Увы, каждый собес Qtшника заканчивается одной и той же историей: "Ой, я не знаю STL, потому что в Qt свои контейнеры/алгоритмы/многопоточка". Коллега, рекомендую тебе сначала выучить STL, а только потом приходить на собес. Компании не готовы платить деньги специалисту без базового знания языка и его стандартной библиотеки.
2. Тотальный опыт во встраиваемой разработке, МК, STM32 и далее по железячному списку
Это специфический опыт, который часто вообще никак не связан ни с C++, ни даже с C. Обычно всё сводится к "я в основном пишу на C", а последующая попытка копнуть C заканчивается полным фиаско. Рекомендация та же, что и для Qt.
3. Фрилансеры
Если у кандидата где-то в опыте затесался один-два года фриланса — это вполне ок. Может быть, кандидат реально фрилансил, может, просто отдыхал. Бывает😎 Но если в последнем месте работы указано 5, 8 или даже 20 лет фриланса — это повод для отказа.
Во-первых, это намек на явную накрутку опыта разработчика. Во-вторых, даже если это не накрутка, велика вероятность, что кандидат не умеет работать в команде, не умеет работать под руководством и не умеет работать на длинных дистанциях над одним проектом.
4. Категория 60+
Во всех резюме возрастных кандидатов, которые я видел, был сплошной винегрет из доменов, ЯП, технологий и рабочих мест. В итоге опыт выглядит разношерстным, а кандидат не производит впечатления специалиста, который глубоко разбирается в какой-то области.
Скачки из домена в домен нормально воспринимаются для разработчиков с небольшим опытом — понятно, что специалист ищет комфортный и интересный для себя домен. Но чем больше у вас опыта, тем сильнее в резюме должен прослеживаться акцент на определенный домен. Умеете в несколько доменов? Отлично, сделайте несколько резюме. Но не стоит делать резюме "эникейщика".
5. Накрутчики-вкатуны
Я бы даже написал "нелепые накрутчики". В основной массе это школьники и студенты, которые насмотрелись известных видео про накрутку, сдули оттуда шаблон резюме и легенды (некоторые — прямо слово в слово).
Вычисляется это всё при первом изучении резюме, даже дополнительные проверки не нужны.
Фьюх, на этом на сегодня всё. Надеюсь, никого сильно не расстроил😉
Последнюю неделю я опять частично провел в отборе резюме кандидатов на позицию С++ разработчика и последующих технических собеседованиях. За время участия в найме у меня накопилось несколько рекомендаций на тему "как не надо делать", и я хотел бы ими с вами поделиться. Уверен, кому-то из вас они помогут повысить конверсию резюме.
1. Резюме на английском
NB! Вакансия была на русском, размещена на HH в РФ
То есть кандидат в приоритете ищет работу в зарубежной компании, а для рынка РФ поленился создать второе резюме на русском языке. Лично у меня нет никакого желания разбираться в этой "подачке".
2. Нет опыта в C++, есть опыт в других ЯП
Я не знаю, зачем кандидаты с опытом в JS, C#, Python откликаются на вакансию плюсовика. Автокликер? Или надежда, что такого классненького фронтендера возьмут без опыта? Как минимум, сопроводительное письмо могло бы пролить свет на эту тайну.
3. Нет опыта вообще
Пустое резюме, просто пустое😁 Сопроводительное также отсутствует.
4. Меньше 18 лет
Честно, вообще не хочется разбираться, то ли это реальный возраст, то ли попытка скрыть свои данные. Если второй вариант, то выглядит это крайне нелепо.
5. Выпускники онлайн-курсов
Да, они до сих пор есть и пишут всё по методичкам онлайн-курсов😁
NB! В вакансии, конечно же, был указан требуемый стек
1. Тотальный опыт с Qt
Тотальный — это значит, что практически на всех рабочих местах кандидат использовал Qt. Увы, каждый собес Qtшника заканчивается одной и той же историей: "Ой, я не знаю STL, потому что в Qt свои контейнеры/алгоритмы/многопоточка". Коллега, рекомендую тебе сначала выучить STL, а только потом приходить на собес. Компании не готовы платить деньги специалисту без базового знания языка и его стандартной библиотеки.
2. Тотальный опыт во встраиваемой разработке, МК, STM32 и далее по железячному списку
Это специфический опыт, который часто вообще никак не связан ни с C++, ни даже с C. Обычно всё сводится к "я в основном пишу на C", а последующая попытка копнуть C заканчивается полным фиаско. Рекомендация та же, что и для Qt.
3. Фрилансеры
Если у кандидата где-то в опыте затесался один-два года фриланса — это вполне ок. Может быть, кандидат реально фрилансил, может, просто отдыхал. Бывает😎 Но если в последнем месте работы указано 5, 8 или даже 20 лет фриланса — это повод для отказа.
Во-первых, это намек на явную накрутку опыта разработчика. Во-вторых, даже если это не накрутка, велика вероятность, что кандидат не умеет работать в команде, не умеет работать под руководством и не умеет работать на длинных дистанциях над одним проектом.
4. Категория 60+
Во всех резюме возрастных кандидатов, которые я видел, был сплошной винегрет из доменов, ЯП, технологий и рабочих мест. В итоге опыт выглядит разношерстным, а кандидат не производит впечатления специалиста, который глубоко разбирается в какой-то области.
Скачки из домена в домен нормально воспринимаются для разработчиков с небольшим опытом — понятно, что специалист ищет комфортный и интересный для себя домен. Но чем больше у вас опыта, тем сильнее в резюме должен прослеживаться акцент на определенный домен. Умеете в несколько доменов? Отлично, сделайте несколько резюме. Но не стоит делать резюме "эникейщика".
5. Накрутчики-вкатуны
Я бы даже написал "нелепые накрутчики". В основной массе это школьники и студенты, которые насмотрелись известных видео про накрутку, сдули оттуда шаблон резюме и легенды (некоторые — прямо слово в слово).
Вычисляется это всё при первом изучении резюме, даже дополнительные проверки не нужны.
Фьюх, на этом на сегодня всё. Надеюсь, никого сильно не расстроил😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍6😁2🤔2💯1
Активность в канале, весна и найм
Как вы, наверное, заметили, активность в канале в последние недели снизилась — и причина тому весна и майские праздники😁 Погода мотивирует проводить больше времени на улице, а значит, на активности, связанные с компьютером, остаётся меньше времени. Сейчас я пересматриваю свои приоритеты, хочу найти возможность для более активного ведения канала в летний период (кого я обманываю — просто для ведения канала😁). Увы, с некоторыми задачами придётся временно расстаться.
Причём тут найм
В найме сейчас наблюдается похожее затишье. По моему опыту прошлых лет, пониженная активность сохранится до конца лета. Во-первых, многие компании уже закрыли план найма (то есть набрали то количество сотрудников, которое было заложено в бюджете на начало года). Во-вторых, в найме тоже работают люди, у которых "праздники, отпуска, поездки" — большинство из них приходится как раз на лето.
Если вы всё ещё в поиске или только начали
Пониженная активность — это всё-таки активность, а не её полное отсутствие😉 Не отчаивайтесь и уж тем более не соглашайтесь на офферы, которые вам не особенно интересны, только потому, что "ну хоть кто-то обратил на меня внимание". Запасайтесь терпением и продолжайте поиск🔍
Как вы, наверное, заметили, активность в канале в последние недели снизилась — и причина тому весна и майские праздники😁 Погода мотивирует проводить больше времени на улице, а значит, на активности, связанные с компьютером, остаётся меньше времени. Сейчас я пересматриваю свои приоритеты, хочу найти возможность для более активного ведения канала в летний период (кого я обманываю — просто для ведения канала😁). Увы, с некоторыми задачами придётся временно расстаться.
Причём тут найм
В найме сейчас наблюдается похожее затишье. По моему опыту прошлых лет, пониженная активность сохранится до конца лета. Во-первых, многие компании уже закрыли план найма (то есть набрали то количество сотрудников, которое было заложено в бюджете на начало года). Во-вторых, в найме тоже работают люди, у которых "праздники, отпуска, поездки" — большинство из них приходится как раз на лето.
Если вы всё ещё в поиске или только начали
Пониженная активность — это всё-таки активность, а не её полное отсутствие😉 Не отчаивайтесь и уж тем более не соглашайтесь на офферы, которые вам не особенно интересны, только потому, что "ну хоть кто-то обратил на меня внимание". Запасайтесь терпением и продолжайте поиск
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20❤🔥3💯2
Шпаргалка по
Два варианта использования ключевого слова
1. Спецификатор типа
Член класса, объявленный как
Сценарии использования:
- Кэширование
- Ленивые (отложенные) вычисления
- Мьютексы
Привер 1.1. Традиционный пример с мьютексом:
Пример 1.2. Странный пример с константным объектом:
2. Спецификатор лямбды
Позволяет телу лямбды модифицировать объекты, захваченные по копии, и вызывать их неконстантные методы. Проще говоря, для лямбды со спецификатором
Пример 2.1. Захватываем базовый тип по копии и модифицируем его значение в теле лямбды:
Пример 2.2. Захватываем пользовательский тип по копии и вызываем его неконстантный метод:
mutable
Два варианта использования ключевого слова
mutable
:1. Спецификатор типа
Член класса, объявленный как
mutable
, может быть изменен, даже если содержащий его объект объявлен константным.Сценарии использования:
- Кэширование
- Ленивые (отложенные) вычисления
- Мьютексы
Привер 1.1. Традиционный пример с мьютексом:
#include <mutex>
class A
{
public:
int get() const
{
std::lock_guard guard{mutex_};
return a_;
}
private:
int a_{0};
mutable std::mutex mutex_;
};
Пример 1.2. Странный пример с константным объектом:
struct A
{
mutable int a{0};
};
int main()
{
const A a;
a.a = 1;
}
2. Спецификатор лямбды
Позволяет телу лямбды модифицировать объекты, захваченные по копии, и вызывать их неконстантные методы. Проще говоря, для лямбды со спецификатором
mutable
генерируется неконстантная версия operator()
.Пример 2.1. Захватываем базовый тип по копии и модифицируем его значение в теле лямбды:
int main()
{
int i{0};
auto lambda = [i]() mutable { ++i; };
}
Пример 2.2. Захватываем пользовательский тип по копии и вызываем его неконстантный метод:
class A
{
public:
void set(int a)
{
a_ = a;
}
private:
int a_{0};
};
int main()
{
A a;
auto lambda = [a]() mutable { a.set(1); };
}
👍5✍1🔥1
Занятия спортом и собеседования. Что общего?
В собеседованиях, как и в спорте, важна цикличность. Мы многократно повторяем одни и те же действия, организм адаптируется к нагрузке, и со временем действия доводятся до автоматизма — то есть превращаются в навык. Стоит расслабиться, сделать паузу — и навык либо ослабеет, либо будет утрачен полностью.
Представьте, что вы начали тренироваться на турнике. Это так просто — турники есть почти в каждом дворе. Через пару недель начинают болеть мышцы, на ладонях появляются мозоли. Вы решаете сделать перерыв на неделю-другую, чтобы "мышцы восстановились", "мозоли зажили", "посмотреть видео по технике"... Наш мозг легко находит оправдания, чтобы тело не напрягалось😞
Что происходит в итоге? Прогресс теряется, и приходится начинать сначала. У многих моих знакомых так и не получилось научиться подтягиваться: спустя пару недель они, наконец, делали одно подтягивание, радовались — и прекращали тренировки, чтобы отдохнуть и восстановиться. Через пару недель 1 превращалось в 0.
Причём тут собеседования?
На мой взгляд, с собеседованиями всё то же самое. Мы учимся справляться со стрессом, слушать интервьюера, чётко формулировать мысли, концентрироваться и показывать максимум за короткий промежуток времени.
Знания, на самом деле, — вторичны. Под стрессом можно забыть даже банальные вещи (например, сказать, что размер
Почему?
В IT нет стандартизированного списка вопросов и единых критериев оценки. На одном собеседовании могут спросить про умные указатели, на другом — про примитивы синхронизации, а на третьем вообще попросят проревьюить код. Если вы после неудачного собеса делаете паузу на недельку-вторую, чтобы подтянуть знания по умным указателям, это вовсе не гарантирует, что эта тема будет актуальна на следующем интервью.
Собеседование — это не экзамен. Его нельзя "пересдать" по тем же вопросам.
Как и в спорте, нужен баланс
Если тренироваться каждый день без отдыха и растяжки, можно истощить организм или даже получить травму. С собеседованиями — аналогично. Вот несколько рекомендаций, которые помогут пройти этот марафон:
1. Определите приоритетные компании.
Собеседуйтесь в компании "мечты" только после того, как наберёте форму — начнёте уверенно проходить собеседования в менее приоритетных местах.
2. Не перетруждайтесь.
Начните с одного собеседования в неделю. Когда появится уверенность — переходите к двум, максимум трём в неделю. Оптимально — два. Освободившееся время посвятите пункту 3.
3. Анализируйте и учитесь.
После каждого собеседования анализируйте свои ответы. Лучше — с ментором. Нет ментора — обратитесь к более опытному коллеге. Иногда трудно заметить свои ошибки, особенно если вы пока не знаете правильного ответа. Ведите свою базу знаний: вопрос с собеса — ваш ответ. Для этих целей отлично подойдет Obsidian.
4. И главное — не отчаивайтесь.
Проходить собеседования — действительно сложно. Большую часть времени мы пишем код, меньшую — делимся знаниями, и уж точно редко кто в рабочем процессе обсуждает, как устроен control block в
В собеседованиях, как и в спорте, важна цикличность. Мы многократно повторяем одни и те же действия, организм адаптируется к нагрузке, и со временем действия доводятся до автоматизма — то есть превращаются в навык. Стоит расслабиться, сделать паузу — и навык либо ослабеет, либо будет утрачен полностью.
Представьте, что вы начали тренироваться на турнике. Это так просто — турники есть почти в каждом дворе. Через пару недель начинают болеть мышцы, на ладонях появляются мозоли. Вы решаете сделать перерыв на неделю-другую, чтобы "мышцы восстановились", "мозоли зажили", "посмотреть видео по технике"... Наш мозг легко находит оправдания, чтобы тело не напрягалось😞
Что происходит в итоге? Прогресс теряется, и приходится начинать сначала. У многих моих знакомых так и не получилось научиться подтягиваться: спустя пару недель они, наконец, делали одно подтягивание, радовались — и прекращали тренировки, чтобы отдохнуть и восстановиться. Через пару недель 1 превращалось в 0.
Причём тут собеседования?
На мой взгляд, с собеседованиями всё то же самое. Мы учимся справляться со стрессом, слушать интервьюера, чётко формулировать мысли, концентрироваться и показывать максимум за короткий промежуток времени.
Знания, на самом деле, — вторичны. Под стрессом можно забыть даже банальные вещи (например, сказать, что размер
char*
— 1 байт). Из-за слабых коммуникативных навыков — не задать уточняющий вопрос и, как следствие, неправильно решить задачу. Поэтому фразы вроде «я ещё чуть-чуть подготовлюсь и тогда точно пойду на собес» или «возьму паузу, чтобы лучше подготовиться» — не только не помогут, но и могут навредить.Почему?
В IT нет стандартизированного списка вопросов и единых критериев оценки. На одном собеседовании могут спросить про умные указатели, на другом — про примитивы синхронизации, а на третьем вообще попросят проревьюить код. Если вы после неудачного собеса делаете паузу на недельку-вторую, чтобы подтянуть знания по умным указателям, это вовсе не гарантирует, что эта тема будет актуальна на следующем интервью.
Собеседование — это не экзамен. Его нельзя "пересдать" по тем же вопросам.
Как и в спорте, нужен баланс
Если тренироваться каждый день без отдыха и растяжки, можно истощить организм или даже получить травму. С собеседованиями — аналогично. Вот несколько рекомендаций, которые помогут пройти этот марафон:
1. Определите приоритетные компании.
Собеседуйтесь в компании "мечты" только после того, как наберёте форму — начнёте уверенно проходить собеседования в менее приоритетных местах.
2. Не перетруждайтесь.
Начните с одного собеседования в неделю. Когда появится уверенность — переходите к двум, максимум трём в неделю. Оптимально — два. Освободившееся время посвятите пункту 3.
3. Анализируйте и учитесь.
После каждого собеседования анализируйте свои ответы. Лучше — с ментором. Нет ментора — обратитесь к более опытному коллеге. Иногда трудно заметить свои ошибки, особенно если вы пока не знаете правильного ответа. Ведите свою базу знаний: вопрос с собеса — ваш ответ. Для этих целей отлично подойдет Obsidian.
4. И главное — не отчаивайтесь.
Проходить собеседования — действительно сложно. Большую часть времени мы пишем код, меньшую — делимся знаниями, и уж точно редко кто в рабочем процессе обсуждает, как устроен control block в
std::shared_ptr
😉💯10👍6🔥6
Шпаргалка по inline. Часть 1. Функции
На мой взгляд, inline — одно из наиболее часто неправильно трактуемых ключевых слов в C++. Эта заметка посвящена использованию
Первоначальный смысл
Изначально
К нашей радости, задача инлайн-оптимизации давно снята с плеч программистов и теперь полностью ложится на компилятор. Писать
Текущее состояние
В современном C++ (подозреваю, речь идёт об эпохе после C++11) ключевое слово
На мой взгляд, inline — одно из наиболее часто неправильно трактуемых ключевых слов в C++. Эта заметка посвящена использованию
inline
при объявлении функций. Вторая часть будет посвящена его использованию при объявлении переменных.Первоначальный смысл
Изначально
inline
служило подсказкой компилятору: вместо вызова функции код можно "вставить" тело функции прямо в место вызова. Теоретически этот механизм, известный как inline expansion, должен был привести к увеличению быстродействия программы при незначительном росте размера исполняемого файла. Увы, на практике всё оказалось, как обычно, прозаичнее: inline
-функции могли приводить как к ускорению, так и к замедлению программыК нашей радости, задача инлайн-оптимизации давно снята с плеч программистов и теперь полностью ложится на компилятор. Писать
inline
в целях оптимизации в современном мире — занятие бессмысленное: компиляторы умеют инлайнить функции, даже если они не помечены как inline
, и могут отказаться инлайнить функции, даже если они помечены как inline
. Единственное, в чём компилятор вам не откажет — это просьба не инлайнить функцию. Для этого в GCC можно использовать __attribute__((noinline))
.Текущее состояние
В современном C++ (подозреваю, речь идёт об эпохе после C++11) ключевое слово
inline
означает "допустимо несколько определений", и связано с правилом One Definition Rule (ODR). То есть функция, помеченная как inline
, может иметь несколько определений в разных единицах трансляции. Например, вы объявили и определили функцию в заголовочном файле, который затем подключили в несколько .cpp
-файлов. Ключевой момент: все определения должны быть идентичными, иначе — ill-formed, no diagnostic required. Чем это отличается от привычного undefined behavior обсуждается здесь (спойлер: ничем)👍10🔥5❤🔥2🤔1
Шпаргалка по inline. Часть 2. Переменные
Вторая часть посвящена использованию ключевого слова
Начиная со стандарта C++17, значение ключевого слова
Применительно к inline-переменным я хотел бы выделить два наиболее интересных, на мой взгляд, случая их использования в проде. Если вы считаете, что я что-то упустил, традиционно призываю вас не держать это в себе, а написать в комментариях🙂
Случай 1. Статические члены классов
Меня всегда расстраивал неуклюжий синтаксис работы со статическими членами классов. Только взгляните на этот синтетический пример времён "до C++17":
Выглядит откровенно костыльно.
Напишем этот же класс в стиле C++17:
Лаконично и понятно.
Случай 2. Глобальные константы
Обратим внимание на интересные свойства встроенных переменных:
- В программе может быть более одного определения встроенной переменной.
- При этом встроенная переменная имеет один и тот же адрес в каждой единице трансляции.
Благодаря этим свойствам, начиная с C++17, объявление констант в заголовочном файле стало достаточно тривиальным занятием:
Этот заголовочный файл можно подключить к нескольким единицам трансляции — в каждой из них
Вторая часть посвящена использованию ключевого слова
inline
при объявлении переменных.Начиная со стандарта C++17, значение ключевого слова
inline
было распространено на переменные. Предпосылкой к этому послужил тот факт, что смысл inline
для функций давно уже приобрёл значение "допускается несколько определений".Применительно к inline-переменным я хотел бы выделить два наиболее интересных, на мой взгляд, случая их использования в проде. Если вы считаете, что я что-то упустил, традиционно призываю вас не держать это в себе, а написать в комментариях🙂
Случай 1. Статические члены классов
Меня всегда расстраивал неуклюжий синтаксис работы со статическими членами классов. Только взгляните на этот синтетический пример времён "до C++17":
class A
{
// Тут объявляем переменную
static int a_;
};
// А вот тут определяем и инициализируем
int A::a_{0};
Выглядит откровенно костыльно.
Напишем этот же класс в стиле C++17:
class A
{
// И объявляем, и определяем, и инициализируем
inline static int a_{0};
};
Лаконично и понятно.
Случай 2. Глобальные константы
Обратим внимание на интересные свойства встроенных переменных:
- В программе может быть более одного определения встроенной переменной.
- При этом встроенная переменная имеет один и тот же адрес в каждой единице трансляции.
Благодаря этим свойствам, начиная с C++17, объявление констант в заголовочном файле стало достаточно тривиальным занятием:
// math.h
#pragma once
inline constexpr double pi{3.14};
Этот заголовочный файл можно подключить к нескольким единицам трансляции — в каждой из них
pi
будет именно константой времени компиляции, и (вишенка на торте) в памяти программы будет создан только один экземпляр pi
. Думаю, программисты, которые помнят, как выглядела работа с глобальными переменными до C++17, на этом моменте выдохнули с облегчением😉 Если по какой-то причине вы до сих пор вынуждены использовать стандарт старше C++17, рекомендую посмотреть вот этот доклад👍6🔥5✍1
Я собрал оглавление из наиболее полезных постов в этом канале и добавил его в закреп. Надеюсь, теперь искать нужную информацию здесь будет намного проще. Enjoy😉
👍7🔥5❤🔥2
Читы vs code. Как передать параметры конфигурации CMake?
Дано. C++ (или C) проект, который собирается с помощью CMake.
Задача. Передать параметры конфигурации CMake. Настройка проекта выполняется через UI vs code.
Решение. В директории с проектом создаем поддиректорию .vscode, а в ней файл settings.json. В файл прописываем следующий конфиг:
Параметры конфигурации пишутся в нотации key:value, префикс -D не используется.
p.s.: в сети можно найти рекомендации передавать параметры через cmake.configureArgs, официальная документация не рекомендует этого делать
#vscode
Дано. C++ (или C) проект, который собирается с помощью CMake.
Задача. Передать параметры конфигурации CMake. Настройка проекта выполняется через UI vs code.
Решение. В директории с проектом создаем поддиректорию .vscode, а в ней файл settings.json. В файл прописываем следующий конфиг:
{
"cmake.configureSettings":
{
"BUILD_TESTING": "ON",
},
}
Параметры конфигурации пишутся в нотации key:value, префикс -D не используется.
p.s.: в сети можно найти рекомендации передавать параметры через cmake.configureArgs, официальная документация не рекомендует этого делать
#vscode
👍3✍2🔥2
Аргументы по умолчанию в виртуальных методах
Для начала попытайтесь ответить на вопрос: что выведет код ниже? Ответ под катом.
Если вы ни разу не встречались с аргументами по умолчанию в виртуальных методах — не расстраивайтесь, вы не одиноки. Я тоже не могу припомнить, чтобы когда-либо с ними работал😞 Давайте разберёмся, почему в обоих случаях вызывается метод , но в первом случае выводится 2, а во втором — 1.
Итак, виртуальные методы могут иметь аргументы по умолчанию — об этом написано здесь .
Прежде всего, стоит запомнить: значения по умолчанию из базового класса не наследуются производными. Выбор значения по умолчанию определяется на основе статического типа, который используется при вызове метода:
- если метод вызывается через объект базового класса, указатель или ссылку на него, используется значение по умолчанию, указанное в базовом классе;
- если метод вызывается через объект производного класса, указатель или ссылку на него, используются значения по умолчанию, указанные в производном классе.
Итого.
В первом случае объект имеет статический тип , поэтому при вызове метода переменная будет иметь значение из производного класса;
Во втором случае метод класса вызывается через указатель на базовый класс (а указатель имеет статический тип ), поэтому переменная будет иметь значение из базового класса.
Для начала попытайтесь ответить на вопрос: что выведет код ниже? Ответ под катом.
#include <iostream>
#include <memory>
class Base
{
public:
virtual void foo(int var = 1)
{
std::cout << "Base::foo(): var: " << var << '\n';
}
};
class Derived: public Base
{
public:
void foo(int var = 2) override
{
std::cout << "Derived::foo(): var: " << var << '\n';
}
};
int main()
{
Derived derived;
derived.foo();
std::unique_ptr<Base> derivedPtr{ std::make_unique<Derived>() };
derivedPtr->foo();
}
Derived::foo()
Итак, виртуальные методы могут иметь аргументы по умолчанию — об этом написано
Прежде всего, стоит запомнить: значения по умолчанию из базового класса не наследуются производными. Выбор значения по умолчанию определяется на основе статического типа, который используется при вызове метода:
- если метод вызывается через объект базового класса, указатель или ссылку на него, используется значение по умолчанию, указанное в базовом классе;
- если метод вызывается через объект производного класса, указатель или ссылку на него, используются значения по умолчанию, указанные в производном классе.
Итого.
В первом случае объект
derived
Derived
foo
var
2
Во втором случае метод
foo
Derived
Base
var
1
👍6🔥6❤🔥1
Что работает быстрее — std::lock_guard или std::scoped_lock?
Ответ: в случае захвата одного мьютекса их производительность идентична, потому что код реализации
Что использовать?
Ответ: в случае захвата одного мьютекса их производительность идентична, потому что код реализации
std::lock_guard
идентичен коду специализации шаблонного класса std::scoped_lock
для одного мьютекса.Что использовать?
std::lock_guard
добавлен в C++11, std::scoped_lock
— в C++17. Если у вас нет требования к совместимости кода со старыми версиями компиляторов или более ранними стандартами, то рекомендуется использовать std::scoped_lock
👍5🔥4✍2
Какие недостатки есть у std::make_shared?
1. Проблемы с освобождением памяти
2. Невозможность использования custom deleter
3. Отсутствие поддержки массивов
До C++20
4. Потенциальные проблемы с производительностью
Единый блок памяти может привести к false sharing: два или более потока обращаются к разным данным (в нашем случае это control block и данные объекта), расположенным в одной cache line процессора, это приводит к инвалидации кеша, процессор вынужден синхронизировать cache line между ядрами.
5. Нельзя использования с приватными конструкторами
Просто неприятный факт:
6. Проблемы при использовании перегруженных operator new и operator delete
1. Проблемы с освобождением памяти
std::make_shared
выделяет память для объекта и control block в одном блоке. Это приводит к тому, что память объекта не может быть освобождена до тех пор, пока существуют std::weak_ptr
, даже если все std::shared_ptr
уже уничтожены2. Невозможность использования custom deleter
std::make_shared
не позволяет указать собственный deleter3. Отсутствие поддержки массивов
До C++20
std::make_shared
не поддерживал массивы4. Потенциальные проблемы с производительностью
Единый блок памяти может привести к false sharing: два или более потока обращаются к разным данным (в нашем случае это control block и данные объекта), расположенным в одной cache line процессора, это приводит к инвалидации кеша, процессор вынужден синхронизировать cache line между ядрами.
5. Нельзя использования с приватными конструкторами
Просто неприятный факт:
#include <memory>
class A
{
public:
static std::shared_ptr<A> create()
{
return std::make_shared<A>(); // Ошибка сборки!
// return std::shared_ptr<A>(new A); // Соберется без проблем
}
private:
A() = default;
};
int main()
{
const auto a = A::create();
}
6. Проблемы при использовании перегруженных operator new и operator delete
std::make_shared
игнорирурет перегруженные operator new
и operator delete
#include <memory>
#include <iostream>
class A
{
public:
void* operator new(size_t)
{
std::cout << __func__ << '\n';
return ::new A();
}
void operator delete(void* a)
{
std::cout << __func__ << '\n';
::delete static_cast<A*>(a);
}
};
int main()
{
const auto a = std::make_shared<A>(); // игнорирует перегрузку
// const auto a = std::shared_ptr<A>(new A); // использует перегрузку
}
❤🔥5👍3🔥3🤔1
Что выбрать: деньги или опыт?
Ответ на один из популярных вопросов от моих студентов.
Кратко: деньги.
Развёрнуто — ниже.
Надеюсь, у меня получилось разбудить в тебе бурю эмоций, ведь мы «пишем код, прежде всего, потому что нам это приносит удовольствие». Но также я надеюсь, что ты уже достиг той точки взросления, когда начинаешь понимать: ответ на любой вопрос зависит от множества факторов. И да, в одной ситуации нужно выбрать деньги, а в другой — опыт. Что ж, попытаюсь порассуждать, что и когда стоит выбирать.
Нужно ли думать о деньгах
Банальный факт, который почему-то отвергается многими: нам нужны деньги для того, чтобы закрыть свои базовые потребности (еда, лечение, жильё). Увы, базовые потребности стоят очень много (просто посмотри на цены квартир в твоём регионе).
Увы #2 — вероятность того, что кто-то из работодателей закроет твои базовые потребности (в смысле — подарит тебе квартиру), стремится к нулю. Поэтому специалист работает за деньги не потому, что он алчный и жадный, а потому что он стремится к нормальному уровню жизни и стабильности.
Обесценивание денег
Деньги обесцениваются — отрицать это глупо. Получая 300к пять лет назад в Москве, можно было позволить себе ипотеку, машину, отдых, макбук, айфон и прочие радости жизни. Сейчас с этими же деньгами можно просто жить, снимать жильё и копить на новостройку где-нибудь в Подмосковье. Не думаю, что эта тенденция изменится.
Поэтому из вариантов:
- устроиться стажёром в 2025 году за 70к и 2–3 года расти до синьора в рамках одной компании
или
- устроиться джуном в 2025 году за 100к и каждый год менять работу с x2 по зарплате
я бы рекомендовал второй вариант.
Человек очень хрупок
У всех по-разному, но у большинства моих знакомых промежуток жизни, когда здоровье позволяет вкалывать и вывозить нагрузки, оказался очень коротким. К 30 у многих организм начал "сыпаться": строгий режим питания, таблетки, постоянные походы к врачам или даже операции — всё это отнимает время, силы и мотивацию. С определённого возраста ты просто перестанешь одновременно «вывозить» и рабочую нагрузку, и бесконечное самообразование.
А тебе точно не надоест писать код?
Некоторые мои знакомые разработчики, ушедшие из отрасли, рассказывали одну и ту же историю:
"Я проснулся с утра и понял, что выгорел. Я не хочу больше писать код, сидеть на дейликах и фиксить баги."
Увы (или к счастью) — это реальность, которая может настигнуть каждого из нас.
И теперь вопрос: пригодились ли им в их новой деятельности, не связанной с IT, знания Boost, низкоуровневой оптимизации или многопоточности?
Крутой специалист != высокооплачиваемый специалист
В эту истину упорно отказываются верить многие:
"Я подучу умные указатели и пойду на собес",
"Я поработаю ещё полгода — и точно попрошу повышение",
"Я закрою ещё один проект — и тогда моё резюме будет нарасхват".
Нет, нет и ещё раз нет. Умение продавать себя слабо связано с технической грамотностью и количеством лет опыта. Без шуток — специалиста с 10+ годами стажа могут оценить так же, как и вчерашнего выпускника.
Так что же теперь — думать только о деньгах, учить только то, что нужно для собесов, и менять работу, как только предлагают чуть больше зп?
Нет. Есть моменты, когда действительно не стоит думать только о деньгах. Эти и некоторые другие ситуации я разберу в следующей части поста😉
До встречи!
Ответ на один из популярных вопросов от моих студентов.
Кратко: деньги.
Развёрнуто — ниже.
Нужно ли думать о деньгах
Банальный факт, который почему-то отвергается многими: нам нужны деньги для того, чтобы закрыть свои базовые потребности (еда, лечение, жильё). Увы, базовые потребности стоят очень много (просто посмотри на цены квартир в твоём регионе).
Увы #2 — вероятность того, что кто-то из работодателей закроет твои базовые потребности (в смысле — подарит тебе квартиру), стремится к нулю. Поэтому специалист работает за деньги не потому, что он алчный и жадный, а потому что он стремится к нормальному уровню жизни и стабильности.
Обесценивание денег
Деньги обесцениваются — отрицать это глупо. Получая 300к пять лет назад в Москве, можно было позволить себе ипотеку, машину, отдых, макбук, айфон и прочие радости жизни. Сейчас с этими же деньгами можно просто жить, снимать жильё и копить на новостройку где-нибудь в Подмосковье. Не думаю, что эта тенденция изменится.
Поэтому из вариантов:
- устроиться стажёром в 2025 году за 70к и 2–3 года расти до синьора в рамках одной компании
или
- устроиться джуном в 2025 году за 100к и каждый год менять работу с x2 по зарплате
я бы рекомендовал второй вариант.
Человек очень хрупок
У всех по-разному, но у большинства моих знакомых промежуток жизни, когда здоровье позволяет вкалывать и вывозить нагрузки, оказался очень коротким. К 30 у многих организм начал "сыпаться": строгий режим питания, таблетки, постоянные походы к врачам или даже операции — всё это отнимает время, силы и мотивацию. С определённого возраста ты просто перестанешь одновременно
А тебе точно не надоест писать код?
Некоторые мои знакомые разработчики, ушедшие из отрасли, рассказывали одну и ту же историю:
"Я проснулся с утра и понял, что выгорел. Я не хочу больше писать код, сидеть на дейликах и фиксить баги."
Увы (или к счастью) — это реальность, которая может настигнуть каждого из нас.
И теперь вопрос: пригодились ли им в их новой деятельности, не связанной с IT, знания Boost, низкоуровневой оптимизации или многопоточности?
Крутой специалист != высокооплачиваемый специалист
В эту истину упорно отказываются верить многие:
"Я подучу умные указатели и пойду на собес",
"Я поработаю ещё полгода — и точно попрошу повышение",
"Я закрою ещё один проект — и тогда моё резюме будет нарасхват".
Нет, нет и ещё раз нет. Умение продавать себя слабо связано с технической грамотностью и количеством лет опыта. Без шуток — специалиста с 10+ годами стажа могут оценить так же, как и вчерашнего выпускника.
Так что же теперь — думать только о деньгах, учить только то, что нужно для собесов, и менять работу, как только предлагают чуть больше зп?
Нет. Есть моменты, когда действительно не стоит думать только о деньгах. Эти и некоторые другие ситуации я разберу в следующей части поста😉
До встречи!
👍14🔥8❤🔥3💯1