Как Plane, альтернатива Jira с открытым исходным кодом, менее чем за год стала №1 в управлении проектами на GitHub
18 сентября этого года мы преодолели отметку в 14 тысяч звезд и заняли первое место в списке инструментов управления проектами с открытым исходным кодом на GitHub. Любопытно, что каждый разговор за последние два месяца, будь то с пользователями, которые переходят на Plane с Jira, Aha! и Linear, с другими OSS-компаниями, которые хотят стать партнерами, или с предложениями выступить на OSS-мероприятиях, начинается с удивления нашим ростом звезд и повторяет то, что другие спрашивали меня онлайн и офлайн.
"Как вам это удалось?"
Этот пост является кратким ответом на этот вопрос, нашим обзором короткого путешествия в последний год. В нем рассказывается о том, что у нас получилось, где мы потерпели неудачу и что мы узнали о популярности в open source. Надеюсь, это поможет другим стартапам с открытым исходным кодом избежать наших ошибок.
Статья: https://plane.so/blog/how-we-got-to-20k-github-stars
18 сентября этого года мы преодолели отметку в 14 тысяч звезд и заняли первое место в списке инструментов управления проектами с открытым исходным кодом на GitHub. Любопытно, что каждый разговор за последние два месяца, будь то с пользователями, которые переходят на Plane с Jira, Aha! и Linear, с другими OSS-компаниями, которые хотят стать партнерами, или с предложениями выступить на OSS-мероприятиях, начинается с удивления нашим ростом звезд и повторяет то, что другие спрашивали меня онлайн и офлайн.
"Как вам это удалось?"
Этот пост является кратким ответом на этот вопрос, нашим обзором короткого путешествия в последний год. В нем рассказывается о том, что у нас получилось, где мы потерпели неудачу и что мы узнали о популярности в open source. Надеюсь, это поможет другим стартапам с открытым исходным кодом избежать наших ошибок.
Статья: https://plane.so/blog/how-we-got-to-20k-github-stars
Собираем объёмный дисплей на Raspberry Pi
Недавно мне посчастливилось очутиться в пабе с очень творческими и талантливыми людьми. Обсуждение затронуло тему светодиодных свечей и того, как можно создать нечто, под любым углом напоминающее мерцающую свечу. Я предложил дисплей на основе эффекта инерции зрения, но большинство сошлось на том, что для этого понадобится слишком много механики: подшипники, возможно, контактные кольца и так далее.
Статья: https://habr.com/ru/companies/ruvds/articles/780316/
Недавно мне посчастливилось очутиться в пабе с очень творческими и талантливыми людьми. Обсуждение затронуло тему светодиодных свечей и того, как можно создать нечто, под любым углом напоминающее мерцающую свечу. Я предложил дисплей на основе эффекта инерции зрения, но большинство сошлось на том, что для этого понадобится слишком много механики: подшипники, возможно, контактные кольца и так далее.
Статья: https://habr.com/ru/companies/ruvds/articles/780316/
🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Мой опыт прохождения собеседования в Google
Как и большинство инженеров-программистов, получить работу в Google было моей мечтой на протяжении многих лет. Google славится своей инженерной культурой, сложными задачами и инновационными технологиями. Возможность работать в такой влиятельной компании рядом с лучшими умами в отрасли была для меня главным стимулом.
Статья: https://apptractor.ru/info/articles/moy-opyt-prohozhdeniya-sobesedovaniya-v-google.html
Как и большинство инженеров-программистов, получить работу в Google было моей мечтой на протяжении многих лет. Google славится своей инженерной культурой, сложными задачами и инновационными технологиями. Возможность работать в такой влиятельной компании рядом с лучшими умами в отрасли была для меня главным стимулом.
Статья: https://apptractor.ru/info/articles/moy-opyt-prohozhdeniya-sobesedovaniya-v-google.html
4 простые привычки в разработке ПО, которые изменили мою производительность
1. Оставляйте работу немного незавершенной, чтобы на следующий день было легче начинать
2. Лучше владейте быстрыми сочетаниями клавиш на клавиатуре и мыши
3. Держите под рукой список команд и ссылок для поиска
4. Чаще говорите "нет"
Статья: https://read.engineerscodex.com/p/simple-software-engineering-habits
1. Оставляйте работу немного незавершенной, чтобы на следующий день было легче начинать
2. Лучше владейте быстрыми сочетаниями клавиш на клавиатуре и мыши
3. Держите под рукой список команд и ссылок для поиска
4. Чаще говорите "нет"
Статья: https://read.engineerscodex.com/p/simple-software-engineering-habits
❤1
Кто должен управлять продуктом?
Недавно продуктовая сфера всколыхнулась из-за спорного шага Airbnb - компания вывела менеджеров по продукту из продуктовых команд и преобразовала их в менеджеров по маркетингу продукта. Возможно, преобразования Airbnb и являются единичными - по сути, это попытка перенять нисходящую модель аппаратного обеспечения Apple, но эта история и последовавшая за ней дискуссия подняли на поверхность вековой спора: кто должен управлять продуктом?
Статья: https://itamargilad.com/trios/
Недавно продуктовая сфера всколыхнулась из-за спорного шага Airbnb - компания вывела менеджеров по продукту из продуктовых команд и преобразовала их в менеджеров по маркетингу продукта. Возможно, преобразования Airbnb и являются единичными - по сути, это попытка перенять нисходящую модель аппаратного обеспечения Apple, но эта история и последовавшая за ней дискуссия подняли на поверхность вековой спора: кто должен управлять продуктом?
Статья: https://itamargilad.com/trios/
🔥1
Простой саботаж в мире разработки
Допустим, вы работаете техническим директором в тылу врага и хотите изничтожать производительность так долго, как только сможете, чтобы вас не поймали. Вы, конечно, можете принять ряд очевидно плохих решений, но вас быстро уволят. Настоящая цель здесь - медленно лишить компанию производительности, сохраняя при этом фасад правдоподобия и нормальности. Что вы можете сделать?
В технологиях:
• При поступлении в компанию требуйте 6-18 месяцев на переписывание core системы. Вините предыдущего технического директора.
• Побуждайте всех использовать свой собственный язык и фреймворки.
• Разделяйте системы по произвольным границам: максимизируйте количество систем, задействованных в любой функции.
• Поощряйте сложную настройку для разработчиков: запуск сетки сервисов с дюжиной сервисов как минимум.
• Убедитесь, что производственная среда отличается от среды разработчиков как можно больше.
• Деплойте как можно реже. Призывайте к крайней осторожности в развертывании. Используйте любую производственную проблему как повод "спустить все на тормозах".
• Внедряйте очень сложные процессы изменения кода и общие рабочие процессы. Сваливайте все на "безопасность" или "соответствие требованиям".
• Убедитесь, что каждая задача отслеживается в трекере задач, рассматривается, расставляется по приоритетам и подписывается группой из как минимум пяти человек.
• Запретите все, что выходит за рамки первоначальной задачи, например, чистку кода или другие "проходные" улучшения.
• Создавайте собственные версии почти всего, что не относится к основной компетенции. Оправдывайте это тем, что "избегаете привязки к поставщику".
• Настаивать на добавлении слоев абстракции поверх всего. Использовать поставщиков, которые сами являются абстракциями, а затем добавлять дополнительные слои абстракций.
• Поощряйте технические решения, основанные на дико оптимистичных ожиданиях масштабирования. Планируйте нагрузку как минимум на 3 порядка больше, чем у вас есть.
• Поощряйте коллективное владение системами. Сделайте так, чтобы никто не чувствовал себя ответственным за обслуживание.
• Настаивайте на централизации почти всего в виде "платформы", принадлежащей "платформенной команде". Не укомплектовывайте штат платформенной команды и не позволяйте другим командам создавать то, что может принадлежать платформе.
• Заставьте команду платформы часто итерировать API и требовать от других команд как можно чаще рефакторить свой код до последней версии.
• Нанимайте "архитекторов" и требуйте, чтобы даже небольшие изменения проходили "архитектурный обзор".
• Требуйте, чтобы даже небольшие изменения проходили "проверку на безопасность".
Продуктовые, лидерские, проджет менеджерские и советы по найму: https://erikbern.com/2023/12/13/simple-sabotage-for-software.html
Или поставьте 👍, если хотите прочитать это на русском.
Допустим, вы работаете техническим директором в тылу врага и хотите изничтожать производительность так долго, как только сможете, чтобы вас не поймали. Вы, конечно, можете принять ряд очевидно плохих решений, но вас быстро уволят. Настоящая цель здесь - медленно лишить компанию производительности, сохраняя при этом фасад правдоподобия и нормальности. Что вы можете сделать?
В технологиях:
• Побуждайте всех использовать свой собственный язык и фреймворки.
• Разделяйте системы по произвольным границам: максимизируйте количество систем, задействованных в любой функции.
• Поощряйте сложную настройку для разработчиков: запуск сетки сервисов с дюжиной сервисов как минимум.
• Убедитесь, что производственная среда отличается от среды разработчиков как можно больше.
• Деплойте как можно реже. Призывайте к крайней осторожности в развертывании. Используйте любую производственную проблему как повод "спустить все на тормозах".
• Внедряйте очень сложные процессы изменения кода и общие рабочие процессы. Сваливайте все на "безопасность" или "соответствие требованиям".
• Убедитесь, что каждая задача отслеживается в трекере задач, рассматривается, расставляется по приоритетам и подписывается группой из как минимум пяти человек.
• Запретите все, что выходит за рамки первоначальной задачи, например, чистку кода или другие "проходные" улучшения.
• Создавайте собственные версии почти всего, что не относится к основной компетенции. Оправдывайте это тем, что "избегаете привязки к поставщику".
• Настаивать на добавлении слоев абстракции поверх всего. Использовать поставщиков, которые сами являются абстракциями, а затем добавлять дополнительные слои абстракций.
• Поощряйте технические решения, основанные на дико оптимистичных ожиданиях масштабирования. Планируйте нагрузку как минимум на 3 порядка больше, чем у вас есть.
• Поощряйте коллективное владение системами. Сделайте так, чтобы никто не чувствовал себя ответственным за обслуживание.
• Настаивайте на централизации почти всего в виде "платформы", принадлежащей "платформенной команде". Не укомплектовывайте штат платформенной команды и не позволяйте другим командам создавать то, что может принадлежать платформе.
• Заставьте команду платформы часто итерировать API и требовать от других команд как можно чаще рефакторить свой код до последней версии.
• Нанимайте "архитекторов" и требуйте, чтобы даже небольшие изменения проходили "архитектурный обзор".
• Требуйте, чтобы даже небольшие изменения проходили "проверку на безопасность".
Продуктовые, лидерские, проджет менеджерские и советы по найму: https://erikbern.com/2023/12/13/simple-sabotage-for-software.html
Или поставьте 👍, если хотите прочитать это на русском.
Erik Bernhardsson
Simple sabotage for software
How to sabotage software productivity, in the style of CIA
🔥3👍1
Эпический вопрос: как Google проиграл там, где Apple выиграла
Слушая вердикт в зале суда, я поначалу не мог поверить своим ушам. Читатели в наших комментариях и в интернете чувствовали то же самое. Как Epic могла выиграть у компании, которая бесплатно раздает свою операционную систему с открытым исходным кодом, особенно после того, как проиграла более закрытому конкуренту этой компании?
Статья: https://apptractor.ru/info/articles/epicheskiy-vopros-kak-google-proigral-tam-gde-apple-vyigrala.html
Слушая вердикт в зале суда, я поначалу не мог поверить своим ушам. Читатели в наших комментариях и в интернете чувствовали то же самое. Как Epic могла выиграть у компании, которая бесплатно раздает свою операционную систему с открытым исходным кодом, особенно после того, как проиграла более закрытому конкуренту этой компании?
Статья: https://apptractor.ru/info/articles/epicheskiy-vopros-kak-google-proigral-tam-gde-apple-vyigrala.html