FEDOR BORSHEV

@pmdaily Нравится 3

Пишу о производстве сложных проектов, управлении продуктами, профессиональном росте программистов.
borshev.com / patreon.com/f213
Связаться со мной — fedor@borshev.com
Реклама не продаётся.
Гео и язык канала
Россия, Русский
Категория
Технологии


Написать автору
Гео канала
Россия
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
26.12.2017 02:52
реклама
Продаешь канал?
Покупаем каналы за 5-20р./подписчик. Образовалки, биз!
Telegram Analytics
Подписывайся, чтобы быть в курсе новостей TGStat.
SearcheeBot
Ваш гид в мире Telegram-каналов
14 740
подписчиков
~8.3k
охват 1 публикации
~4.5k
дневной охват
~4
постов / нед.
56.3%
ERR %
49.26
индекс цитирования
Данные о подписчиках
Пол подписчиков  
М 81.3%
Ж 18.7%
? - 3.5527136788005E-15%
Был в сети
был в сети недавно
97.1%
от 2 до 7 дней назад
1.5%
от 7 до 30 дней назад
0.9%
более 30 дней назад
0.5%
удаленный аккаунт
0%
На основе отчета @crosser_bot от 23 May, 07:40
  Канал очищается от неактивных участников с помощью @crosser_bot
Репосты и упоминания канала
113 упоминаний канала
36 упоминаний публикаций
79 репостов
кариконтент
atikhono_mind
запуск завтра
I hate overtime
Remote IT (Inflow)
Стартап дня
Python / Power BI / PowerBI
Девопсина / DevOpsina
QlikSense ! Qlik Sense ! QlikView
Python Books
IT Relocation (Inflow)
Remote IT (Inflow)
Python Daily
(НЕ) Kruzya
start from startup
Представляешь,
Dank Code
start from startup
ТЕРАБИТ
запуск завтра
The After Times
TSIYA
Devops Today
DevPassion
запуск завтра
АйТиБорода
UniLecs
корк ома
I hate overtime
Octo stuff
Senior Software Vlogger
habr.com
ХабраХабр Pub.
Колонка некодера
Каналы, которые цитирует @pmdaily
запуск завтра
запуск завтра
запуск завтра
Анатолий Буров
Пусть будет™
Менеджер от боженьки
запуск завтра
alexcouncil
Python Books
Анатолий Буров
Startups & Products
toverovskiy
запуск завтра
Oh My Py
Бабаева, к доске!
Kulinkovich is typing...
Криптонит Startup Challenge
Digital October
Analysis Paradisis
Digital October
WebDEV
Groks
Java Developer
Java Developer
Java Developer
Тёмная сторона
Тёмная сторона
Артемий Лебедев ❤️
Канал Саши Бизикова
Последние публикации
Удалённые
С упоминаниями
Репосты
FEDOR BORSHEV 13 Jul, 10:45
Четвёртая часть совета об аккуратном коде: принцип единой ответственности

Я рассказал про S из SOLID — почему плохо делать божественные объекты и что каждый класс, должен решать только одну задачу.

Хотите получить развёрнутый совет об управлении разработкой? Задавайте вопросы. Только обязательно напишите, что задаёте вопрос Фёдору, чтобы я мог отличить ваш вопрос от вопросов к другим советчикам.
Читать полностью
FEDOR BORSHEV 10 Jul, 10:45
Если облажался — признавай сразу

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

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

Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!

Во-вторых, не принимать критику — это неконструктивно. Представьте, что вы не сдали клиенту работу вовремя и доказываете, что это по его вине. Какая разница, чья вина, если проект не запущен?

В-третьих, это портит отношения. Если вы пару раз грубо пошлёте человека, который пришёл к вам с полезной критикой, он не просто перестанет вас критиковать — он, скорее всего, вообще начнёт избегать коммуникации с вами и будет прав.
Читать полностью
FEDOR BORSHEV 8 Jul, 10:45
Забота 80 уровня от DigitalOcean

Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»

DigitalOcean нигде на сайте это не продаёт, денег за такие письма не берёт. При этом они потратили силы — интегрировались с партнёром, который это делает, составили текст письма, настроили отправку. Обожаю компании, которые работают не только для того, чтобы было что написать на лендинге, но ещё и для счастья пользователей.
Читать полностью
FEDOR BORSHEV 3 Jul, 08:45
Я ушёл в офлайн где-то рядом с Монгольской границей, так что постов сегодня и в понедельник не будет.

Тут тихо и красиво, а самое главное — LTE встречается раз в 100 километров

:-)
FEDOR BORSHEV 1 Jul, 10:45
Хороший код не соответствует ТЗ

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

Проблема в том, что мир, описанный в ТЗ, часто успевает поменяться ещё до того, как по этому ТЗ что-нибудь сделают. И вот уже магазин превращается в службу доставки, а сервис подписок — в систему управления игровыми турнирами.

Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!

