Очередной наброс от создателя «алгоритмы не нужны»

Тесты не нужны (почти)

Когда я только начинал свою карьеру как инженер, я не понимал зачем нужны тесты. Я же сам могу пробежаться по тому, что написал и проверить, что все работает как мне нужно. Зачем писать код, который проверяет, что я написал то, что хотел.
И я не писал тесты

Чуть позже, когда опыта стало немного больше, я считал, что тесты писать круто, каждый синьор пишет тесты, TDĐ единственно возможный подход к разработке. Но я работал в компании Аля стартап и у нас не было времени на написание тестов.
И я не писал тесты

Позже я уже стал руководителем, устроился в компанию, что-то среднее между корпорацией и стартапом, там уже было время на то, чтобы писать тесты, тесты были заложены в пайплайн ci/cd, но… я все равно не писал тесты. Нанять еще парочку стажеров monkey qa, было дешевле, чем покрывать код тестами, обеспечивать их стабильность и стабильность ci/cd

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

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


Я стал руководителем, и я все еще не пишу тесты

Сколько с меня?

Желаю всем в этом чатике платить налог 22% 😎

Welcome to the club 22

Сегодня по расписанию необычная задача :)

https://youtu.be/HFg83HoNuCM?si=d3vNlpA67G8fIOZn
Просто оставлю это здесь :)

какой компьютер нужен, чтобы запустить Android проект?

Задумывались ли, как автоматизация android-разработки может поднять вашу продуктивность?

Подключайтесь к онлайн-конференции Podlodka Android Crew с 16 по 20 сентября! 🛠

🤖 Анна Жаркова из Usetech расскажет, как AI может автоматизировать создание UI в Android и KMP.
🎯 Григорий Шимичев из Dodo Engineering расскажет о продвинутых возможностях detekt и необходимости статического анализа кода.
🚄 Дмитрий Кудренко из Яндекс 360 расскажет, как релизный поезд помогает автоматизировать релизы и улучшить их стабильность.
💬 Круглый стол с экспертами из Авито, Wheely и PlataCard - обсудим лучшие практики организации CI/CD в мобильных командах.

Каждая сессия — это максимум прикладной пользы! Присоединяйтесь и не пропустите возможность узнать больше! https://podlodka.io/droidcrew 🎟

А специальный промокод сообщества android_crew_12_ujF60P даёт скидку в 500 руб🥳

Вопрос, который долгое время любили задавать на собесах:
«Как создать Android приложение, которое не убивает система»
Матвей разобрал наиболее часто встречающиеся способы решения проблем

https://youtu.be/RnhfpQUAdjc?si=xbS-EwNBh3h0qx0V

Скоро языка Kotlin больше не будет
https://youtrack.jetbrains.com/issue/KT-71605/Rename-Kotlin-to-something-else-to-distance-from-Russia

Kotlin или Flutter?

Если вам вдруг стало скучно, предлагаю вам порешать RegExp кроссворды

Google открыли бесплатный курс по генеративным ИИ.

Это 5-дневный интенсив для самостоятельного изучения. Внутри: лекции, подкасты и интерактивные задания на базе сервисов Google.

Все материалы лежат тут.

Грейды, основанные на импакте

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

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

Модель из статьи, как мне кажется, стоит на правильном пути. Вот ее основные принципы:

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

А сама линейка выглядит так (детальное описание каждого уровня есть в статье):

1️⃣Level 1 – Scoped Tasks
2️⃣Level 2 – Scoped Projects
3️⃣Level 3 – Unscoped Projects
4️⃣Level 4 – Team Force Multiplier
5️⃣Level 5 – Group Force Multiplier
6️⃣Level 6 – Company Force Multiplier