Mikhail Tabunov

2022-09-01 17:42:23 Для проверки качества рекомендаций мы месяц назад начали делать тесты смеха. Спрашиваем в лоб у пользователя, насколько смешной этот мем или нет. И дальше проверяем, насколько action rate мема соответствует процентовке ответов «Смешно».

Получается интересная штука: мы берем TOP 100 мемов по action rate за прошлую неделю. Обычно там только хороший контент (action rate 10-12 из 100, что мы считаем очень хорошим).

Из ста мемов только десять аудитория признает смешными (более 60% респондентов ответят что это смешно). Туда обычно заходят шутки на грани, пример прикладываю. Остальное это просто обычные мемы, массовка, которая просто по стате получила лайки и шеры.

Это я к чему: бигдата это круто, но иногда лучше делать дабл-чек старыми добрыми методами Открыть/Комментировать

2022-08-24 11:56:16 Кстати, есть такая советская книжка – ТРИЗ – Теория решения изобретательских задач. Единственная на моей памяти книжка по инжинирингу, которая учит упрощать. Пример из книги такой:

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

Есть два решения:
1) в лоб – вы делаете электрические-гидравлические привода, блок управления, ножи которые чистят решетку. подводите электричество и придумываете систему мониторинга работоспособности
2) красивое – вы делаете поплавок, который приводит ножи в движение от волн на реке. не надо электричества, сложных инженерных систем, мониторинга

Пример абстрактный, но тем не менее показательный. Речь про то, что задачу в лоб может решить любой дурак. А вот найти красивое решение – это мастерство. Открыть/Комментировать

2022-08-24 11:42:24 Херовые программисты пишут много кода, много сервисов, придумывают архитектуру, потом геройски это все тестируют и катают в прод. Хорошие программисты придумывают как сделать так чтобы этого не надо было делать.

Пока не видел ни одних курсов по программированию где учат упрощать) Открыть/Комментировать

2022-08-24 11:41:13 «Простота — это великая добродетель, но она требует напряженной работы, чтобы её достичь и образование, чтобы оценить. И к сожалению, сложность продается легче.» — Дейкстра.

—

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

Кажется, что раз решение сложное — то в него вложено больше труда и значит оно должно быть лучше.

Это, конечно, не так. Процитирую Паскаля: «если бы у меня было больше времени, я бы написал письмо покороче».

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

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

—

Отличная статья об этом феномене на примере научных статьей в области машинного обучения. Спасибо Игорю за наводку. Открыть/Комментировать

2022-08-18 14:40:09 За прошлый год у меня было два крутых тренера: по электрогитаре и по мотоциклу.

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

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

Оба эти тренера - крутые ребята и мастера своего дела. Они знают как сделать результат.

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

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

2022-08-12 14:47:25 Пачка — быстрый корпоративный мессенджер

В Пачке можно общаться всей командой, как в привычном Slack. Для этого есть треды, видеозвонки и схожий интерфейс.

Узнать подробнее и попробовать можно по этой ссылке

#adv Открыть/Комментировать

2022-08-11 14:56:38 Никто не любит таких вопросов от начальника: какого хуя, почему только сейчас, что за пиздец, чем мы думали, почему они а не мы, че за хуйня у нас в проде. Всё это токсично, а значит можно и выгореть.

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

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

Так что лайк если это про тебя Открыть/Комментировать

2022-08-04 18:50:46 У нас плохие метрики потому что в продукте баги. Давайте сначала починим баги, а потом будем решать нормальный ретеншен или нет. Crash Free только 90%, о какой конверсии может идти речь?

Так продакты переводят стрелки на разработчиков и тестировщиков. Хотя, казалось бы, всё верно.

Прикол в том, что продуктом пользуются не потому, что он работает без багов, а потому что он нужен. Возьмем iPhone в 2012 году и HTC на Android 4. По сравнению с iPhone андройды были просто кладбищем багов, но их покупали, потому что против УТП не попрешь. Все хотели айфон но дешевле, а то что он глючит – ну что вы хотели, не надо было экономить) Открыть/Комментировать

2022-07-28 19:16:38 Открыть/Комментировать

2022-07-28 16:25:20 Ошибка найма – это когда на собеседовании чувак мастерски отвечает на все вопросы, делает тестовые задания, а на испытательном (или после него) начинается какая-то хуйня. То есть, это мастер проходить собеседования. Теоретические знания есть, но реальной практики не хватает. Часто это встречается у ребят из корпораций, которые красили год подряд кнопку в админке, но в резюме написали что "увеличили конверсию в выполненный заказ за счет улучшения бек-офиса".

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

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

Я знаю что многие компании с сильной инженерной культурой первоначальный скрининг делают через написание кода, и это экономит кучу времени Открыть/Комментировать