Наткнулся на обсуждение "как это классно, когда ввели вторники без митингов, можно хоть день поработать нормально".
Когда в большой организации вводят правило "вторники без митингов", я смотрю на это со скепсисом.
С вероятностью 99% это означает лечение поноса затыканием жопы. Вместо того, чтобы искать корень проблемы, почему же все, собственно, задолбаны митами.
Обычно перегрузка митами происходит, когда:
1. слишком много контроля (микроменеджмент), приходится постоянно отчитываться о том, как именно ты что-то делаешь
2. слишком много согласований с другими отделами, нет независимости команды в принятии решений ( как Tight coupling в программировании). Или например, фронтенд одна команда, а бекенд другая, со своими планами и приоритетами.
3. есть какие-то наслоения сбоку типа структур "Engineering excellence", "отдел корпоративного обучения" и прочие активности, оторванные от реальных дел бизнеса, и находящиееся в абстрактном вакууме. Поймите меня правильно, можно много всего классного полезного придумать и сделать, но запрос должен идти от команды, а не насильно в команду.
4. обязательное на всю организацию внедрение скрама и прочих штук, которые нужны так-то далеко не всем. Я, например, как-то работал в команде из 2(!) разработчиков, куда насильно навязали скрам. А скрам - это много странных приседаний (планирование, демо, ретро, хуетро и т.д.)
ну и, собственно, правило "вторник без встреч" кому-то очень нужно (все задолбались), а кому-то только мешает (встреч и так немного, зачем вторник вычеркивать, неудобно). Ковровая бомбардировка, один размер подходит всем.
Кстати, в маленьких стартапах никогда не бывает таких дней, потому что все встречи, в общем-то, по делу, и их мало.
🫥 Cross Join - канал о разработке
⠀
Когда в большой организации вводят правило "вторники без митингов", я смотрю на это со скепсисом.
С вероятностью 99% это означает лечение поноса затыканием жопы. Вместо того, чтобы искать корень проблемы, почему же все, собственно, задолбаны митами.
Обычно перегрузка митами происходит, когда:
1. слишком много контроля (микроменеджмент), приходится постоянно отчитываться о том, как именно ты что-то делаешь
2. слишком много согласований с другими отделами, нет независимости команды в принятии решений ( как Tight coupling в программировании). Или например, фронтенд одна команда, а бекенд другая, со своими планами и приоритетами.
3. есть какие-то наслоения сбоку типа структур "Engineering excellence", "отдел корпоративного обучения" и прочие активности, оторванные от реальных дел бизнеса, и находящиееся в абстрактном вакууме. Поймите меня правильно, можно много всего классного полезного придумать и сделать, но запрос должен идти от команды, а не насильно в команду.
4. обязательное на всю организацию внедрение скрама и прочих штук, которые нужны так-то далеко не всем. Я, например, как-то работал в команде из 2(!) разработчиков, куда насильно навязали скрам. А скрам - это много странных приседаний (планирование, демо, ретро, хуетро и т.д.)
ну и, собственно, правило "вторник без встреч" кому-то очень нужно (все задолбались), а кому-то только мешает (встреч и так немного, зачем вторник вычеркивать, неудобно). Ковровая бомбардировка, один размер подходит всем.
Кстати, в маленьких стартапах никогда не бывает таких дней, потому что все встречи, в общем-то, по делу, и их мало.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cross Join - канал о разработке
Канал о разработке Антона Околелова. Разрабочик/ex-тимлид Go, живу в Чехии. Мысли, новости, вопросы.
По вопросам рекламы @antonokolelov
По вопросам рекламы @antonokolelov
1👍33💯8
Периодически наталкиваюсь на разработчиков, которые думают, что они незаменимы, потому что знают в каком-то месте кода прям всё на свете. И поэтому их-то точно никогда не уволят - слишком опасно и долго обучать новичка.
Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.
Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.
Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.
В-третьих, в кризисные времена сокращают целые направления, вместе с Васей и бизнесом, который Вася подпирал столько лет своим плечом, как заправский атлант. Причем, такие новости обычно приходя внезапно, как снег на голову. Типа, наш отдел закрывают с первого числа, сорян.
Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.
🫥 Cross Join - канал о разработке
⠀
Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.
Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.
Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.
В-третьих, в кризисные времена сокращают целые направления, вместе с Васей и бизнесом, который Вася подпирал столько лет своим плечом, как заправский атлант. Причем, такие новости обычно приходя внезапно, как снег на голову. Типа, наш отдел закрывают с первого числа, сорян.
Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cross Join - канал о разработке
Канал о разработке Антона Околелова. Разрабочик/ex-тимлид Go, живу в Чехии. Мысли, новости, вопросы.
По вопросам рекламы @antonokolelov
По вопросам рекламы @antonokolelov
💯64😢5❤2👍1😐1
Forwarded from UfoStation
В посте выше обозначил такую проблему при работе с swc компилятором, как очень скромная документация (или ее отсутствие), и что необходимо читать исходники, чтобы собрать в голове архитектуру проекта, выделить используемые сущности и связи между ними, а все для того, чтобы понимать ограничения своих решений, написанных wasm-плагинов. А в прошлом мне потребовалось две пары выходных, чтобы прочитать код, прежде чем внести исправление и закрыть issue в swc.
Сейчас на досуге пытался понять почему в swc два runtime для wasm — wasmtime и wasmer. Быстро нашел ADR, в котором было указано, что wasmer был выбран как основной runtime для wasm-плагинов. Но если хочется узнать как он запускает wasm-плагины, как встраивается в компилятор — иди читай исходники.
Здесь мне помог проект deepwiki.com, который в ситуации подобной моей делает прекрасный onboarding: отвечает на вопросы, знакомит с основными частями кодовой базы и тем, как они связаны, рисует графики зависимостей, сопровождает свои ответы участками исходного кода. Более того он собирает лендинг с документацией на основе исходников, например, https://deepwiki.com/swc-project/swc
В общем, рекомендую приглядеться к deepwiki.com
Сейчас на досуге пытался понять почему в swc два runtime для wasm — wasmtime и wasmer. Быстро нашел ADR, в котором было указано, что wasmer был выбран как основной runtime для wasm-плагинов. Но если хочется узнать как он запускает wasm-плагины, как встраивается в компилятор — иди читай исходники.
Здесь мне помог проект deepwiki.com, который в ситуации подобной моей делает прекрасный onboarding: отвечает на вопросы, знакомит с основными частями кодовой базы и тем, как они связаны, рисует графики зависимостей, сопровождает свои ответы участками исходного кода. Более того он собирает лендинг с документацией на основе исходников, например, https://deepwiki.com/swc-project/swc
В общем, рекомендую приглядеться к deepwiki.com
🔥10
Про синдром самозванца.
"Ой, мой опыт N лет, но замучил синдром самозванца, ничего не знаю ни в чем, хаха"
Не смешно, потому что ты самозванец и есть. Всё меняется каждые несколько лет, текущие знания не стоят ничего.
Перед Go я писал много лет на php, куда мне засунуть эти знания? Надо ли их вычитать теперь из годов? А еще я наблюдал, как в том же пыхе всё меняется. Как писали на php4 и как пишут, допустим, сейчас - да там ничего общего нет. Вообще. Совсем.
И если у тебя много лет работы условно на старье, то у тебя вообще нет опыта работы. И когда ты слышишь/читаешь чьи-то разговоры и не понимаешь их, то это не синдром самозванца, ты самозванец и есть.
Знания - это sliding window.
Да, есть вечные темы, типа дизайна распределенных систем или баз данных, но и там инструменты меняются постоянно.
Хуже только в javascript, там просто пиздец. Моргнул - и устарели два фреймворка и сборщик.
Куда, опять же, мне засунуть опыт с jQuery?
Сейчас еще и ИИ этот гребучий делает из нас самозванцев. Только подружился с чатгпт, а уже надо юзать агентов. Только заюзал агентов, а уже давно надо иметь хитрожопые навыки по подсовыванию/поддержанию контекста, иначе неэффективно.
Только Go радует своей консервативной деревянностью, но вокруг него всё в броуновском движении.
Синдром самозванца - это, короче, не синдром самозванца.
"Ой, мой опыт N лет, но замучил синдром самозванца, ничего не знаю ни в чем, хаха"
Не смешно, потому что ты самозванец и есть. Всё меняется каждые несколько лет, текущие знания не стоят ничего.
Перед Go я писал много лет на php, куда мне засунуть эти знания? Надо ли их вычитать теперь из годов? А еще я наблюдал, как в том же пыхе всё меняется. Как писали на php4 и как пишут, допустим, сейчас - да там ничего общего нет. Вообще. Совсем.
И если у тебя много лет работы условно на старье, то у тебя вообще нет опыта работы. И когда ты слышишь/читаешь чьи-то разговоры и не понимаешь их, то это не синдром самозванца, ты самозванец и есть.
Знания - это sliding window.
Да, есть вечные темы, типа дизайна распределенных систем или баз данных, но и там инструменты меняются постоянно.
Хуже только в javascript, там просто пиздец. Моргнул - и устарели два фреймворка и сборщик.
Куда, опять же, мне засунуть опыт с jQuery?
Сейчас еще и ИИ этот гребучий делает из нас самозванцев. Только подружился с чатгпт, а уже надо юзать агентов. Только заюзал агентов, а уже давно надо иметь хитрожопые навыки по подсовыванию/поддержанию контекста, иначе неэффективно.
Только Go радует своей консервативной деревянностью, но вокруг него всё в броуновском движении.
Синдром самозванца - это, короче, не синдром самозванца.
🤡36💯24❤12🔥4💊4👍3👎3😁3🍌1
Бюро статистики труда США прогнозирует рост вакансий software developers и QA на 15% до 2034 года. И это несмотря на все ИИ, массовые сокращения и прочие экономические закидоны.
Любопытно
Любопытно
Bureau of Labor Statistics
Software Developers, Quality Assurance Analysts, and Testers
Software developers design computer applications or programs. Software quality assurance analysts and testers identify problems with applications or programs and report defects.
1👍15
Говорят, что ИИ - это финансовый пузырь, который лопнет, и мы все заживём по-старому.
Чё думаете?
Имхо, финансовый пузырь - скорее да, чем нет. Компании вкладывают столько денег, что это может окупиться наверно только с AGI, до которого еще далеко.
Но и по-старому не заживём никогда, ЛЛМки уже никуда не денутся. Будут, наверно, в 2-3 раза дороже, но на этом всё.
Если даже сейчас можно запустить на ноуте какую-то убогую версию, куда она денется-то? Ну да, она медленная, тупая и жрёт все ресурсы, но никуда уже не исчезнет.
Я раньше думал, что глобально человечеству может не хватить энергии, чтобы каждый чел пользовался ии каждый день, но блин, Гугл запускает эту хреновину на каждый запрос, надо или нет. И вроде бы пока норм.
Но я не настоящий сварщик, интересно ваше мнение. Может, были какие-то исследования или типа того
Чё думаете?
Имхо, финансовый пузырь - скорее да, чем нет. Компании вкладывают столько денег, что это может окупиться наверно только с AGI, до которого еще далеко.
Но и по-старому не заживём никогда, ЛЛМки уже никуда не денутся. Будут, наверно, в 2-3 раза дороже, но на этом всё.
Если даже сейчас можно запустить на ноуте какую-то убогую версию, куда она денется-то? Ну да, она медленная, тупая и жрёт все ресурсы, но никуда уже не исчезнет.
Я раньше думал, что глобально человечеству может не хватить энергии, чтобы каждый чел пользовался ии каждый день, но блин, Гугл запускает эту хреновину на каждый запрос, надо или нет. И вроде бы пока норм.
Но я не настоящий сварщик, интересно ваше мнение. Может, были какие-то исследования или типа того
1🤔14🌚8💯4❤1
Имхо, халява давно кончилась. Если когда-то можно было, изучив основы, пойти джуном и быстро дойти до приличной зп, то сейчас это уже давно не так.
Во-первых, ИИ мощно убивает работу для джунов, а во-вторых, и до ИИ рынок войти-в-айти уже стал перенасыщенным. Толпы прям уже туда пёрлись.
Так что перспективы очень сомнительны.
Разве что для общего развития изучать. Логическое мышление и всё такое.
Во-первых, ИИ мощно убивает работу для джунов, а во-вторых, и до ИИ рынок войти-в-айти уже стал перенасыщенным. Толпы прям уже туда пёрлись.
Так что перспективы очень сомнительны.
Разве что для общего развития изучать. Логическое мышление и всё такое.
👍25👎17🤔5
Обалдеть, чего только не бывает в природе. Наткнулся тут на pglite - Postgres, скомпилированный под wasm, который можно запускать в браузере (или на nodejs).
Для сложного фронтенда, который делает хитрожопые джойны и оконные функции. Поддерживает даже пгшные расширения, типа pgvector.
Может персиститься в IndexedDB и другие штуки.
https://github.com/electric-sql/pglite
Для сложного фронтенда, который делает хитрожопые джойны и оконные функции. Поддерживает даже пгшные расширения, типа pgvector.
Может персиститься в IndexedDB и другие штуки.
import { PGlite } from "@electric-sql/pglite";
const db = new PGlite();
await db.exec(`
CREATE TABLE IF NOT EXISTS notes (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
content TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
`);
https://github.com/electric-sql/pglite
GitHub
GitHub - electric-sql/pglite: Embeddable Postgres with real-time, reactive bindings.
Embeddable Postgres with real-time, reactive bindings. - electric-sql/pglite
🙈15🔥9🤯2😢2❤1👍1
Топ-3 инсайта по внедрению AI-разработки
1. Гигиена контекста и субагенты
Качество большинства средних моделей критически падает после 70–80k токенов: начинаются пропуски логики и галлюцинации.
Решение: Субагенты. Выноси задачи в изолированные инстансы.
Метрика: Лимит задачи — 3-4 часа работы мидла.
2. Детерминированный Feedback Loop
Никакого доверия модели. Агент должен проверять себя жесткими инструментами.
Инструменты: Линтеры, Type-check, тесты.
Пайплайн: Код -> Линтер (ошибка) -> Авто-фикс агентом. Без этого — генерация легаси.
3. Приоритет планирования (90/10)
Генерация кода без плана — сжигание бюджета.
Правило: 2-3 часа на архитектуру с рассуждающими моделями (GPT-5.2 High).
ROI: Плохой план утраивает расход токенов на правки. Исправлять галлюцинации дороже, чем планировать.
Если хотите ещё больше практических советов по AI coding, подписывайтесь на канал Тимура Хахалева, он в этом эксперт и делится своим опытом на канале.
1. Гигиена контекста и субагенты
Качество большинства средних моделей критически падает после 70–80k токенов: начинаются пропуски логики и галлюцинации.
Решение: Субагенты. Выноси задачи в изолированные инстансы.
Метрика: Лимит задачи — 3-4 часа работы мидла.
2. Детерминированный Feedback Loop
Никакого доверия модели. Агент должен проверять себя жесткими инструментами.
Инструменты: Линтеры, Type-check, тесты.
Пайплайн: Код -> Линтер (ошибка) -> Авто-фикс агентом. Без этого — генерация легаси.
3. Приоритет планирования (90/10)
Генерация кода без плана — сжигание бюджета.
Правило: 2-3 часа на архитектуру с рассуждающими моделями (GPT-5.2 High).
ROI: Плохой план утраивает расход токенов на правки. Исправлять галлюцинации дороже, чем планировать.
Если хотите ещё больше практических советов по AI coding, подписывайтесь на канал Тимура Хахалева, он в этом эксперт и делится своим опытом на канале.
👍17🤡3🔥2❤1💯1