Если вы до сих пор пытаетесь выстроить нормальную работу в таск-трекере — расслабьтесь. Это скучно и неблагодарно. Гораздо интереснее использовать эти 11 вредных советов.

Недавно я тут на Хабре написал цикл статей про «Запрещенные фразы для ИТ-менеджера». Это фразы которыми неопытные менеджеры пытаются отбиться от неожиданных задач, и это же фразы, от которых почему то плохо заказчикам, бизнесу и начальству.

Там я разбирался почему плохо, и почему фразы:

— Этого нет в ТЗ!

— Этого нет в должностной инструкции!

— У меня нет на это ресурсов!

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

Каждая статья собрала больше 10 000 прочтений, и в каментах к каждой был вопрос: «Окей, чел, если так говорить нельзя, то как можно? Расскажи и покажи на примерах, раз такой умный!»

Это — мой ответ на вопрос, а заодно — легкая шпаргалка, которую можно сохранить и применять постоянно, отправляя тем, кто этого подхода еще не знает.

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

Основана она на моем личном опыте (см профиль), на опыте менеджеров, у которых я этому учился и на опыте менеджеров, которых я этому учил сам, как РПО и ментор.

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь, там уже почти 4000 манагеров, также читайте мои статьи тут, на Хабре.

Итак, поехали.

Вчера мой скрипт завис. Процессор горел на 100%. Я убил процесс.

Я Senior Developer с 10 годами опыта. Пишу на Python, знаю Java и много модных фреймворков. Но в этот момент я понял: я не умею программировать. Точнее, я умею использовать инструменты. Но я не понимаю природу вычислений.

Эта статья — о том, как одна математическая задача изменила моё понимание разработки.

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

Возможно, и тебя тоже.

Программирование, да и вообще в целом ИТ — это всегда про компромиссы. Выигрывая в чём-то одном, мы обязательно проигрываем в чём-то другом. Не существует той самой «серебряной пули», то есть инструмента, решающего абсолютно все задачи. Также не бывает и идеального языка программирования. Но что если я скажу вам, что существует почти идеальный язык? И это Rust. Далее я постараюсь обосновать свои доводы, чтобы в глазах читателей на казаться слепым крабом фанатом очередной хайповой технологии.

За свой почти 14-летний путь в ИТ я успел профессионально поработать на нескольких языках программирования: PHP, Ruby, JS/TS, также мне доводилось «потрогать» Python, Go, даже Clojure и Haskell. Каждый имеет свои недостатки: у PHP — кривая архитектура, у Ruby — медленная работа, у функциональных языков — недостаток библиотек и обучающих материалов. При разработке на них каждый раз приходится идти на уступки и выбирать между изящным синтаксисом, скоростью работы и написанием «велосипедов» на каждый чих. В Rust всё обстоит совсем иначе и вот почему.

Вы проектируете масштабируемую систему на System Design интервью в BigTech. Всё идёт хорошо, пока вам не задают неожиданный вопрос. От ответа на который зависит ваше прохождение.

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

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

Всем привет, меня зовут Олег Юрчик, я старший разработчик в Cloud.ru. Современный интернет — это не только IT-гиганты и готовые облачные сервисы. Под капотом глобальной сети скрываются базовые принципы, которые может воспроизвести любой технический специалист. В этой статье сначала вспомним, как появился Интернет и как он работает. А затем разберем, как создать его уменьшенную, но полностью управляемую копию с собственными DNS, центром сертификации и веб-сервисами.

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

Привет, Хаброжители!

Большинство книг об алгоритмах фокусируются на нотации «О большое» и основных принципах проектирования, однако эта книга предлагает уникальный подход, выводя разработку и анализ на уровень предсказуемой практической эффективности. В ней обсуждаются базовые и классические алгоритмические задачи, возникающие при создании приложений больших данных, для которых демонстрируются элегантные решения постепенно возрастающей сложности. Анализ решений дается в рамках как классической RAM-модели, так и более значимой с практической точки зрения модели с использованием внешней памяти, позволяющей оценивать сложность ввода-вывода.

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

