This is a guest post from Adam Leventhal. Enjoy.
Dear new developer,
I love software engineering. Even as excited as I was to start my first job, I didn’t imagine the deep and enduring joy it would bring. In my career, I’ve oscillated closer and farther from writing code, and while management and entrepreneurship are wonderful, there’s nothing like the pure joy of building software.
Building great products takes a team. Code is a critical piece, but that doesn’t mean you need to stick to your narrow lane. Yes, developers write code, product managers write specs, doc writers write docs, marketing writes slides, sales sells, support supports, etc. Focus is important, but it’s a myth that doing your job well requires focus at the expense of understanding the holistic view of how products are built. Understanding the full product lifecycle–from conception, to purchase, install, and support–will make you better at your job and lead to better products.
One of the first things I worked on professionally was a product called DTrace. It’s a tracing tool to help understand how systems operate. It’s used to find bugs, chase down performance problems, or explore how a code base operates. I was drawn to the project early on because of the extremely precise and creative engineering required to safely instrument running programs and kernels. It was all very cool, very satisfying. An extremely formative moment in my career came when I was demonstrating an early DTrace prototype to a customer. We used this new lens into their software to understand behaviors that had always been mysterious to them. Their ideas came one on top of the next as we exposed all kinds of crazy behaviors and pathologies on the fly. I had seen the power and utility of what I had built in my own use, and my team’s use. Seeing a customer–and engineers quite different from me–get so fired up was eye opening. I still wanted to build cool stuff and write hard code, but understanding the problems it solved and the people who used it informed my work from then on.
There were three engineers working on DTrace. We were our own product management. We built features we needed to solve urgent problems for ourselves and customers. We were our own marketing, giving talks and writing blog posts. We were our own doc writers, churning out a hefty users guide. Those activities weren’t downstream of development, they were an integral part of it. When building a feature, we talked about how to explain it to sales people, to users, to support engineers. Sometimes that meant changing what we had planned to build: if you can’t write the documentation for a feature you’re probably building the wrong feature.
Almost a decade later I joined a new team that could not have been more different. The development team was comfortable in their ignorance of the broader product. They didn’t just stick to the code, they were narrowly focused on just their own subsection of the code. In the Solaris Kernel team where we built DTrace, we would follow bugs up and down the stack, through multiple, enormous code bases, to determine the root cause of problems. Here, developers were content to chase a problem to the edge of the module they owned, and then reassign the bug to the developer who owned the next module. The team barely had a shared understanding of what they were building, much less of that true north of customer need. That gap was evident in the end product: modules were poorly integrated and features fell short of solving customer problems.
Whatever you’re working on, understand not just what’s needed, but why. Listen in on a sales call, talk to a customer, or do a ride-along with a support engineer working on an escalation. Some companies have great programs to involve engineers in the broader product lifecycle. If yours doesn’t it’s probably (hopefully!) because no one has asked. Empathy is an engineer’s greatest asset: empathy for the customer to understand their problems and priorities; empathy for the doc writer trying to explain a complex feature; empathy for the next engineer to pick up your code and make sense of it. Empathy starts from a curiosity to understand what and why.
Find true north for the products you work on. It will make your work better and bring you more satisfaction.
Adam H. Leventhal is an engineer at Oxide Computer Company building a new, modern computer. Previously he was a software engineer at Sun Microsystems, CTO at Delphix, and co-founder, CEO at Transposit. He’s sheltering in place in San Francisco with his wife, teen, toddler, and two dogs. Find more of his writing here, here and here.
Letters To A New Developer 