Рубрика «управление разработкой» - 18

Вернёмся года на два назад, когда я был разработчиком. Что я думал? «Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора». Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.

Тимлидство — роль, которая может стать ловушкой для разработчика, а может дать огромные возможности для создания ПО - 1

Я дважды становился тимлидом

У меня есть такая черта: стараться во всем наводить идеальный порядок, систематизировать, выстраивать процессы. Поэтому меня всегда тянуло брать на себя больше, чем просто написание кода. В моём первом стартапе, назовем его «T», был полный хаос в процессах разработки.
Читать полностью »

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

«Я что-то накодил и все упало»: провалы в Python-разработке на Russian Python Week 2020 - 1

Когда вокруг только истории «успешного успеха» даже сеньоры и техлиды чувствуют себя неуверенно — ведь они сравнивают успех спикера со своими ошибками. И сравнение не в пользу участников. Мы решили сломать эту тенденцию и на Russian Python Week запускаем целую секцию под кодовым названием «FailPy». Она будет посвящена провалам Python-разработчиков. Расскажем зачем и для кого это нужно.
Читать полностью »

Привет! Меня зовут Алексей Скоробогатый. В 2015 году я пришел в Lamoda на позицию разработчика. Сейчас я системный архитектор e-commerce платформы и по совместительству Technical Lead команды CORE. В этой статье хочу поделиться инсайтами, которые получил за эти 5 лет — в формате takeaways, с историями, мемами и ссылками на литературу.

image

Буду рад любой дискуссии в комментариях под статьей: вопросы, мнения, опровержения!
Читать полностью »

Профессор Никлаус Вирт был прав. Создатель языка Pascal, соавтор технологии структурного программирования, лауреат премии Тьюринга в 1995 году заметил:

«Замедление программ происходит куда быстрее, чем ускорение компьютеров»

С тех пор это высказывание считается законом Вирта. Он фактически нивелирует закон Мура, согласно которому количество транзисторов в процессорах удваивается примерно с 1965 года. Вот что пишет Вирт в статье «Призыв к стройному софту»:

«Около 25 лет назад интерактивный текстовый редактор умещался всего в 8000 байт, а компилятор в 32 килобайта, тогда как их современные потомки требуют мегабайтов. Стало ли всё это раздутое программное обеспечение быстрее? Нет, совсем наоборот. Если бы не в тысячу раз более быстрое железо, то современное программное обеспечение было бы совершенно непригодным».

С этим трудно не согласиться.
Читать полностью »

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

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

Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют? - 1

Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Читать полностью »

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

В одной лодке с «ублюдком»: 11 продвинутых советов по использованию Git - 1

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

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Читать полностью »

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

«Конституция» для разработчиков: как страничка на GitHub помогает нам не ругаться уже год - 1

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

Привет! Я управляю командами разработки уже 10 лет.

Недавно меня попросили поделиться на внутренней конференции «секретами управления» с другими руководителями. Поводом стала низкая текучка в моём подразделении и здоровый дух внутри команды — так было на всех моих работах. Я отказался, сославшись на то, что не делаю для этого ничего особенного. Сработала внутренняя установка «не будь выскочкой».

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

Поэтому выключаю тумблер «не будь выскочкой» и делюсь «секретами».

Советы руководителю от руководителя - 1

Тут не будет стандартных «делегируй», «налаживай процесс», «стой в правильной позе на стендапе» — об этом написано уже достаточно. Будет о другом.
Читать полностью »

Как нанять 50 синьоров за 43 дня и быстро включить их в процесс разработки? - 1


В следующий вторник, 21 июля в 20:00 в наших соцсетях пройдет стрим с Андреем Евсюковым, заместителем CTO в Devilery Club.

Андрей занимается созданием инжереной культуры в Delivery Club: найм, формирование команд, создание процессов разработки. До этого разрабатывал на PHP и на go.

Сейчас Delivery Club развивается с бешеной скоростью — команда выросла с 50 до 130 человек за год, а через месяц в команде будет уже 150 человек. Андрей отвечает за то, чтобы все они прижились и как можно скорее включились в работу.Читать полностью »

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

Что спрашивают маленькие девочки у чеширских котов?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js