Все мы знаем эту формулу. .

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

Но задавали ли вы себе когда-нибудь вопрос: почему именно квадраты?
Почему не кубы? Почему не просто сумма модулей ?

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

Сегодня мы разберем этот «черный ящик» и увидим, что теорема Пифагора — это вовсе не про треугольники. И доказывать её нужно совсем не так, как нас учили.

Школьная программа не дает ответа. Более того, история преподавания теоремы Пифагора — это история того, как живую, наглядную геометрию превращали в сухую, мертвую алгебру. Нас уводили всё дальше от понимания сути в сторону абстракции.

Сегодня мы разберем этот путь деградации и покажем доказательство, которое вернет вас к реальности. Спойлер: теорема Пифагора — это не про треугольники. Она про зеркала.

Приготовьтесь к полному разрыву всех шаблонов!

Привет, Хабр. С вами снова Вадим.

В прошлом посте я рассказывал, как написал AI‑бота Аврора, который ищет вакансии вместо меня.

Статья залетела, и к нам пришли первые 100 тестеров. И тут началось веселье.

Представьте: вы нажимаете кнопку «Найти работу», а бот молчит. 10 секунд, 20 секунд. Вы думаете: «Сломалось» и жмете кнопку еще 5 раз.

А на самом деле бот не сломался. Он просто «ушел на кухню готовить».

В этой статье расскажу, как мы переписали архитектуру с «однорукого повара» на «промышленный конвейер», зачем использовали SQL вместо модного Redis и как наша скорость стала нашей проблемой.

Если вы разработчик — найдете тут код про SKIP LOCKED.

Если вы ищете работу — поймете, почему наш бот теперь быстрее, чем пальцы любого рекрутера.

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

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

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

Результаты исследования помогут вам увидеть, как устроены эти сферы изнутри и где вам комфортнее расти и работать.

Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.

Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.

Разбирать методику будем в AI редакторе Cursor, но повторить ее вы сможете в любом кодовом ассистенте. Поехали...

Прослеживается тенденция, что сложность CLB повышается, сами примитивы становятся хитрее. От сюда вытекает вопрос, а на сколько эффективными становятся ячейки, и сколько ресурсов ПЛИС они экономят в сравнении с предыдущими поколениями?

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

Вся история цивилизации — это поиск идеального ритма. Но все наши маятники и кварцевые резонаторы были попытками измерить секунду по колебаниям ветра. В 1967 году мы, казалось, нашли абсолют: эталоном секунды объявили 9 192 631 770 колебаний атома цезия. Но и у этого триумфа был изъян.

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

Почему одни проекты мы бросаем, а другие — тащим годами?

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

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

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

Представьте себе ситуацию: компании по всему миру (и Россия не исключение) жалуются на острейший кадровый голод, не могут найти сотрудников с нужными навыками, и это ставит под удар их рост и конкурентоспособность. В то же время миллионы людей активно ищут работу, готовы трудиться полный день, но остаются не у дел. Их резюме годами пылятся в базах, не доходя до рекрутера. На Хабре постоянно выходят гневные статьи про то, что даже сверхопытные разрабы, менеджеры и дизайнеры вынуждены откликаться на сотни вакансий ради одного-двух приглашений в течение полугода. Зачастую их резюме или не просматривают, или после пяти секунд оценки ботом приходит стандартный вежливый отказ. Matrix has you! 

Это не сценарий из антиутопии, а суровая реальность, которую в своем исследовании «Скрытые работники: неиспользуемый талант» (Hidden Workers: Untapped Talent) описали эксперты Harvard Business School и Accenture. Авторы вводят термин «скрытые работники» (hidden workers) — это не те, кто прячется от работы, а те, кого система найма по разным причинам «не видит».

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

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

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

Сегодня поговорим о том, как CPython управляет памятью для малых целых чисел (почему диапазон выбран именно от -5 до 256?), как работает паттерн Flyweight на уровне ядра языка и почему две одинаковые строки могут иметь разные id. А также разберем неочевидную разницу работы компилятора в интерактивной оболочке (REPL) и при запуске скриптов.