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

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

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

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

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

Последние 6 лет я работаю backend team lead. В основном это проектная разработка, но с продуктами тоже приходилось работать.

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

Нет, нет и ещё раз нет!

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

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

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

Я далек от того, чтобы делать какие-либо моральные оценки этому явлению (если
прочтете до конца, поймете, почему).  Я – тимлид с 15-летним опытом работы в IT. Я лично нанимал многих людей и со многими прощался. У меня есть своя приличная статистика откровенных мыслей и настроений людей, которые со мной работали, работают, или работают, но не со мной. На основании этого своего опыта (и не только своего) я попытаюсь дать ответ на вопрос, как и почему вырастает фига в кармане программиста. Я потяну за ниточку клубка причин и постепенно попытаюсь его распутать целиком. Результатом будет сводный граф причин феномена саботажа в IT. Поехали!

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

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

В этой статье я поделюсь своим «интересным» опытом, как я искал решение проблемы и о том, что Windows можно починить и не переустанавливать.

Getcontact — мобильное приложение, позиционирующее себя как менеджер звонков и блокировщик спама. Появилось в конце 2017-го и стремительно взлетело на первые места магазинов приложений. Создатели сервиса оценивают свою аудиторию в 400+ миллионов пользователей.

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

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

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

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

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

Наиболее успешным подходом сейчас считается норвежская инициатива Vision Zero (ноль смертей), которая постепенно распространяется в Европе. На хабре уже была разгромная статья про нее. Теперь пришло время, наоборот, похвалить Vision Zero и подчеркнуть ее плюсы.

Водитель не виноват

Виновата инфраструктура. Один из главных принципов Vision Zero - участники дорожного движения будут иногда ошибаться, а инфраструктура никогда не должна ошибаться.

Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.

Итак, четыре проблемы начинающего тимлида.

Кто интересуется темой рисующих нейросетей знают, что сейчас самый продвинутый и часто используемый интерфейс для Stable Diffusion (далее SD) это Automatic1111. Он позволяет использовать, вероятно, все существующие возможности SD на сегодня. Множество расширений, регулярные обновления и поддержка сообщества делают его мощным и удобным инструментом для генерации изображений. Но есть и альтернативные решения, одно из которых я сегодня рассмотрю.

Статья подойдет как тем кто уже пользуется Automatic1111, так и тем кто только планирует более глубоко погрузиться в мир "процедурного рисования".