As software engineers, we all want to write the best code possible. Along the way, it’s easy to get carried away in search of perfection and lose sight of actually shipping. Recognizing how we get distracted or stuck in the weeds can help us stay focused on delivering value rather than getting paralyzed by the endless array of things we could do. With some self-awareness and experience, we can better judge what’s truly important in the moment.
The Story of Ana the Perfectionist
Ana was an introverted computer science major who studied machine learning after taking an elective course in her senior year. She loved the complexity of neural networks and was fascinated by their ability to find hidden patterns. After graduating, she jumped at a chance to join a small but growing e-commerce company as a machine learning engineer.
The product team at the company had been asking for a modern recommendations model for months to enhance the online shopping experience. Customers needed more personalized suggestions based on their purchase history and interests. The initiative had been delayed, but with Ana on board, the managers were eager to finally launch it.
Ana started strong, quickly building a basic prototype model. She used the latest deep-learning techniques and was proud of their early accuracy. However, as the deadline got closer, Ana started spiraling. She became convinced the model wasn’t good enough yet. There were more optimization techniques and frameworks she wanted to explore. Ana began a side project experimenting with an approach combining several models.
Meanwhile, the backend engineering work piled up. The infrastructure to serve recommendations still needed work. Plus, Ana needed to run scalability tests and work out how to evaluate the models. When the head PM asked Ana for an update, she said she needed more time to analyze the results.
Ana’s manager, Ian, began noticing the delays. He wondered if Ana was biting off more than she could chew. This wasn’t her first time getting sucked into a research rabbit hole. He remembered her previous project developing a custom image recognition algorithm. He’d had to pull her off to meet the launch date after months of unfinished experimentation.
Ways We Get Stuck
Ana was excited to join the company and build fancy machine-learning models. But she got a bit carried away.
We’ve all been in Ana’s shoes before. You start a new project all pumped up, but then you get bogged down trying to make it perfect. Or you go down an internet rabbit hole researching the latest hot approaches instead of just picking something that works. Or you spend more time helping coworkers debug their code than writing your own.
It’s tough to find the right balance. You want to plan ahead but not over-plan and end up spinning your wheels. You want to learn new things without obsessing and over-analyzing every new tool. You want to be helpful but not become the office therapist listening to everyone’s problems.
Recognizing when you get stuck takes a lot of experience and self-awareness. If you’re lucky, your manager will help you by checking in regularly — no matter how both engineers and managers hate this, there’s no better way yet. The more you work as a software developer, the more you learn the patterns you have and start foreseeing upcoming problems. Here are a few of the most common reasons why we get stuck to help you out, from Camille Fournier, author of the book “The Manager’s Path.”
Brainstorming/architecture overplanning
We’ve all been there — staring at a blank file, dying to dig in but compelled to plan everything out first. Ben can spend weeks whiteboarding detailed diagrams, trying to think through every possible edge case. He just wants to mitigate risk and avoid surprises down the line. But often, excessive planning leads to analysis paralysis that actually delays progress. Ben’s feature rollouts keep getting pushed back while he architects the perfect system only he can see yet.
Researching solutions forever
Mykola loves evaluating new tools and APIs — he’s like a kid in a candy store. But he often gets carried away, losing whole days benchmarking notification libraries when all he really needs is something that works okay. He just doesn’t want to pick something subpar and be stuck with it forever. Of course, his teammates don’t care if it’s the absolute coolest notification library — all they need is the notifications feature live. Mykola has to start asking himself — is this research really necessary right now? Or am I just having fun?
Refactoring endlessly
Mike suffers when reviewing some of the older database code. It’s far from being elegant. He’s itching to clean it up and impose order on the messy logic. But while refactoring can feel quite satisfying, Mike has to admit it’s a lower priority right now. As much as she loves clean code, he knows staying focused on new capabilities delivers more value. At least until the next sprint.
Helping others instead of own tasks
Olha is the person you go to when you are stuck — she just can’t resist helping anyone out. But she often spends way more time digging into others’ problems than her own tasks. Part of being a team player, sure, but Olha has to learn to say no sometimes, or she’ll keep blowing her own deadlines. Her manager reminded her recently she wasn’t doing her teammates any favors by enabling them to lean on her too much. They need to learn to solve problems on their own.
Jumping on fires when not on-call
Zack prides himself on being available anytime something breaks. Even if it’s not his problem, he takes it on like it is. Late nights debugging weird production issues unrelated to his work are the norm. No good deed goes unpunished, apparently. Zack is burning out being the hero all the time. As a result, his manager told him to stay in his lane, write some docs for others, and let them learn to put out fires, too.
Excessive testing
Ella meticulously wrote tests for everything, including the functions that just returned obvious values. But she’s coding much longer than anyone else, bogged down by test maintenance. Other engineers are joking that Ella will start testing the tests too soon. And even though she doesn’t want anything to slip through the cracks, testing had diminishing returns. Sometimes, a B+ approach is good enough.
Excessive automation
Elia loves writing scripts and bots cause they are so robust and powerful. Why do repetitive tasks manually? But everyone on the team knows Elia is easily carried away, automating things rarely used or easily replaceable with quick manual steps. His time should be better spent building core features, not tools no one will use. The lead PM reminded Elia to pause and consider the ROI before going down the automation rabbit hole. Sometimes, you must resist the allure of potential scaling and stay focused on the now.
Learn the Balance and Look for Patterns
It’s easy to get carried away as an engineer. We want to build elegant systems, use the latest and sexiest technologies, and help our colleagues. But we have to balance ambition with pragmatism. Perfectionism can lead to paralysis and distraction from core goals.
The most intelligent engineers focus their time on what delivers the most value. They resist rabbit holes that aren’t critical right now. They know when to say no to helping others at the expense of their own work. And they are comfortable shipping something good enough rather than chasing the impossible ideal. All while somehow writing maintainable code and minimizing tech debt.
Learning this balance takes experience and self-awareness. Look for patterns when you get derailed. Be honest about when research has gone too far, or a problem isn’t yours to solve. And don’t be afraid to ship it — you can iterate later. Keeping your manager in the loop will provide guidance when you’re unsure.
Striving for excellence is great — as long as it doesn’t prevent you from finishing anything at all.
Originally published on Medium.com
