A Director of Engineering’s perspective on becoming a results-driven engineer
Dave Copeland was actively involved in making Washington, DC an East Coast tech hub.
He’s been a technical leader on engineering teams at startups like Opower and LivingSocial. Most recently, he was the Director of Engineering at Stitch Fix, the personal styling subscription box.
His array of experiences provided a front-row seat to best principles of effectively writing code.
In his recent book, SOLID is not Solid: Five Object-Oriented Principles to Create a Codebase Everyone will Hate, he shares some practical tips he’s learned from writing code in the startup space.
One of the main takeaways is a principle that Dave actively incorporates into his software development work:
Focus on results, instead of blindly following patterns.
We sat down with Dave to hear how he applies this concept as an individual developer and a technical lead.
The conversation below has been edited for length and content.
One of the main points in your book is to focus on results instead of blindly following patterns. How do you apply this idea in programming?
Before Stitch Fix, I worked in more traditional engineering environments. You’re given requirements to implement and you go implement them. In that situation, you don’t have a lot of agency, so it’s easy to focus too heavily on the way you’re writing your code.
For example, a lot of developers have been taught to make their code fit a rule or pattern. I used to see a lot of developers who would always use patterns first. Sometimes, if you wrote code that didn’t use a pattern, you’d be told it wasn’t good code.
There are these five patterns called The SOLID Principles. They’re very pithy, such as “all objects should have a single responsibility.” I started reading the papers that underly these patterns and they’re much more nuanced. Many developers are taught to default to these patterns but, really, they’re context-dependent.
It’s rarely “always use this.” But that’s how patterns often are thought about.
Any time there’s a pattern discussed, I ask two questions:
- What problem does that pattern solve?
- Do I have that problem?
Some patterns don’t make sense. There’s one called the “open-closed” principle that talks about making your code flexible and reusable. Every time I’ve seen it, it’s a nightmare. Often, you’re trying to solve a specific problem and you don’t need flexible code. If you’re trying to solve a specific problem, why make it more flexible than you need?
Part of the problem is there’s a lot of noise. There’s a low barrier to entry to give advice about coding, so there are a lot of thought leaders who generalize their own limited experience. And that includes me!
There are also these Agile aphorisms like “do the simplest things that could possibly work.”
“Could possibly work?”
I have to deliver code that actually works. What they’re really trying to say is “write simple code.”
Another aphorism I hear is “keep it simple stupid.”
I’m not stupid. These overly cute and unspecific sayings doesn’t lead to clarity or better outcomes. The reality is that solving the right problem in the right way is more impactful than structuring your code in any particular way. I’ve seen a lot of OO patterns that make code more confusing.
If someone is giving out advice I want to know – “Have you done that? Have you experienced this problem, or is it just theoretical?”
If you’ve just played with small applications, then how does what you’re proposing work with hundreds of developers? I want to dig in and figure out what exactly the person means. That can be hard because it turns a pithy, quotable thing into a long, drawn-out discussion with a lot of nuance. But at least you can get to the message.
How do you create an environment that allows an engineering team to focus on results?
I start by making sure I hire engineers with this mindset—focus on results. At Stitch Fix, we would assess applicants by having them write code in an app. Some developers would make this complicated system of abstractions. Other developers would do something straightforward to get it working.
That was what we wanted to see.
The result was we hired a lot of people focused on delivering business value, and not so much focused on technology for its own sake. Their “reward center” was making the user happy or productive. The code was a means to that end.
With that kind of mentality, you don’t see these patterns come up nearly as much. Instead of writing complicated, flexible code, you start doing things simply and directly. If it works, provides value, and is easy to understand it doesn’t matter if you used a pattern. Of course you still use them when it’s warranted, but it’s not the focus of how you work.
This comes from giving engineering teams agency, which is how we worked at Stitch Fix. If there’s a problem in, say, the warehouse, you have the agency to see that and improve it. You are evaluated on actual results. When you think about outcomes and have agency to achieve them you do better work.
In other words, one of the best ways to empower engineers is by letting them code the way that works best. Don’t force them to conform to arbitrary rules or patterns. Coding patterns are there to serve us, not for us to serve them.
