Лаборатория Математики и Программирования Сергея Бобровского – Telegram
Лаборатория Математики и Программирования Сергея Бобровского
1.29K subscribers
1.18K photos
24 videos
929 links
ЛаМПовое с Бобровским
Download Telegram
Как программисту зарабатывать побольше денег? Средняя зарплата программистов в России в нонешнем году, по данным ведущих сайтов по работе, около 90 тыс. руб. Но совсем не обязательно, что вы будете зарабатывать именно столько. Знаю немало ребят, которые получают 50-70 тыс., но немало и таких, кто за 300т. получает.

Так что же определяет, сколько денег вы будете зарабатывать как программист?

Это вообще не про то, сколько у вас лет опыта, не про то, насколько вы хороши как программист. Тут есть три принципиальных скилла, которые вы должны непрерывно тренировать.

1) Насколько хорошо вы умеете себя продвигать. Вот почему постоянно делаю акцент на софт-скиллах, рекомендую создать и постоянно развивать блог и гитхаб, постоянно улучшать себя как программиста так, чтобы об этом знало как можно больше других людей. Это не даст эффекта сегодня или завтра, или даже через год (а может, и даст), но это даст потрясающий эффект через 3-5-10 лет.

2) Насколько хорошо вы умеете себя продавать. Речь о том, насколько успешно вы способны проводить переговоры о зарплате на собеседованиях и аттестациях, продавая ваше время и ваши навыки. Тут буквально две дополнительные минуты правильных переговоров могут вам дать дополнительно многие десятки тысяч рублей каждый год. На эту тему готовлю в рамках курса карьеры цикл "Бесстрашные переговоры о зарплате", пошаговые сценарии таких переговоров. Вам ничего не надо выдумывать, достаточно просто следовать скрипту и повторять заученные фразы -- профит! :)

3) Насколько широко и насколько активно вы ищете работу. Чем больше компаний, в которые вы обращаетесь в поисках работы, тем выше вероятность того, что у вас будет выбор и вы сможете договориться о более высокой зарплате.
Только эти обращения, конечно, не надо понимать как механический спам своим резюме, это самый зашквар, не надо так. На курсе карьеры подробно поясняю, как правильно.
Обратил случайно внимание, вроде бы официальный заголовок referer в запросе HTTP написан с грамматической ошибкой (правильно же referrer). Действительно, оказывается, он попал когда-то в стандарт с опечаткой, и ради обратной совместимости так и сохранился навсегда.
И таких примеров в ИТ полно.
Разработка софта -- это когда мы принимаем решения, которые нельзя отменить и которые должны поддерживаться вечно.
Поэтому крайне важно тренироваться в проектировании программных систем прежде всего на абстрактном уровне формальных спецификаций, чтобы обязательно можно было утверждать (в идеале -- доказать), что каждая его подсистема, каждый компонент корректен сам по себе, независимо от всей остальной программы, даже если в целом программа прошла все виды тестирования и соответствует внешним требованиям на данный момент.
Но что с ней случится завтра, когда начнём добавлять в неё новые фичи и улучшать существующие?
Лаборатория Математики и Программирования Сергея Бобровского pinned «Обратил случайно внимание, вроде бы официальный заголовок referer в запросе HTTP написан с грамматической ошибкой (правильно же referrer). Действительно, оказывается, он попал когда-то в стандарт с опечаткой, и ради обратной совместимости так и сохранился…»
Эта строчка в некотором смысле изменила мир программирования лет 20 назад :)

i = 0x5f3759df - ( i >> 1 );

Причём она годами скрывалась в исходниках графического движка Quake 3 Arena, реально это уровень PhD.

Не знаю, сам ли Кармак её написал, очень возможно, ну фишка в том, что пришёл такой в офис, подумал над очередной эпической мировой проблемой пару часиков, выпил кофейку, скромно зафигачил в проекте очередной подвиг, и продолжаешь кодить на таком же космическом уровне дальше.

Это суперскоростное вычисление "1 / корень из x" по IEEE 754.
Довольно часто (очень часто) разработчиков нанимают за то, что они умеют на данный момент, "здесь и сейчас", а на их потенциал менеджерам пофиг :)

Однако как разработчик вы можете расти только в том случае, если будете решать проблемы, в которых вы (пока) не компетентны.

Поэтому, где бы и над чем бы вы ни работали, всегда думайте прежде всего о своих собственных интересах, затем -- об интересах своей семьи, и только потом об интересах компании. И именно в такой схеме, что интересно, интересы компании будут удовлетворяться куда полнее, чем нежели чем-то личным ради неё жертвовать тактически, проигрывая в профессии стратегически.
Очень поучительно, про "хрупкость" языков программирования (насколько легко собранная на некотором языке программа переносится между разными компьютерами).
https://cancel.fm/blog/2019-11/language-fragility/

