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

Здравствуйте! Сегодня я хочу поведать вам свой путь становления как разработчика. Сейчас, на волне множества курсов и вездесущей рекламы «как войти в IT», много людей устремилось в эту бескрайнюю, интересную и очень непростую область. Я написал эту историю для них и для себя. Как некоторый взгляд в прошлое. На всё, что было сделано и чего это стоило. Кому интересно, прошу под кат.

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

^{Дисклеймер: все события являются вымышленными, а совпадения - случайными}

Все они были мертвы. Последний выстрел поставил жирную точку в этой истории. Я снял палец с курка — всё было кончено.

Макс Пэйн

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

Моё путешествие в IT наконец-то дошло до несгораемой суммы. Я, как и тысячи других до меня, кинувший работу ради мечты, добился-таки своего. Мама смотрела на меня с гордостью, а друзья — с завистью! Недоброжелатели же захлёбывались от желчи, ведь стало понятно, что я неиллюзорно переиграл и уничтожил всех дешёвок :) А сам стал иметь VIP-статус недешёвки, ведь мой работодатель уже побежал насыпать мне 100500 килорублей в секунду на мой швейцарский счёт.

Красивая история, правда? Хотите так же? Тогда переходите по этой ссылке и приобретайте курс от <default_school_name>, и через Х дней мы будем трудиться вместе!

Если вы дочитали до этого места, то наверняка поняли, о чём мы сегодня поговорим. Рекламой различных интенсивов и онлайн-курсов сейчас завален весь интернет:

Сериализация и десериализация данных — это преобразование между необработанной структурой данных и экземплярами классов для их хранения и передачи. Например, преобразование объектов Python в JSON-представление. Мы рассмотрим две популярные Python-библиотеки Marshmallow и Pydantic, которые помогут нам справиться как с преобразованием, так и с валидацией данных. Сначала я представлю вам каждую библиотеку, используя небольшие примеры, а потом мы сравним их и разберем различия. Я также расскажу, чего вам стоит избегать при работе с обеими библиотеками.

Есть принцип «выбирай любые два понятия из "быстро, качественно и дёшево"». Да, он верен для проектных историй, но не верен для разработки. В разработке, как процессе, нет никакого треугольника качества. Ты можешь делать либо быстро и качественно, либо медленно и плохо. И нет ни одной причины выбирать «медленно и плохо (и дорого)», если только не в силу привычки и неосознанности.

Случай с бомжом

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

Обычно вместо денег я даю попрошайкам-мужчинам телефон отдела кадров одной курьерской компании, которая постоянно нуждается в сотрудниках. Но у него не было ног… Тогда я подумал: «Чувак, у тебя полным полно времени. Работа за компом — лучшее, что может случиться в твоей жизни. Купон со скидкой на курс по PHP — вот, что должны были положить тебе на койку туда, где раньше были ноги, когда ты очнулся после ампутации».

Я решил предложить ему изучить программирование. В его положении он должен был быть чертовски мотивирован. Но получится ли у него?

В самом начале моей карьеры мы собеседовали тимлида Г. На собеседовании Г. был хорош, уверен в себе и показал отличные технические знания, и мы его взяли. Но буквально через пару недель человек начал вести себя не очень корректно с моей точки зрения. Я решил посоветоваться со своим непосредственным руководителем:

— Как-то мне не очень комфортно и приятно будет работать с человеком, который такое вот делает. Наверное, надо нам с ним расстаться.

На что мой руководитель резонно мне ответил:

— ${zloy_stas}, таких, как этот Г., в твоей работе будет много; если ты будешь увольнять каждого, кто тебе не понравился лично, ты быстро перестанешь быть руководителем. Твоя задача — не детей с ними крестить, а извлекать из них пользу и уметь с ними работать. Пусть этот Г. будет для тебя таким менеджерским челленджем.

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

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

