Reading Material

Leadership

Senior Engineers Reduce Risk

This is a really great article about what a senior engineer is and how they add value to companies of different sizes. It also covers culture and interviewing.

Help Me, OKR Kenobi: OKRs Explained Through Star Wars

Objectives and Key Results are a common way for large software teams to align their priorities in order to be most effective as a whole. It’s difficult to wordsmith objectives which yield measurable and specific key results, but it starts with understanding what a good objective and a good key result look like.

Growing as a Product Owner: Five Product Owner Maturity-Levels

In order to create clarity about the level of Product Ownership in your organization, we distinguish five types of Product Owners:

The Scribe
The Proxy
The Business Representative
The Sponsor
The Entrepreneur

Know your Domain — The Cynefin Framework

The Cynefin Framework is a conceptual framework used to aid decision-making. It’s a great way to model both decision making, but also system design:

Simple systems are known, cause-effect relationships are perceivable, predicable, and repeatable
Complicated systems are knowable, cause-effect relationships are separated in time and space
Complex systems are retrospectively coherent, cause-effect relationships are not repeatable
Chaotic systems are incoherent, cause-effect relationships are not perceivable

Engineering Maturity Model

Mike Fisher’s maturity levels (layers) are useful as a framework to consider your investment efforts (ratios?): “While I do think of this kind of like a maturity model, they are not stages that one achieves and moves on from. These are areas that one must keep returning to and keep investing in, always from the bottom up.”

Mental Models: The Best Way to Make Intelligent Decisions (~100 Models Explained)

This guide explores everything you need to know about mental models. By the time you’re done, you’ll think better, make fewer mistakes, and get better results.

Mental models are how we understand the world. Not only do they shape what we think and how we understand but they shape the connections and opportunities that we see. Mental models are how we simplify complexity, why we consider some things more relevant than others, and how we reason.

A mental model is simply a representation of how something works. We cannot keep all of the details of the world in our brains, so we use models to simplify the complex into understandable and organizable chunks.

A thorough team guide to RFCs

By defining a process for decision-making, you can give your team the space to own the outcome of the choices they make. RFCs are one of the ways that you can do this, and this guide may help you manage the change.

An introduction to event storming: The easy way to achieve domain-driven design

Event storming is a rapid, lightweight, and underappreciated group modeling technique that is intense, fun, and useful for accelerating development teams. It catalyzes and accelerates group learning, often achieving in a few hours or days what more traditional modeling techniques never do—a common understanding of the domain in which the software must operate.

Personal Development

How to Feel Progress

Feeling like you’ve made progress towards a worthy goal at the end of a day or week is critically important to moral and motivation. Understanding that context and learning some tools to break large tasks into small bite-sized ones are the first steps in feeling your progress.

A journey from Junior Developer to Technical Lead

You own your career, and each phase of your career has different challenges. Understanding your trajectory and what you need to succeed at each step is critical in personal and professional growth.

Maker’s Schedule, Manager’s Schedule

The classic 2009 article used to defend an engineer’s time against meetings and pointless interruptions.

Engineering Levels: A Simple Framework for Startups

Career ladders can be confusing, this is a good breakdown of common responsibilities and trajectories for engineers in the first ~10 years of their career.

Some thoughts on my presentation style

Very good suggestions to create slidedeck presetations which follow storytelling methods to engage with the audience and break down cognative barriers.

Meetings

What is Pig and Chicken in Scrum?

The business fable of The Chicken and the Pig explains breakfast pigs and chickens in the Scrum process. It’s a way to differentiate between roles in the Scrum/Agile world. Roles are key in Agile. They are constant and form the basis of every decision and define the very basic human relationships in Scrum. Pigs are committed whereas chickens are involved.

ESVP – Explorer, Shopper, Vacationer, Prisoner

This is a short activity to measure participants’ engagement for the meeting at hand.

How to run 1:1 meetings that work for 2

A comprehensive how-to in scheduling, planning, executing, and following up with productive 1:1s with your direct reports.

Reaching Peak Meeting Efficiency

Unlike almost everyone I know, I appreciate meetings and find them valuable. Most people just rant against meeting and constantly delete them from their calendars. This post helps identify the true purpose for a wide range of meeting types, and most importantly when/where they should be applied. This helps you schedule, manage, and run meetings more effectivly, and give you the reasons for removing meetings that aren’t working.

Programming

Ship Small Diffs

Why continuous deployment is important, how continuous integration affects your deployment process, and why it’s important to help your reviewers with small changes.

Best practices for using Git

Make clean, single-purpose commits
Write meaningful commit messages
Commit early, commit often
Don’t alter published history
Don’t commit generated files

How to manage your Git history: Tips for keeping your commits tidy

A few best practices for managing history in feature branches to keep your master branches semantic.

Unlearning Toxic Behaviors in a Code Review Culture

What can you do to become a better code reviewer? There are certain toxic behaviors common in our industry when it comes to code reviews, but there is a simple checklist you can follow to make your reviews more positive, productive, and collaborative.

Run Less Software

Engineering and Product teams need to focus on their core value prop in order to stay competitive. This means teams need to spend less time on technologies and tools that have a high overhead cost, but provide little direct value to the business. Knowing when to outsourcing these tools is a key indicator of a successful engineering team.

SOLID Principles

