4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

Source: Dev.to

You spent days on a 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 lead asked me to redo a seemingly trivial task—storing emails before sending them. It wasn’t a full rewrite, but I had to change my approach. We had completely different expectations for the same task, and two days of work were almost wasted.

If I had asked just one question before starting—“Hey, I’m doing it like this, are we on the same page?”—the wasted time would have disappeared.

If you’re like me—eager to jump into the code and confident in your solution—hold your horses and follow these four tips.

Tip 1 – Clarify the problem before you write any code

• Ask “Why?”
  • Why is this task needed?
  • What real problem are we solving?
  • Why do we need to solve it now?
• Make sure you understand any hidden dependencies (e.g., legacy code that must be refactored) before estimating effort.
• A simple clarification can prevent the impression that you’re taking too long on a simple task.

Tip 2 – Sketch a plan in comments first

• Write a brief outline of your approach directly in the source file as comments.
  This serves as a blueprint you can review before committing any code.
• After the implementation is complete, delete the noisy comments.
  Remember: good naming beats comments, and type information beats vague names.

Tip 3 – Draft a personal summary of the changes

• Create a short, bullet‑point summary of what you intend to change and why.
  This forces you to think clearly before typing a single line of code.
• Keep the summary for yourself (or as a quick reference in a PR description) to stay aligned with the original intent.

Tip 4 – Communicate and confirm before you start

• Share your proposed solution with the team and get explicit agreement.
  It’s better to “annoy” people with a few extra questions than to make costly mistakes later.
• Strive for context before coding. Typing isn’t the hardest part of development; knowing what to type is.

I cover 30 lessons like these in my book, Street‑Smart Coding, which provides the roadmap I wish I’d had on my journey from junior to senior.