Весь мэйнстрим (Java, C#/.NET, Python, JavaScript) -- самое дно :)
Впрочем, совершено не удивлён.
Топчик из популярных -- только Go.

Си/С++ и Rust на вторых местах.
Про качественную разницу между фундаментальными знаниями и хрупкими знаниями.

Когда отключат интернет, вы сможете так же продуктивно программировать, как сейчас? :)
Следующий вопрос на собеседованиях, к которому вы тоже абсолютно точно должны как следует подготовиться, это "какой самый большой опыт вы получили из последних проектов?".
Ну или "какое ваше самое большое достижение в программировании?" -- только не отвечайте вот так )))

Этот вопрос в частности позволяет интервьюеру понять, что вы на самом деле делали на вашей последней работе :)

Вам надо продемонстрировать, что вы не просто тупо и однообразно фигачили код, а постоянно развивались, росли над собой :) Вам надо подтвердить, что то, что вы понаписали в резюме, реальность, а не выдумка.

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

Что самое важное вы узнали на вашей последней работе, или
какое было ваше самое эпическое достижение в ваших предыдущих проектах, и т. п.

Такие вопросы задаются часто, поэтому важно, чтобы вы подумали об этом и подготовились как следует.

Это опять прекрасная возможность хорошо продать некоторые ваши навыки: рассказывайте не только о технических успехах, но и демонстрируйте ваши софт-скиллы -- как успешно вы помогали команде в целом, как поддерживали её дух в трудные минуты :)

Упоминайте свои сильные стороны, привязывая их к текущей вакансии -- объясняйте, почему вы считаете. что вы готовы к данной работе именно благодаря тому, чему вы научились в прошлом, и как это невероятно мощно поможет этой вашей новой потенциальной команде, если вас наймут :)
В Формуле-1 за лидерство последние 20 лет бьются три команды -- Mercedes, Red Bull и Ferrari. Другие иногда пытаются с ними конкурировать, но получается редко и случайно.

Сермяга в том, что если вы не будете выступать за одну из этих топовых команд, вы никогда не победите. И неважно, насколько вы хороши, насколько хорош ваш болид. Если вы не будете выступать за них, у вас нет шансов на победу.

Нечто подобное происходит и в ИТ-компаниях, особенно в стартапах.

Вы можете расти, расти, расти, а потом бах -- и всё прекращается. Вы не растёте. Вам больше нечего решать. Нет сложной задачи. Нет нового вызова.

Может быть, сам стартап не может расти или не хочет расти; может быть, он растёт вширь, а не вглубь. Что бы это ни было, в таком случае вы сами больше не сможете расти, дорогие.

Пришло время менять команду на чемпионскую.
Классный ресурс
https://hyperpolyglot.org/
Поэлементное сравнение разных языков программирования и разных программистских инструментов, которые сгруппированы по схожести.
Оч. наглядные сравнительные таблички по семантике, грамматике и др., очень удобно, если знаешь один язык, и хочешь быстро перейти на другой.
Просмотрел задачки "Российские школьники завоевали четыре золота на Европейской олимпиаде юниоров по информатике (EJOI 2021)".

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

Задачи не чисто программистские, почти везде нужно какое-то математическое мышление в плане оптимизации именно алгоритмов, а не кода. Вот именно такие ребята потом и станут топовыми разработчиками в лучших компаниях мира. Вчера как раз в обзоре книги "Радость познания" физика Ричарда Фейнмана писал, почему лучшим программистам надо развивать не репродуктивное, а продуктивное мышление, которое лучше всего тренируется математикой.

Всего 6 задачек, скачать можно тут (есть на русском)
если их отсортировать по "больше математики — больше программирования", примерно так выходит:
BinSearch, Xcopy, Waterfront, Kpart, Addk, Dungeons.
Хотя оптимизацией везде фактически надо заниматься. Dungeons очень хороша, обожаю roguelikes, кодил когда-то много подобного.
Как за пару часов изучить любую веб-технологию?
Через хорошее практическое знание и понимание пяти фундаментальных вещей, на которых базируется веб-разработка:
1. Работа в браузере с DOM (Document Object Model).
2. Асинхронное выполнение.
3. Триггеры свойств/данных/событий.
4. Обмен клиента с сервером (туда-сюда) через HTTP.
5. Управление состояниями UI.
Есть ли какая-то универсальная метрика, по которой можно быстро оценить качество хороших программистов, например, в компаниях уровня Google, Amazon, Microsoft? Строки кода в час, реализованные фичи в джире, скрамовские сторипоинты, какие-то ещё?

Строки кода легко считаются, но ничего не значат.
Фичи много значат, но их невозможно подсчитать по единому критерию.
Сторипоинты слишком развлекательны, как kings bounty.

