Многие реально не понимаю чем мой кейс отличается от большинства других.

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

И таких проектов уже много: soer.pro, narisapp, devs2devs, Соер.Клуб. Мне не интересно намекать на какой-то там свой коммерческий опыт, если я не могу предъявить конкретные результаты.

Каждый желающий может залететь в любой мой действующий проект и пощупать его руками, тот же Мурыч уже несколько раз рассказывал как я делаю все неверно и какой я непрофессионал (действительно реализовал проект с ребятами без опыта, который компаниям обходится в десятки миллионов рублей, это же на изи любой сделает, чего тут уметь?).

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

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

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

Но мне все равно нравится, по кайфу получилось

Сегодня с Алексеем Гладковым в Соер.Клубе обсудили вопрос разработки мультиагентных систем для написания кода. Я на выходных начал писать своего ИИ агента для Nvim и мне было интересно узнать, что делает Алексей (мы оба решаем задачу генерации кода).

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

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

Простые задачи (например, создание лендинга) такой конвейр вывозит, интересно делать что-то более сложное - анализировать пользовательские истории и реализовать api-first подход.

Буду постпенно копать в этом направлении.

Про оценку сроков

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

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

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

В защиту программистов скажу, что проблема оценок существует не только в айти: любой сложный процесс практически невозможно спрогнозировать. Один мой менеджер как-то сказал: представь, что твой врач не может назвать, сколько времени уйдет на лечение, что ты будешь чувствовать? Это был очень плохой пример: как раз в это время я проходила стоматологическое лечение, которое заняло на год больше ожидаемого и оказалось в 2,5 раза дороже изначально планируемой суммы.

Разработка - это сборка конструктора из мелких деталей: никогда не знаешь, подойдёт ли новая деталь к уже собранной части. Это напоминает известную проблему остановки Тьюринга: для любых двух функций F и G мы никогда не можем определить, что их суперпозиция остановится (= заработает как надо). Алан Тьюринг доказал неразрешимость этой проблемы еще 90 лет назад, однако менеджеры по сей день продолжают пытать программистов на очередном дейли вопросом “так, сколько тебе еще делать эту задачу?”.

Однако можно сделать ровно противоположное: не угадывать срок, который уйдет на разработку, а зафиксировать время, которое вы готовы уделить на фичу. Например: “Мы готовы потратить на эту фичу 2–5 дней. Обязательно - чтобы работало вот это. Всё остальное сделаем по возможности”. Тогда вы не будете зависеть от точных оценок, и при любом раскладе сделаете главное.

Первый раз я применила этот способ еще в 2019 году. Я прикинула, что мне нужно около двух недель на задачу. Однако менеджер вернулась ко мне со словами - “бизнес не дал тебе две недели, бизнес дал тебе неделю”. “Хорошо, я могу сшить семь шапок из этой шкурки,” - подумала я. Я сделала каркас фичи за неделю, но не успела добавить несколько удобных штук в свое решение, плюс пропустила некоторые корнер кейсы. Менеджер осталась довольна. А затем попросила доработать решение и учесть корнер кейс. “Хорошо,” - сказала я, - “на это мне нужна еще неделя”. На том и порешили.

Если вы разработчик и от вас требуют конкретные сроки - попробуйте так и сказать: “Я точно успею сделать вот это, а остальное - постараюсь, если не вылезем за дедлайн”. Тогда вы точно сможете рассчитывать на то, что критическая функциональность будет готова в срок, а опциональной можно пренебречь.

Простой пример того почему не стоит слепо верить ИИ. Это ответ Алисы.

Ещё один пример соера который сделал крутую карьеру, к тебе только один вопрос: почему ты думаешь, что не можешь так же?

Вот ещё пример успеха за счёт карьерного роста, хардов и личного бренда. (Мне просто интересно в какой момент мои оппоненты признают, что в их подходе к карьере даже близко таких примеров нет?) 👇👇👇

Вышел классный подкаст со мной и у Таалая! Таалай очень крутой инженер, гуглер с зарплатой выше 500к долларов в год

https://youtu.be/ExoGv_oUbvQ?si=V_4Pt64c9GYNBNoM

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

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

1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».

|                     | Нравится    | Не нравится |
|-----------|-------------|---------------|
| Я умею      | Тут список  | Тут список  |
| Я не умею | Тут список  | Тут список  |

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

2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом.

3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить.

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

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

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

Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".

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

На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".

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

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

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

Внимание! В этом посте есть метаирония, которую 100% опять не поймут, но вот такой я метаироничный тип.

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

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

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

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

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

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

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

На канале Деплой вышел ролик, показывающий реальное положение дел в найме Айтишников. Если коротко - теперь соеры лидируют не только по хардам, но и по зарплатам.

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

Пример из видео - архитектор облачных решений - миллион рублей. 👆

Стратегия все та же - нетворкинг, харды, личный бренд и движение к цели малыми шагами.