Парень начинает работать над новым проектом.

Компания предоставляет ему много времени и ресурсов для улучшения оригинального стека. Он гуру, а у компании есть время и ресурсы. Если он не сможет сделать этот стек продуктивнее, то кто?

Парень изобретает что-то новое.
Проходит 2 года.

Новая оптимизирующая технология снижает стоимость эксплуатации стека на 5% и уменьшает требования к памяти на 2%, и пользователи восторженно рассказывают о том, как всё летает. Большой команде инженеров нравится работать с новым стеком, он великолепен.

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

Молодой программист читает одну из его статей и думает: "Ого! Мне эта технология обязательно нужна на случай, если взлетит мой оригинальный стек".

Цикл повторяется.

=

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

Мои две копейки по поводу "въё* или уё*".
Сколько работал программистом, ещё с середины 1980-х, во всех программистских коллективах всегда были отношения хорошо-отлично, редко когда на три с плюсом. Единичные случаи (причем только в последние лет 10) выпиливался сам либо когда босс забывал, что программисты -- это белая кость :) и начинал вести себя как барин, либо (сам виноват) устраивался в компании где программирование -- не ведущая сфера деятельности, и для основной массы сотрудников действительно действовал режим галеры-концлагерь , который манагеры распространяли и на программистов, которые в итоге регулярно разбегались.

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

Если видите, что бигдата действительно находит низкие KPI -- значит внедряйте чёткие должностные инструкции, и пусть бигдата шлёт напоминалки, предупреждения. Такая мягкая сила отлично действует; периодически консультирую небольшие команды, и в 100% случаев получается обходиться без увольнений, просто организационный процесс надо улучшить, роли грамотно прописать, и т. д. Уверен что в любой конторе 90++% сотрудников вполне можно простимулировать лучше работать именно такими спокойными и рациональными способами.

Я сам вообще трудоголик и не вижу никаких проблем работать разумным темпом и по 12-16 часов 365 дней в году, если соблюдать режим дня (о чём регулярно пишу в тележке в другом канале), но при этом никогда бы не стал принуждать к такому ритму других. Люди действительно выгорают, психологически бывает тяжело в сложных проектах, маленькие зарплаты, проблемы с пандемией... Конечно, лень на работе это не оправдывает,
но и сокращения ради "оптимизации бизнес-процессов", чтобы босс лишний раз с гаремом любовниц скатал на Канары -- таких карма точно покарает; а тех, кто пострадал безвинно, обязательно поощрит :)

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

Самый топ наверное -- это "с какой технической проблемой вы недавно столкнулись, и как вы её решили?".

На самом деле, это вопрос с подковыркой. Он тестирует не столько ваши технические знания, сколько ваше умение самостоятельно решать проблемы + ваши софт-скиллы.

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

Ok, вы наняты! :)

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

Этот процесс, собственно, и есть именно тот товар, который вы им продаёте в обмен на вашу зарплату.

https://vc.ru/hr/278924-kak-obmanyvayut-na-it-kursah-i-chto-skryvaet-reklama-professii-programmista
"Я вам как тим-лид говорю, всферу реально войти, начиная с курсов. Это мой личный опыт. Я выучил программирование на курсах и в интернете сам. Начал работать с 50к как стажёр. Прошло 3,5 года и вот я уже тим-лид с зп 300. И это не конец пути, дальше буду менять немножко сферу и планировать переезд. Потому что 300 для России практически потолок. Проблема правда ещё в том, что нужно впахивать."

Вот бы всем такие проблемы )))

Другой классический вопрос: "почему вы считаете, что подходите для этой работы?". Это очень хороший вопрос сам по себе, особенно если его задают где-то в середине собеседования (что показатель, что вы им действительно интересны).
Его задают не всегда, но если это случилось, считайте что вам повезло, бинго! :)

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

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

В Китае буквально на днях, в конце июля, был полностью разгромлен рынок репетиторства. Крупнейшие онлайн-школы TAL Education и New Oriental Education подешевели в разы, должны переформатироваться в некоммерческие организации, не могут иностранные инвестиции привлекать, и т. п.
А школьным учителям например вообще запрещено проводить платные занятия со школьниками, даже в свободное время. Причина -- что хорошо сдать гаокао (ЕГЭ), поступить в институт, без помощи репетиторов стало очень сложно, и получается, что способные но бедные ребята лишаются вообще всех шансов как-то подняться, так как их обходят менее способные, но лучше натасканные.
Ну и расходы реально большие взваливаются на родителей:
"Chinese parents spend up to US$43,500 a year on after-school classes for their children"
https://www.scmp.com/news/china/society/article/2176377/chinese-parents-spend-us43500-year-after-school-classes-their

У нас на эту тему тоже стали появляться материалы, например:
https://www.kp.ru/daily/28311.5/4452640/

Звоночек? Не думаю.

Почему ИТ-репетиторы (или, скорее, менторы) и малые-средние онлайн-школы по программированию в России останутся спокойно работать и после 19 сентября? :)

Потому что,
во-первых, рынок такого репетиторства в нашей стране пока в 50(!) раз меньше, чем в Китае (а у них он там аж 120 млрд. долл.!), ну и как бы в зародыше его ликвидировать странно,
во-вторых, главное, репетиторство в нынешнем виде часто -- это действительно дрессировка на успешную сдачу тестов, никаким развитием интеллекта там и не пахнет, и такую форму конечно ограничивать полезно.

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

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

Сермяга в том, что даже если не выпущать и принуждать программистов въ*****ть за символические суммы, то стоимость соответствующих проэктов будет отнюдь не меньше, а наоборот, из-за херового качества станет экспоненциально расти )))

Стоимость разработки F-35 составляет полтора триллиона долларов на сегодня, и её стремительный рост удалось прищучить лишь после 2014-го, когда спохватились и взялись за тотальную цифровую трансформацию проекта, набрав кучу дорогущих топовых спецов.

Как программисту зарабатывать побольше денег? Средняя зарплата программистов в России в нонешнем году, по данным ведущих сайтов по работе, около 90 тыс. руб. Но совсем не обязательно, что вы будете зарабатывать именно столько. Знаю немало ребят, которые получают 50-70 тыс., но немало и таких, кто за 300т. получает.

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

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

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

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

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

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

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