Хороший код, особенно в стартапе, — это не чёткое соответствие ТЗ, а вариация на тему ТЗ, которую легко можно адаптировать как к самому ТЗ, так и ко всему, что хоть как-то пересекается по предметной области.

См. также:

Почему длинные ТЗ не работают
Почему важно писать хороший код
Читать полностью
FEDOR BORSHEV 30 Jun, 12:00
#реклама #развдвенедели

OTUS открывает набор на продвинутые онлайн-курсы июля, способные прокачать и сделать незаменимыми программистов с опытом ООП.

🔥Чтоб проверить свой уровень, пройдите тест:
— Алгоритмы и структуры данных: https://otus.pw/ZH8a/
— Scala-разработка: https://otus.pw/U3if/
— Backend-разработка на Kotlin: https://otus.pw/h9Vf/

📌Узнайте больше о курсах на бесплатных вебинарах:
06.07 — Всё о курсе «Backend-разработка на Kotlin»: https://otus.pw/0D0s/
10.07 — Всё о курсе «Алгоритмы и структуры данных»: https://otus.pw/C786/
15.07 — Всё о курсе «Scala-разработчик»: https://otus.pw/uQNz/

Познакомитесь с преподавателями-практиками, зададите любые вопросы по Scala/алгоритмам/Kotlin, программе курсов и тому, как после обучения обеспечить себе надёжный карьерный прогресс.
Читать полностью
FEDOR BORSHEV 29 Jun, 10:45
#вопрос. А расскажи просто по пунктам про корпоративную культуру в компании? Как сделать, чтобы люди забирали ответственность?

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

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

Но вживую я такого не видел, поэтому мой подход к ответственности — простой:

1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.

Задать вопрос → fedor@borshev.com
👍 285
💩 6
Читать полностью
FEDOR BORSHEV 26 Jun, 10:45
Сегодня я немного пожалел, что 3 года назад ушёл из студии Лебедева.

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

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

Бесконечный респект команде — чтобы сделать такой проект в реальной жизни и с клиентам масштаба студии, нужно иметь стальные яйца.
Читать полностью
FEDOR BORSHEV 24 Jun, 10:45
Не отдавайте технические решения

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

Само по себе это не плохо: человек-указатель «Результат — там» действительно помогает не забывать о важном в ежедневной рутине. Плохо становится, когда такой человек начинает принимать ВСЕ решения на проекте.

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

Чтобы не превращаться в раба человека-указателя, никогда не отдавайте технические решения наружу. Не обсуждайте, стоит ли вам писать тесты. Определяйте сами версии библиотек и фреймворков. Не спрашивайте, можно ли вам поправить техдолг, — просто берите и правьте.
Читать полностью
FEDOR BORSHEV 22 Jun, 10:45
У меня вышел новый совет для тех, кто решил, что не будет учить новые технологии, а глубоко вкопается в одну и будет сидеть с ней до пенсии.

Полезно получилось?
Полезно 156
Ну так 144
FEDOR BORSHEV 21 Jun, 13:30
FEDOR BORSHEV 19 Jun, 10:45
Work-life balance

Ниже очень непопулярное мнение, кидайте помидоры

У понятия work-life balance есть странная асимметрия — его почти всегда употребляют только в одну сторону — «что-то я многовато работаю». Никогда не слышал, чтобы люди говорили: «Что-то я маловато работаю, надо бы побольше».

Думаю, эта асимметрия вызвана тем, что люди из второй группы (назовём их «упёртыми») в принципе не считают какой-либо баланс необходимостью. Вместо мифического баланса упёртые просто определяют свои цели и идут к ним. Если эта цель — проводить по 8 качественных часов с семьёй, и на счету хватает денег на 5 лет такой жизни, зачем напрягаться на работе? Если цель — заработать 50 миллионов, зачем бездельничать?

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

Если вам не нравится ваш work-life balance, может, у вас просто цели нет?
🍅 79
👍 314
Читать полностью
FEDOR BORSHEV 17 Jun, 10:45
Лайв-девопс: поднимаем кластер на docker swarm для W1D1

На прошлом стриме о докере вы просили рассказать, как запускать контейнеры не только на своей машине, но и в продакшене.

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

Сейчас бэкенд у W1D1 состоит из кучки микросервисов на ноде, которые поднимаются руками. Пора наводить порядок — проверить приложения по чек-листу 12 факторов, настроить централизованное логирование, описать инфраструктуру.

Ребята любезно разрешили мне сделать это публично, так что приходите на ютуб в 14:00 воскресенья — будем поднимать маленький кластер на docker swarm при помощи моего любимого Ansible. Как обычно, всё будет в лайве и без репетиций, так что никто не знает, получится ли у меня вообще что-нибудь.
Читать полностью
FEDOR BORSHEV 16 Jun, 14:00
#реклама #развдвенедели

22 июня пройдет открытый практический вебинар «Индексы в MySQL: best practices и подводные камни». Присоединяйтесь, будет интересно и профессионально: https://otus.pw/MqKo/

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

