Как понять, что вы сеньор? Это когда в вашем стеке вы можете сделать потенциально любой проект (хорошо понимаете, как) полностью самостоятельно. Неважно, что на него может потребоваться 100 лет, речь именно о понимании.

Если аналогично понимаете, как делаются отдельные подсистемы (не менее 50%), значит вы миддл.

Если понимаете устройство и способны реализовать 20-50% подсистем, значит вы пока джуниор.

Иначе, стажёр :)

VK Tech приглашает будущих программистов на стажировку

Сроки проведения отбора: май-июнь 2023
Сроки проведения стажировки: июль-август 2023

(нереклама, просто рекомендую, потому что ВК очень любит деньги -- в прошлом году они заработали 100 миллиардов рублей, и стажёрам наверняка перепадёт)

P.S. Надо отметить, что стажировка по мэйлрусски -- это не писать немножечко ясного кода, они хочут, чтобы стажёр например был в стеке Java + Python + Go + JS + Vue/React (а кому сейчас легко)

ахаха Demiurges — новое слово в компьютерных играх )))

Клон HoMM (неплохой кстати), но в печальном тренде последних лет нарочитой ретро-графики (мне ужасно не нравится), доведённой до абсурда.

Впрочем, уже совсем скоро таким самоделкам придёт конец, вот полюбуйтесь, сегодня подобное начинает клепать AI: симулятор жизни

Как они это делают:
https://arxiv.org/abs/2304.03442

Почему AI в ИТ вряд ли станет массовым?

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

Буквально, даёшь AI сложные задачи -- решает 20%. Добавляешь к условиям фразу "Lets go step by step" -- решает 80% :)

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

Ну, со светлым праздником: сегодня в СССР отмечается День Науки 💥

Дико уважаю.
В феврале 2018-го у него в последний раз было 2-3 дня пауз в работе.
А чего добился ты?

P.S. Пока вы тупите в соцсетях, ваши конкуренты вот так упорно и неустанно трудятся, чтобы захватывать потенциально ваши рабочие места с хорошими зарплатами.

Есть такая канадская Wave Financial, которая стоит 1,7 млрд. долл. -- финтех для малого бизнеса, онлайн-бухгалтерия и пр. Сам сервис, по большому счёту, чистый CRUD, занимающийся сложением чиселок. В Wave работает считанные десятки разработчиков, которые пилят прозаический монолит на Python поверх Postgresql.

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

Почти за такую же цену был куплен в своё время и StackOverflow, который так же успешно масштабировал свой монолит.

...У нас были 4 Microsoft SQL Servers, 11 IIS Web Servers, 2 Redis Servers, 3 Tag Engine servers, 3 Elasticsearch servers, 4 HAProxy Load Balancers и 4 циски.
Ну совсем скромная архитектурка, да ещё и под виндой :)

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

P.S. Поподробнее на эту тему в вк напишу пост.

Воистину.

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

Однако вот отличная статья топовых исследователей ОС:
"A fork() in the road"
— Microsoft Research, Boston University, ETH Zurich.

Они там как раз утверждают то, что и хотелось бы сегодня (а не вчера) слышать от онлайн-курсов и университетов, уважающих себя и своих учеников: Unix API fork() -- это пережиток прошлого, непригодный для большинства случаев использования и нарушающий концептуальный дизайн.

In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives. As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.

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

Из чата с курсантом, по развитию карьеры. 50 вакансий -- это статистически значимая выборка!

Евгений:
...я посмотрел около 50 вакансий дата инженера в основных индустриях, где с данными работают (ИТ, телеком, банки, ритейл).
Везде в принципе одно и тоже просят:
- sql и всё смежное по субд (прям отличный уровень нужен, не просто select) (может стоит все-таки ваш курс по SQL пройти, если там есть какая-нибудь теория по БД);
- python,scala,java (обычно один или два языка просят, скалу часто вижу в требованиях);
- hadoop,apache airflowи тд (программы для работы с big data; их много достаточно);
- все остальное что касается ETL процессов

На сеньорских позициях встречается подобное:
- Опыт разработки высоконагруженных бэкенд сервисов на Java, Scala или Python;

Вообще как мне кажется (дилетанским взглядом конечно) дата инженер похож на backend разработчика, который использует в работе много разных big data штук, типо оркестраторов и так далее. А в остальном как будто требования пересекаются в 70-80% случаев.

Мой ответ:

Да, безусловно, 80% это бэкенд, 20% специфика, акцент на ETL (вся унылая грязная работа по очистке датасетов, которую обычно сваливают на джуниоров :) работа с моделями это элитное сеньорское). Вообще, бэк рулит везде, даже для фронтенда немножко ) Я поэтому на нём и делаю основной акцент.

Отличное знание SQL и БД в датасайнсе абсолютно обязательно, прочитайте от корки до корки учебник Бьюли "Изучаем SQL" но это лишь начало, главное уверенно решать middle-hard задачки на хакерранге и codewars, очень правильный навык дата-моделирования при этом вырабатывается. И конечно поизучать классику
"Системы баз данных. Полный курс" Ульмана.

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

