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

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

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

Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».

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

Продуктовый разработчик — это следующая ступень эволюции разработчика, который активно участвует в бизнес-процессах. © Никита Пастухов, мейнтейнер FastStream

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

Так вышло, что кроме России, я работал в Европе, Казахстане и Австралии и немного в США. И мне есть что сказать на тему «чем отличается российский стиль менеджмента от Европейско-американского».

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

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

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

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

Итак начнем с первого и очевидного вопроса:

Перед собеседованием (и тем более перед принятием оффера!) обязательно нужно проверить компанию: финансы, продукт, культура, отзывы, юридическая информация, сотрудники, руководство.

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

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

Этот опыт настиг меня в самом начале карьеры Руководителя ИТ-проектов (далее – РП). Поэтому все истории мне пришлось пройти, не имея ни многолетнего опыта управления проектами, ни вообще какого-либо образования менеджера.

Все что у меня было — это большое желание расти и достигать поставленных целей. А инструменты мне пришлось искать по пути) И я не о типичных пунктах из PMBoK!

Меня зовут Алина Прасковина, я руководитель проектов в MONS, «КОРУС Консалтинг». И прежде чем раскрыть секреты своей системы, расскажу предысторию: как же так случилось, что на еще совсем юного РП свалилось такое количество проектов?

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

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

Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.

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

Агрессия вместе с страхом являются древнейшими эмоциями, поэтому присутствуют практически у всех существ с нервной системой. И если у большинства организмов агрессия проявляется только в двух случаях: при нападении и при защите, у нас очень разнообразные формы агрессии. Помимо примитивной формы физической агрессии, мы разработали множество других; это и пассивная агрессия, и буллинг, и вынос мозга, и разнообразнейшие виды наездов, сарказм и куча других. Агрессия самый простой, самый быстрый и наименее затратный способ добиться результата или по крайней мере сбросить негатив на ближнего своего, поэтому она широко применяется Хомо. Ребенок не слушается - наори, подчинений ленится - обложи его матом, муж никак не прибьет гвоздик - вынеси мозг, попутно вспомнив все его грехи, а если просто скучно, всегда можно устроить эмоциональные качели кому-нибудь. Человеческая фантазия поистине безгранична в том числе и в видах агрессии. Кто-то пускает в ход агрессию только когда нет иного выхода, а кто-то сразу переходит в нападение, дабы сэкономить время и ресурсы.

Есть два аспекта которые нужно учитывать в рассмотрении половых отличий, генетический и культурологический, они часто переплетаются и искажают общую картину, в том числе и в случае агрессии. Давайте попытаемся разобраться кто же в итоге агрессивнее: мужчины или женщины?

Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.

Американцы обожают играть на деньги и смотреть красочное шоу. Это самое примитивное и оттого ошибочное объяснение популярности программы The Price Is Right. Если вы никогда не видели эту передачу дневного американского телевидения, представьте себе многолетнюю светскую церемонию потребления, где зрителей зовут на сцену и награждают за умение ориентироваться в ценниках. Зритель из зала слышит заветную фразу «Come on down!», выбегает к подиуму и соревнуется в угадывании стоимости бытовых товаров.

Впервые формат появился в 50-х годах прошлого века, а в 1972 году The Price Is Right подобновили и начали транслировать днём по будням на канале CBS. Но идёт передача не в прайм-тайм, а в 10:00 или 11:00 утра. Несмотря на её странное время показа, знакома она всем американцам. Смотрят её не только пенсионеры и домохозяйки, её хотя бы раз видели затемпературившие дети, которые вместо школы остались дома.

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

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

Идея сделать приложение-визуализатор пришла после чтения книги CPython Internals. Там подробно объясняется, как устроены арены, пулы и блоки. Но пока читаешь текст, всё это воспринимается слишком абстрактно. Захотелось увидеть механику своими глазами: как память выделяется, как освобождается и почему иногда остаётся занята. Так и появился MemoryMonitorApp, а вместе с ним — эта статья.

Пациенты часто искренне очень стараются как можно лучше описать доктору своё состояние.

Любой начинающий стоматолог бывал смущён выражениями типа «А у меня неправильный привкус?», «Депультируйте мне зуб» и «Если есть верхнее нёбо, то значит, есть и нижнее».

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

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

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

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

Привет, Хабр!

Меня зовут Артем Лакомов, я филолог из МГУ. Да, вы не ослышались. И сегодня я хочу поговорить с вами о самой главной (и самой дорогой) боли в IT, но с совершенно неожиданной стороны.

Каждый из вас хоть раз в жизни видел код, от которого хотелось плакать или же тихо ненавидеть свою работу. Код с переменными вроде data, res, temp. Код, где есть один гигантский класс, который делает абсолютно всё, и коллеги с любовью (или ужасом) называют его godObject.

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

Последние несколько лет я занимаюсь тем, что применяю классическую лингвистику к программному коду. И я обнаружил поразительную вещь: правила, по которым вы даете имена переменным и классам, практически дословно повторяют законы, по которым в любом человеческом коллективе — от школьного класса до команды разработчиков — возникают прозвища.

Давайте я покажу вам, как теория прозвищ, разработанная великим отечественным лингвистом А.В. Суперанской, вскрывает то, о чем инженеры только догадывались интуитивно, но, увы, не могли сформулировать.

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

За годы профессионального пути мне довелось побывать в самых разных ролях: от рядового сотрудника до руководителя, от наставника до консультанта. Я работал и в государственных учреждениях, и в частных компаниях, и в крупных корпорациях, и в небольших стартапах.

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

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

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

Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.

Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что он «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.

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

Ко мне тут пришло одно уважаемое айтишное издание и попросило комментарий на тему технического долга. Как бы, сразу возникают два вопроса. Вопрос номер раз — им это зачем? И вопрос номер два — а я тут при чем? (есть люди, которые гораздо лучше в теме разбираются). Но как-то они сами не сказали. А я как-то не спросил…

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