/Julia Evans

Confusing Git Terminology tl;dr: "One of my biggest problems is that after almost 15 years of using git, I’ve become very used to git’s idiosyncrasies and it’s easy for me to forget what’s confusing about it." Julia asked folks "what git jargon do you find confusing? thinking of writing a blog post that explains some of git’s weirder terminology: “detached HEAD state”, “fast-forward”, “index/staging area/staged”, “ahead of ‘origin/main’ by 1 commit”, etc."

featured in #463

Some Miscellaneous Git Facts tl;dr: “None of these things feel super surprising in retrospect, but I hadn’t thought about them clearly before. The facts are: (1) The “index”, “staging area” and “–cached” are all the same thing. (2) The stash is a bunch of commits. (3) Not all references are branches or tags. (4) Merge commits aren’t empty.” Julia discusses each in detail.

featured in #459

Making Hard Things Easy tl;dr: When you face a topic that’s hard to understand, you are likely not alone. Julia talks about how to move folks from the "I really don't get it" column, to the "okay, I can mostly deal with this” column using some of the following tricks: sharing useful tools, sharing references, telling a chronological story of what happens on your computer, turning a big list into a small list of the things you actually use, showing the hidden things, and demoing the tool. Julia gives examples of how these have made learning for her easier.

featured in #455

In A Git Repository, Where Do Your Files Live? tl;dr: Julia explores the inner workings of git, specifically how it stores files in the .git/objects directory. Through Python programs, Julia investigates the location of specific files and their older versions discovering "content addressed storage," where the filename is the hash of the file's content. The article also demystifies the encoding process, showing that files are zlib compressed, and emphasizes that git stores complete files, not just the differences.

featured in #449

What Helps People Get Comfortable On The Command Line? tl;dr: Various strategies and resources to help people become more comfortable with using the command line. It identifies three main areas to focus on: reducing risks, finding motivation, and utilizing resources. To reduce risks, the article suggests regular backups, using tools, avoiding wildcards, and building --dry-run options into scripts. Motivations might include finding a "killer command line app" or being inspired by command line wizardry. Resources include utilizing tools like explainshell, fzf, and oh-my-zsh, and seeking help from experienced friends or co-workers. Cheat sheets, aliases, and workshops are also mentioned as helpful aids.

featured in #440

Some Tactics For Writing In Public tl;dr: Julia discusses various strategies and tactics to engage with comments and feedback on her writing, especially in the context of technical blogging. Key points include: (1) Talk about facts leads to fact-based comments and discussions. (2) Sharing personal stories encourages good discussions and helps in understanding the context and different perspectives. (3) Ask technical questions or mentioning uncertainties invites answers and makes the comments section more valuable. And more. 

featured in #438

Some Blogging Myths tl;dr: (1) You need to be original. (2) You need to be an expert. (3) Posts need to be 100% correct. (4) Writing boring posts is bad. (5) You need to explain every concept. (6) Page views matter. (7) More material is always better. (8) Everyone should blog.

featured in #423

Writing Javascript Without A Build System tl;dr: “I want to talk about what’s appealing to me about build systems, why I still don’t use them, and why I find it frustrating that some frontend Javascript libraries require that you use a build system.”

featured in #410

A List Of Programming Playgrounds tl;dr: “I really like using programming playgrounds, and I got thinking the other day about how I didn’t have a great list of playgrounds to refer to.” Julia provides us with a laundry list of playgrounds across multiple categories.

featured in #406

Some Possible Reasons For 8-Bit Byte tl;dr: Julia explores the question: why does the x86 architecture use 8-bit bytes? Why not some other size? She evaluates a couple of options: (1) It’s a historical accident, another size - like 4 or 6 or 16 bits - would work just as well. (2) 8 bits is objectively the Best Option for some reason, even if history had played out differently we would still use 8-bit bytes. (3) Mix of 1 & 2.

featured in #396