A. Rudenets

Всё по делу. Дополню лишь, что в trade-off между скоростью поставки фич и качеством их технической реализации разработчики максимизируют первое и минимизируют второе, когда среда вынуждает команду действовать именно так. Например, в компании придумали какой-нибудь KPI, начали планировать спринты под завязку или ввели трекинг времени и начали пристально следить за попаданием в оценку. По наблюдениям, именно в подобных ситуациях начинаются жертвы, о которых пишет Андрей.

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

Серёжа уже очень давно пишет очень толковые статьи о фрилансе и удалёнке. В своей новой статье он рассказывает, как заинтересовать заказчика с Upwork на этапе знакомства и договориться о приемлемой для вас ставке. Плюс немножко статистики и цифр со средними ставками по разным регионам.

Чек-листы для проверки качества дизайна различных компонентов и сценариев пользовательского интерфейса.

Благодаря @vitallium наткнулся на каких-то сумасшедших в хорошем смысле чуваков, которые большой толпой пишут исчерпывающие руководства на разные темы – найм инженеров, доли в компаниях в качестве компенсации, удалёнка и т.д. И, например, у них ещё есть гайд по использованию твиттера! Поразительно.

Онлайн-книга на русском языке о принципах SOLID с примерами на TS от Саши Беспоясова и Артёма Самофалова. Очень неплохо!

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

Рон Джеффрис пересматривает понятие Story Point’ов, которые широко распространены для оценки задач. Рон приходит к неутешительному выводу, что оценки часто используются неправильно. Изначально они призваны помогать разработчикам ориентироваться в бэклоге и находить задачи, которые при малой оценке могут принести много пользы. На деле используются неграмотными менеджерами, которые пытаются сравнить оценку (которая дается в условиях частичной или полной неопределенности) с актуальным временем выполнения задачи. Это приводит к разным негативным последствиям.

Короче говоря, почитать статью точно стоит.