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

Интересное наблюдение, что плавно переучивать людей переходить к более продвинутым парадигмам программирования практически невозможно. Рассуждаешь о формальной логике приложения, как её "запрограммировать" на HoTT, а человек не хочет отрываться от примитивной императивщины, даже в ООП правильно не хочет проектировать, абстрактными (даже не алгебраическими) типами данных, не говоря уж о ФП. Ты изучил сотни книг по математике и computer science, а человек смотрит программирование (смотрит! программирование!) на ютубе и не читает вообще.

Мудрецы кстати в таком случае рекомендуют не плавный переход, а резкую смену вообще всего контекста, всей парадигмы. Не вымучивать плавное использование LINQ в C# или functools в Python, а сразу принудительно заставлять писать код исключительно на F# например. В университетах уровня Оксфорда кстати так и делают прямо с первого курса.

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

Смартфоном компании S пользуются миллиарды людей, однако у самой S почти нулевая власть, потому что они не могут влиять на тех, кто использует их смартфоны.

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

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

Но это совсем не так. Тикток просто передаёт другим, что делают люди, но никак не участвует в создании контента. Реальная власть тиктока случайная, очень неустойчивая и почти нулевая.

Может казаться, что владельцы Facebook или Google невероятно могущественны, но это не так. Реальной властью обладают анонимные инженеры, настраивающие поисковые алгоритмы; математики, разрабатывающие продвинутые AI; программисты, непосредственно кодирующие блокчейны электронных выборов ))) Все остальные просто ходят к ним на поклон. Как например в 8-й серии первого сезона Миллиардеров -- когда вычисляли крота, то космический босс сам пришёл "в серверную" к айтишнику, у которого хранятся все-все-все цифровые ниточки.

И все эти айтишники -- в отличие от всех остальных вроде бы обладающих "властью" в своей конторе -- совершенно не привязаны к этим громким корпоративным именам, в любой момент могут из них уйти; и такая незримая власть самой могущественной в мире секты, огромной пиринговой сети независимых it-анонимусов, связанных профессиональной солидарностью и языком общения, доступным лишь немногим посвящённым, по мере оцифровывания мира, стремительного роста числа балбесов :) и движения к технологической сингулярности будет только расти и расти.

Сообщать о погоде -- это совсем не то, что создавать погоду.

Создатели погоды существуют, но это совсем не те люди и не те компании, которых мы знаем.

Типичный ньюбский вопрос "почему AAA-игры пишут на C++ а не на Java?", и на него часто дают ньюбский ответ "потому что Java медленнее (нет)", или "потому что Java не умеет работать с графическим процессором (нет)".

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

В Java же единственная реальная проблема в этом плане фактически в том, что в JVM по дефолту есть сборщик мусора, который автоматически очищает память. И для обычного софта это вполне приемлемо, и работает хорошо, но в играх динамически создаётся и уничтожается множество довольно больших объектов. Их детальное описание (ну, вертексы, текстурные координаты...) хранится в больших нативных буферах, которые непосредственно в программе представлены маленькими объектами, содержащими лишь ссылку на эти буферы. И вот сермяга в том, что сборщик мусора не знает, сколько байт реально занимает родной буфер, так как он находится вне зоны компетенции сборщика. Он видит лишь маленький объект, думает, что в памяти всего лишь несколько таких маленьких объектов, и поэтому не вычищает их. А в результате получается OutOfMemoryException, потому что её всю забили здоровенные буферы.

Но есть способы обойти эту проблему (например, созданием специализированных JVM), и для многих задач Java даже превосходит C++. Так, многие игры, написанные на C++, часто падают :) ага, из-за нарушения доступа к памяти, а в Java этого не может произойти в принципе, потому что в ней нету арифметики указателей. Время выполнения благодаря JIT-компилятору иногда даже превосходит время выполнения программ на C++. Ну вот довольно старые тесты, с тех пор Java ещё больше ускорилась: https://stackoverflow.com/questions/145110/c-performance-vs-java-c

Ну и Minecraft написан на Java например, а популярнейший игровой движок Unity3D использует C# в качестве основного языка программирования, а C# очень похож на Java (свой сборщик мусора, байткод, нет указателей...).

Резюме, что язык программирования под проект надо выбирать не из его ТТХ, а из удобства и качества разработки на нём. Соответственно, под Windows/.NET идеальным будет F# для основной логики, например.

Часто спрашивают что почитать при подготовке к собеседованиям, ну прежде всего рекомендую вечную классику "Карьера программиста. Как устроиться на работу в Google, Microsoft или другую ведущую IT-компанию" ("Cracking the Coding Interview: 150 Programming Interview Questions and Answers") Гейл Макдауэлл/Лакман.

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

Потому что знание того, как решать подобные алгоритмические проблемы и как использовать структуры данных и алгоритмы эффективно, действительно очень важно для прохождения собеседований (и да, это может быть совершенно неважно в реальной работе, ну просто вот так устроен мир). Понимаю, что вам не нравится идея писать сложный код на собеседованиях, вам может не понравиться тот факт, что и Яндекс, и Сбер, и Мэйлру, и Microsoft, и Google, и Apple, и многие другие крупные компании используют подобные задачи на интервью, но это не меняет того факта, что вам нужно очень хорошо знать и уметь решать подобные задачи. Если вы хотите пробиться в такие компании, как Яндекс или Google, Мэйлру или Microsoft, вам придется выучить все эти вещи, так что вы можете просто взять эту книгу и изучить на практике то, что в ней рассказано.

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

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

Конечно, вам потребуется определённое время, чтобы пройти все задачи в книге, но почти гарантированно вы сможете проходить интервью, связанные с алгоритмическими темами и навыками решения задачек. Такие интервью характерны прежде всего для крупных компаний МЯСО/FAANG, потому что чем примитивнее компания, тем больше в ней требуется знания всякой технической фигни и веб-фреймворков, и тем менее ценится в ней абстрактное мышление, так как заниматься придётся в основном шаблонной реализацией довольно простых и скучных фич.

Так что эти усилия стоят того, если вы серьёзно настроены получить работу в Яндексе или Сбере или Google, или IBM, Facebook ...

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

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

О чём думает тимлид в течение дня?

- Сколько тикетов за сегодня закроет Олег?

О чём думает Олег в течение дня? (т.н. "обезьяний ум")

- Приехать вовремя на работу к митингу... Как бы смыться с работы пораньше? Как там детишки дома? Когда там у Ленки день рождения? Надо бы вечером на велосипеде покататься... Новенький за соседним столом какой-то странный... Надо бы в обед заскочить в магаз за покупками, едой... Когда кофемашину сменят? Пора детально продумывать маршрут на зимний отпуск и уже заказывать билеты... Интересно, кто у Оксаны новый парень? Надо бы за интернет и телефон заплатить... Пора продумывать планы на выходные...

Смешно: в Кембридже формализовали модель параллельной работы памяти в С++ (!) -- описали семантику многопоточных программ и доказали в Isabelle/HOL корректность процесса компиляции
https://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf

А потом оказалось, что в стандарте C++20 она была внезапно переделана более чем наполовину, и теперь надо начинать всё с нуля.

Вообще, поразительно конечно, какой бардак творится в мировом IT даже на топ-уровне ведущих комитетов по стандартизации :)