Julia Evans is working on a new zine about debugging, so she took to Mastodon to ask for tips and compiled a list of the best ones (with explainers). Here’s a short list of some tips covered:
Julia Evans shares five things you can do to getting better at debugging, which is a critical skill for everyone in tech! They are:
Each thing comes with an explanation and she shares a great quote at the end (from a paper she extracted these things from):
Their findings did not show a significant difference in the strategies employed by the novices and experts. Experts simply formed more correct hypotheses and were more efficient at finding the fault. The authors suspect that this result is due to the difference in the programming experience between novices and experts.
Julia Evans lays out her process for taking API responses in her browser’s dev tools and using them in her own programs/scripts:
Some of you might be wondering – can you always do this?
The answer is sort of yes – browsers aren’t magic! All the information browsers send to your backend is just HTTP requests. So if I copy all of the HTTP headers that my browser is sending, I think there’s literally no way for the backend to tell that the request isn’t sent by my browser and is actually being sent by a random Python program.
If you’d prefer code over comics, see instead her little Go program that explains the same.
Julia Evans has a cool new web tool for experimenting with DNS. She wrote up why she created it and some of the tech behind the tool on her announcement post:
Mess With DNS gives you a real subdomain, and it’s running a real DNS server (the address is
mess-with-dns1.wizardzines.com). The interesting thing about DNS is that it’s a global system with many different computers interacting, and so I wanted people to be able to actually see that system in action.
On this special edition of The Changelog, we tell Vim’s story from the mouths of its users. Julia Evans, Drew Neil, Suz Hinton, and Gary Bernhardt join Jerod Santo for a deep and wide-ranging discussion about “the best text editor that anyone ever wrote.”
This is just one of four (as of now) mysteries put together by Julia Evans to help us practice our debugging skills. Can you crack the case?!
You can think of Julia Evans’ new dnspeep tool as similar to tcpdump but specifically for watching your machine’s DNS queries.
One thing I like about this tool is that it gives me a sense for what programs on my computer are using the Internet! For example, I found out that something on my computer is making requests to ping.manjaro.org from time to time for some reason, probably to check I’m connected to the internet.
A friend of mine actually discovered using this tool that he had some corporate monitoring software installed on his computer from an old job that he’d forgotten to uninstall, so you might even find something you want to remove.
It also probably comes in handy when debugging those pesky “could it be DNS?” issues, but this might be a limitation on that front:
One thing this program doesn’t do is tell you which process made the DNS query, there’s a tool called dnssnoop I found that does that. It uses eBPF and it looks cool but I haven’t tried it.
I love posts like this because they apply to both work life AND life life. Julia covers helping people clarify their questions, figuring out what they already know, pointing them to documentation, explaining what you did, and more.
Julia Evans:
I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do, plus a bit extra to collect some anonymous metrics about what folks were learning.
Listeners of JS Party know I’m an advocate for JavaScript sprinkles. Not on every site, but on most sites I think that’s the best way to start out.
Now more than ever, you can get a lot done with what’s right there in the browser. Wait until you feel the pain before you solve the problem. Who knows, maybe you’ll never have to…
A fun, quick dive into Facebook’s tracking pixel and how it does its thing:
I think it’s fun to see how cookies / tracking pixels are used to track you in practice, even if it’s kinda creepy! I sort of knew how this worked before but I’d never actually looked at the cookies on a tracking pixel myself or what kind of information it was sending in its query parameters exactly.
Creepy, indeed. Our browsers are the last line of defense against such creepiness. Choose yours wisely.
Yesterday I was working on an explanation of window functions, and I found myself googling “can you filter based on the result of a window function”. As in – can you filter the result of a window function in a WHERE or HAVING or something?
Eventually I concluded “window functions must run after WHERE and GROUP BY happen, so you can’t do it”. But this led me to a bigger question – what order do SQL queries actually run in?
Kind of a snappy headline because Julia is talking about order in terms of execution and most of the time we’re thinking about order in terms of authoring. But still, TIL!
Most people are modest about their contributions in the workplace. We also forget how important our contributions are. Then, when it comes time for recognition, you’ve forgotten, others didn’t notice because they don’t understand all the details and moving parts, and work just moves on. What do you do if/when your work goes unnoticed? Here’s what Julia Evans suggests…
Instead of trying to remember everything you did with your brain, maintain a “brag document” that lists everything so you can refer to it when you get to performance review season! This is a pretty common tactic – when I started doing this I mentioned it to more experienced people and they were like “oh yeah, I’ve been doing that for a long time, it really helps”.
Where I work we call this a “brag document” but I’ve heard other names for the same concept like “hype document” or “list of stuff I did” :).
BONUS — Julia included a basic template for a brag document at the end of the post.
Julia Evans has finished up her 3 months of funded work on rbspy (thanks to the Segment Open Fellowship) and wrote up her experience. If you can’t tell from the title, she liked it.
This was an interesting statement coming from Julia (whose reputation amongst developers is impeccable, if you ask me):
Another benefit of doing this was that now I have actual code that I’ve written out in the open on GitHub! I don’t really believe in “github is your resume” (lots of great programmers don’t do any open source work! that’s fine!) but it does feel good to have.
One huge benefit to employees who work for open source-oriented companies is that they get to build an open source portfolio on the job. That levels the playing field for folks who don’t have the luxury of disposable free time outside business hours.
