The Basics

Here’s what I consider to be the basics. I call them that not because they’re easy, but because they’re fundamental. The foundation on which your advanced skills and expertise rest. Multipliers and nullifiers, makers and breakers of everything you do.

They don’t usually show up in technical books and yet without them a lot of brilliant effort can go to waste. I constantly have to remind myself of them, sitting on my own shoulder and wagging a finger in my face.

Here they are:

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.