I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.
Learnings about debugging
Today, I debugged two major problems in the course of fixing bulk uploads. Here’s what I learned from both:
Facts change over time. Recheck them when you need them. Uploaded users couldn’t access paid tools, and when I investigated I discovered that their Stripe IDs were blank. That’s strange - I uploaded them with Stripe IDs. In fact, those Stripe IDs were being reset to null upon sign-in (b r u h) because I was using the wrong Stripe credentials. The funny thing is that I might have missed this if I checked the DB immediately after upload. “Yup, looks good.” However, facts change over time. Checking the DB after sign-in, when I encountered the issue, ensured I could catch the error. Recheck the relevant facts of the world when they are needed.
AI can be helpful but abort if you’re spinning your wheels. Debugged a Keycloak error. Claude did not help much here. Claude can be very helpful sometimes when you ask open ended qustions, and if that fails it can be good as a rubber duck partner, but sometimes you have to fall back on classic debugging strategy.
Find a positive control - get something working. The real frame that ended up helping me was to get a positive control working. My prod load uploaded to prod auth was failing. Test load → prod auth was failing too. I stripped it back again to get something working. Previously test load → test auth had worked, so this was my positive control. It failed - so I knew that I had regressed, and this narrowed my search space. I tried something different each time and realized that I was hitting the wrong endpoint.
High entropy. Once you’ve narrowed your search space, try lots of different things to fix the issue. Try to find buttons and knobs in your process that you didn’t know were there. This is also called questioning your assumptions.
General learnings and observations
As a PM - ensure that agenda and quick context are in the calendar invite notes. Could be a sentence or two but it makes sure people have something to catch up with if they’re confused or get distracted during the meeting.
Just ship updates really fast. If you see something, fix it and put a PR up. Be prolific. Cultures that reward this will win - learned a lot from the Pragmatic Engineer interview with Facebook’s “Coding Machine.”
It felt really easy to do postgres commands after writing the guide yesterday.
If I do work that I’m proud of - if I do the things that help me feel good, like follow a plan, complete something, create an artifact, send a status update - I feel incredible. It doesn’t matter how long I spend doing it, I can recover an entire sluggish day with a few hours of dedicated work. It doesn’t even matter what specifically I’m working on - yesterday’s bulk upload work felt as satisfying as any advanced LLM type shit I’ve ever done. This solves the procrastination-guilt buzz that seems to rack my body otherwise.
Doing this consistently day in and day out seems to open me up to more kinds of learning. At the end of the day today I was able to ask Mark for advice on some scary things that I normally would feel too insecure to confront. If I’m working consistently and with discipline, it leads to a positive spiral where I can seek out help and continue to learn and discover new possibilities. If I’m not, it leads to a negative downward spiral where I isolate myself and continue to feel alone. No matter where I am in the spiral, the lever I can always pull is to make a plan, make a schedule, execute, and send a status update.
I have good taste on how to tell stories and communicate ideas. I consciously put on that hat today while helping to edit a startup’s application for an accelerator. I let myself slide firmly into having strong opinions and thinking about good story structure. It feels really good to recognize this skill in myself.
I learned that it’s possible to have a vulnerable conversation with my client about how I’m meeting expectations. I mean, my fear has been that talking about it will Speak that Reality into being. But if we’re disconnected, we can probably both sense that. And if there’s a mismatch in expectations - that exists already! Naming it will create a path forward if any. Seems like the key is to view an expectation gap as something mutable, not something permanently broken.
I’m being pitched on founding a company. On the one hand, my focus is on becoming a really good engineer. On the other - maybe I could do this while founding and building something from scratch? I’m kind of already doing that.
I feel like my capability has grown even in the last two days. I was able to solve a new sign-in issue today on my own, and I felt overpowered rather than underpowered while doing it. I knew how to access more logs if I ended up really stuck, and felt a new confidence and determination to solve my own problems after yesterday’s reflections.
Take ownership. What happens when I can’t rely on that senior engineer?
(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)