Надо ли доводить код до совершенства?

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

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

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

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

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

Однако если меня спрашивают, стоит ли им бросить универ, я всегда говорю "нет! продолжайте заниматься!". Причина, по которой я советую им остаться, заключается в том, чтобы развивать в себе выдержку, упорство и дисциплину. Это важно, так что слушайте внимательно.

Многие люди не могут придерживаться чего-то одного, не могут сконцентрироваться на важном и полезном для них, не способны ни один длительный проект довести до конца. И это одна из главных причин, по которой они НИКОГДА не заработают много денег. Вот почему они застревают в своих 9-18, пока в 65 лет не становятся старыми и морщинистыми.

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

Из многих сотен ребят все мои курсы, мою Школу до конца за последние три года прошло всего два человека, и ещё считанные единицы с тренинга по проектированию higher work к этому подбираются. А 99% просто не способны даже такое не очень долгое время учиться нужному и полезному. По сути, они предают сами себя. Ну штош...

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

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

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

Например, есть такая штука, как джанглоид -- кусочек кода, который синтезируется автоматически и выполняет некоторый условно клиентский запрос к API на основании заданных типов входных и выходных значений. Так вот, формальная теория джанглоидов была разработана в начале 2000-х, задолго до явления хипстерских AI-ассистантов. Джанглоиды отлично комбинируются, и на их основе для Eclipse (основной Java IDE того времени) был разработан плагин, который выдавал адекватные подсказки и варианты кода, и, в частности, нашёл решение 18 из 20 задач =>
"Jungloid mining: helping to navigate the API jungle"

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

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

Но вот факт: большинство недостатков в вашей системе в плане безопасности невозможно использовать.

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

Ну, посмотрите например стандарт безопасного кодирования института программной инженерии SEI (авторы CMM и PSP) при университете Карнеги-Меллона, и вы увидите, что то, что отметит типовой эксперт по ИБ -- это множество мелких деталей, которые можно заметить с первого взгляда, при стандартном code review. Они утверждают, что если сделать всё это стилистически правильно, то ваше программное обеспечение, скорее всего, будет безопасным. Написание правильного кода подразумевает создание модулей, которые могут быть рассмотрены по отдельности.

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

Между мышлением разработчика и мышлением хакера имеются кардинальные различия. Это принципиально разные думательные машики, которые встраиваются в ум качественно разными способами и приёмами. У каждой из них своя математическая логика (у программистов -- логика Хоара прежде всего). Чтобы тут не путаться, дам курсантам в СильныхИдеях, которых учу ясному формальному мышлению классического разработчика, чёткое научное определение модели мышления разработчика эксплойтов, как правильно рассуждать в хакерской парадигме, по материалу исследователей формальной (и несовместимой с хоаровской) хакерской логики из фейспалма и University College London.

Знакомые пацаны-скалисты из финтеха звали к себе посоветовали глянуть ZIO -- внезапно действительно оказалась крутая вещь, рекомендую!

Type-safe, composable asynchronous and concurrent programming for Scala

Особенно им понравился мой коммент, что дескать

ZIO[R, E, A] (an immutable value that lazily describes a workflow or job) -- это великолепная и отлично масштабирующаяся абстракция гексагональной архитектуры, причём шикарно эээ композиционирующаяся (русского не хватает, composable), и даже фрактальная по сути!

Смешное: как я ни пытался заставить ChatGPT-4 (!) закодить простейшую задачку на питоне -- сгенерировать список всех файлов и каталогов в заданном каталоге, включая список всех файлов и каталогов одного уровня вложенности если включён флажок (простая задачка для моих начинающих курсантов с околонуля), оно так и не смогло.

Генерит код, который при флажке выдаёт все вложенные подкаталоги (оно и понятно, тупо берёт os.walk). И как я не возмущался и не уточнял что и как именно надо сделать, так и не исправилось. Ну, за такое даже из стажёров сразу выгоняют.

Может и вышло бы, если целый час детально уточнять и мучить промтами на такой элементарной задачке, что требуется; да, но час сеньора стоит в 10 раз дороже часа джуниора.

А вы говорите, скоро заменит профессиональных программистов....

С другой стороны, никто и не обещал, что AI действительно буквально будет писать любой код, нет конечно. Его относительный успех в кодинге объясняется прежде всего тем, что миллионы программистов (да и вообще белковые мозги в целом) мыслят крайне шаблонно, и число типовых приёмов в programming in small оказалось невелико, сотни, может быть тысячи, их надо просто уметь комбинировать. Если задача похожа на что-то ранее решавшееся, может быть решена по аналогии короткой комбинацией паттернов, то AI дописывает, а если хотя бы немного оригинальное, где надо немножечко оригинально подумать в формате символьных вычислений, сразу пасует. На codeforces например AI откровенно зашкварилось, вообще ничего не может.

