Steve Kaliski

Who do we write code for?

No matter the language, framework, or environment in which your code is being written, it has an audience. Typically, when we think of audience, we consider the end user; the person or group using your product, perhaps even paying for it. But in actuality, we’re writing for three groups.

  1. We write code for users.
  2. We write code for each other.
  3. We write code for ourselves.

Knowingly or unknowingly, your team distributes effort across this audience. The end-user experience is fundamentally affected by a teams distribution choice. There’s no right or wrong answer, but it’s important to think critically about it.

Think of it as a stock portfolio — given a metric to optimize, paired with a risk profile, you allocate approach across these audiences. As a tech lead or engineering manager you have to make these types of allocations, optimizing for that particular metric, with the constraints of your resources and team.

Examples

Here are a few of the most common distributions. We’ll start with the base case, learning.

1. Learning.

chart a

Most often this is the approach taken as an individual when learning something new. The developer writes code in a manner that helps is intellectually stimulating and satisfying for them. It’s about understanding how a system works, experimenting, prototyping. With a technical audience of one, the code doesn’t necessarily need to be “useable” by another engineer. This code may often have minimal documentation, commented out code, and be untested.

2. Shipping.

chart b

This is the “classic startup mvp” style approach. Teams write code to for the sole purpose of shipping. It’s often (and understandably) written quickly (and thrown away just as fast), may not be DRY or well abstracted, with large areas owned by individual contributors. Technical debt accrues quickly.

Developers often choose battle tested tools and frameworks, out-of-the-box solutions, etc.

3. Scaling.

chart c

The technical debt has accrued. The team has grown. Multiple developers share ownership of sections of the codebase.The business implications of each deploy has escalated — downtime, bugs, etc all directly affect the success of the business.

It is at this point that the balance has shifted. Critical paths are thoroughly tested and well documented. Code is abstracted, shared, and maintained by a dedicated team. It may seem that the product velocity is reduced, but stability is higher.


Steve Kaliski

Hey! I am Steve Kaliski, an engineer and entreprenuer based in NYC. I love building tools to help people do their jobs.