Так вот, в FAANG на самом деле используют универсальную секретную метрику, которая называется fff/f

Расшифровывается fff/f как fault-free features per fortnight -- число фич без багов, которые прогер выкатил в продакшен за две недели.

Произносится fff/f как "Стэнфорд".

Разработчик, работающий в темпе 1.62 стэнфорда, считается норм.
Разработчик, недотягивающий до 1.62 стэнфорда, лишается привилегии ставить свою машину на бесплатной корпоративной парковке.
Разработчик, превзошедший 1.62 стэнфорда, становится продакт-менеджером.

P.S. это шутка была, а то тут меня вопросами засыпали )))
Однажды N лет назад, я сидел как обычно в своей комнате за компом, реализовывал очередную фичу, не помню уже, на C# или Python, зашла жена и почему-то заглянула с интересом в мой экран. У меня шёл классический рабочий процесс: в браузере традиционно открыты десятки закладок -- обсуждения разных тем на stackoverflow, сайты с документацией, примеры на гитхабе, результаты поиска в гугле и т. п. и т. д.

Она с удивлением спросила:

-- Серый, а что это ты делаешь?

Я сам слегка удивился её интонации и пояснил, что работаю как обычно над очередной проектной фичей (по-моему, разбор телеметрии с автомобильной CAN-шины).

-- Но разве ты не жульничаешь? -- широко раскрыла она глаза.

-- В смысле? -- я вообще растерялся.

-- Ты смотришь кучу разных сайтов с подсказками, но разве ты не должен разобраться в этом сам?

Я не знал, что ей ответить. Она умная женщина (учительница началки с кучей грамот, множество её малышей побеждали на разных конкурсах и олимпиадах), и идея использовать чужой труд вот таким вот образом была ей глубоко чужда.

-- Ну, это вот документация... а это примеры, как некоторые люди делают это, определенным оптимальным образом, и многие делятся своими успешными способами, и таким образом все как бы выигрывают... в некотором смысле... -- начал я оправдываться.

-- Хмммм... обманщики.... -- только и сказала она.
Седьмая привычка Стивена Кови в книге "Семь привычек высокоэффективных людей" -- "точить пилу", что означает, что нужно регулярно тратить время на то, чтобы становиться лучше и совершенствовать себя. Это краткая мудрость, которую большинство разработчиков игнорирует: "у меня нет времени точить пилу -- я должен пилить!" )))

Основной принцип eXtreme Programming заключается в том, что всё постоянно меняется. Технологии, инструменты, процессы и люди постоянно развиваются и порой меняются внезапно и радикально. Если мы не будем постоянно заниматься профессиональным самосовершенствованием, эти изменения нас раздавят, и мы будем в лучшем случае неэффективными, а в худшем -- унылыми легаси-кодерами.
И то, и другое -- гарантированные убийцы карьеры в наше гиперконкурентное время.

Вашему космическому директору очень хочется регулярно получать бонусы с семью нулями, а владельцу вашего стартапа -- регулярно катать на Канары с гаремом любовниц, и они с радостью заменят всю вашу "уникальную" команду на любую другую из множества более дешевых альтернатив... особенно если энергичные голодные конкуренты с толпой дешёвых джунов, готовых пилить по 100 часов в неделю за копейки и "за опыт", смогут привести весомые аргументы в пользу своей производительности.

Поэтому настоятельно рекомендую тратить хотя бы два часа в неделю на изучение чего-то нового в вашей области разработки. Узнавайте немного больше об инструментах, которые вы применяете, чтобы задействовать хорошие фичи, с которыми вы ещё не познакомились. Делайте небольшие законченные проекты по схеме "один проект -- одна новая технофишка". Каждый месяц прочитывайте не менее одной технической книги.
Очередной оч. частый вопрос на собеседованиях, к которому вам нужно подготовиться абсолютно точно, и это технический вопрос, это очень конкретный вопрос: "поясните плюсы и минусы фреймворка/технологии, которая используется в нашем проекте, и которую вы (возможно) будете использовать".

Например, плюсы и минусы Node.js :)

Плюсы и минусы Django, плюсы и минусы Spring/Hibernate, MySQL, PyTorch...

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

Но плюсы и минусы часто упускаются из виду, хотя легко гуглятся очень даже профессиональные сравнительные обзоры (не говоря уж о википедии), и люди просто начинают мямлить: "нуммм, мда, я мпрограммирую на Java, я использую мноду...".

На самом деле они просто не знают объективных плюсов и объективных минусов, и когда пытаются что-то сформулировать, то говорят что-то вроде: "ну, java это объектный язык... node.js это реактивный веб-сервер...".

