Articles

Whenever I notice a theme when talking with my colleagues and clients, I like to write about it. Here are some examples of my articles.

Simplifying technical designs

A set of coding standards

A shout out for ADRs

Code reviews in the age of AI coding

Choosing a backend language, choosing a culture

Crossing the distributed systems chasm

Politics and sales as a software engineer

How big should a service be? The age-old problem

Changing coding habits

Deciding how frequently to deploy

Simplifying technical designs

Someone recently shared with me that they really appreciate my ability to take a massive, complex problem or design and find creative ways to simplify it, making it easier and faster to build and reducing the overall maintenance costs and risks.

As often happens with me, I hadn't actually thought I had that skill or that it was anything special...

Anyway, I thought I'd share a few tools in my toolbox that I use to try and bring problems down to a reasonable, hopefully achievable size. And who knows, perhaps these can be useful for you...

Read more...

A set of coding standards

We have decided to focus on improving coding practices within my team, and I wanted to provide a digestible summary of key practices. It can be used to guide coding and code reviews, and also as input to an LLM generating code.

I thought I'd share it with you in case you find it useful or a good starting point. This is for Java, but I believe it can be easily tweaked for other languages.

And please I don't want to start a big debate about things like SOLID or clean code. Take what you want, leave the rest.

A shout out for ADRs

I just want to offer another shout-out for Architectural Decision Records (https://adr.github.io/)

I helped initiate the use of them at eBay for eBay-wide engineering guidance and direction a few years ago. They have been so powerful.

they offer a transparent and open way for anyone to participate in the conversation
they are a point of reference when the question comes up (and it always, always does) "why did we make this decision?" or if someone (and they always do) goes against the grain of a decision and is being somewhat stubborn about it
they offer a history of decisions, almost like reading a novel, to help new arrivals understand how we got where we are.

We are now using them as we work towards building a new API, and it is helping the team get clear alignment quickly and move on towards execution.

Code reviews in the age of AI coding

Whenever I "vibe code" using RooCode or Cline, the amount of code I generate in just an hour is massive.

This is fine when I am working on my own. But in a team setting, where we want to offer small PRs incrementally, this is going to start placing an overwhelming load on code reviewers. Imagine getting 5-10 PRs a day from someone whipping out code with an AI tool.

Choosing a backend language, choosing a culture

Somebody was talking to me about choosing a backend programming language for their startup.

I was realizing that in general, it is true that most languages offer many of the same features. But the community and tools that form around the language are the hidden factors that actually are more important.

Crossing the distributed systems chasm

A large part of my career has been helping an engineering organization evolve from a single monolithic system that brought the company success, to a system that can scale as the company hits their growth stage and starts taking off.

Often at this point, product and leadership are starting to feel hampered by a technology that is preventing them from quickly exploring new markets and new solutions. Engineering needs to scale out to multiple teams that can design, refactor, evolve, and deliver value independently.

Although there are exceptions, in the vast majority of cases a single monolithic server is not going to enable that.

But when you start breaking apart the monolith into independent services and components, you run into a whole new set of problems. You now have a distributed system. You have to deal with API contracts, partial failures, timeouts, data inconsistency, distributed logging and tracing, and so on. It's a pretty big leap.

Politics and sales as a software engineer

Politics and sales can definitely be a dirty business. Some people will say anything if it is to their advantage. Some people feel the only way they can win is if someone else loses. And I don't know, perhaps in some situations that's true, but that's not something I'm personally signed up for.

But that doesn't mean there isn't real value in learning how to practice "good" politics and sales as a software engineer.

For example, I often hear from engineers that the only things on their backlog are feature stories. They have all these ideas about how to make the product better - improving performance, getting rid of a bug-infested design, significantly improving productivity - but even though there is much serious head-nodding, it never actually gets prioritized.

I also work regularly with mentees who want to grow in their careers who feel their work should speak for itself.

It has taken many bumps and bruises along the way, but what I have learned is that it's not enough to let the facts to speak for themselves.

How big should a service be? The age-old problem

It happened again. I was in a conversation with a colleague, and they were trying to decide whether to make something a separate service or keep it with an existing service.

They said they were given the feedback, "see if there is a way to split your service into multiple services. If you can do this, then make them separate services."

This made me cringe, and motivated me to write this article.

Changing coding habits

Over the last few years, I have been working with teams trying to help them change their design and coding habits.

I am someone who loves theory and principles. In the past I had tried the approach of giving talks both as a group or individually, sharing these principles, trying to explain the impact of doing things differently, pointing them in the right direction. But after repeated attempts at this approach, I had to admit, it wasn't really working. Lots of heads were nodding, but when it came to the next feature or next pull request, the old habits were still there. It was somewhat disheartening.

There is also plenty of evidence showing that it doesn't really work to do a top-down big-bang transformation, where teams are restructured and everyone is told there is a new way of doing things. Again, heads would nod (or eyes would roll). The new rituals were followed, but underneath the rituals it was the same old approach and the same outcomes.

As my grandfather used to say, "a man convinced against his will is of the same opinion still."

As technical leaders, we are expected to help our teams get better at how they build software. But how do we get a new habit to stick and really make a difference?

Deciding how frequently to deploy

I was talking with a colleague last week about whether they should increase or decrease their deploy frequency. They were worried that deploying more frequently could cause more bugs. They also were concerned because it takes time and effort to do a deploy.

There is a well-known optimization curve in queueing theory that talks about the optimal batch size. You need to balance the holding cost - the cost of holding off delivering a batch with the transaction cost - the cost of processing a batch.

Page updated

Google Sites

Report abuse