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

В какой-то момент моей карьеры меня перестало радовать ПО которое я разрабатывал.

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

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

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

Ко мне в коучинг пришёл джентльмен. Чуть меньше 20 лет опыта в разработке. Одна из ключевых задач, которая ему была интересна — Как начать литкодить каждый день?

«То настроения, то сил нету, то задачи не понимаю.. Начинаю раз в полгода и бросаю» — самый обычный набор приколов, которые мешают.

Я предложил ему обернуть всё это в привычку и дисциплину. Я собрал свою методологию прививания привычек основываясь на:

Ежедневно он тратил на Литкод 15–20 минут. Не более. Иногда участвовал в турнирах, которые и зафиксировали результат в топ 4%.

Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.

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

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

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

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

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

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

Позиция тимлида вообще предполагает relationship management, который может быть направлен как и на команду, так и наверх, в сторону стейкхолдеров. Но в этой статье я хочу поговорить именно про связку TL + Dev Team. Руководителю важно выстроить и поддерживать доверительные отношения с сотрудниками. Это поможет эффективно управлять командой и добиваться слаженной и продуктивной работы.

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

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

Меня зовут Константин, последние 6 лет я профессионально занимаюсь разработкой. К сожалению (а может быть и к счастью) у меня нет фундаментального образования по computer-science. Я решил сменить профессию после 30, поменяв предметную область с фондового рынка на программирование. И я прекрасно помню этот период времени, когда хватался любую полезную информацию в поисках того, куда и как двигаться дальше. 

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

Итак, приступим.

Привет! Меня зовут Андрей, я head of platform в финансовом маркетплейсе Банки.ру. 

Для создания своих продуктов мы применяем микросервисный подход. Он помогает нам ускорить разработку и делает ее гибкой и управляемой. Но как в любом подходе, у него есть темная сторона, проявление которой может создать кучу неприятностей и осложнить работу над проектом. Сегодня хочу поговорить об одном из таких аспектов — о сервисах-«сиротах» (так мы их ласково называем в Банки.ру, поэтому дальше кавычки ставить не буду).

Эта статья – оптимистичное и структурированное продолжение моего доклада на ту же тему, с которым я выступал в 2018 году. Текстовая версия есть на Хабре.

Годы взаимодействия с разномастными сиротами помогли их классифицировать, поэтому захотелось уделить больше внимания тому, какие сироты бывают, чем они опасны или хороши (такое тоже случается), каких нужно возвращать в семью, а от каких отказываться. Чтобы было зрелищнее и веселее, использовал образы и иллюстрации из мира «Гарри Поттера» в целом и «Фантастических тварей» в частности, прошу понять и простить. Права на изображения незыблемо принадлежат братьям Уорнер – и всё такое.

В данной статье расскажу о планировщике Go. Основу материала взял из книги Уильяма Кеннеди Ultimate Go. Вначале поговорим о планировщике OS, после перейдем к планировщику Go и сравним их.

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

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

В этой статье рассматриваются следующие сортировки: сортировка обменами, сортировка выбором, сортировка пузырьком, сортировка вставками.

Давайте представим ситуацию.

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

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

Вопрос: будете ли вы предпринимать какие-либо действия для того, чтобы Сергей заменил одного из ваших текущих руководителей?

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

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

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

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

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

А какой у вас уровень?

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

Наткнулся на данную статью случайно, когда находился в очередном поиске ответа на вопрос "Как же так?!" в интернете. Автор данной статьи занимается мобильной разработкой, но тем не менее его наблюдения и выводы касательно владения кодом разительно перекликаются с моими:

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

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