Привет, Хабр! Меня зовут Капитолина Кузнецова, я Ruby-разработчик и на своём текущем месте работы в Купере (ex СберМаркет) доросла до роли тимлида. За 2,5 года я, так сказать, освоилась в этом статусе и, если верить моей команде, руководитель из меня получился неплохой, но вьетнамские флэшбэки о своих первых месяцах работы в новой роли ещё свежи.

Быть начинающим тимлидом — это...

- когда встречи занимают по семь, восемь, а то и девять часов подряд;

- когда ты целый день что-то делаешь, дико устаешь, а в конце не видишь никакого результата;

- когда о Jira знаешь больше, чем о собственной семье, а встречи с друзьями планируешь на новогодние праздники 2025 года.

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

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

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

Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

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

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

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

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

Меня зовут Настя, я руководитель службы инструментов репозитория в Yandex Infrastructure. Больше 15 лет я проработала в IT-индустрии: сначала как разработчик, потом тимлид, техлид, менеджер проектов и руководитель службы. За это время несколько сотен человек рассказали мне о своём карьерном пути: кто-то собеседовался со мной как с нанимающим менеджером, кто-то приходил ко мне на менторинг, кто-то расширял свой нетворк, как теперь модно говорить. Из этих разговоров можно выделить причины недовольства работой, которые я вижу у людей чаще остальных. Одна из главных причин — ошибка выбора вакансии.  

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

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

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

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

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

Перевод статьи разработчика из Южной Кореи.

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

1) Быть перфекционистом

Ничто не идеально, и я уверен, что «идеального кода» не существует тоже.

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

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

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

В общей сложности я разбираю 10 самых распространённых ошибок "эффективных менеджеров" и показываю гуманные и более действенные подходы.

В 2018 году команда организационного развития Google поставила перед собой вопрос — что влияет на эффективность команд? Что их делает результативными и успешными?

Исследователи собрали более 250 «маркеров» эффективности, проинтервьюировали 200 команд по всему миру, а также задействовали 35 статистических модели и «кодировали» более 170 000 слов во внутренних отчетах компании.

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

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

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

Я не понимаю, как на это реагировать. Некий товарищ полгода спрашивает у меня советы как начать с Verilog/FPGA/ASIC, но при этом ничего не начинает, хотя его вопросы становятся все более экзотическими. Чтобы было понятнее, опишу как бы это выглядело для программирования. Предположим к вам пришел молодой человек и спрашивает как научиться программировать. Вы ему говорите что-нибудь типа:

"Сесть за компьютер, написать и запустить программу Hello, world. Одновременно скачать книжку с описанием языка и базовых приемов и читать ее в общественном транспорте, перед сном и в приемной у зубного врача. Периодически садиться за компьютер, написать и отладить программы: сортировки массива, игры Жизнь, ханойских башень итд. С выводом на текстовый терминал, окно в GUI или веб-страницу - по вкусу. Далее вы поймете в какую сторону копать или не идти в это дело вообще."

Молодой человек вас горячо благодарит и уверяет как он сильно хочет стать настоящим программистом. Потом он Hello, world не пишет и никакой книжки читать не начинает, но последовательно спрашивает у вас:

Меня зовут Игорь Симаков, я тимлид Java-разработки в команде Маркетплейс Банки.Ру. Сегодня на практическом примере разберу использование UNIT-тестирования. Оно применяется как для тестирования состояния, так и для проверки поведения кода. В этом материале сосредоточусь на последнем аспекте. Покажу, как использовать JUnit, Mockito и AssertJ для тестирования кода, а также JaCoCo для оценки покрытия тестами на примере простого мини-сервиса.

Эта статья основана на моем внутреннем воркшопе, который я проводил для своих коллег. В моем репозитории на GitHub можно ознакомиться с текстом доклада. Там содержится обзор основных понятий, используемых в статье, а также подробное описание инструментов.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

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

Продолжаем цикл статей об организации мониторинга. В первом материале разбирали, как и куда вообще имеет смысл навешивать алерты. Теперь поговорим о мониторинге базового серверного ПО, которое встречается в работе практически любого веб-проекта. Хочу поделиться метриками и алертами, которые мы в ITSumma используем для мониторинга виртуальных машин, docker/LXC-контейнеров, web- и application-серверов, supervisor’а, кастомных сервисов, а также ping-url’ов, SSL-сертификатов и доменных имен.

Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

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

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

Что такое OAuth 2.0