The Next Last Mile
A Worthwhile Struggle for Engineering Excellence
As an engineer, I find that the most exciting moments come when prototyping new things. But the final 10% of taking the prototype to a ready-to-ship product usually consumes a disproportionate amount of time. The last mile often involves cleaning up the details: reliability, snappiness, handling of edge cases. In the end, the prototype and shipped product are capable of roughly the same things - but one delivers delight, and the other delivers frustration.
I apply that mindset to my skills as an engineer. There’s a big difference between being able to do something, being able to do something well, and being able to do something really well. Though it takes a “last mile” struggle to move up through those ranks, I find it to be both worthwhile and enjoyable (at least in retro. And once I level up, it’s fun to find the next last mile to tackle.
In that spirit, I thought I would document areas I’ve been focused on improving as an engineer. For context, I joined Maybern as a software engineer just over a year ago. Maybern is an early-stage startup building software to automate private equity fund calculations. It’s my first full-time job after college. I’ve had a great time so far and learned a ton - but there are plenty more tons left to go.
On-The-Fly Communication
Sometimes, I struggle with answering reasonable but off-the-cuff questions. I also occasionally blank during our daily standup, forgetting what I worked on the past day and what I am planning to work on for the current day. Examples of questions I’ve struggled with include:
“When do you expect that feature to land?”
“What is difficult about building this?”
“What was the root cause of that bug you patched yesterday?”
These questions aren’t usually difficult. It’s just that I’m not always ready to answer them in the moment. Part of that is because I maintain many concurrent work streams. This results in two problems:
It takes me a few seconds to “load” and organize that information in my mind
When I start speaking without fully formulating my message, I tend to speak quickly and in a hard-to-follow, stream-of-consciousness style, which can confuse other people
To deal with #1, I’ve been keeping closer mental tabs on what I’m working on, why I’m working on it, and how it’s going. This lets me “load” that information more quickly when needed. I’ll also sometimes write down a few small notes about my current work for reference.
For #2, I try to remind myself to slow down and think before I speak. There are engineers on the team who do this well, so I have great examples to learn from. I also occasionally practice speaking while holding a pencil between my teeth - it’s a good exercise to practice proper articulation.
Planning and Chunking Work
When I joined Maybern, I would dive in headfirst when starting on a new task. This would lead to a few issues:
I’d miss the forest for the trees and build something in a way that worked fine in isolation but didn’t fit well with the rest of the task
I’d miss out on the opportunity to clarify product requirements, resulting in unnecessary work and wasted time
I would lack a mental scaffolding of the overall task, which would sometimes contribute to my problems answering unexpected questions
I still feel the urge to write code immediately. But I’ve started to spend more time clarifying ambiguities with the product team and foreseeing engineering challenges. I’ll ask myself questions like:
What problem is this task solving for the customer? Why did we choose this approach to solve it? Are there simpler ways to solve it?
How will the new code fit into the codebase? What existing code can be re-used as part of this new task?
How will I break down this work into separate segments? Which part will be the most challenging? Will anyone else’s work block or interfere with mine?
By thinking through questions like these upfront, I’ve been able to work more linearly and more efficiently. I’m able to clarify important aspects with other members of the team ahead of time instead of after the fact. I’m not yet where I’d like to be, though, so I’ll continue working on this.
Platform Engineering
So far, most of my time at Maybern has been focused on product engineering. This requires building workflows and features using domain-expertise and an understanding of the problem being solved. It’s the core driver of potential customer value.
Platform engineering is akin to building the foundation and plumbing for a beautiful house. It is necessary to fulfill the product’s potential customer value. Just like you wouldn’t want to live in a house with a shaky foundation, users won’t want to use slow, unstable software. The product needs to scale well, be tested rigorously, and be auditable. Also, internal tools need to be built to allow team members to efficiently serve customers.
You’ve probably heard the saying, “Premature optimization is the root of all evil.” It’s important to keep that in mind. However, it’s equally important to accurately anticipate future needs. Good judgement can lead to engineering decisions that cost a little extra time today but save a lot of extra time (and headaches) down the road.
Over the last few months, I’ve gotten a small taste of platform work. Examples include:
Processing expensive computations asynchronously and in parallel
Introducing a testing framework to prevent regressions
Contributing to the rebuild of an important internal tool
Although I generally enjoy product engineering more, I’m looking forward to further diversifying my engineering skillset in the coming months.
One Inch at a Time
The good news is that all three areas are well within my control. The bad news? It’s still tough to break old habits and learn new things. But I’ll take it one inch at a time - and 63,360 inches later, I’ll have completed a mile. Then, it’ll be time for the next last mile. As I stack these miles into a marathon, I hope to bring users a little more delight and a little less frustration.