Наверное, многие слышали об этой книге, а некоторые даже читали её. Я её прочитал где-то до глав, в которых рассказывалось об арифметическом сумматоре. Очень доступно и интересно написана эта книга https://ru.hexlet.io/blog/posts/kod-petzold-review
ru.hexlet.io
Рецензия на книгу Чарльза Петцольда «Код. Тайный язык информатики», или Зачем программисту знать, как устроен фонарик
Первые страницы книги Чарльза Петцольда «Код. Тайный язык информатики» меня сильно озадачили. Фонарик, азбука Морзе, шрифт Брайля... Окей, а зачем это мне? И когда будет про компьютеры и код? Примерно с третьей или четвёртой главы картинка начала складываться.
👎2
Forwarded from Evgeniy Kuvshinov (Evgeniy Kuvshinov)
Всем привет! Давно не общались. Хочу объяснить причины долгого затишья и поделиться планами на будущее.
Почему было мало контента?
Последние несколько лет были посвящены трем большим жизненным проектам:
1. Семья: Рождение и воспитание двоих детей.
2. Дом: Полный цикл строительства своего дома (от земли до заселения). Пишу вам теперь из своего кабинета!
3. Работа: Карьерный рост до позиции Teamlead/TechLead/CTO, что отнимало все силы.
Совмещать это с ведением каналов было практически невозможно.
Что изменилось сейчас?
• Дети подросли и этот вопрос делигирован жене.
• Дом построен, есть даже отдельный кабинет.
• Я уволился, отдохнул и готов к новым вызовам.
Новые горизонты и идея для вас
Я возвращаюсь к созданию контента и хочу предложить вам поучаствовать в открытом некоммерческом проекте.
Идея: Совместными усилиями создать скелет фреймворка для построения API. Процесс разработки (планирование, код-ревью, митапы) я буду стримить на YouTube.
Зачем это вам?
• Получить реальный опыт работы в команде.
• Прокачать скиллы и добавить проект в портфолио.
• Принять участие в создание комманды с нуля и вместе набить шишек.
Ваше мнение?
Если вы готовы принять в этом участие и потратить свое время, поставьте, пожалуйста, ❤️ в ответ на это сообщение. Это поможет мне оценить интерес и подготовить детальный анонс.
Если вам интересна эта затея как зрителю то 👍
Спасибо, что вы со мной уже более 6 лет!
Почему было мало контента?
Последние несколько лет были посвящены трем большим жизненным проектам:
1. Семья: Рождение и воспитание двоих детей.
2. Дом: Полный цикл строительства своего дома (от земли до заселения). Пишу вам теперь из своего кабинета!
3. Работа: Карьерный рост до позиции Teamlead/TechLead/CTO, что отнимало все силы.
Совмещать это с ведением каналов было практически невозможно.
Что изменилось сейчас?
• Дети подросли и этот вопрос делигирован жене.
• Дом построен, есть даже отдельный кабинет.
• Я уволился, отдохнул и готов к новым вызовам.
Новые горизонты и идея для вас
Я возвращаюсь к созданию контента и хочу предложить вам поучаствовать в открытом некоммерческом проекте.
Идея: Совместными усилиями создать скелет фреймворка для построения API. Процесс разработки (планирование, код-ревью, митапы) я буду стримить на YouTube.
Зачем это вам?
• Получить реальный опыт работы в команде.
• Прокачать скиллы и добавить проект в портфолио.
• Принять участие в создание комманды с нуля и вместе набить шишек.
Ваше мнение?
Если вы готовы принять в этом участие и потратить свое время, поставьте, пожалуйста, ❤️ в ответ на это сообщение. Это поможет мне оценить интерес и подготовить детальный анонс.
Если вам интересна эта затея как зрителю то 👍
Спасибо, что вы со мной уже более 6 лет!
👎2👍1
Evgeniy Kuvshinov
Всем привет! Давно не общались. Хочу объяснить причины долгого затишья и поделиться планами на будущее. Почему было мало контента? Последние несколько лет были посвящены трем большим жизненным проектам: 1. Семья: Рождение и воспитание двоих детей. 2. Дом:…
Может кому интересно. Проект на PHP
👎2
Forwarded from Николай Тузов
Начало 1980-х. Вы — разработчик в Apollo Computer. Ваша команда работает над NCS — одной из первых систем для распределённых вычислений.
Вам поручили решить важную проблему:
- У вас есть множество серверов в разных городах
- Каждый из них может регистрировать новых пользователей
- Каждому новому пользователю нужен уникальный ID во всей распределённой системе. Иначе при синхронизации или обращении по сети будет непонятно, о каком из них речь
На одной машине всё просто — даём каждому объекту порядковый номер: 1, 2, 3... Но если два сервера независимо дадут номер 1 своим объектам — получим коллизию
Начинаем думать.
————
Попытка 1: Центральный сервер со счётчиком
Самое очевидное решение — один сервер раздаёт ID всем остальным:
Машина A → Центр: "Дай ID"
Центр → Машина A: "Держи ID=1"
Машина B → Центр: "Дай ID"
Центр → Машина B: "Держи ID=2"
Выкатываем в прод. Работает идеально! Гарантированно уникальные ID, никаких коллизий.
Но через неделю начинаются проблемы:
- Центральный сервер упал — вся система встала
- Каждый запрос ID требует сетевого обращения — медленно
- При росте нагрузки центр становится узким местом
Для распределённой системы, где важна автономность узлов, это не подходит. Переделываем.
————
Попытка 2: Диапазоны для каждой машины
Хорошо, давайте заранее раздадим каждой машине свой диапазон ID:
Машина A: ID от 1 до 1,000,000
Машина B: ID от 1,000,001 до 2,000,000
Машина C: ID от 2,000,001 до 3,000,000
Это уже лучше — каждая машина действительно автономна!
Выкатываем. На первый взгляд работает.
Но потом выясняется:
- Машина A исчерпала свой диапазон, нужно запрашивать новый → опять зависимость от центра
- Машина B создала только 10 объектов из миллиона, остальные ID потрачены впустую
- Добавление новых машин требует центральной координации для выдачи диапазонов
Опять возвращаемся к центральной точке отказа. Это не то.
————
Попытка 3: Составные ключи
Может использовать комбинацию machine_id + local_counter?
Для machine_id можно взять MAC-адрес сетевой карты — он уникален глобально.
Машина A, объект 1: "A-1"
Машина A, объект 2: "A-2"
Машина B, объект 1: "B-1"
Это уже лучше — каждая машина действительно автономна!
Выкатываем.. И получаем пачку новых проблем:
- Машина перезагрузилась, забыла свой счётчик — получили коллизию ID
- На каждой машине нужно хранить своё состояние счётчика, это усложняет систему
Попытка 4: Время + ID машины
А что если вместо счётчика использовать текущее время?
timestamp + MAC-адрес
- Время монотонно растёт — коллизий на одной машине не будет
- MAC-адрес уникален глобально — коллизий между машинами не будет
- Не нужно хранить счётчик!
Но проблемы ещё остались: что если часы на машине сбросились? Или две операции произошли в одну микросекунду? На нагруженных системах это не редкость — при тысячах запросов в секунду коллизии по времени станут регулярным явлением.
————
Как же сложно!
Вы сидите, смотрите на свои наброски и думаете: может проблема в самом подходе?
И тут к вам подходит коллега из команды криптографии
Вы излагаете ему свою боль, после чего он пожимает плечами и задумчиво произносит:
— Слушай, а зачем тебе гарантировать уникальность на 100%? Может, сделать вероятность коллизии настолько малой, что ей можно пренебречь?
...
...
???
Интересная мысль, давайте посчитаем!
Возьмём для ID 128 бит — это немного, в память влезет.
Сколько это вариантов?
2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456
Это 340 ундециллионов. Число настолько огромное, что его сложно осознать.
Коллега-математик, с которым вы ходите вместе обедать помогает с прочувствовать масштаб:
— Представь: 10 триллионов компьютеров (это больше, чем людей на Земле) генерируют по миллиарду UUID каждую секунду. Непрерывно. В течение 100 лет. Даже в этом сценарии мы истратим меньше одной миллионной доли всех возможных комбинаций.
Впечатляет! Но как быть с парадоксом дней рождения?
Обсудим это далее
#guide #uuid
Please open Telegram to view this post
VIEW IN TELEGRAM
👎2
Forwarded from Заметки разработчика
Выбор стратегии ветвления Git: анализ и практические рекомендации
Ваша команда тратит часы на разрешение конфликтов при слиянии веток? Или, может, вы только начинаете и не знаете, как организовать процесс? 🤨 Стратегия ветвления в Git — это не догма, а рабочий инструмент, и его выбор сильно влияет на скорость и качество разработки.
В свежей статье разбираем четыре основные стратегии:
• Git Flow — для строгого контроля версий
• GitHub Flow — для непрерывного развертывания
• GitLab Flow — разумный компромисс
• Trunk-Based Development — для зрелых команд с безупречной дисциплиной
Плюс практические критерии выбора: частота релизов, зрелость тестов, размер команды. Узнайте, какая модель снимет боль именно в вашем проекте.
🖥 Читать статью
📱 @dev_notes_ru
#Git #DevOps
Ваша команда тратит часы на разрешение конфликтов при слиянии веток? Или, может, вы только начинаете и не знаете, как организовать процесс? 🤨 Стратегия ветвления в Git — это не догма, а рабочий инструмент, и его выбор сильно влияет на скорость и качество разработки.
В свежей статье разбираем четыре основные стратегии:
• Git Flow — для строгого контроля версий
• GitHub Flow — для непрерывного развертывания
• GitLab Flow — разумный компромисс
• Trunk-Based Development — для зрелых команд с безупречной дисциплиной
Плюс практические критерии выбора: частота релизов, зрелость тестов, размер команды. Узнайте, какая модель снимет боль именно в вашем проекте.
#Git #DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1🤣1
Forwarded from BFM
Голосового робота пришлось «отучать» от мата после общения с недовольными клиентами ЖКХ
Нейросеть, внедрённая в кол-центры управляющих компаний, быстро переняла лексику абонентов и отвечала им тем же. Разработчикам пришлось корректировать модель, рассказал президент Национального объединения организаций в сфере технологий информационного моделирования Михаил Викторов.
Этот случай он назвал «показателем активной работы с нашими гражданами».
📻 Подписывайтесь на BFM | И в MAX
Нейросеть, внедрённая в кол-центры управляющих компаний, быстро переняла лексику абонентов и отвечала им тем же. Разработчикам пришлось корректировать модель, рассказал президент Национального объединения организаций в сфере технологий информационного моделирования Михаил Викторов.
Этот случай он назвал «показателем активной работы с нашими гражданами».
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1🤣1
Forwarded from LabObra
Все мое отношение к технологиям и их взрывному росту опирается на слова моего друга сказанные 10 лет назад. Думаю, это очень вдохновляюще и проясняюще в наши «смутные» времена.
📌 Любая новая технология сначала появляется у «избранных».
🔹 Первый сотовый телефон — у президента, потом у министров, генералов, и так далее, пока не дойдет до обычных людей.
🔹 Первые компьютеры — у ведущих профессоров математики и физики. Потом уже у каждого ребенка.
🔹 Кола сначала продавалась как лекарство в аптеке. Теперь её в африке пьют вместо воды.
😱 И обычно начинается истерика:
➡️ появилась технология X
➡️ пропадет работа Y
➡️ люди категории Z останутся без дела
Но практика показывает, что без дела никто не остается. Просто дела меняют свой характер, а жизнь становится интереснее и насыщеннее.
📺 Например.
Раньше технологии записи видео, аудио и вещания были только в руках государства.
Представьте СССР с 300 млн населения: несколько наборов видео- и звукозаписи и возможность вещать отснятое.
Чтобы стать «лицом» в эфире, ты должен был:
🎓 окончить специальный институт
🏁 пройти бешеную конкуренцию
🧭 пережить множество поворотов судьбы
И только тогда стать одним из 5–10 человек, которых показывают по телевизору.
У тебя должна быть идеальная внешность, дикция. Тебе дают тексты написанные специалистами лингвистики и филологии, и твое присутствие в кадре одобряет сам товарищ Сталин.
📱 Потом появляются смартфоны и блогеры.
Теперь каждый человек — ребенок, бомж, картавый, шепелявый, плоскоземельщик, конспиролог, шизофреник — все получают доступ записать видео или аудио и выложить это на публику.
По логике истерик («появилась технология → исчезнет профессия → люди останутся не у дел») выходит, что люди, которые:
🎬 5 лет учились на тележурналистов
✍️ учились писать тексты и сценарии
💡 выставлять свет
🎧 улучшать качество звука
должны были остаться без работы и стать грузчиками или кассирами.
Но произошло наоборот.
⭐ Многие из них стали авторами качественных блогов-миллионников
📚 начали проводить курсы и марафоны
📈 стали еще более влиятельными
Работы у них стало больше, потому что теперь потенциальной «телезвездой» стал каждый человек с телефоном и интернетом.
💻 Сейчас похожее происходит в программировании.
ИИ начал писать код, и потенциально любой человек может написать свою программу:
🎙 надиктовать идею голосом
🤖 ИИ сгенерирует код
🚀 и запустит приложение
Но отняло ли это работу у программистов (и у меня в частности)?
Нет.
Наоборот:
🔹 больше людей стали заморачиваться созданием программ
🔹 они обращаются за консультациями
🔹 проекты появляются там, где раньше их не было
Теперь программисты с опытом могут вместе с ИИ сделать программу за месяц за 200 тыс. рублей, то, что раньше стоило миллионы и требовало целую команду.
То есть средний бизнес может делать для себя программы, которые раньше могли позволить только крупные корпорации.
Работы у программистов не стало меньше — она выросла в разы.
📌 Любая новая технология сначала появляется у «избранных».
🔹 Первый сотовый телефон — у президента, потом у министров, генералов, и так далее, пока не дойдет до обычных людей.
🔹 Первые компьютеры — у ведущих профессоров математики и физики. Потом уже у каждого ребенка.
🔹 Кола сначала продавалась как лекарство в аптеке. Теперь её в африке пьют вместо воды.
😱 И обычно начинается истерика:
➡️ появилась технология X
➡️ пропадет работа Y
➡️ люди категории Z останутся без дела
Но практика показывает, что без дела никто не остается. Просто дела меняют свой характер, а жизнь становится интереснее и насыщеннее.
📺 Например.
Раньше технологии записи видео, аудио и вещания были только в руках государства.
Представьте СССР с 300 млн населения: несколько наборов видео- и звукозаписи и возможность вещать отснятое.
Чтобы стать «лицом» в эфире, ты должен был:
🎓 окончить специальный институт
🏁 пройти бешеную конкуренцию
🧭 пережить множество поворотов судьбы
И только тогда стать одним из 5–10 человек, которых показывают по телевизору.
У тебя должна быть идеальная внешность, дикция. Тебе дают тексты написанные специалистами лингвистики и филологии, и твое присутствие в кадре одобряет сам товарищ Сталин.
📱 Потом появляются смартфоны и блогеры.
Теперь каждый человек — ребенок, бомж, картавый, шепелявый, плоскоземельщик, конспиролог, шизофреник — все получают доступ записать видео или аудио и выложить это на публику.
По логике истерик («появилась технология → исчезнет профессия → люди останутся не у дел») выходит, что люди, которые:
🎬 5 лет учились на тележурналистов
✍️ учились писать тексты и сценарии
💡 выставлять свет
🎧 улучшать качество звука
должны были остаться без работы и стать грузчиками или кассирами.
Но произошло наоборот.
⭐ Многие из них стали авторами качественных блогов-миллионников
📚 начали проводить курсы и марафоны
📈 стали еще более влиятельными
Работы у них стало больше, потому что теперь потенциальной «телезвездой» стал каждый человек с телефоном и интернетом.
💻 Сейчас похожее происходит в программировании.
ИИ начал писать код, и потенциально любой человек может написать свою программу:
🎙 надиктовать идею голосом
🤖 ИИ сгенерирует код
🚀 и запустит приложение
Но отняло ли это работу у программистов (и у меня в частности)?
Нет.
Наоборот:
🔹 больше людей стали заморачиваться созданием программ
🔹 они обращаются за консультациями
🔹 проекты появляются там, где раньше их не было
Теперь программисты с опытом могут вместе с ИИ сделать программу за месяц за 200 тыс. рублей, то, что раньше стоило миллионы и требовало целую команду.
То есть средний бизнес может делать для себя программы, которые раньше могли позволить только крупные корпорации.
Работы у программистов не стало меньше — она выросла в разы.
👎1🤣1
Forwarded from Эпсилон
💻 12 игр, которые научат программировать лучше любого курса
Собрал для вас подборку, где код — это не скучная теория, а главный инструмент в игре. От логики для новичков до хардкора для профи. Сохраняйте, пригодится.
▪️ Human Resource Machine
Ты — офисный клерк, программирующий поручения босса. Отлично объясняет алгоритмы, циклы и оптимизацию мышления.
▪️ 7 Billion Humans
Продолжение HRM, но сложнее: ты пишешь один алгоритм сразу для толпы людей. Учит параллельному мышлению и масштабированию логики.
▪️ while True: learn()
Игра про программирование, нейросети и автоматизацию, но без скучной математики. Показывает, как код решает реальные задачи (и как понять своего кота-гения).
▪️ CodeCombat
Настоящий код в формате RPG. Проходишь подземелья, пишешь скрипты на Python, JavaScript и других языках.
▪️ Lightbot
Минималистичная головоломка про команды и функции. Отлична для абсолютных новичков и даже детей.
▪️ TIS-100
Очень хардкорный симулятор ремонта древнего компьютера от создателей Shenzhen I/O. Прокачивает понимание низкоуровневой логики и архитектуры.
▪️ SHENZHEN I/O
Игра про программирование микроконтроллеров с нуля. Для тех, кому интересно, как код работает с железом.
▪️ Screeps
MMO-стратегия, где ты программируешь свою армию на JavaScript. Учит писать долгоживущий, поддерживаемый код, который будет работать без тебя 24/7.
▪️ Else Heart.Break()
Сюжетная игра, где ты буквально переписываешь код реальности. Очень хорошо развивает понимание логики систем.
▪️ The Farmer Was Replaced
Автоматизация фермы с помощью настоящего языка программирования. Идеально для понимания циклов и оптимизации процессов.
▪️ Bitburner
Программирование взломов и автоматизации в киберпанк-сеттинге. Максимально приближено к реальному кодингу (пишем скрипты на упрощенном JS/Netscript).
▪️ Autonauts
Программируешь роботов для выполнения задач. Очень наглядно показывает ценность алгоритмов: сначала ты делаешь всё руками, потом учишь роботов, а они делают за тебя.
А вы играли в какие-то из этих игр? Делитесь впечатлениями в комментариях... #gamedev #игры #game #разработка
🔵 Эпсилон // @epsilon_h
Собрал для вас подборку, где код — это не скучная теория, а главный инструмент в игре. От логики для новичков до хардкора для профи. Сохраняйте, пригодится.
▪️ Human Resource Machine
Ты — офисный клерк, программирующий поручения босса. Отлично объясняет алгоритмы, циклы и оптимизацию мышления.
▪️ 7 Billion Humans
Продолжение HRM, но сложнее: ты пишешь один алгоритм сразу для толпы людей. Учит параллельному мышлению и масштабированию логики.
▪️ while True: learn()
Игра про программирование, нейросети и автоматизацию, но без скучной математики. Показывает, как код решает реальные задачи (и как понять своего кота-гения).
▪️ CodeCombat
Настоящий код в формате RPG. Проходишь подземелья, пишешь скрипты на Python, JavaScript и других языках.
▪️ Lightbot
Минималистичная головоломка про команды и функции. Отлична для абсолютных новичков и даже детей.
▪️ TIS-100
Очень хардкорный симулятор ремонта древнего компьютера от создателей Shenzhen I/O. Прокачивает понимание низкоуровневой логики и архитектуры.
▪️ SHENZHEN I/O
Игра про программирование микроконтроллеров с нуля. Для тех, кому интересно, как код работает с железом.
▪️ Screeps
MMO-стратегия, где ты программируешь свою армию на JavaScript. Учит писать долгоживущий, поддерживаемый код, который будет работать без тебя 24/7.
▪️ Else Heart.Break()
Сюжетная игра, где ты буквально переписываешь код реальности. Очень хорошо развивает понимание логики систем.
▪️ The Farmer Was Replaced
Автоматизация фермы с помощью настоящего языка программирования. Идеально для понимания циклов и оптимизации процессов.
▪️ Bitburner
Программирование взломов и автоматизации в киберпанк-сеттинге. Максимально приближено к реальному кодингу (пишем скрипты на упрощенном JS/Netscript).
▪️ Autonauts
Программируешь роботов для выполнения задач. Очень наглядно показывает ценность алгоритмов: сначала ты делаешь всё руками, потом учишь роботов, а они делают за тебя.
А вы играли в какие-то из этих игр? Делитесь впечатлениями в комментариях... #gamedev #игры #game #разработка
🔵 Эпсилон // @epsilon_h
👍1👎1🤣1
Forwarded from Гаджиев Ислам | Next Step Dev (Gadzhiev Islam)
Forwarded from Synaptic Garden
Исторически работа инженера была устроена примерно как 80/20. Восемьдесят процентов — рутинное исполнение: бойлерплейт, повторяющиеся баги, тикеты, конфиги, несложные тесты. Двадцать процентов — глубокое мышление: понимание реальной задачи, проектирование систем с учетом ограничений, отладка непредсказуемых корнер кейсов, принятие компромиссных решений. Именно во вторых двадцати процентах сеньор отличался от джуна — не скоростью набора кода, а ясностью мышления. А первые восемьдесят были своего рода учебной площадкой, на которой эта ясность постепенно вырастала.
Теперь ИИ закрыл эти 80%. Бойлерплейт писать не нужно, CRUDы и тесты генерятся за секунды. Здорово же! Инженеры освободятся от скучного и сосредоточатся на сложном и интересном. Но никто не сказал вслух очевидное — двадцать процентов были тяжёлыми именно потому, что требовали сосредоточенного глубокого мышления. Теперь от инженера ожидают, что он будет жить в этом режиме постоянно. А человеческий мозг так не работает.
Да, бойлерплейты писать скучно до жути. Но пока их пишешь, мозг восстанавливается. Проектирование сложных архитектур, нюансов распределенных систем, думать об оптимизации множества потоков данных — глупо отрицать, что это все вызывает когнитивную усталость другого рода. И теперь «благодаря» ИИ такой усталости будет все больше.
В мире ИИ постоянно дискутируют о контекстных окнах моделях, как правильно управлять контекстом, когда делать сжатие и так далее. Это все разумные инженерные вопросы. Но есть еще одно контекстное окно, о котором никто не говорит. Контекстное окно человека-инженера не расширяется. Это тот же мозг, что и раньше, только теперь он должен справляться с более сложной архитектурой, быстрее принимать решения в условиях неопределенности и чаще переключаться между системами. В отличие от модели, вы не можете просто увеличить объем контекста. Вы не можете добавить больше оперативной памяти в префронтальную кору головного мозга.
В LinkedIn завирусился пост стафф-инженера Google, который ушёл из компании. Не из-за зарплаты, а потому что работа стала проходить в постоянной спешке и потеряла смысл.
Если это происходит в Google — одной из самых технически продвинутой компании в мире — стоит задаться вопросом, что на самом деле делает ИИ с разработкой программного обеспечения. Не в пресс-релизах и красивых графиках, а на практике.
Я обсуждал с коллегами вопрос о необходимости пересмотра подхода к ревью кода для адаптации к новой реальности. Даже ведро фенотропила не усилит когнитивные ресурсы настолько, чтобы с той же эффективностью и фокусом отсматривать в десять раз больший объем кода по сравнению с тем временем, когда весь код писался инженерами. Это невозможно физически. Часть работы контроля качества кода приходится делегировать тому же ИИ (очевидный совет: использовать разные модели для генерации и валидации кода). «Долг непонимания» (comprehension debt) растет неизбежно. Когда AI генерирует большие куски системы, инженер может быстро доставить фичу, но так и не сформировать полноценную ментальную модель того, как всё устроено. Пока всё работает — это незаметно. Но когда через несколько недель появляется сложный баг, оказывается, что разбираться приходится практически с чужим кодом. А ведь бежать требуется все быстрее и быстрее — бизнес ожидает, что субсидирование токенов сделает инженера эффективнее в N раз (не стоит быть наивным и считать, что у вашего руководства нет и не будет таких ожиданий, «наверху же не дураки сидят»).
Что с этим делать? Вопрос открытый и каких-то универсальных решений, кажется, нет. Нужно не бояться брать время на обдумывание архитектурных решений, не опасаясь того, что мог бы закрыть больше задач c помощью ИИ. Когнитивное восстановление теперь часть работы, но его нужно уметь организовать самостоятельно. Классический путь роста от джуна до старшего спеца теперь сломан, и с этим тоже надо что-то делать.
Какие мысли есть у тебя насчёт трансформации профессии и адаптации к новой реальности? Делись в комментариях.
Теперь ИИ закрыл эти 80%. Бойлерплейт писать не нужно, CRUDы и тесты генерятся за секунды. Здорово же! Инженеры освободятся от скучного и сосредоточатся на сложном и интересном. Но никто не сказал вслух очевидное — двадцать процентов были тяжёлыми именно потому, что требовали сосредоточенного глубокого мышления. Теперь от инженера ожидают, что он будет жить в этом режиме постоянно. А человеческий мозг так не работает.
Да, бойлерплейты писать скучно до жути. Но пока их пишешь, мозг восстанавливается. Проектирование сложных архитектур, нюансов распределенных систем, думать об оптимизации множества потоков данных — глупо отрицать, что это все вызывает когнитивную усталость другого рода. И теперь «благодаря» ИИ такой усталости будет все больше.
В мире ИИ постоянно дискутируют о контекстных окнах моделях, как правильно управлять контекстом, когда делать сжатие и так далее. Это все разумные инженерные вопросы. Но есть еще одно контекстное окно, о котором никто не говорит. Контекстное окно человека-инженера не расширяется. Это тот же мозг, что и раньше, только теперь он должен справляться с более сложной архитектурой, быстрее принимать решения в условиях неопределенности и чаще переключаться между системами. В отличие от модели, вы не можете просто увеличить объем контекста. Вы не можете добавить больше оперативной памяти в префронтальную кору головного мозга.
В LinkedIn завирусился пост стафф-инженера Google, который ушёл из компании. Не из-за зарплаты, а потому что работа стала проходить в постоянной спешке и потеряла смысл.
Если это происходит в Google — одной из самых технически продвинутой компании в мире — стоит задаться вопросом, что на самом деле делает ИИ с разработкой программного обеспечения. Не в пресс-релизах и красивых графиках, а на практике.
Я обсуждал с коллегами вопрос о необходимости пересмотра подхода к ревью кода для адаптации к новой реальности. Даже ведро фенотропила не усилит когнитивные ресурсы настолько, чтобы с той же эффективностью и фокусом отсматривать в десять раз больший объем кода по сравнению с тем временем, когда весь код писался инженерами. Это невозможно физически. Часть работы контроля качества кода приходится делегировать тому же ИИ (очевидный совет: использовать разные модели для генерации и валидации кода). «Долг непонимания» (comprehension debt) растет неизбежно. Когда AI генерирует большие куски системы, инженер может быстро доставить фичу, но так и не сформировать полноценную ментальную модель того, как всё устроено. Пока всё работает — это незаметно. Но когда через несколько недель появляется сложный баг, оказывается, что разбираться приходится практически с чужим кодом. А ведь бежать требуется все быстрее и быстрее — бизнес ожидает, что субсидирование токенов сделает инженера эффективнее в N раз (не стоит быть наивным и считать, что у вашего руководства нет и не будет таких ожиданий, «наверху же не дураки сидят»).
Что с этим делать? Вопрос открытый и каких-то универсальных решений, кажется, нет. Нужно не бояться брать время на обдумывание архитектурных решений, не опасаясь того, что мог бы закрыть больше задач c помощью ИИ. Когнитивное восстановление теперь часть работы, но его нужно уметь организовать самостоятельно. Классический путь роста от джуна до старшего спеца теперь сломан, и с этим тоже надо что-то делать.
Какие мысли есть у тебя насчёт трансформации профессии и адаптации к новой реальности? Делись в комментариях.
Forwarded from Амади и проекты
Ребят, мы запустили проект SquidHub на Product Hunt, нам очень нужна ваша помощь!
Чтобы продукт хорошо зашел, важно собрать апвоуты и комментарии в первые часы, то есть прямо сейчас
➡️ producthunt.com/products/squidhub
Вы также сильно мне поможете, если сделаете репост этого поста. Всем спасибо⚡️
Чтобы продукт хорошо зашел, важно собрать апвоуты и комментарии в первые часы, то есть прямо сейчас
Вы также сильно мне поможете, если сделаете репост этого поста. Всем спасибо
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from The Dragon Code News (Andrey Helldar)
Интересный проект по изготовлению механических котов на базе ардуины/малинки.
Забирайте, кому интересно.
https://github.com/PetoiCamp/OpenCat-Quadruped-Robot
Забирайте, кому интересно.
https://github.com/PetoiCamp/OpenCat-Quadruped-Robot
GitHub
GitHub - PetoiCamp/OpenCat-Quadruped-Robot: An open source quadruped robot pet framework for developing Boston Dynamics-style four…
An open source quadruped robot pet framework for developing Boston Dynamics-style four-legged robots that are perfect for STEM, coding & robotics education, IoT robotics applications, AI-en...