Last week I built a feature, and half of it wasn't even needed. Classic me.
These aren't lessons from a book or a YouTube video. These are mistakes I've made — some of them multiple times — while building features at work.
Every time I think "this time I'll do it right," I catch myself falling into the same patterns. So I'm writing these down — mostly for myself, but if even one point hits home for you, this was worth publishing.
1. Don't Jump to Code Without Understanding the Request
This is the trap I fall into the most.
A feature request comes in. On paper or in a discussion, it looks simple. Straightforward. And then something happens in my head — I know this, I've built something similar, let me just start coding.
I skip analyzing the actual impact. I don't ask — why does the customer want this? How does it align with the product? What's the real problem being solved here? I just jump to the solution I already know.
Just last week, this happened to me. A client request came in. Instead of discussing it with the team, I went ahead and built the full picture myself. I solved most of the user problems — but then I kept going. I added export functionality, migration flows, things that felt related to me but weren't actually needed for what was requested.
I made a small request into something big. Because in my head, if I'm building this, might as well build it complete. Turns out nobody needed the export and migration part. I just added it because it felt incomplete to me.
What I'm trying to do now is simple — understand why the request exists, check if it aligns with the product, discuss with the team before building the full picture alone, and document even a small PRD before writing code.
2. Personal Biases Are Real — Filter Yourself First
I know I get self-biased. This feature should look like this. This approach is better. I've pushed my opinions on teams many times. Most of the time, I was wrong. Sometimes I was right — but even then, I didn't have a solid answer for why this way.
That same feature from last week? After I built it, the team came with UI/UX suggestions. And I didn't accept them. Not because their suggestions were wrong — but because I'd already built it my way, and changing it felt like admitting my version wasn't good enough.
Now I'm stuck. The feature is built, but there's friction with the team, and I know deep down some of their suggestions actually made sense.
When someone — a colleague, a senior, even the founder — suggests something different, I feel frustrated. Because in my head, my point is right. But their point might also be right. And I'm not listening because I've already decided.
Everyone carries biases. Founders, seniors, colleagues. But the first person you need to filter is yourself. Build the feature, present it, explain your approach, and then actually listen. Even the silly suggestions — take patience. I'm not good at this yet, but I'm trying.
And honestly, code is cheap. If you're at 50-60% done, it's good enough to show the user. You don't know what happens until a real user touches it. Ship first, get rejected, improve, repeat.
3. Not Every Problem Needs a Quick Fix (And Not Every Small Thing Needs Deep Thinking)
I've done both extremes.
We were building the task management module, and there were bugs in the task spreadsheet. Column widths were off. I found what felt like a quick win — just remove the min and max width constraints. Problem solved, things looked right. Fast. Until they didn't. Things started overlapping each other. My quick fix created a new problem because I didn't think about what those constraints were protecting.
On the other side, I shipped a sections feature for projects. Spent way too much time on it. And ironically, the things that actually mattered — like making sections private or public — I skipped. I had them in mind, I knew they were necessary, but I got so deep into other parts that I missed what would actually make the user's life easier.
Sometimes we spend time on the wrong things and skip the right ones. The better way is to always ask — what's the cost and effort vs the actual benefit? And before shipping, ask yourself — did I build what looks good to me, or what makes the user's life easier?
4. Don't Get Emotionally Attached to Your Code
When I build something, I get deeply bound to it. It becomes my feature. And then when someone criticizes it or suggests changes, I feel hurt. Frustrated. Like they're criticizing me, not the code.
We were redesigning the onboarding flow. I got personally attached to my approach. Team members gave suggestions, and I didn't take them seriously. Not because the suggestions were bad — but because in my head, I'd already decided how it should look and feel. Looking back, that's not confidence. That's just being stubborn.
It's built for the end user, not for me. Even if I did everything 100% right technically, if the client or the team doesn't feel good about it — it's not serving its purpose. Sometimes you're right, and things still don't go your way. That's just how building things works.
5. Overthinking Early Doesn't Mean Better Output
I've spent way too much time thinking about perfection in the early stages of a feature. And then when stakeholders ask why are you behind the deadline — I don't have a good answer.
I built an Activity Hub feature. I spent an entire month on it. I went deep — finding every edge case, handling every aspect, building every possible scenario. And by the end of it, yes it was functional. It was usable. But the UX had a lot of problems, it didn't look good, and I'd burned a full month on something that should have shipped in phases.
I was building complex. The user wanted simple. Ship Phase 1, get feedback, then iterate. A month of building in isolation almost always produces something the user didn't ask for.
But the opposite trap is also real — I've shipped features without thinking about the long term and missed things users genuinely needed. The balance is hard. Think enough to not miss critical things. Don't think so much that you never ship.
6. Not Feeling Confident? Ship Anyway.
When I first joined my current company, I genuinely didn't feel confident that I could ship features here. The codebase was new, the product was different from what I'd worked on before, and every task felt bigger than it was. I kept thinking — can I actually do this?
But I did. One feature at a time. It happened.
When you're building something and you don't know what the end user really wants, when you can't fully visualize the outcome — you feel unsure. That's okay. Ship it. You get real feedback, you implement it, you ship again. That's how it works. You ship, you learn, you ship again.
7. Don't Take Feedback and Bugs Personally
When the team reports bugs, or repeats the same feedback, or keeps pointing out issues — I sometimes take it personally. Like it's a judgment on me as an engineer.
This keeps happening. With the Activity Hub, with the sections feature, with the feature I shipped last week — every time the team comes with suggestions, my first thought is but my approach is right. I feel it in my gut. And I resist.
Sometimes I am right. But I can't explain why clearly enough to the team. And if you can't explain why, maybe you haven't thought it through as well as you think.
Most of the friction isn't about the feedback itself — it's about when it comes. If I talk to the team before building, their input feels like collaboration. If they say the same thing after I've shipped, it feels like criticism. Same words, different timing, completely different reaction from me.
The other pattern I've noticed — I go too deep. I pick up a feature, then I start connecting it to other features in my head, and suddenly I'm building three things instead of one. And now I'm stuck, the team is waiting on me, and the thing I was actually supposed to ship is delayed.
Simple rule I'm setting for myself — ship what's assigned. Everything else goes in a separate plan.
These aren't rules I've mastered. These are reminders I keep giving myself — and honestly, I'll probably keep giving myself for a long time. I'm still learning to do most of these consistently.
If you're building things and making similar mistakes — you're not alone. I'm not there yet. But at least I know what to fix.