Коротенько о зарплатах в Европе

Есть один товарищ, ex-разработчик, ex-Microsoft, ex-Uber. Но не из долины, а местный, европейский. У него классный блог про всякие engineering management темы. И, в частности, про зарплаты.

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

Суть простая: есть три лиги tech компаний. Классификация происходит по локализации рынка труда! Локальные компании конкурируют за специалистов (читай разработчиков) в своем городе. И такие локальные специалисты мигрируют из одной такой локальной компании в другую. Региональные компании конкурируют со всеми локальными, а также другими крупными игроками в их регионе/стране. Ну а глобальные готовы перевозить специалистов из других стран/континентов.

Зарплаты в каждой лиге отличаются в разы! Если принять за x1 зарплату разраба в локальной компании, то в региональной она будет x2. А в глобальной - от x3 до x10 и выше.

NB: x1 в Западной Европе это где-то 50-60K EUR в год.

Конечно, требования к специалистам отличаются в разных лигах. И уровень стресса, видимо, тоже. Но не думаю, что прямо в 10 раз... Как человек, прошедший путь от локальной, до около-глобальной компании говорю =) Так что каждый должен решить для себя, в какой лиге ему играть.

https://blog.pragmaticengineer.com/software-engineering-salaries-in-the-netherlands-and-europe/

P.S. Полагаю, что в некотором приближении такая модель верна для всего IT рынка труда, включая СНГ.

Rust увлечен идеей четкого владения данными. Вы начинаете со значения в стеке и перемещаете его. Когда вам нужно получить доступ к значению из нескольких мест, вы его копируете. Если копирование слишком дорого или неуместно, вы начинаете использовать ссылки. Ссылки могут быть ограничены сроком службы. Когда ансамбль времени жизни становится слишком сложным или невозможным для статического выражения, вы начинаете помещать свои значения в кучу и передавать указатели. Наиболее часто используемые типы указателей - это Box <T> и Rc <T>. Сами указатели являются переменными стека и, следовательно, подчиняются одному и тому же принципу владения. Box единолично владеет значением, на которое он указывает, поэтому мутации упрощаются. Rc обеспечивает долевое владение. С точки зрения компилятора, совместное владение означает отсутствие изменений. Если вам нужно изменить общее значение, компилятор вам больше не поможет. Вы отказываетесь от статического доказательства правильности и обманываете компилятор с помощью Rc<RefCell<T>>. RefCell обеспечивает фиктивную неизменяемость во время компиляции и позволяет получать изменяемую ссылку во время выполнения. Но за магию всегда есть цена! (c) Цена RefCell - паника во время выполнения, когда вы случайно получаете две изменяемые ссылки на одно и того же значение.

Мне определенно нравится качество этого перевода. Google Translate rules!

P.S. скоро допишу очередную дилетансткую статью по Rust'у

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

https://habr.com/ru/company/timeweb/blog/558612/

Картиночки подвезли

https://twitter.com/iximiuz/status/1402315573766328322?s=21

И еще одна полезная штука для тех, кто много зависает в Grafana (видео)

https://twitter.com/iximiuz/status/1402357757794205699

Немножечко пятничной саморефлексии - про прокачку технических скилов

https://twitter.com/iximiuz/status/1403430327226359816?s=21

P.S. Саморефлексия - какое-то странное слово. Попахивает тавтологией.

Новые картиночки про Prometheus - правила матчинга векторов.

https://twitter.com/iximiuz/status/1404118335227375620?s=21

Игрек - если задуматься, звучит очень странно. Но я первые 25 лет не задумывался, а потом перестал практиковать математику на русском языке. И вот на 4м десятке мне вдруг довелось узнать, что игрек - это «И греческая», она же Y... Наконец-то это слово обрело для меня смысл!

Похоже, вопросы классификации и этимологии заботят меня больше всего на свете. Поэтому, вот вам два твита про DevOps vs SRE. Лучшее, что я видел по этому поводу since forever.

