I have changed my mind about most things since my first job. These are the ones that stuck.
Reading code is the actual skill
I spent my first two years optimizing for how fast I could write code. Almost all of the value turned out to be in reading it: understanding a system well enough to make a small, correct change instead of a large, plausible one.
The habit that helped most was tracing one request end to end — from the click to the query and back — before touching anything.
Naming is design
If a function is hard to name, it usually does more than one thing. handleSubmit that validates, transforms, posts, and navigates is four functions sharing a name.
// Before
async function handleSave(data: unknown) { /* 80 lines */ }
// After
const parsed = postSchema.parse(data);
const post = await postService.save(parsed);
redirect(`/admin/posts/${post.id}/edit`);The second version is not shorter. It is nameable, which matters more.
Clever code has an interest rate
Every clever line is borrowed time. You pay it back every time someone — including you, in six months — has to reconstruct the reasoning.
Write the version you could explain to a tired colleague at 5pm on a Friday.
Comments should explain why
// Bad: increments the counter
count += 1;
// Good: the API counts from 1, we count from 0
count += 1;The code already says what. Only you know why.
Review for the important things
Formatting is a job for a linter. Spend the human attention on:
- Is this correct at the boundaries?
- Can it fail halfway and leave bad data?
- Will the next person find this?
- Is the trust boundary enforced on the server?
The bit that took longest
Saying "I don't know yet" without flinching, and then going to find out. Every senior engineer I respect does this constantly. It reads as confidence because it is.