(A living document.) 1
If you are faced with a question to which you don’t know the answer, spend fifteen minutes looking for the answer yourself. Then ask someone else.
There is no shame in asking questions.
There is a great deal of shame in being too proud to ask questions.
Always leave a codebase cleaner than you found it — whether it’s adding documentation, cleaning up syntax, or fixing an edge case. Someone will be grateful, even if that someone is Future You.
Tests deserve comments, too.
Decide what you’re willing to leave at work. Stick to it. 2
The best way to improve as a programmer is to program; the best way to improve as a software developer is to use software.
Never forget that one can use software by reading it.
Don’t treat code reviews or design critiques as a adversarial process; recognize that its a cooperative effort to refine artifacts into their best possible form.
Assume that everyone has the best intentions. Even if they don’t, it’ll make your life easier.
When debating an issue, ask yourself “how much do I really care about this?” Otherwise, you will inevitably spend time and energy debating whether something should be named FooWidgetProcessor or FooWidgetHandler.
Sometimes, though, it’s important to decide whether or not something should be FooWidgetProcessor versus FooWidgetHandler. Naming is important; conventions are important.
Communication is a more important skill than code. Be cautious of anyone or anything that implies otherwise.
Take enough pride in your work to be happy when it succeeds but not enough to be destroyed when it fails.
Your stuff will fail, like, a lot. The test data won’t be extensive enough; there will be an edge case you missed; you will miss a use case; your work will not be resilient enough or robust enough or gracious enough. Don’t think less of yourself for it; learning through error is still learning.
In ascending order of robustness: thought, conversation, email, documentation, code.
Optimize for robustness.
All documents are living documents.
Don’t confuse reliability with uptime.
Everything happened for a reason, even if it’s that six-year-old cron job that checks for emails containing the word “yes”, and even if the reason was “we had to ship this feature in two days.” Pretending that past developers are incorrigible bogeymen is only going to cause you more grief.
“Boring” is a better heuristic for code quality than “clever”.
All code is technical debt. Even if its a CLI that you think you’ll use for a one-off job and then delete; even if its a ‘stop-gap measure’. (Stop-gap measures stop being stop-gap measures as soon as they’re promoted to prod, at which point they become the status quo.)
You make what you measure. Invest a lot of time in making sure that you’re measuring the right things.
Everyone knows some things better than you and some things worse than you. Investing too much in either is a bad idea.
There is no shame in investing in your tools.
Consider everything that helps you work as a tool: your language, your code conventions, your IDE, your headphones, your chair, your iTerm font, your desktop background, your coffee.
Help as many people as possible.