Writing code is one thing. Maintaining it after 3 weeks, 3 teammates, and 300 Slack messages? That’s the real challenge.
Over time, I started collecting small rules, not from books, but from real experience.
Here are my personal Code Commandments or Code Principles: the ones I wish someone had shared with me earlier.
1. Write for your future self (and your teammates)
Write code like someone else will maintain it. Because they will. And one day, that "someone" is you after two sleepless nights and a different mindset.
If your code needs a diagram and a Slack explainer just to read, it's probably too clever.
Aim for obvious over original.
2. Don’t stay stuck longer than 20 minutes
Feeling stuck is normal. But spinning your wheels for hours isn't: it’s a silent killer of momentum.
Set a timer. After 20 minutes: explain the problem, what you tried, and ask for help.
Example:
Hi Tim, I can't seem to fix this bug that I'm working on. I get a 500 response, most likely because the payload is incorrect. I've tried rewriting the regex for the name validation, but it still does not work. Do you have a minute to help me?
3. Clarity > cleverness
Code is communication. If it makes you feel smart but confuses everyone else: rewrite it.
If your function makes you feel like a 10x dev but nobody else can understand it: rewrite it.
Clarity makes collaboration possible. Clean code communicates, even to someone who started yesterday.
4. Know the “what” and “why” before you code
No vague Jira tickets. Clarify outcomes and ask questions before your IDE gets involved.
So before you write a line of code:
- What's the goal?
- What are the edge cases?
- What doesn’t need to be built?
Understanding the why prevents wasted effort. It also makes you the kind of developer teams rely on.
5. Overcommunicate
Write clear commit messages. Describe PRs like you're onboarding someone. Leave better breadcrumbs.
Your team doesn’t need perfect code: they need visibility. Share blockers early. Explain PRs like you're onboarding a stranger.
Don’t assume others know what you know.
Communication builds trust. Trust builds teams.
6. Admit what you don’t know
No one expects you to know everything (that is, if you're working at a good company with realistic standards). But pretending you do slows everyone down.
Asking for clarity doesn’t show weakness: it shows ownership. Try to say “I don’t know...yet” more often. That’s how you grow.
7. Use micro-commits
Don’t commit 300 lines with the message “wip”.
Make small, focused commits. It’s a gift to your reviewers (and your sanity).
Massive PRs are a pain to review and a nightmare to debug.
Use atomic commits. Each should answer: “What’s the smallest, meaningful thing I changed?”
Future you (and your reviewers) will thank you.
7. Ask the "five-whys"
It’s tempting to fix the symptom:
- The test fails? Add a wait.
- The user clicks too fast? Disable the button.
- The data’s null? Add a fallback.
But patches aren’t solutions. They’re postponements.
The Five Whys is a simple but powerful tool: Ask “why?” five times to dig beyond the obvious.
Example:
- ❌ “The dropdown broke.”
- ✅ “Why did it break?”
- → Because the data was undefined.
- → Because the fetch failed.
- → Because the endpoint wasn’t ready.
- → Because it was never implemented.
- → Because we missed it in the planning.
Each “why” brings you closer to the real issue and the real fix. This approach saved me from countless repeat bugs and sloppy fixes. It also helped me communicate more clearly with PMs and designers, because I understood the system, not just the symptom.
Final Thoughts
You don’t need to follow every rule every day. But having principles beats winging it.
Which ones resonate with you? What would you add to your own list?
Drop it in the comments or share your own version! I’d love to read it.
Top comments (0)