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."
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.
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.
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.
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.
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.
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.
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.”
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.
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.