Django: бить модели по файлам, а файлы — по приложениям
Как не следуй гайдлайнам, а в любом проекте на Django рано или поздно окажется файл
Не стесняйтесь бить
Ну и напоследок — не делайте слишком больших приложений. Приложение Django, которое состоит из одной модели — это абсолютно нормально. Когда вырастете в большой проект, это здорово облегчит вам жизнь — ведь такие приложения это неплохая основа для микросервисов.
Как не следуй гайдлайнам, а в любом проекте на Django рано или поздно окажется файл
models.py длиной в 1500 строк. Запускать такую ситуацию нельзя — длинные файлы неудобно читать и править, и команда начинает сама того не осознавая тратить силы на неважное: вместо размышлений о бизнес-логике, программисты вынуждены запоминать, на какой строке находится та или иная модель.Не стесняйтесь бить
models.py на файлы. Даже если у вас всего две модели, скажем, Author и Book, пусть они лежат в models/author.py и models/book.py. К сожалению, без бойлерплейта сделать это не получится, поэтому вам придётся сделать ещё models/__init.py__. Ничего страшного, новые модели добавляются редко, и 5 минут на импортирование всех моделей окупятся уже за следующую неделю.Ну и напоследок — не делайте слишком больших приложений. Приложение Django, которое состоит из одной модели — это абсолютно нормально. Когда вырастете в большой проект, это здорово облегчит вам жизнь — ведь такие приложения это неплохая основа для микросервисов.
Раскрыта уязвимость в Zoom, с помощью которой можно было удалённо включить камеру на любом маке.
Раскрытие соседствует с кучей неприятных подробностей, самое страшное — от нахождения уязвимости до первого патча прошло аж 4 (!) месяца. Лично мне патч прилетел всего пару дней назад.
Уязвимы были даже те компьютеры, на которых когда-либо был установлен зум. То есть, даже если вы его поюзали один раз, а потом снесли, вашу камеру всё равно можно было включить.
Я сам очень люблю Зум за его «просто работу», когда ты отсылаешь ссылочку любому человеку, и он просто появляется у тебя на мониторе, сразу со звуком и видео, даже если до этого никогда не пользовался Зумом. Именно в механизме, который обеспечивает эту магию, и была уязвимость, кстати.
Пост с деталями — http://bit.ly/2YRRwhy
Обновляйтесь почаще.
Раскрытие соседствует с кучей неприятных подробностей, самое страшное — от нахождения уязвимости до первого патча прошло аж 4 (!) месяца. Лично мне патч прилетел всего пару дней назад.
Уязвимы были даже те компьютеры, на которых когда-либо был установлен зум. То есть, даже если вы его поюзали один раз, а потом снесли, вашу камеру всё равно можно было включить.
Я сам очень люблю Зум за его «просто работу», когда ты отсылаешь ссылочку любому человеку, и он просто появляется у тебя на мониторе, сразу со звуком и видео, даже если до этого никогда не пользовался Зумом. Именно в механизме, который обеспечивает эту магию, и была уязвимость, кстати.
Пост с деталями — http://bit.ly/2YRRwhy
Обновляйтесь почаще.
Вопрос: я дизайнер, и хочу не просто рисовать макеты, а делать работающие штуки, которые решают проблемы в реальном мире. Чтобы запустить проект, кроме языка программирования обычно нужно выучить ещё много всего, хотя бы тот же PyCharm и пару библиотек. Как делать работающие штуки не тратя время на борьбу с настройкой IDE?
Среда разработки — это всего лишь инструмент, как гвозди и молоток. Если вы, не умея забивать гвозди, возьмётесь строить дом — вы скорее всего просто отобьёте все пальцы. А дом, даже если вы его достроите — развалится.
IDE для программиста — такой же базовый инструмент, как молоток для строителя. Вы правы — кроме IDE, таких инструментов ещё множество: отладчик, эмулятор, билд-ферма, CI. Собранные вместе, все эти инструменты дают свободу — вы можете построить что угодно, от счётчика пролетевших за окном голубей, до нового Инстаграма.
Чтобы не осваивать базовые инструменты, но при этом делать работающие вещи, откажитесь от свободы. Уменьшив требования, можно собирать прекрасные веб-страницы на Тильде, писать ботов на pipe.bot, и botmother, а интерфейсы к базам данных — в Retool. Для мобильных приложений тоже существует десяток конструкторов — выбирайте любой.
Просто откажитесь от программирования совсем — снесите IDE, закройте мануалы по питону. Решайте проблему тем, что есть под рукой. Ну а если всё-таки решите усложнить себе решение и разобраться в программировании — начните с веба, это самый понятный путь. Обязательно перед началом прочтите совет Юрия Мазурского о том, как дизайнеру стать разработчиком.
Это был традиционный вопрос по понедельникам. Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Среда разработки — это всего лишь инструмент, как гвозди и молоток. Если вы, не умея забивать гвозди, возьмётесь строить дом — вы скорее всего просто отобьёте все пальцы. А дом, даже если вы его достроите — развалится.
IDE для программиста — такой же базовый инструмент, как молоток для строителя. Вы правы — кроме IDE, таких инструментов ещё множество: отладчик, эмулятор, билд-ферма, CI. Собранные вместе, все эти инструменты дают свободу — вы можете построить что угодно, от счётчика пролетевших за окном голубей, до нового Инстаграма.
Чтобы не осваивать базовые инструменты, но при этом делать работающие вещи, откажитесь от свободы. Уменьшив требования, можно собирать прекрасные веб-страницы на Тильде, писать ботов на pipe.bot, и botmother, а интерфейсы к базам данных — в Retool. Для мобильных приложений тоже существует десяток конструкторов — выбирайте любой.
Просто откажитесь от программирования совсем — снесите IDE, закройте мануалы по питону. Решайте проблему тем, что есть под рукой. Ну а если всё-таки решите усложнить себе решение и разобраться в программировании — начните с веба, это самый понятный путь. Обязательно перед началом прочтите совет Юрия Мазурского о том, как дизайнеру стать разработчиком.
Это был традиционный вопрос по понедельникам. Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Производство и потребление: продолжение
После прошлой заметки о производстве и потреблении, многие ребята спрашивали в личку, как производить больше 95% людей имея только блокнот и ручку?
На самом деле, задача очень простая — 95% людей, которых вы встречаете, не производят совсем ничего. К примеру почти всё, что большинство делает на работе — это всего лишь простые действия, которые улучшают потребление. У многих цепь настолько простая, что не отличается от мышки в лабиринте: совершил 100 звонков -> выполнил KPI -> получил бонус -> улучшил потребление.
Никто не задаётся вопросами. Кому стало лучше от 100 звонков? Мне? Близким? Человечеству?
Чтобы производить больше, достаточно сделать очень маленький шаг. Начните делать что-то, что делает какой-нибудь понятной группе людей измеримо лучше.
Заведите блог (те самые блокнот и ручка). Кому-то будет полезно и интересно.
Сделайте пет-проект — не просто todo-MVC, а что-то с конкретной пользой: удобного бота для телеграма, помощника в выборе одежды, каталог эмодзи с поиском по настроению, что угодно.
Запишитесь в волонтёрскую организацию.
Прочитайте 150 книг.
Возьмите кусочек рынка и переверните его с ног на голову.
Вариантов — куча: главное, чтобы то, что вы делаете, исходило изнутри вас, а не было бы улучшенным способом выплатить кредит на новый айфончик.
После прошлой заметки о производстве и потреблении, многие ребята спрашивали в личку, как производить больше 95% людей имея только блокнот и ручку?
На самом деле, задача очень простая — 95% людей, которых вы встречаете, не производят совсем ничего. К примеру почти всё, что большинство делает на работе — это всего лишь простые действия, которые улучшают потребление. У многих цепь настолько простая, что не отличается от мышки в лабиринте: совершил 100 звонков -> выполнил KPI -> получил бонус -> улучшил потребление.
Никто не задаётся вопросами. Кому стало лучше от 100 звонков? Мне? Близким? Человечеству?
Чтобы производить больше, достаточно сделать очень маленький шаг. Начните делать что-то, что делает какой-нибудь понятной группе людей измеримо лучше.
Заведите блог (те самые блокнот и ручка). Кому-то будет полезно и интересно.
Сделайте пет-проект — не просто todo-MVC, а что-то с конкретной пользой: удобного бота для телеграма, помощника в выборе одежды, каталог эмодзи с поиском по настроению, что угодно.
Запишитесь в волонтёрскую организацию.
Прочитайте 150 книг.
Возьмите кусочек рынка и переверните его с ног на голову.
Вариантов — куча: главное, чтобы то, что вы делаете, исходило изнутри вас, а не было бы улучшенным способом выплатить кредит на новый айфончик.
Хороший план исходит от команды
Планирование работы во всех командах выстроено по-разному, но есть один признак, который всегда есть в результативных командах и редко встречается в обычных: у результативных ребят план работ формируют исполнители, а у обычных — менеджеры.
В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.
Когда спринт планируют исполнители, мозг перестраивается — вместо накидывания задач, чтобы забить ёмкость, люди начинают под них подписываться. Внутренний диалог ведётся совсем по-другому: не «верно ли я оценил эту задачу», а «успею ли я выполнить вот эти обещания в срок?».
Такой процесс менее чёток с точки зрения цифр, зато приводит к планам, которые действительно сбываются. Ну и вообще повышает самостоятельность у команды — система, в которой спринты планируют исполнители, требует гораздо меньше управляющих воздействий.
См. также: почему я не люблю оценивать задачи
Планирование работы во всех командах выстроено по-разному, но есть один признак, который всегда есть в результативных командах и редко встречается в обычных: у результативных ребят план работ формируют исполнители, а у обычных — менеджеры.
В плане менеджеров обычно все завязано на цифры: берем беклог, оцениваем каждую задачу в часах, а затем всё как в бухгалтерии: в двухнедельном спринте у нас 80 часов, 20 оставляем про запас, а остальные 60 — забиваем задачами. От такого плана исполнители уже не отвертятся — раз оценил задачу в трекере на 4 часа, значит 4 часа над ней и работай.
Когда спринт планируют исполнители, мозг перестраивается — вместо накидывания задач, чтобы забить ёмкость, люди начинают под них подписываться. Внутренний диалог ведётся совсем по-другому: не «верно ли я оценил эту задачу», а «успею ли я выполнить вот эти обещания в срок?».
Такой процесс менее чёток с точки зрения цифр, зато приводит к планам, которые действительно сбываются. Ну и вообще повышает самостоятельность у команды — система, в которой спринты планируют исполнители, требует гораздо меньше управляющих воздействий.
См. также: почему я не люблю оценивать задачи
Вопрос: приведи примеры софт-скиллов в контексте программирования?
Пожалуйста:
— думать вне рамок
— быть проактивным
— держаться на долгих дистанциях
— писать понятно
— понимать, откуда у людей берутся требования
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Пожалуйста:
— думать вне рамок
— быть проактивным
— держаться на долгих дистанциях
— писать понятно
— понимать, откуда у людей берутся требования
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Игнорировать оценки
Ещё в школе мы привыкаем получать оценки. Помог учителю донести пачку тетрадей — молодец. Опоздал на урок — плохо, двоечник.
Когда мы вырастаем, эту же модель поведения мы применяем к рабочим отношениям с коллегами: начинаем делать вещи, нацеленные на одобрение, и избегаем вещей, которые приведут к неодобрению.
Ради хорошей оценки мы готовы пойти на должностное преступление — не спросить с коллеги спросить за пропущенный дедлайн; недожать ресурсов для важного проекта; поставить в спринт неважную фичу только только потому, что попросили. Типа коллега запомнит, и на ежеквартальному ревью помянет вас добрым словом. Так вы становитесь «душой компании» — все с вами дружат, но результатов бизнесу вы не приносите.
Если не хотите превращаться в талисман — игнорируйте внешние оценки. Если для важной задачи нужно переругаться со всем офисом — ругайтесь. Пусть первичными будут ваши внутренние правила, а не мнение коллег.
Тяжелее всего применять внутренние правила в стартапах: вокруг бардак, вместо одного руководителя вы отчитываетесь всей компании, и каждый коллега норовит вам поставить «самую важную на текущий момент» задачу.
Начнёте браться за всё — быстро сгорите, ничего не добившись. Так что выбирайте важное, и не стесняйтесь жертвовать одобрением коллег ради внутренних стандартов качества.
Ещё в школе мы привыкаем получать оценки. Помог учителю донести пачку тетрадей — молодец. Опоздал на урок — плохо, двоечник.
Когда мы вырастаем, эту же модель поведения мы применяем к рабочим отношениям с коллегами: начинаем делать вещи, нацеленные на одобрение, и избегаем вещей, которые приведут к неодобрению.
Ради хорошей оценки мы готовы пойти на должностное преступление — не спросить с коллеги спросить за пропущенный дедлайн; недожать ресурсов для важного проекта; поставить в спринт неважную фичу только только потому, что попросили. Типа коллега запомнит, и на ежеквартальному ревью помянет вас добрым словом. Так вы становитесь «душой компании» — все с вами дружат, но результатов бизнесу вы не приносите.
Если не хотите превращаться в талисман — игнорируйте внешние оценки. Если для важной задачи нужно переругаться со всем офисом — ругайтесь. Пусть первичными будут ваши внутренние правила, а не мнение коллег.
Тяжелее всего применять внутренние правила в стартапах: вокруг бардак, вместо одного руководителя вы отчитываетесь всей компании, и каждый коллега норовит вам поставить «самую важную на текущий момент» задачу.
Начнёте браться за всё — быстро сгорите, ничего не добившись. Так что выбирайте важное, и не стесняйтесь жертвовать одобрением коллег ради внутренних стандартов качества.
Как передавать знания в агентстве?
Специфика агентской разработки — малое погружение специалистов в проект: проектов много, а специалисты постоянно меняются.
Если у вас так же и вас достало по 100 раз пережёвывать одни и те же правила, постройте у своих программистов систему наставничества.
Подробнее — в моём новом совете на сайте Бюро.
Специфика агентской разработки — малое погружение специалистов в проект: проектов много, а специалисты постоянно меняются.
Если у вас так же и вас достало по 100 раз пережёвывать одни и те же правила, постройте у своих программистов систему наставничества.
Подробнее — в моём новом совете на сайте Бюро.
Любимые посты
— Хороший план исходит от команды,
— Твой отдых — твоя ответственность,
— Одна задача — один ответственный,
— Найм людей: лучше false negative, чем false positive,
— Как начать новый проект без знаний программирования,
— Сначала процесс, потом автоматизация.
А ещё я пишу в блоге и фейсбуке, а так же даю советы на сайте Бюро.
Ну а если вы программист, фоловьте меня на гитхабе.
— Хороший план исходит от команды,
— Твой отдых — твоя ответственность,
— Одна задача — один ответственный,
— Найм людей: лучше false negative, чем false positive,
— Как начать новый проект без знаний программирования,
— Сначала процесс, потом автоматизация.
А ещё я пишу в блоге и фейсбуке, а так же даю советы на сайте Бюро.
Ну а если вы программист, фоловьте меня на гитхабе.
FEDOR BORSHEV pinned «Любимые посты — Хороший план исходит от команды, — Твой отдых — твоя ответственность, — Одна задача — один ответственный, — Найм людей: лучше false negative, чем false positive, — Как начать новый проект без знаний программирования, — Сначала процесс, потом…»
Всё ужé
Важный чекпоинт на пути профессионального роста — состояние «всё ужé». Это когда смотришь на работу программиста, проверяешь, скажем, покрыты ли тестами крайние случаи — а они уже покрыты. Проверяешь, как ПР будет интегрироваться с соседним проектом — а там уже все обсудили и утвердили. Смотришь, насколько итог работы соответствует изначальному дизайну — а дизайнер сам уже написал, что всё ок.
Состояние «всё ужé» означает, что обучение полностью завершено, человек «врос» в своё рабочее место. Кто-то доходит до такого состояния за полгода, кому-то и через пару лет нужен небольшой контроль в сложных моментах.
Есть ребята, которые после достижения «всё ужé» замедляются — зачем бежать вперёд, когда всё понятно, уважение коллег заслужено, все нужные паттерны поведения освоены. Есть те, кто наоборот, начинает в таком состоянии скучать.
Эти два типа ни в коем случае нельзя путать: первым нужно помогать плавно развиваться в их зоне комфорта, а вторых периодически оттуда выпинывать, иначе они скиснут и уйдут, либо превратятся в первых.
Важный чекпоинт на пути профессионального роста — состояние «всё ужé». Это когда смотришь на работу программиста, проверяешь, скажем, покрыты ли тестами крайние случаи — а они уже покрыты. Проверяешь, как ПР будет интегрироваться с соседним проектом — а там уже все обсудили и утвердили. Смотришь, насколько итог работы соответствует изначальному дизайну — а дизайнер сам уже написал, что всё ок.
Состояние «всё ужé» означает, что обучение полностью завершено, человек «врос» в своё рабочее место. Кто-то доходит до такого состояния за полгода, кому-то и через пару лет нужен небольшой контроль в сложных моментах.
Есть ребята, которые после достижения «всё ужé» замедляются — зачем бежать вперёд, когда всё понятно, уважение коллег заслужено, все нужные паттерны поведения освоены. Есть те, кто наоборот, начинает в таком состоянии скучать.
Эти два типа ни в коем случае нельзя путать: первым нужно помогать плавно развиваться в их зоне комфорта, а вторых периодически оттуда выпинывать, иначе они скиснут и уйдут, либо превратятся в первых.
Что делать, чтобы вас не заменили роботом
Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.
Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.
Права рута появились у каждого программиста, а сисадмины стали с умным видом делать гораздо меньше вещей.
Потом появился докер, и мы полностью абстрагировались от компьютеров — все крутится внутри легкого контейнера в абстрактном облаке. Самые прошаренные сисадмины стали девопсами, а у остальных осталось не так много дорог, отличных от условного электрика на заводе.
Если не хотите, чтобы в ближайшее время люди придумали абстракцию, которая вас заменит, остается два пути: или постоянно учить новое (и откладывать деньги на период, когда вы не сможете этого делать по физиологическим причинам), или учить софтскиллы, которые роботом пока не заменить: управление людьми, ответственность и результативность.
Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.
Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.
Права рута появились у каждого программиста, а сисадмины стали с умным видом делать гораздо меньше вещей.
Потом появился докер, и мы полностью абстрагировались от компьютеров — все крутится внутри легкого контейнера в абстрактном облаке. Самые прошаренные сисадмины стали девопсами, а у остальных осталось не так много дорог, отличных от условного электрика на заводе.
Если не хотите, чтобы в ближайшее время люди придумали абстракцию, которая вас заменит, остается два пути: или постоянно учить новое (и откладывать деньги на период, когда вы не сможете этого делать по физиологическим причинам), или учить софтскиллы, которые роботом пока не заменить: управление людьми, ответственность и результативность.
Вопрос: работаете ли вы с подрядчиками в части разработки кода? Если да, то как проводите код-ревью?
На больших проектах со обязательным код-ревью я избегаю подрядчиков. Причина банальная — это дороже и дольше. Внешней команде нужно погружаться в проект, как-то передавать знания у себя. Полноценное погружение «своего» бекендера в кодовую базу занимает пару месяцев, что уж говорить про внешних?
К тому же у внешних ребят обычно страдает качество кода (писал об этом тут). Кодовая база — достояние компании, её будущее. А я не хочу, чтобы будущее строилось на дорогих костылях и техдолге, созданном людьми, которыми я не управляю.
На мелких проектах, вроде быстрых проверок гипотез, аутсорсеры вполне могут быть полезны. Идеально — изолировать их от кодовой базы настолько, чтобы вообще не требовать код-ревью. Пусть пишут как умеют, и получают деньги за результат. В идеальном мире мы проверяем гипотезу силами внешней команды, и если гипотеза ок, просто выкидываем их реализацию и делаем качественно, своими силами.
Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.
На больших проектах со обязательным код-ревью я избегаю подрядчиков. Причина банальная — это дороже и дольше. Внешней команде нужно погружаться в проект, как-то передавать знания у себя. Полноценное погружение «своего» бекендера в кодовую базу занимает пару месяцев, что уж говорить про внешних?
К тому же у внешних ребят обычно страдает качество кода (писал об этом тут). Кодовая база — достояние компании, её будущее. А я не хочу, чтобы будущее строилось на дорогих костылях и техдолге, созданном людьми, которыми я не управляю.
На мелких проектах, вроде быстрых проверок гипотез, аутсорсеры вполне могут быть полезны. Идеально — изолировать их от кодовой базы настолько, чтобы вообще не требовать код-ревью. Пусть пишут как умеют, и получают деньги за результат. В идеальном мире мы проверяем гипотезу силами внешней команды, и если гипотеза ок, просто выкидываем их реализацию и делаем качественно, своими силами.
Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.
Отдых — твоя ответственность
Ребята, которые впервые попадают в распределённую команду, особенно со свободным графиком, часто начинают перерабатывать. Если раньше день можно было разделить на две части походом в офис, то теперь этого нет: есть задачи, есть дедлайны и 24 часа в сутках, которыми ты управляешь самостоятельно.
Возникает что-то вроде синдрома отличника, ты неосознанно начинаешь брать больше и закидывать дальше: жертвовать спортзалом, сном, прогулками с близкими. Часто ситуацию усугубляют менеджеры, которые впихивают задачи пока впихивается, легко преодолевая неумелое сопротивление новичка.
Чтобы не катиться по наклонной, начни воспринимать своё внимание как ограниченный ресурс. К примеру, как деньги. Взял задачу у менеджера — значит отдал немного внимания из кошелька. Засиделся допоздна за задачей — забрал внимание у близких. Начал спать по 6 часов в день — крадёшь внимание у своего организма.
Воспринимай себя, как атлета перед соревнованиями. Важно всё: как ты ешь, как ты спишь, с кем ты говоришь, насколько ты спокоен и уравновешен. Когда ты в хорошей форме — ты достигаешь результатов: и на работе, и в хобби, и дома. Когда ты в пытаешься делать вещи в плохой форме — ты просто тратишь здоровье.
На самом деле внутреннее состояние важно не только тебе — коллегам гораздо приятнее работать не с мёртвым пнём, а с надёжным товарищем. Но ответственность за своё состояние, в любом случае, несёшь только ты.
Ребята, которые впервые попадают в распределённую команду, особенно со свободным графиком, часто начинают перерабатывать. Если раньше день можно было разделить на две части походом в офис, то теперь этого нет: есть задачи, есть дедлайны и 24 часа в сутках, которыми ты управляешь самостоятельно.
Возникает что-то вроде синдрома отличника, ты неосознанно начинаешь брать больше и закидывать дальше: жертвовать спортзалом, сном, прогулками с близкими. Часто ситуацию усугубляют менеджеры, которые впихивают задачи пока впихивается, легко преодолевая неумелое сопротивление новичка.
Чтобы не катиться по наклонной, начни воспринимать своё внимание как ограниченный ресурс. К примеру, как деньги. Взял задачу у менеджера — значит отдал немного внимания из кошелька. Засиделся допоздна за задачей — забрал внимание у близких. Начал спать по 6 часов в день — крадёшь внимание у своего организма.
Воспринимай себя, как атлета перед соревнованиями. Важно всё: как ты ешь, как ты спишь, с кем ты говоришь, насколько ты спокоен и уравновешен. Когда ты в хорошей форме — ты достигаешь результатов: и на работе, и в хобби, и дома. Когда ты в пытаешься делать вещи в плохой форме — ты просто тратишь здоровье.
На самом деле внутреннее состояние важно не только тебе — коллегам гораздо приятнее работать не с мёртвым пнём, а с надёжным товарищем. Но ответственность за своё состояние, в любом случае, несёшь только ты.
Как проверить компетентность веб-разрабротчика?
На сайте бюро вышел мой совет, как проверить компетентность разработчика, если не сильно глубоко в этом разбираешься.
Спойлер: сделать с ним тестовый проект.
На сайте бюро вышел мой совет, как проверить компетентность разработчика, если не сильно глубоко в этом разбираешься.
Спойлер: сделать с ним тестовый проект.
Вопрос: кто такой CTO для бизнеса?
CTO для бизнеса это такой же топ-менеджер, как и все остальные: CFO, COO, CPO и кто там ещё есть. То есть человек, который полностью закрывает своё направление — выполняет KPI, согласовывая с CEO только бюджет.
KPI могут быть самые разные, но обязательно завязанные на основные задачи бизнеса. В технологичном стартапе на ранней стадии это valuation. В галерном агентстве — способность производства переварить весь проданный скоуп.
Кстати, хороший CTO понимает, что в своей работе он ближе всего к бухгалтерам или уборщицам: его департамент — это центр затрат, а не центр прибыли, как продажи или продукт. Это накладывает определённый отпечаток на общение с коллегами: когда осознаёшь, что сам по себе ты не приносишь денег, уходят всякие плохие мысли вроде «опять хуйню напродавали».
Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.
CTO для бизнеса это такой же топ-менеджер, как и все остальные: CFO, COO, CPO и кто там ещё есть. То есть человек, который полностью закрывает своё направление — выполняет KPI, согласовывая с CEO только бюджет.
KPI могут быть самые разные, но обязательно завязанные на основные задачи бизнеса. В технологичном стартапе на ранней стадии это valuation. В галерном агентстве — способность производства переварить весь проданный скоуп.
Кстати, хороший CTO понимает, что в своей работе он ближе всего к бухгалтерам или уборщицам: его департамент — это центр затрат, а не центр прибыли, как продажи или продукт. Это накладывает определённый отпечаток на общение с коллегами: когда осознаёшь, что сам по себе ты не приносишь денег, уходят всякие плохие мысли вроде «опять хуйню напродавали».
Это был традиционный вопрос по понедельникам. Другие ответы можно почитать по хештегу #вопрос. Задать свой — @fedor_borshev.
Бирюзовое доверие
Возьмём типичную проблему — допустим есть бизнес, у которого разработка периодически ломает прод. Если решать эту проблему классическим способом, как решали раньше на заводах, то вы просто построите ОТК: отдельный этап тестирования, жёсткие правила для код-ревью, чтобы без одобрения двух коллег нельзя было выкатывать. Как настоящий кризисный менеджер, вы придумаете какой-нибудь солидно звучащий KPI для программистов, вроде количества автотестов. Только вот прод реже ломаться не начнёт.
Проблема этого способа в том, что вы не доверяете своей команде, и строите систему, которая каждый день это недоверие демонстрирует, буквально повторяет: «ты дебил, делай что сказали, соблюдай правила».
Даже если отбросить то, что за месяц любая команда научится обходить ваши барьеры, такая практика выглядит глупо хотя бы потому, что вы нанимаете весьма дорогих творческих людей, и при этом пытаетесь сами же за них делать их работу. Уверенные в себе люди, которым эти рамки мешают, просто не приживутся в вашей команде. Подумайте сами, кто останется?
Бирюзовый подход работает совсем по другому. В основе лежит простое правило, что все люди — хорошие: если доверять на 100%, то вас никогда осознанно не обманут. А если обманут случайно, то приложат все силы для исправления проблемы. Парадоксально: если давать новичкам с самого начала полный доступ на прод, они пользуются им с большей осторожностью, чем доступом, честно заслуженным за испытательный срок.
Сфокусируйтесь не на преградах, а на помощниках. Пусть программист сам решает, когда привлекать QA, сколько и каких писать автотестов, в какой момент приглашать в задачу представителей бизнеса. Ваша задача как лидера — создать для этого инфраструктуру: быстрый деплой/откат, нужное количество QA, а самое главное — климат, в котором люди не боятся ошибаться.
Возьмём типичную проблему — допустим есть бизнес, у которого разработка периодически ломает прод. Если решать эту проблему классическим способом, как решали раньше на заводах, то вы просто построите ОТК: отдельный этап тестирования, жёсткие правила для код-ревью, чтобы без одобрения двух коллег нельзя было выкатывать. Как настоящий кризисный менеджер, вы придумаете какой-нибудь солидно звучащий KPI для программистов, вроде количества автотестов. Только вот прод реже ломаться не начнёт.
Проблема этого способа в том, что вы не доверяете своей команде, и строите систему, которая каждый день это недоверие демонстрирует, буквально повторяет: «ты дебил, делай что сказали, соблюдай правила».
Даже если отбросить то, что за месяц любая команда научится обходить ваши барьеры, такая практика выглядит глупо хотя бы потому, что вы нанимаете весьма дорогих творческих людей, и при этом пытаетесь сами же за них делать их работу. Уверенные в себе люди, которым эти рамки мешают, просто не приживутся в вашей команде. Подумайте сами, кто останется?
Бирюзовый подход работает совсем по другому. В основе лежит простое правило, что все люди — хорошие: если доверять на 100%, то вас никогда осознанно не обманут. А если обманут случайно, то приложат все силы для исправления проблемы. Парадоксально: если давать новичкам с самого начала полный доступ на прод, они пользуются им с большей осторожностью, чем доступом, честно заслуженным за испытательный срок.
Сфокусируйтесь не на преградах, а на помощниках. Пусть программист сам решает, когда привлекать QA, сколько и каких писать автотестов, в какой момент приглашать в задачу представителей бизнеса. Ваша задача как лидера — создать для этого инфраструктуру: быстрый деплой/откат, нужное количество QA, а самое главное — климат, в котором люди не боятся ошибаться.
Незавершёнка
Почти любую деятельность, начиная от программирования и заканчивая продажей картошки на рынке, можно организовать при помощи простого принципа из теории ограничений — избавления от незавершённой работы.
Незавершёнка — это начатая, но не законченная работа: неотвеченные письма, незакрытые спринты, неоплаченные счета, непроданные излишки. Чем больше незавершёнки, тем больше болит голова — горы незавершёнки нужно где-то «складировать», доставать из них части, которые все-таки требуют завершения, объяснять одним стейкхолдерам, почему вы достали не их работу, а работу других стейкхолдеров.
Любые принципы продуктивности основаны на очистке мозга от незавершёнки — пустые списки дел в GTD, удаленные письма в Zero Inbox, пустые колонки в Kanban.
Чтобы очистить себе голову — просто поймите, что является незавершёнкой в вашей деятельности. Скажем, у программиста незавершёнка — это несмёрдженные пулл-реквесты, неотвеченные письма коллег, незакрытые баги. У продажника — незакрытые сделки.
А дальше выстройте процесс, при котором вы системно избавляетесь от каждого вида незавершёнки: к примеру раз в день вы делаете коммиты в незакрытые ПР, а по вечерам 25 минут уделяете очистке ящика.
Почти любую деятельность, начиная от программирования и заканчивая продажей картошки на рынке, можно организовать при помощи простого принципа из теории ограничений — избавления от незавершённой работы.
Незавершёнка — это начатая, но не законченная работа: неотвеченные письма, незакрытые спринты, неоплаченные счета, непроданные излишки. Чем больше незавершёнки, тем больше болит голова — горы незавершёнки нужно где-то «складировать», доставать из них части, которые все-таки требуют завершения, объяснять одним стейкхолдерам, почему вы достали не их работу, а работу других стейкхолдеров.
Любые принципы продуктивности основаны на очистке мозга от незавершёнки — пустые списки дел в GTD, удаленные письма в Zero Inbox, пустые колонки в Kanban.
Чтобы очистить себе голову — просто поймите, что является незавершёнкой в вашей деятельности. Скажем, у программиста незавершёнка — это несмёрдженные пулл-реквесты, неотвеченные письма коллег, незакрытые баги. У продажника — незакрытые сделки.
А дальше выстройте процесс, при котором вы системно избавляетесь от каждого вида незавершёнки: к примеру раз в день вы делаете коммиты в незакрытые ПР, а по вечерам 25 минут уделяете очистке ящика.
Спокойствие и уверенность в себе
Критично важно, чтобы люди в творческих командах чувствовали себя спокойно и уверенно в себе. Дизайнер никогда не придёт с сильным дизайном, если будет ждать неконструктивной критики в стиле «я начальник, ты — дурак». Программист никогда не откажется от сложного требования, если будет ожидать пиздюлей за одно предложение это сделать.
Такое доверие и отличает хорошие продуктовые команды от галер и заводов, где вся система заточена на то, чтобы заставлять человека делать ровно то, о чём договорились в менеджеры в кабинете.
Когда я только начинал строить команды разработки, я искал баланс — как дать ребятам спокойствие и уверенность в себе, при этом не отпускать рычаги — бизнес есть бизнес, и чтобы заработать денег, надо иногда делать штуки, которые делать никто не любит, вроде всплывающих окон и говнокода в проде. В ГдеМатериале мне повезло — всю команду нанимал я. Это позволило мне почти не тратить сил на поиск баланса — люди либо совместимы отсутствием ТЗ, «чтобы что» и свободным графиком, либо у нас не работают.
С командами, которые давно стоят на привычных рельсах взаимного недоверия, всё гораздо сложнее.
Скажите, а какой у вас опыт перестроения обычной команды из парадигмы галеры в сторону доверия? Можно даже не программистов, или не на работе. Насколько получилось приблизиться к цели? Что помешало? Как доносили участникам парадигму доверия?
Критично важно, чтобы люди в творческих командах чувствовали себя спокойно и уверенно в себе. Дизайнер никогда не придёт с сильным дизайном, если будет ждать неконструктивной критики в стиле «я начальник, ты — дурак». Программист никогда не откажется от сложного требования, если будет ожидать пиздюлей за одно предложение это сделать.
Такое доверие и отличает хорошие продуктовые команды от галер и заводов, где вся система заточена на то, чтобы заставлять человека делать ровно то, о чём договорились в менеджеры в кабинете.
Когда я только начинал строить команды разработки, я искал баланс — как дать ребятам спокойствие и уверенность в себе, при этом не отпускать рычаги — бизнес есть бизнес, и чтобы заработать денег, надо иногда делать штуки, которые делать никто не любит, вроде всплывающих окон и говнокода в проде. В ГдеМатериале мне повезло — всю команду нанимал я. Это позволило мне почти не тратить сил на поиск баланса — люди либо совместимы отсутствием ТЗ, «чтобы что» и свободным графиком, либо у нас не работают.
С командами, которые давно стоят на привычных рельсах взаимного недоверия, всё гораздо сложнее.
Скажите, а какой у вас опыт перестроения обычной команды из парадигмы галеры в сторону доверия? Можно даже не программистов, или не на работе. Насколько получилось приблизиться к цели? Что помешало? Как доносили участникам парадигму доверия?
90% фич вылетает в трубу
Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.
9 из 10 фич. Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?
Вместо пиления фич вы начнёте проверять гипотезы.
Ваш код тоже станет другим — вы начнёте тратить время не на фичи, а на скорость производства новых фич.
Помните мой совет со входом через инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.
Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.
Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.
9 из 10 фич. Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?
Вместо пиления фич вы начнёте проверять гипотезы.
Ваш код тоже станет другим — вы начнёте тратить время не на фичи, а на скорость производства новых фич.
Помните мой совет со входом через инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.
Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.
Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?
Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.
Человек, который внутренне уверен в себе и своих знаниях, вряд ли будет когда-нибудь кого-нибудь буллить, так что я бы поставил под сомнение компетентность первого, как разработчика.
Подумайте внимательно, насколько поведение первого программиста совместимо с профессионализмом на работе в вашем представлении? Как далеко он заходит в своём буллинге? Если недалеко (хотя мне сложно такое представить) — отправьте его на месяц или два в отпуск, посмотрите как команда поживёт через него. Если сильно — немедленно увольняйте, иначе второй просто сбежит или, ещё хуже, превратится в фикус, и вы в любом случае останетесь без двух программистов.
Это был традиционный #вопрос по понедельникам. Задайте свой — @fedor_borshev
Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.
Человек, который внутренне уверен в себе и своих знаниях, вряд ли будет когда-нибудь кого-нибудь буллить, так что я бы поставил под сомнение компетентность первого, как разработчика.
Подумайте внимательно, насколько поведение первого программиста совместимо с профессионализмом на работе в вашем представлении? Как далеко он заходит в своём буллинге? Если недалеко (хотя мне сложно такое представить) — отправьте его на месяц или два в отпуск, посмотрите как команда поживёт через него. Если сильно — немедленно увольняйте, иначе второй просто сбежит или, ещё хуже, превратится в фикус, и вы в любом случае останетесь без двух программистов.
Это был традиционный #вопрос по понедельникам. Задайте свой — @fedor_borshev