/Jessica Kerr

Product Teams Own Capabilities, Not (Only) Code tl;dr: "As a software engineer, what is your job? and what is your value?" Jessica makes the point that delivering capabilities is critical to the health of software teams, not just delivering features or code. 

featured in #257


What Is This “Product” You Speak Of? tl;dr: Software doesn't fall into either traditional economic bucket of product or service. In economics 101, a product is tangible, and has a one-off capital expenditure e.g. a rug. A service is non-tangible has a recurring cost e.g. cleaning. Software is neither. "Software is not done when it first works," it requires substantial costs to maintain and improve.

featured in #252


Better Coordination, Or Better Software? tl;dr: As a company scales and software scales, more inter-department co-ordination is required. It may seem like a good idea to help departments coordinate smoothly and frequently, but the counter is better - help them coordinate less, and establish boundaries and the few interfaces that cross them. This leads to better quality software.

featured in #244


Those Pesky Pull Request Reviews tl;dr: "We know that code review improves outcomes – compared to coding alone without any review. Don’t do that. Do code together - with constant, live review and growing understanding between the team members and the code, between the team members and each other."

featured in #228


When Costs Are Nonlinear, Keep It Small tl;dr: "Do the easy boring job regularly, instead of the hard scary job in a panic." Jessica highlights the increasing, non-linear costs incurred when we don't repair something often and frequently.

featured in #224


10x Developer: Work -> Knowledge -> Work tl;dr: "The most productive developer on a team is usually the one with the most knowledge of the system." This compounds - knowledgable developers are chosen for more tasks and accrue more knowledge. To counter this, assign work to the least busy person for training, use pair and ensemble programming.

featured in #221


Other People’s Messes tl;dr: We're comfortable writing messy code when it's just ourself who will see it. If you know others will at some point review it, it's best to clean it sooner rather than later.

featured in #148


For Cleaner Code, Write Ugly Code tl;dr: When prototyping code, make it ugly. Generally speaking, the number of iterations correlates more closely to success than the total time spent. This way, you are forced to go revisit your code, streamline and beautify it.

featured in #147


Knowledge Resides In Teams tl;dr: The "magic of a gelled team is that they know how to work together". The responsibility of a team's manager is to understand the inter-relationships that create that magic.

featured in #146