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

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

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

В книге «I am sorry, I Broke Your Company» (простите, я разрушил вашу компанию) Карен Фелан, бросает вызов стереотипной культуре, навязанной консультантами и специалистами по достижению успеха. Карен есть, что сказать: она имеет тридцатилетний опыт работы консультантом, является успешным руководителем в компаниях из списка Fortune 100. 

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

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

Четыре года назад я упёрся в стену. Я работал QA инженером, изучал инструменты, автоматизацию, базы данных — но карьерного роста не было. Мне хотелось развиваться, двигаться в сторону тест-менеджмента, но одних технических навыков оказалось недостаточно. Тогда я впервые осознал, что не только харды определяют успех.

Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.

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

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

Сегодня различные методы для улучшения ваших LLM ассистентов как никогда актуальны и важны, особенно, если мы говорим про бизнес интеграцию. Сейчас расскажу про технологию Self-RAG, которую мы опробовали, почему она нам показалась выгодна в наших задачах и подводные камни, на которые мы наткнулись при развертывании данной системы. А также как мы всё это локально поднимали и делали кастом.

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

В мире программирования существуют различные идеологии написания кода, которые отвечают за коммуникации (Unix-way), гибкость (Agile), чистоту и читаемость кода (DRY, KISS).

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

Никто давно не пытается выводить теорий о том как правильно писать код.

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

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

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

Что если я скажу, что можно создать прошивку для ПЛИС на языке Verilog (VHDL), не написав ни одной строчки кода?

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

Что объединяет частицу в воде, биржевой курс и кота Барсика, бродящего по району в поисках ларька с рыбой?

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

Мы начнём с истории открытия броуновского движения — от наблюдений Роберта Броуна до формулы Альберта Эйнштейна, которая связала наблюдаемое явление с атомной гипотезой. Покажем, как идея случайного движения превратилась из гипотезы в надёжный инструмент научного анализа.

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

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

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

Привет, Хабр! Я Настя, редактор YouGile — мы делаем систему управления проектами. Когда-то мы выяснили, что первыми закрываются компании, где ставится много задач. Теперь поговорим, реально ли работать над несколькими задачами одновременно и что об этом говорят исследования.

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

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

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

Telegram — это не только мессенджер. Его функциональности достаточно, чтобы превратить этот инструмент в полноценную систему управления знаниями. В статье я расскажу, как настроить «Второй мозг» внутри Telegram, приведу простые примеры и поделюсь практическими советами.

puts "ПЛИС-культ привет, FPGA / RTL / Verification ХАБ!"

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

Несмотря на свою архаичность, Tool Command Language все же остается самым востребованным языком управления средой проектирования для ПЛИС и ASIC. ЕМНИП все эти инструменты управляются через Tcl, Vivado так уж точно, поэтому было бы не плохо научиться или хотя бы посмотреть какие инструменты отладки этих самых пресловутых Tcl-сценариев вообще существуют или существуют ли они вообще, кроме православного puts

В этой заметке, я постараюсь вам показать, что advanced tcl debugging - это не миф, а вполне реальная сущность, которая была создана еще на заре двухтысячных и не то что бы эта сущность как-то изменилась за эти 20 с небольшим лет.

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.

Вот так учишь-учишь английский, думаешь, что ты все знаешь и на коне, а потом приходишь в IT-компанию после ВУЗа и осознаёшь, что, по сути, не знала ничего.

Какие открытия я сделала для себя в английском, когда начала делать первые шаги в technical writing и переводах 13 лет назад? Я тогда тщательно фиксировала всё интересное - и делюсь этим списком с вами. Кстати, он будет полезен не только тех. писателям, но и тестировщикам, аналитикам и вообще всем, кто пишет ТЗ, отчёты и test cases.