You spent days on your JIRA ticket... only to be told to redo it after your team lead reviewed your code?
A few years ago, I was working on a hotel management tool. My team lead asked me to redo an apparently trivial task. I had to store emails before sending them. It wasn't a full rework, but I had to change my approach. We had completely different expectations from the same task. Two days of work almost wasted.
If I had only asked one single question before starting... "Hey, I'm doing it like this, are we on the same page?"
If you're like me, eager to jump into the code, confident in your solution, hold your horses and follow these four tips:
#1. Always ask why.
Don't start coding if you don't understand what needs to be done—Especially relevant these days of AI-assisted coding.
Before coding, ask:
- Why this task?
- What's the real problem?
- Why solve it now?
#2. Read the existing code before starting.
Your changes might be simple, unless you have to refactor some legacy code first.
If you rush to code without knowing that, you'll give the wrong impression you're taking too long on a simple task. Yes, estimates are hard.
#3. Outline your solution with comments.
Start by sketching your "coding" plan in comments. That's your blueprint.
Of course, once you're done, don't forget to delete the noisy comments. Remember: names over comments and types over names.
#4. Write a one-page spec.
Draft a summary of the changes you need to implement, just for yourself. It's for you to think clearly before writing a single line of code.
A simple question would have saved me from wasting two days of work. Make sure everyone agrees on your solution before you start. It could save you from building the wrong thing.
It's better to annoy people by asking too many questions than by making mistakes for not asking any questions at all.
Strive for context before coding. Always! Because typing isn't the hardest part of coding, but knowing what to type.
I cover 30 lessons like the one in this post in my book, Street-Smart Coding here. That's the roadmap I wish I had on my journey from junior to senior.
Top comments (16)
had almost the exact same experience - built out a whole feature the way I thought made sense, and it turned out my mental model of the problem was just wrong from the start. the question thing is underrated. I started framing it as "here is my plan, what am I missing" instead of "is this ok" - gets way more useful pushback because people respond to concrete plans differently than open questions. two minutes of that conversation saves a day of wrong work
Great idea! And it shows we've already done some work. I like this rephrame.
yeah exactly - it also forces you to do the thinking first instead of outsourcing it. the plan being there means you have something to defend or update, not just accept
It reminds me of Eric Ries' book "The Lean Startup," where we must first ask ourselves, "Should it be created?" and if so, create it in parts so as not to advance too much. And if it's wrong, we don't have to throw everything away, but rather "pivot" and change the dynamics and start from where it was working.
That works for startups and for JIRA tickets/GitHub issues too...Putting that recommendation into my to-read list :)
If it helps, you can also read this article that I found while browsing the topic. I Stopped Writing Code First, And My Productivity Doubled
This is painfully accurate. The rush to code syndrome is something almost every junior developer goes through and honestly, even seniors fall into it when deadlines loom. The one-page spec tip is gold. I've started doing something similar: a quick design doc in a Google Doc before touching any code. It takes 15 minutes but saves days of rework. The hardest lesson in our field is that typing is the easy part; thinking is what actually matters.
These days, my preferred version is a quick, dirty PR with a proof of concept
100%
Very true! Another great tip.
Thanks! Probably something I learned from a book. I think it was Code That Fits Into Your Head or something like that.
Thanks for this post. I agree, always be a good communicator and that lands as even more important than the code itself. Code is cheap but context is expensive.
Especially true these days of AI-assisted coding, vibecoding, or whatever it's called now :P
I think adding tests improves clarity on which functionality we have to implement.
I completely forgot about tests when writing this. Great addition!
Very recognizable - I'm sure I made this same mistake, more than once!
Been there and done that plenty of times...I needed to write it somewhere as a reminder for myself.