Вебинар проходит в рамках набора на профессиональный онлайн-курс «Архитектор высоких нагрузок». Чтобы попасть на этот курс с welcome-скидкой, пройдите вступительный тест: https://otus.pw/fswX/
Читать полностью
FEDOR BORSHEV 15 Jun, 10:45
#вопрос
Почему в твоей письменной/печатной речи так много грубых слов типа «говно» и так далее?

Если программисты себя считают элитой, то почему их общение (не только твоё) скатилось до смеси сленга с быдлятиной?

И второй, про сленг. Тебе правда нравится изобилие сленга и слов типа «фейлить», «факапить» и прочих в твоих текстах?

————
#ответ

Сленг складывается помимо нашей воли. Идти против сленга — глупо. Представьте себе дальнобойщика, который по рации скажет «Вижу засаду ГИБДД» вместо «машинка работает», или кладовщика, который назовёт рохлю «вилочным погрузчиком» — поймёте, о чём я.

Любая речь легко воспринимается только в случае, если соответствует контексту подачи. В электронной почте никто не ожидает стикеров с зелёной лягушкой или сообщений из одного слова «привет» — так же, как в Телеграме никто не ожидает красиво оттипографленных лонгридов. Я хочу, чтобы мои сообщения читались легко, поэтому и стараюсь, чтобы тексты не выходили за рамки привычного сообщения в чат — как по объёму, так и по форматированию и матюкам.

Вообще, я дотошный перфекционист. Когда я только начинал работать в студии Лебедева, одно из моих первых писем клиенту как-то вернули на доработку больше 10 раз. Сколько именно — не помню, но зато точно помню, что после двенадцатого раза я всё ещё получал удовольствие. Если бы я с таким подходом делал каждую заметку в этом канале — их было бы в лучшем случае на порядок меньше. В худшем — я бы заебал сам себя настолько, что забросил бы это всё в дальний угол и пошёл заниматься чем-нибудь, что можно никому не показывать.

Поэтому здесь я пишу коротко и без заморочек — как писал бы в рабочий чатик или в личку товарищу. Единственное отличие — недавно здесь появился корректор (Ольга, привет!): теперь, надеюсь, мои писюльки стало воспринимать ещё чуть легче.
Читать полностью
FEDOR BORSHEV 12 Jun, 10:45
Фабрика фич и просранное время

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

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

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

Очень важно — в «просранное время» ни в коем случае нельзя переводить гипотезы, которые прошли по продуктовому циклу, но не выстрелили — если вы сели, придумали, как быстро проверить гипотезу, проверили и она не выстрелила, вы молодцы, и никакого времени мы не просрали.
Читать полностью
FEDOR BORSHEV 10 Jun, 10:45
Качество ведения проекта

Понять, насколько хорошо менеджер ведёт проект, легко после его завершения. Всё просто — если менеджер успел в срок с хорошим качеством и не угробил команду, значит, молодец. Не успел — не молодец. Но как быть, когда проект ещё не завершён, а измерять качество уже надо?

Мой любимый способ — посмотреть на прозрачность. Насколько извне проекта видно, как идут дела? Публичны ли еженедельные планы? Как часто проводятся демо?

Отсутствие прозрачности не говорит, что проект не придёт к результату — бывают команды, которые привыкли держать всё в голове, и не мне их судить. Но вот если с прозрачностью всё в порядке — моя вера в проект сильно повышается.
Читать полностью
FEDOR BORSHEV 8 Jun, 10:45
Запись вебинара об автоматизации разработки

2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн.

В честь первого дня продаж, цена — 1800 рублей.
FEDOR BORSHEV 5 Jun, 12:00
Научи ловить рыбу

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

Неопытные программисты в ответ на просьбу по-быстрому что-нибудь сделать обычно что-нибудь делают. Продвинутые даже выстраивают системы реагирования, типа «Сегодня Вася делает все задачи по-быстрому, а завтра — Федя».

Опытные же, наоборот, — не дают рыбу, а учат её ловить: они не сбрасывают пароль, а делают кнопку для сброса пароля; не меняют телефон, а делают поле в админке; не делают выгрузки, а ставят Metabase или PowerBI. В ГдеМатериале у меня вообще было правило, что разработчик никогда не участвует в операционке, что бы ни произошло: так мы тратим время разработчика не на решение задачи, а на фичу, которая нужна, чтобы подобные задачи больше никогда не приходили.
Читать полностью
FEDOR BORSHEV 3 Jun, 10:45
Смеяться в коде

Обожаю смеяться в коде. Самый распространённый товар в тестах ГдеМатериала у нас назывался «Камаз Отходов». Иногда он трансформировался в «Камаз Овец» или «Камаз Гвоздей». Большинство прорабов звали «Львовичами» («Петрович» не хотелось по понятным причинам).

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

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

Я не призываю вас шутить — вдруг вы пишете бэкенд для похоронного агентства (хотя, уверен, там самая мякотка). Но с шутками — гораздо веселее, это точно.
Читать полностью