Syntax Error #4: Refreshing wrong window

I should have made this newsletter to be sent on the 4th of the month, now I missed a grand opportunity to make a Star Wars joke to kick off this month's Syntax Error. I guess this is the way.

Thank you being a subscriber and reading this. Whether it arrives to your email or your RSS feed, I'm very happy that you decided to give my newsletter your time and focus in this world that is full of everything to do. I hope you are having a brilliant day. ❤️

Make sure you are running the code you are changing

As I mentioned in the very first issue of Syntax Error, debugging situations are inherently stressful. And when we are stressed out, our cognitive abilities are limited as our focus narrows to the task at hand. It means that we often miss things that otherwise would be easy and obvious - and that's why we don't notice we missed them.

That brings us to today's tip: make sure you are running the code you are changing. Whether you are building a website or web app, a mobile application or something else, it's way too easy to keep refreshing something that points to a wrong place. It sounds so obvious but the stress factor and human mistakes make it happen all the time and that's why it's so important to repeat.

Why isn't production changing when I save in the editor?

It's not uncommon for a web developer to have multiple tabs of the same app open: maybe there's one for production and another for local development or maybe they are logged in to different test accounts.

I have spent way too many cumulative hours of my life trying to refresh a page to see if my change fixed a bug to no avail. I've continued making changes, refreshing and seeing no results. Only to later realize, I wasn't refreshing the dev page but the production and actually the very first fix I tried was the one that fixed the problem but I steered away from it because it didn't seem to work.

Make sure you don't have multiple dev servers running

Another thing that has bitten me a few times is that in one of the terminal tabs, a development server was running an older version of the code. It was not hot reloading changes and I had mindlessly started a new one in another tab. The old server was happily serving my requests without any clue that anything was wrong or being changed.

... or multiple folders and changing the wrong one

Another tiny sin of mine is, especially early into experimentation of new technologies is that I might create new folders to get a "fresh start" and not realizing that my editor opened in the old one while the dev server was running in the new one.

If your terminal application supports colored tabs based on the folder path, I highly recommend setting that up so you'll get one extra visual indicator that things haven't changed even though you started something new.

Does your backend need rebooting or binaries rebuilding?

I've worked in a project where backend tests always ran with the latest changes – it booted the backend server – but the end-to-end integration tests only refreshed the frontend before running them. So when I was working with a feature, it wasn't uncommon for me to start with backend tests, write and run them for a good chunk of the day before moving to end-to-end tests and forget that I need to refresh in the middle if I keep making changes to the backend.

If different parts of the system behave differently, it's easy to forget things like these and keep running against the incorrect state.

Do we need to talk about caching?

Caching is a wonderful way to keep unnecessary requests down and get the results faster but it can also make debugging so painful. Whether it's the caching that needs debugging or the cache being the culprit in providing old stuff, it's not always easy.

In web development, private browsing windows are a really nice way to double check browser cache. In one of the legacy projects I worked with, the backend caching was a bit rudimentary and anytime I started developing, I had to comment out the cache initialization and remember to turn it back on before review and deploy. You can only imagine how many times I got frustrated for my changes not working before realizing I forgot to turn it off.

Story time

If you have debugging stories or examples you want to share to the Syntax Error community, please reach out via hello@syntaxerror.tech and we might share your story!

This month's story comes from Alex Taylor's blog and deals with debugging time. I've personally found time related bugs really annoying since there's so many things about time that's hard.

In a post titled Adventures in Time: Debugging a Daylight Saving Bug, Alex talks about a bug related to time addition around daylight savings.

When subscribing a customer to a monthly plan in our billing system, we calculate the date of the customer’s next bill by adding 30 days to their current time, and using that to create a subscription on Stripe.

However, at some point in October, we started to see this fail:

Stripe::InvalidRequestError: 
  billing_cycle_anchor cannot be later than next
  natural billing date (1669817382) for plan

When comparing the “natural billing date” to the time we sent the request, it was indeed more than 30 days in the future – by exactly an hour. Curious!

Alex then talks about how he dug into the internals of Ruby code responsible for time and fins the root of the issue:

Aha! There’s our bug. Depending on whether I use a Duration object or plain old seconds, I get a different answer. This feels like a daylight saving issue, since we’re crossing the boundary here, and our two times disagree by exactly an hour.

The rest of the blog post is about going down the rabbit hole to understand why things happen the way they do. I really like Alex's approach using pry's debugging functionality to move inside the code to see the design and implementation of these functionalities.

Head over to Alex's blog to read the whole story! And while you're there, I recommend checking his other blog posts as well, he has really good stuff there especially for Ruby developers.

If you want to learn more about time stuff, here are some that I've found interesting, educational and entertaining:

• Tom Scott has a great video about dealing with timezones in Computerphile's Youtube channel.
• Another great talk on the topic is Miroslav Šedivý's A Day Has Only 24±1 Hours from PyCon SK (don't worry, it's in English after the first 18 seconds).
• Infinite Undo has a great post listing falsehoods programmers believe about time.

Syntax Error is created with love by Juhis. If you liked it, why not share it with a friend? Or if you have any feedback or just want to say hi, hit reply. I'm always happy to hear from my readers and learn about what you do and how you debug your issues.