https://twitter.com/tambryantbutow/status/1405158127369129989

Два месяца жизни!

https://twitter.com/iximiuz/status/1407980970817490945

Проголосуйте, плиз!

https://twitter.com/iximiuz/status/1410331066112557068

Ещё месяц жизни и я готов поделиться с сообществом новой версией pq

https://twitter.com/iximiuz/status/1413191642761371655?s=21

Разоткровенничался тут

https://iximiuz.com/en/posts/my-choice-of-programming-languages/

И опять делюсь личным опытом. Про разницу между Dev, Ops и SRE, как я ее вижу после двух лет работы не девелопером.

https://twitter.com/iximiuz/status/1421435412157972480?s=21

Сорри, не могу этим тут не поделиться. Енот из каждой строчки - это я в 2019, 2020, и 2021 соответственно.

https://twitter.com/memenetes/status/1423388601056997377?s=21

Как вы знаете, я любитель порисовать всякие диаграммки. Написал тут статью на днях про контейнеры, где в частности упомянул Kata Containers как пример реализации контейнеров на виртуалках. И тут мне подбросили вот это... Сразу две находки в одной ссылке!

Во-первых, это наикрутейшее визуальное объяснение как Kubernetes может запускать Pod-ы внутри выделенных легковесных виртуалок. А во-вторых, это сам сервис, где эта диаграмма размещена! Зацените, какой крутой инструмент для обучения можно получить всего за $4 в месяц! И нет, это не реклама.

Поделюсь еще и тут - я созрел для собственной email-рассылки. План - делать подборку моих самых удачных постов из блога и твитера за прошедший месяц, и, заодно, делиться планами на будущее. Конечно же, на мои классические темы - контейнеры, кубернетисы, линукс и кодотворчество. И, по возможности, с картинками.

Подписаться можно тут. А вот здесь можно посмотреть первый выпуск.

И снова минутка занимательной этимологии.

С давних пор в моей голове не мог уложиться вариант использования слова copy для обозначения оригинального кусочка текста. Все эти copywriters - они ведь не копируют ничего, напротив - им платят за уникальные тексты. И вот это - "ты должен уметь copy, чтобы стать успешным твиттероводом", подразумевающее, что тексты твитов должны быть короткими, понятными и цепляющими. Wtf?

И как это всегда бывает, ответ оказался на расстоянии вытянутого запроса в Google (который я откладывал примерно 10 лет).

Перефразирую тут для коллег-программистов - каждый раз, когда слово copy используется не в значении дубликат, его можно смело заменять на интерфейс copyable. Т.е., самый первый copy - это то, что потом размножат и покажут массам. Условный копирайтер пишет исходных экземпляр такого copyable текста, а затем его тиражируют на билбордах, сайтах, соц. сетях и т.п. Такой вот исторический каламбур из мира книгопечатания с латино-францускими корнями.

Какое-то время назад я подписался на рассылку Matt'а Rickard'а. Matt разрабатывал Kubernetes в Google (вероятно именно так я и натолкнулся на его профиль), и это не единственное его достижение. Но рассылка не об этом. Вот уже полгода Matt каждый день публикует мини-статьи... обо всем. Это может быть технология разработки софта, или обзор современных бизнес моделей в IT, или забавная история про эволюцию CPU. Кругозор этого товарища просто поражает, но самое главное - его идеи оригинальные, а не просто ретрансляция новостей мира технологий.

Из сегодняшнего выпуска:

GitHub's Missing Package Manager

GitHub has the opportunity to streamline and secure the package management layer. Here's how.

GitHub is the system of record for code. But the company rarely takes advantage of this. GitLab, on the other hand, has used this fact to build out products that span the entire software development lifecycle. But GitHub's strength is the sheer amount of public projects it has – projects that end users consume mostly through package managers.

How does it work today?

...

И этот мой твит - тоже про него 🙈