“The Basics” of Software Engineering

This is an opinionated grouping, and prioritization, of The Basics from Thorsten Ball. It guides you on the fundamentals of software engineering. If you enjoy this, I highly recommend you read the original, and subscribe to Thorsten’s Substack as this was his original work that I am merely building upon.

This grouping is a list I wish I had as a junior engineer. A way to think about the different facets of The Work, and the impact that each item has relative to each other. It’s highly opinionated, in that it’s influenced by my own career. While I started in enterprise, the last many years have been startup work. Startups exist across a spectrum of product market fit, yet any startup sufficiently risky that you should think twice about joining usually values an ability to balance getting things done with quality. So, take the following with a grain of salt in your particular situation.

Every high level point is from Thorsten’s work, and I again encourage you to view the original. The only value I add here, if any, is the grouping that guides me day to day. Without further ado, here is what’s important to me, in order of category and impact.

Work the problem / Get Shit Done

These items are laser focused on the tactical work of solving the problem effectively. You may take pause that testing falls in this category, however you will save yourself and your team untold hours by taking the bit of extra time to be thorough.

1. Understand what problem you’re solving. Knowing why you’re doing something is a requirement to knowing whether you’re actually solving the problem.
2. Before you comment on something, read the whole thing.
3. Read the manual, the docs, the instructions, the ticket.
4. Read the error messages.
5. Know why your fix is a fix.
6. 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.
7. 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.

Build your muscle memory

These items are less about particular reps and more about expanding how well you recognize patterns in your approaches. These patterns will be a tip as to whether you’re doing good work. Sometimes, they’ll clue you in when you’re not quite living up to your standards.

1. Do the homework before the meeting. You’ll stand out.
2. 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.
3. Always keep an eye out for bugs.
4. 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.
5. 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.

The work around the work

These are about work that exists outside the code itself. Sometimes it’s work that occurs in a meeting, or work that occurs because you need to make a well-formed PR. All will help you ship with a team effectively.

1. Keep your change free of unrelated changes.
2. Make sure that your PR is up-to-date against latest on your main branch.
3. Be on time.
4. 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.
5. Don’t ask for “quick” reviews when you never review other people’s code.
6. Make it a goal that people want to work with you.

Let me know your thoughts on these groupings. I’m particularly interested in lenses focused on building products in pre-product market fit startups, which has its own unique tradeoffs and challenges.