
## The worst time to learn how to deal with a crisis is during a crisis

How's that for self-evident? But -- it's true.

You should have a plan for when things go wrong. This is especially true in software development.

The first time you're dealing with a production issue is _not_ the time to learn how to deal with one. You need to have a plan in place for when things go wrong, and you should be ready to roll when the time comes.

### Tooling is gives you sensory feedback

Lucky for you, there's loads of tools that can make life easier when everything comes crashing down. You'll want to be able to reliably see what's going on in your system, and to be able to quickly identify what's going wrong.

At [Craftwork](https://craftwork.com), our current debug stack uses [PostHog](https://posthog.com) for session replay and product analytics, [Sentry](https://sentry.io) for error tracking, and Slack webhooks for alerting the team.

### Testing your code is a baseline

If you're not testing your code, you're going to have a bad time. Having tests written for your software is a baseline requirement - great tests prevent you from shipping flawed features, and help you understand when new features break old expectations. At a minimum, write tests for the features and scenarios in your software that are critical to your business, and build the habit of adding more over time.

I have been _really_ impressed with the devX of writing tests for Ruby on Rails - and there is literally no-one better to learn from than my pal and colleague CJ Avilla - he's done a whole series on [testing rails with RSpec](https://www.youtube.com/playlist?list=PLS6F722u-R6Ik3fbeLXbSclWkT6Qsp9ng) that I highly recommend, _even if you're not a Ruby developer_.

It's that good.

### Don't be afraid to ask for help

If you're stuck, ask for help. There's no shame in asking for help; you should view it as a _strength_ to know when a second set of eyes are what you need.

If you're working on a larger team, you'll get a feel for how long you should work on a problem before asking for help (the more severe the problem, the shorter this time should be).

If you're a solo founder or an indiehacker, this is one of the best things about finding community online. There's always smart people willing to help you out.

But -- and I can't emphasize this enough -- **the worst time to start building a community is when you need help.**

[The best time to start is now](https://mikebifulco.com/newsletter/today-is-your-day-to-start).

### Close the loop with affected users

Here's the secret sauce: Once you've found and fixed a problem in production, get in touch with affected users and let them know what happened, and how you fixed it. They'll love you for it, and you'll build trust with them. This is a great way to turn a negative experience into a positive one, and to build a relationship with your users.

Especially if you're a solo founder or indiehacker, vulnerability and transparency are what will make people believe in you. It's a superpower that is waiting for you to use it. Don't squander the chance!

## Get the ball rolling now

The great thing about these problem solving techniques is that each one adds value to the others, and they can be added incrementally. You don't need to have a perfect system in place to start - you just need to start.

---

## More of my work on this topic

As it works out, I've got a few more resources on this topic that you might find interesting:

### Product Analytics for engineers

I've been experiencing a downturn in newsletter subscribers through the form on my website recently. Ironically, if you're reading this, you're probably already subscribed. Rather than just throwing up my hands and saying "oh well", I decided to dig into the data and see what was going on, and I thought it would be a good opportunity to showcase the process I use for debugging web app problems that aren't as simple as "this page is crashing".

Check out [Product Analytics for engineers](https://www.youtube.com/watch?v=4nWcB1a8M1s) on YouTube for the first part of the adventure.

### Automate your SaaS product's crisis response

As it works out, this topic is something I've got some experience with. Back in 2020, just after my previous startup smpl was acquired, I was applying to devrel jobs at Google. As part of the interview process, I put together a talk about how to automate your SaaS product's crisis process, based on my experience at smpl.

While the information might be a bit dated, the principles are sound, and these slides landed me a job running Developer Advocacy for Google Assistant. Check out the slides here: [Automate your SaaS product's crisis response](https://github.com/mbifulco/talks/tree/main/01-automate-your-saas-products-crisis-response-process).

---

## Don't take my word for it

There's loads of great resources out there for debugging, problem solving, and customer support for product builders. Here's a few that I've found helpful recently:

- Kent C. Dodds has a great series of blog posts on testing javascript apps. A great place to start is [Write tests. Not too many. Mostly integration.](https://kentcdodds.com/blog/write-tests)

- PastMaps founder Craig Campbell has shared some incredible stories about proactive and reactive user research in his journey to to growing a sustainable business. I highly recommend following him on Threads for [gems like this one](https://www.threads.net/@that.map.guy.craig/post/C8u9Fn1yIzq).


Debug tips from a lifetime newbie

The worst time to learn how to deal with a crisis is during a crisis

Automate your SaaS product's crisis response


Growing up, I spent a lot of time in the garage with my dad. He's a man of many projects - and hardly a weekend went past where I wasn't helping him work on _something:_ from cars, to household repairs, lawn work or tinkering with electronics. I learned a lot about tools and how to use them, and I learned that the right tool for the job can make all the difference.

Two things that he used to tell me often were:

1. **Power tools are _always_ out to get you.** They may feel like they'll help you get the job done fast, but they're powerful, and they don't care about your fingers. Respect them and act as though they're always trying to hurt you.
2. **There's nothing worse than having to _fix_ your tools.** If you take care of your tools, they'll take care of you. Keep them clean, sharp, and in good working order.

These are both true - and while rule #1 is _less_ applicable to software tools, rule #2 is _absolutely_ something that I've found to be true in my career as a software engineer. The tools we use to get our work done are _incredibly_ important, and taking the time to tune them to work _just right_ can make a huge difference in our productivity and happiness.

## Tuning your tools just feels good

I use Visual Studio Code for nearly all of my coding and writing. I love it because it's quick and customizable, and it just works well. No shade if you're a fan of `vim`; you do you. I dig VS Code, and I've spend some time recently changing up my setup to make it even better.

Here's a few things I've done recently to tune my VS Code experience:

### Houston theme

There's an installable theme for VS Code called [Houston](https://marketplace.visualstudio.com/items?itemName=justusadam.language-houston-theme) which was actually made by the team that makes Astro. If you prefer a dark theme and like some spicy accent colors, you might like Houston.

<Image
  publicId="newsletters/keep-your-tools-sharp/houston-theme"
  alt="Houston theme in VS Code"
  caption="Now that's a delicious-looking theme."
/>

### Zen Mode

[Zen Mode for VS Code](https://code.visualstudio.com/docs/getstarted/userinterface#_zen-mode) is a great way to tune your IDE to be more focused. I use it for writing articles and newsletters. It's _built in_ to VS Code, so you don't need to install anything. Just press `Ctrl + K, Z` to enter Zen Mode, or the `Toggle Zen Mode` command in the command palette.

Straight out of the box, Zen mode is pretty damn minimal - and that's not for everyone (myself included). To customize Zen mode, open up VS Code settings with `Command + ,` and search for `zenMode`. Y

<Image
  publicId="newsletters/keep-your-tools-sharp/zen-mode-settings"
  alt="Zen Mode settings in VS Code"
  caption="I like to use the Center Layout setting for writing articles and newsletters."
/>

### Pieces for VS Code

[Pieces for VS Code](https://marketplace.visualstudio.com/items?itemName=MeshIntelligentTechnologiesInc.pieces-vscode) is... amazing. It's a contextualized note-taking app and code copilot that helps you store, annotate, and generate code snippets in your IDE. Not only is it context aware -- as in, it knows what you're working on as well as the places where you're doing research -- but it also features an _on-device,_ privary first LLM that can generate code snippets and notes _without_ sending your data to the cloud. 🤯

It comes from the lean, mean squad at [_Pieces for Developers_](https://pieces.app/). If Pieces sounds familiar, you probably know about it because of [my interview with their founder Tsavo Knott on Software Engineering Daily](https://softwareengineeringdaily.com/2023/10/25/building-pieces-app-and-the-future-of-developer-productivity-with-tsavo-knott/) a few months back, and definitely not from Scott Hanselman's [recent podcast](https://hanselminutes.com/913/redefining-developer-workflow-with-piecesapps-tsavo-knott) about it. 😅

<Image
  publicId="newsletters/keep-your-tools-sharp/pieces-extension"
  alt="Pieces extension for VS Code"
  caption="Pieces for VS Code is a fantastic use of AI tech."
/>

---

## More from me about whipping VS Code into shape

- Minimalists will appreciate [How to make VS Code load faster with a little bit of housekeeping](https://mikebifulco.com/posts/make-vs-code-load-faster-by-removing-extensions). Spoiler alert: the crux of this one is _getting rid of_ things you don't use.
- If you made the switch from Intel to an M1, M2, or M3 Mac in the past few years, don't miss my article on [Making VS Code Quicker on Apple Silicon Macs](https://mikebifulco.com/posts/make-vs-code-load-faster-mac-apple-silicon). If you're affected by this one, the gains are _huge_.
- This quick tutorial on [using the refactor menu in VS code](https://mikebifulco.com/posts/refactoring-typescript-react-components-vscode) was an awakening for me - I didn't know how much I was missing out on until I started using it!
- If you're a TypeScript dev, there's a couple troubleshooting steps I use to [fix TypeScript errors in VS Code](https://mikebifulco.com/posts/typescript-vscode-error-fix-last-resort) when nothing else seems to work.

---

## Find me online wherever you get your internet

Recently, I've been releasing past newsletters as podcasts - you can find them in your podcatcher under "Tiny Improvements", or if you prefer a direct link, you can subscribe on [Spotify](https://open.spotify.com/show/0H7r0j7q6RXzSie6AbMDwj), [Apple Music](https://podcasts.apple.com/us/podcast/tiny-improvements/id1577037667?uo=4), [Pocket Casts](https://pca.st/itunes/1577037667), and good ol' [RSS](https://feeds.transistor.fm/tiny-improvements).

They're a few minutes long each, and are a ton of fun to make. I hope you enjoy them!

I'm also releasing occasional videos (both short- and long-form) to [my YouTube Channel @mikebifulco](https://youtube.com/@mikebifulco?sub_confirmation=1). I'd love it if you'd subscribe and let me know what you think of the content.

---

## Hey though, how are _you_ doing?

I hope you're doing well. As always, I'd love to know what you're working on, what you think of Tiny Improvements, and what you'd like to see more of. Hit reply and let me know - I do my best to respond to every email I get.

Keep up the good work, and I'll see you in the next one.


Keep your tools sharp

More from me about whipping VS Code into shape

Find me online wherever you get your internet

#devx: 2 posts tagged

Debug tips from a lifetime newbie

Keep your tools sharp