// field-notes/must-do.md
What it actually takes to become a coder
Syntax is the easy part. This is the page for everything else - the logic, the thinking, the communicating, the shipping - the stuff nobody puts in a course syllabus but every working engineer had to figure out anyway. Annotated like a notebook, because that's honestly how it gets learned.
not strictly linear — you loop back through these constantly
Build the logic before you write a single line
Code is just logic translated into syntax. If the logic isn't clear in your head, no amount of framework knowledge saves you. Slow down here on purpose.
The 5-step habit
- 1. Restate the problem in plain English, out loud, in your own words.
- 2. Work a tiny example by hand — literally on paper — before touching a keyboard.
- 3. Find the pattern in how you solved the example manually.
- 4. Write pseudocode — no syntax, just steps.
- 5. Code the happy path first, then handle edge cases.
Signs you skipped this
- You're editing code by trial and error, not by reasoning.
- You can't explain why your fix worked.
- You copy a solution and it works, but you couldn't reproduce it from scratch tomorrow.
- Every new feature request makes you nervous instead of curious.
Level up how you think, not just what you know
Frameworks change every two years. The way you reason about problems is what actually compounds. Treat thinking as a trainable skill.
First principles
Strip a problem to facts you're certain of, then rebuild the solution from there — instead of copying the nearest pattern you remember.
Five whys
Ask 'why' about a bug or decision five times. The first answer is a symptom; by the third you usually hit the real cause.
Think in systems
Before writing a line, sketch how data moves in → through → out. Bugs mostly live at the seams between parts, not inside them.
Abstraction ladder
Practice explaining the same idea at 3 zoom levels: to a beginner, to a peer, to yourself at 2am. Each level sharpens the others.
Build a pattern library
DSA and design patterns aren't trivia — they're a vocabulary of pre-solved shapes. More patterns you recognize, less you invent from scratch.
Deliberate confusion
Sit with not-knowing for a few minutes before searching. The struggle is what builds the mental model, not the answer itself.
A repeatable loop for getting unstuck
Problem solving isn't talent, it's a loop you run on purpose. Same loop for a bug, a LeetCode problem, or a system design question.
Understand — restate the goal and constraints before anything else.
Plan — sketch the approach in pseudocode or on paper.
Execute — write the smallest working version first.
Review — test edge cases, then loop back if something's off.
Stuck for more than 20 minutes? Run this checklist
- Explain the problem out loud, line by line (rubber-duck it).
- Write down exactly what you know vs. what you don't.
- Shrink the problem — solve a smaller version first.
- Work backward from the expected output.
- Search for a structurally similar solved problem.
- Step away for 10 minutes. Seriously — it works.
Communication is a coding skill, not a soft skill
Code that no one can review, a bug no one can reproduce from your report, a PR no one wants to open — all communication failures, not technical ones.
Explaining, the Feynman way
Explain what you built to someone with zero context, using zero jargon. Every place you stumble or reach for a technical word to cover a gap is a spot you don't fully understand yet. Rewrite it in plain language until it's smooth.
Rubber-duck debugging
Explain your code line-by-line to an object on your desk (or a person, or a doc). Most of the time you'll spot the bug mid-sentence — because explaining forces the precision that skimming doesn't.
Vague question
"My code doesn't work, help?"
Good question
"Expected X, got Y. Here's the minimal snippet, the exact error, and the two things I already tried."
Understanding vs. memorizing — know the difference
Syntax recall fades in a month. Real understanding is what lets you rebuild it after it fades.
Self-check: do you actually understand it?
- Can you explain it without opening docs or notes?
- Can you rebuild a simplified version of it from scratch?
- Can you say why it works this way, not just that it does?
- Can you teach it to someone newer than you, and answer their follow-up questions?
If the answer is "no" to more than one, you've memorized the shape, not the substance. That's fine — it just means it's not solid yet.
Projects that actually prove something
A portfolio full of tutorial clones proves you can follow instructions. Projects that prove skill look different.
Tutorial clone
proves you can follow instructions
CRUD app + auth
proves you can wire a real stack
Full-stack app solving a real problem
proves judgment, not just execution
Open-source contribution / collaboration
proves you can work inside someone else's codebase
A project is portfolio-worthy when it has...
- A real (even small) problem behind it — not just 'practice CRUD'.
- A README that explains the why, the stack, and how to run it.
- A live deployed link, not just a repo.
- At least some tests, or a clear explanation of what you'd test next.
- A story you can tell in an interview: a decision, a trade-off, a bug you hunted down.
Resume: signal over decoration
A resume's only job is to earn 6 seconds of attention and turn it into a callback. Every line should pull weight.
Bullet formula
[Action verb] + [what you built/fixed] + [tech used] + [measurable outcome]
e.g. "Rebuilt the checkout flow in React/Node, cutting page load time from 3.1s to 0.9s."
Do
- Quantify impact wherever honestly possible.
- Match keywords from the job description.
- Keep formatting simple — most resumes are parsed by ATS software first.
- Lead each bullet with what changed, not what your job title was.
Don't
- List every technology you've ever touched once.
- Use tables, columns, icons, or images an ATS can't parse.
- Write tasks ("responsible for...") instead of outcomes.
- Let it run past one page early in your career.
Keep this taped above your monitor
The reminders that matter most are the ones you forget under deadline pressure.
Quick-reference cheat sheets
Pin these. They're meant to be glanced at, not studied.
Big-O, at a glance
Git essentials
Debugging checklist
Daily practice loop