Удивительно, но некоторые разработчики до сих пор считают, что коммуникации в работе не нужны или даже вредны. «Наша задача кодить, а не болтать». Конечно это эффективнее некуда, сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут. Или додумывать за ПО спорные моменты в задаче, а потом выкинуть 90 % работы и переделать заново после первого демо. Или не услышать или не понять критику на обсуждении технического решения, а потом переделывать, костылить, велосипедить и получать критические ошибки и блокеры в середине спринта. Или начать сразу разрешать инцидент, не рассказав про него владельцу продукта и бизнесу, и получить тонны негативной обратной связи от клиентов и бизнеса. Или внезапно узнать, что можно было бы обойтись меньшей кровью, ничего не разрабатывая, а решив проблему административными методами.

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

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

Хочу обратить ваше внимание на относительно молодой фреймворк Nest.js. Из коробки он предлагает заранее предопределенную архитектуру, которая заточена под максимально удобную поддержку и масштабируемость вашего приложения. Заложенные архитектурные подходы проверены временем и давно используются в других, более зрелых платформах: Java(Spring), Python(Django), PHP(Laravel) и прочих.

Авторы Nest.js не скрывают, что их вдохновил один из популярных фреймворков для клиентских приложений — Angular.js, а его авторы ориентировались на походы, используемые в Java и C#. Если вы знакомы с Angular.js, то увидите в Nest.js много схожих идей.

Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.

«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.

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

Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.

Тот, кто научится правильно измерять продуктивность разработчиков, точно станет миллионером. Особенно на текущем рынке труда, где кандидаты просто называют случайные пятизначные числа желаемой зарплаты. Есть несколько вендорских платных решений, но они не получили распространения. Никто не ставит такую систему по умолчанию, как, например, CI/CD. Давайте посмотрим на возможные подходы к измерению продуктивности и поговорим об этом в комментариях.

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

У Филиппа Кросби заслуженная репутация лидера в вопросах качества в обрабатывающей промышленности, он написал множество книг о качестве в период с 1968 по 1999 год. Среди его известных и цитируемых работ — «Качество бесплатно», «Ноль дефектов с помощью предотвращения» и «4 абсолютных принципа качества». Хотя Кросби говорил об этих темах в контексте компаний с производственными линиями, его уроки часто без изменений можно перенести на разработку ПО.

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

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

Четыре абсолютных принципа качества

1. Качество определяется как соответствие требованиям.

2. Способ обеспечения качества — предотвращение, а не оценка.

3. Стандартом работы должно быть Отсутствие Дефектов.

4. Мера качества — цена несоответствия, а не индексы.

Всем привет!

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

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

В 2021 году рынок IT — и, в частности, рынок инженеров, которые позиционируют себя как DevOps, — остается перегретым, и пока нет тенденции к его охлаждению. Спрос на специалистов высокого уровня превышает предложение. Компании, конкурируя за перспективных работников, готовы предлагать хорошие условия. Проблема заключается в том, что в погоне за высокими зарплатами пострадало качество набора. Сегодня хотелось бы поговорить о том, какие кандидаты будут привлекать работодателя выдать заветный оффер.

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

def foo():
try:
return 1
finally:
return 2

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

Привет. Сегодня я расскажу о работе с геоданными в PostgreSQL и немного о том, как это сделать в своем Java/Kotlin-приложении.

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

Эту историю я услышал от своего друга из финтеха. История мне понравилась тем, что все мы стараемся защищать свои персональные данные, соблюдаем цифровую гигиену, но на самом базовом (я бы сказал, фундаментальном уровне) всё просто.

Добро пожаловать под кат, далее будет интересно.

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

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

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

Одним из инструментов для анализа качества и usability страницы с составлением отчёта является PageSpeed Insights (далее просто PageSpeed).

Какие вопросы я затрону в статье:

• что такое PageSpeed;
• как измеряется и оценивается производительность;
• лирическое отступление: critical render path;
• способы оптимизации PageSpeed;
• для чего это нужно?