Обратил случайно внимание, вроде бы официальный заголовок 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ктоке (извините). Эти каналы будут автоматически продвигать вас, будут рассказывать другим людям, кто вы есть и что хорошего вы реально умеете делать -- чтобы в случае любых траблов на текущей работе вы могли бы получить новую хорошую работу немедленно.