Всегда чётко знайте по 2-3 плюса и минуса любой без исключения фичи из вашего резюме.
Риторический вопрос: почему программистам так много платят, ведь их работа весьма лёгкая и при этом весьма интересная, и даже печеньки выдают бесплатные (я сам всю жизнь работал программистом, и да, это всегда было довольно легко и увлекательно :) ?
Чтобы стать в ИТ успешным, надо работать прежде всего не тактически -- внутри своей карьеры, а стратегически -- над своей карьерой.

Внутри своей карьеры вы решаете типовые проблемы на работе, и если встречаются такие, которые вы не решали раньше, вы немного растёте, но не сильно. В следующий раз вы просто решите их быстрее.

Это в целом улучшает вашу карьеру, но ненамного. Выгодно это вам на 20%, а вашему работодателю на 80%.

Если же вы хотите улучшить свою карьеру намного, вы должны работать над своей карьерой. Вы должны делать работу, которая умножает ценность прежде всего вас самих в ИТ глобально, а не только вашу рабочую ценность и ценность вашего окружения внутри одной небольшой команды.
Это должно быть уже не столько непосредственное написание кода, сколько мета-деятельность -- регулярный блог, аккуратный и активно развиваемый гитхаб, комиты в известные проекты, активное участие в конференциях etc
Как вам как программисту получить повышение/прибавку?

1. Спросите своего тимлида/менеджера/нач.отдела, что конкретно вам нужно сделать (чему научиться, чего добиться...), чтобы получить повышение в должности или прибавку к зарплате, и в какой срок?

2. Попросите его прислать вам ответ по электронной почте или в корпоративном чате.

3. Пашите.

4. За месяц до окончания срока напомните тимлиду, что близится время повышения вашей зарплаты. Покажите в доказательство его оригинальное письмо и все-все-все документы/комиты/тикеты, объективно подтверждающие, что вы действительно добились и теперь полностью соответствуете всем критериям повышения.
Однажды Каспаров давал сеанс одновременной игры со 100 шахматистами. На одной доске он забрал ферзя, и игрок сказал: "вы скушали моего ферзя, я думаю, что теперь проиграю" :)

Каспаров ответил: "ты проиграл, едва только сел играть со мной".
Каспаров вообще не сомневался, что выиграет.

Это отличный критерий знания вами какой-то темы: когда вы в ней действительно хороши, вы просто будете знать, что у вас всё получится, ещё до того, как начнёте, у вас вообще не будет никаких сомнений.

Я например абсолютно уверен, что могу спроектировать и запрограммировать любую игру, любой сложности. Почему именно игру? Потому, что вообще разработка игр (особенно реального времени) -- пожалуй самое трудное, сложнее разве что всякие embedded-системы, программно-аппаратные комплексы, но это довольно специфическая область сама по себе. В современных онлайн-играх сотни тысяч запросов в секунду не редкость, и ведь это моделируется сложный физический мир (хотя в 3D-шутерах сервак грузится в основном тем что коллизии считает :). В сравнении с тем же WoW бизнес-проекты смотрятся как детский сад. На гитхабе например пиковая нагрузка всего 55k rps, да и логика примитивная.

А главное, что абсолютно уверен, что могу обучить этому всему любого мотивированного миддла.

Сомневаюсь же пока например, что смогу доказать на каком-нибудь прувере (вроде Lean) первую теорему об изоморфизме с помощью гомотопической теории типов. Но это временно.

Найдите тот уровень в программировании, в котором вы абсолютно уверены, что справитесь, и неважно насколько он высок или низок (написать простую консольную игру или клон kings bounty; перерешать все задачки из "Cracking the Coding Interview" или с codeforces.com; ...).

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

Так что вы можете просто придти на работу в один прекрасный день, и сесть писать идеальный код, но колесо судьбы уже остановилось на вашем ID, и они случайным образом выбрали именно вас, и решили вас уволить и взять на вашу позицию кого-то другого с меньшим окладом, кто не справляется с работой даже близко к вашему классному уровню.

Но, всем пофиг.

Гарантий нету нигде и никогда не будет. Вот почему так важно непрерывно развивать свои навыки программиста за пределами текущих рабочих обязанностей, и всегда иметь несколько (а лучше много) вариантов трудоустройства про запас.

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

У вас всегда будут подобные проблемы просто потому, что на самом деле совершенно неважно, насколько вы хороши как специалист в техническом плане.

Вы должны регулярно, всю жизнь развивать блог, зеркалить его в соцсетях, прокачивать гитхаб, вести канал на ютубе, или в инсте, или даже в тiктоке (извините). Эти каналы будут автоматически продвигать вас, будут рассказывать другим людям, кто вы есть и что хорошего вы реально умеете делать -- чтобы в случае любых траблов на текущей работе вы могли бы получить новую хорошую работу немедленно.