Жаловаться на то, что тестирование (в целом) замедляет разработку, всё равно что жаловаться на то, что тормоза замедляют гоночный автомобиль.
(с) Кент Бек

Я никогда не был поклонником правил.

Ну... не тех правил, которым другие люди говорят нам следовать беспрекословно.

Такие правила меня раздражают...

Однако я считаю, что иметь свой собственный набор правил очень важно.

Особенно когда речь идёт о том, чтобы стать лучшим программистом... или вообще стать лучшим в чём-либо.

Это не значит, что вы никогда не должны нарушать свои собственные правила...

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

За последние несколько лет я открыл несколько правил, выработанных за почти 45 лет программирования, создания бесчисленных программных продуктов... и оказания специализированных консультационных услуг серьёзным компаниям и стартапам, но главное -- благодаря регулярному изучению научных конференций по программированию и computer science. Главное, что в этих правилах собраны очень сильные, официально рецензируемые рекомендации с подобных конференций, чем кроме меня больше никто в России не занимается.

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

Но они редко тратят время на деконструкцию того, что они узнали, и создание правил о своих знаниях...

И КАК они достигли огромных прорывов.

Я нашёл время, чтобы сделать это.

Я изложил эти правила в виде простого в исполнении процесса -- практического тренинга по проектированию и программной инженерии.

Он называется Higher Work.

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

Вот и всё.

Я всегда подчёркиваю важность изучения глубоких концепций, а не поверхностных примеров. Например, сейчас готовлю материал для СильныхИдей, с помощью которого хочу научить программистов отключаться от мусорных каталогов со схемами рефакторинга и понять, что большинство знакомых им рефакторингов вытекают из единичных основных алгебраических законов, таких как тождество X^2*A = X^A * X^A, которое легко выводится из аксиом школьной алгебры, и соответствует замене функции, принимающей булевы аргументы, двумя функциями. Все приёмы рефакторинга, которые я знаю, легко выводятся буквально одношаговыми сокращениями конструкций языка программирования через простейшие алгебраические законы.

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

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

P.S. За мои почти 45 лет работы в ИТ могу сказать определённо только одно: есть очень мало вещей в программировании, которые однозначно и безоговорочно можно считать хорошей идеей. Почти всегда всё зависит от ситуации и контекста использования. Поэтому с особой тщательностью отбираю такие золотые крупицы ценных знаний в СильныеИдеи для курсантов, сейчас там около 50 материалов + формат Higher Work (практика в этом всём).

Про ИТ-стартапы -- в какой области создавать?

Мета-идею вам расскажет любой инфоцыган: посмотрите, где есть спрос, и идите туда. Более инженерный подход таков:

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

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

-- Подобные ресурсы будут реально ценны для многих людей.

Из моего недавнего опыта, такая темка как управление версиями REST API. Как вы разрабатываете свои схемы данных, стараясь обеспечить как расширение API, так и сохранение обратной совместимости. Однако в ряде ситуаций отказ от обратной совместимости тоже будет хорошей идеей + надо также учитывать разницу между управлением версиями внутренних и клиентских API и т. д. и т. п.

В мире сегодня только официально насчитывается около 70 тысяч SaaS-компаний (ну и REST API как таковой вообще в любом проекте наверное сегодня имеется). Допустим, что из них как минимум 10 тысяч организаций явно интересуются этой проблемой. Сколько таких в России? Многие сотни точно, особенно с учётом вала проектов по импортозамещению.

Пусть на создание курса/учебника по версионному управлению REST API потребуется даже год работы, а в результате его применения средняя компания сэкономит в год 500 человеко-часов программистов на избавлении от кривых и несогласованных апишек. Если бы я был глобальным министром ИТ, пытающимся улучшить отрасль в целом, имело бы смысл заплатить одному человеку миллион рублей за написание учебника или курса по управлению версиями API. Это тема, с которой сталкивается далеко не каждый разработчик, но ею занимаются сотни или даже тысячи компаний, и хотя тема довольно широкая, она достаточно специфична, чтобы можно было объединить опыт и идеи в одном ресурсе.

И таких точечно-актуальных тем самого разного масштаба полным полно, ну например навскидку: миграции баз данных, корпоративные поисковые системы, рекомендательные системы, системы управления рабочими задачами, преобразование данных между разными форматами, тэгирование, как использовать конкретные популярные API (Github или OpenAI) и т. д.

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

Не перестаю удивляться глубине падения мэйнстрима :)

Ну например, вы создаёте очередной поисковик котиков, для чего берёте готовое key-value хранилище, в котором храните индексы в вашем поисковике (b-tree).

Да, но ваше готовое key-value хранилище внутри себя, в файле файловой системы на своём внутреннем уровне тоже хранит свои индексы (b-tree).

Да, но ваша файловая система на своём уровне тоже хранит свои индексы файловых дескрипторов (b-tree)...

Ну и зачем нужны эти три эквивалентных по сути уровня?

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

Очень хорошо погуглить например "erlang bare metal"