Single responsibility principle - a class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).
Open/closed principle - “software entities … should be open for extension, but closed for modification.”
Liskov substitution principle - “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
Interface segregation principle - “many client-specific interfaces are better than one general-purpose interface.”
Dependency inversion principle - one should “depend upon abstractions, not concretions.”

How to Get Buy-in for Reducing Technical Debt

So important for every engineer to master this “soft skill” of communication. The only way you’ll make an impact is if the stakeholders understand the impact in terms that prove valuable to the business and the mission.

Flattening Arrow Code

The Arrow Anti Pattern is a particular pet peeve of mine. Inverting nested conditionals not only reduces reading complexity, as it no longer requires the reader to mentally keep track of the chained conditionals that has lead to this point, but in my experience it also sometimes maps better to the indended business rules. Unnesting conditionals and exiting early often lead to cleaner code.

Code: Align the happy path to the left edge

Another take on the Arrow Anti Pattern concept coming from Golang. Line of sight is “a straight line along which an observer has unobstructed vision”, to produce a line of sight you can: align the happy path to the left, avoid else returns, flip the if statement, and promote big conditional blocks to their own functions.

Data Structures for Coding Interviews

To really understand how data structures work, we’re going to derive each of them from scratch. Starting with bits. Don’t worry—we’ll skip the convoluted academic jargon and proofs. We’ll cover:

Random Access Memory
Binary Numbers
Fixed-Width Integers
Arrays
Strings
Pointers
Dynamic Arrays
Linked Lists
Hash Tables

Principles of MLOps

Machine learning has become an essential part of our lives because we interact with various applications of ML models, whether consciously or unconsciously. Machine Learning Operations (MLOps) are the aspects of ML that deal with the creation and advancement of these models.

Automation
Continuous
Testing
Monitoring
Versioning
Reproducibility

Architecture

Presentational and Container Components

A great React design pattern which separates presentational view-only React components and stateful Redux connectors. This affords reusability of React components, easy testing, and clear separation of concerns for simple maintainence.

React + Redux Architecture : Separation of Concerns

Take an intermediary dive into arctitecting your client applications with React and Redux by applying separation of concerns. Both tools are unidirectional and promote immutability, configuring them correctly will create resiliant applications.

React Folder Structure

A modern take on organizing React applications following the Screaming Architecture approach of organizing software to reflect the domain and not the technology. An Application orchestrates across a number of Routes, each of which instansiate a Page. Each Page implements one or more Features, which are combinations of Components, Hooks, and Contexts.

Five Things Every Developer Should Know About Software Architecture

Software architecture isn’t about big design up front
Every software team needs to consider software architecture
The software architecture role is about coding, coaching and collaboration
You don’t need to use UML
A good software architecture enables agility

Redux for Transactional Apps

At minute 36, Netflix engineer Jeff Shi talks about designing SPAs where the application and business data is maintained in Redux, so that the rest of the application is a lightweight UI reacting to state changes.

Don’t Rewrite, React!

At React-Europe 2015, Ryan Florence describes an easy bottom-up approach to refactoring large applications with React. Very handy when you’re staring down a large refactor and want to approach it with as little risk as possible.

Screaming Architecture

Your architectures should tell readers about the system, not about the frameworks you used in your system. If you are building a health-care system, then when new programmers look at the source repository, their first impression should be: “Oh, this is a heath-care system”. Those new programmers should be able to learn all the use cases of the system, and still not know how the system is delivered.

Learning Architectural Design Patterns

1. Ports and Adaptors by Alistair Cockburn

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. A recent ~35 minute presentation by Alistair himself can be found here.

2. Onion Architecture by Jeffrey Palermo

It emphasizes the use of interfaces for behavior contracts, and it forces the externalization of infrastructure.

Key Tenents

The application is built around an independent object model
Inner layers define interfaces. Outer layers implement interfaces
Direction of coupling is toward the center
All application core code can be compiled and run separate from infrastructure

3. Domain Driven Design by Eric Evans

Understanding that software is an implimentation of a conceptual design, or Domain Model, of how a system works, and that Domain Model is described in a Ubiquitous Language out of a collaboration of all members of the team. By modeling the domain of the system, requirements and changes can be described to engineers without a loss in translation, and important domain logic is no longer hidden in the code.

4. Clean Architecture by Bob Martin

An evolution of the Onion Architecture that emphasizes higher trust and truth in the center of your architecture, fanning out into layers of higher rates of change, connected together leveraging dependency inversion. It redefines the Onion Architecture in terms of Entities, Use Cases, Interface Adaptors, and Frameworks & Drivers. You can read more in his book Clean Architecture: A Craftsman’s Guide to Software Structure and Design.

Testing

Five Factor Testing

Five reasons why testing is important. Good tests can:

Verify the code is working correctly
Prevent future regressions
Document the code’s behavior
Provide design guidance
Support refactoring

Please don’t mock me: and other test double advice

A break down of some code smells when mocking and other testing tools are misused and mislead issues. A big takeaway is that functions should do or delegate, but never both.

Performance

Jank Free

This site is a collection of articles, presentations, and tutorials which outline UX and technical issues with perceived performance, and how to address them.

JavaScript

Function Declarations vs. Function Expressions

A good write up about variable and function hoisting, functional expressions and declarations, and the benefits of named functions.