Principals
Stated as advice for myself, these are principals that I stand by. To put them here and not follow-through on them would be embarrasing, wouldn’t it? In sharing, I aim to innoculate myself against the slippage of the standards and practices herein. Also, having them here means I’ll probably actually look at them again, unlike much of my personal data. But that’s another issue.
First, there’s all of these. Copy/pasted on December 12th, 2024 from Thorsten Ball’s post titled “The Basics.” At this time I have not edited the wording from Thorsten’s original.
-
Test it manually. Even if you wrote and ran automated tests, test it manually at least once before you ask for a review. Record yourself testing it manually. You’ll be surprised by what you find.
-
Think through the edge cases. That doesn’t mean you have to handle them all right away, but you should have an answer to them.
-
Keep your change free of unrelated changes.
-
Make sure that your PR is up-to-date against latest on your main branch.
-
Before you comment on something, read the whole thing.
-
Do the homework before the meeting. You’ll stand out.
-
Understand what problem you’re solving. Knowing why you’re doing something is a requirement to knowing whether you’re actually solving the problem.
-
Accept that sometimes you’ll have to do things that you don’t find interesting or exciting or that don’t bring you joy. Sometimes it’s just work.
-
Write bug reports that are clear and understandable. Don’t write “it doesn’t work for me.” Give the reader information on what you did, what you expected to happen, what happened. Think about what might be useful to debug this, then put it in the ticket.
-
Bonus points: try to find a minimal set of steps to reproduce before you open a ticket.
-
Read the error messages.
-
Read the manual, the docs, the instructions, the ticket.
-
Be on time.
-
Know why your fix is a fix.
-
Every time you add a test, actually test that it would fail. Yes, literally: go and comment out the code that you think makes the test pass, then run the test, see it fail, comment the code back in, run test again, see it succeed. Only then have you written a test.
-
Do what you said you’ll do. If for some reason you can’t, let the person assuming you’re doing something know about it.
-
Don’t ask for “quick” reviews when you never review other people’s code.
-
Always keep an eye out for bugs.
-
Make it a goal that people want to work with you.
(end of list from Thorsten)
Others
- You get better at what you practice, and everything is practice. Consider this, especially in the midst of action otherwise experienced as habitual.
- Some things just work, yet are easy to skip when in the midst of life. Put your phone away. Use one sheet of paper for the days tasks. Use an alarm to wake yourself up at the same time everday.
- Practicing near skills shows little transferability—even things close the actual thing aren’t that helpful. So, focus on doing “the real thing”—getting the result you are looking for. The actions to do that may differ greatly from what you imagined.
- Do everything ASAP.
- Have a plan. You can always change plans.
- Write messages in the past tense (e.g. ‘I have done xyz’). Then see that the statement true.
- Prefer gratitude over apology.
- Prefer asking advice over asking permission.
- Focus on outcomes.