Skip to main content

2 posts tagged with "swe"

View All Tags

2025 Spring SWE Reading Summary

· 6 min read

SWE Reading

I started catching up on some reading in the first quarter of 2025, likely fueled by some New Year’s resolution motivation. Reading books—mostly on software engineering and mostly from O’Reilly—has been more enjoyable than I expected. While it does sometimes take extra effort to find quiet moments to focus and work through a few chapters, I usually feel that it’s time well spent.

Of course, not all books (or chapters) hit the mark—some are too shallow, some hard to follow, and some more intense than expected, requiring re-reading or hands-on coding to fully grasp the concepts. I finished about three books this spring, with a fourth one paused due to some work and life distractions. I’m jotting down the reviews I had after reading them here—not only to leave a short record for my future self, but also to motivate myself to finish a few more books I have in mind for the upcoming quarter.

One tangential thought about reading: audiobooks help lower the barrier to getting started—they remove some of the stress or friction of grabbing a physical book (or ebook reader) and sitting down. That said, my mind tends to drift when I consume books (especially software engineering ones) in audio form. I do enjoy audiobooks, but I’ve learned I need to be cautious with them. Case in point: I’ve listened to Clean Code by Robert C. Martin a few times while commuting, running, or biking. Unsurprisingly, the book itself warns that you need to concentrate and work through the examples to really benefit from it—and going against the advice- it’s one of the books I remember the least.

Okay, let’s get to the books I read.

Code Isn't Working - Checklist

· One min read

The context: you've made a change, but the code isn't behaving as expected. Perhaps you fixed a bug, yet the buggy behavior persists.

I tend to go through this list in order, but it doesn't have to be strictly followed. For example, taking a break (the last item) is often the most effective first step.

  • Review code changes: are there any syntax errors, parameter differences, or test setup issues?
  • Examine logs: are any indicative logs missing or unexpected?
  • Rerun impacted tests on the same or another machine: could this be a machine-dependent issue?
  • Compare logs from successful and failed runs: what differences stand out?
  • Check surrounding code: are any preconditions broken? Does execution order matter?
  • Take a break, sleep on it, or discuss it.

That's it.