email -> me@ntietz.com mastodon -> @nicole@tietz.social sourcehut -> ~ntietz bandcamp -> atomic reeds pronouns -> she/her timezone -> US/Eastern
Visit ntietz.com → RSS feedOn Hacker News Mar 2015 – Feb 2026
Tools & Productivity 10Software Engineering 10Life, Learning & Writing 7Programming Languages 4Hardware & Electronics 3Web & Frontend 2
After my last blog post about Hurl, someone asked me, and I quote: "... why?" The simple answer is "for the joke." But the longer answer is that useless software [1] is a fantastic way to explore and experience the joy of computing. Play is an important part of exploration and joy.
Most computer systems we interact with have an auth system of some kind. The problem is, that sentence is at best unclear and at worst nonsense. "Auth" can mean at least two things: authentication or authorization [1] . Which do we mean for an "auth system"? It's never perfectly clear and, unfortunately, we often mean…
A long-standing debate between me and a peer at work has been how we should name services. His position was always that services should be named something descriptive, so that you can infer from the name what it does. My position is that the name should definitely not be descriptive, but should be something cute and…
One of my core software engineering practices is writing, by hand, in a physical notebook [1] . It's one of the most important things I do to remain productive and effective. Maybe the single most important. And it's a practice that I see very few others using!
About a month ago [1] , I was onboarding a friend into one of my side project codebases and she asked me why I was using a particular type of UUID. I'd heard about this type while working on that project, and it's really neat. So instead of hogging that knowledge for just us, here it is: some good uses for different…
The next time you start on a major project, I want you to write code for a couple of days and then delete it all . Just throw it away.
Last week, I did a Q&A session for a friend's security class. One of the students asked a question that I loved. They asked something like, "As a principal engineer, how do you make sure your company stays at the forefront of innovation?"
I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust, mostly for the web, and this is where we run into a problem.
Every software engineer uses a programming language, usually multiple. Few of us make programming languages. This makes sense, because the work we need to get done can typically be done just fine in the languages that exist. Those already have people making them better. Let's focus on the task at hand.
Sometimes we have ideas that are bad but demand to enter reality. A few months ago, while chatting with a friend, we toyed around with the idea of a language where the only control flow you get is error handling. This idea embedded itself in my brain and wouldn't let me go, so I kept just talking about it until two…
Nearly every line of code I write for fun is in Rust. It's not because I need great performance, though that's a nice benefit. I write a lot of Rust because it's a joy to write code in. There is so much else to love about Rust beyond going fast without segfaults.
My computer setup attracts attention when I'm out and about. This has two effects: engineers [1] ask me about it, and everyone else ignores me. These effects are not undesirable, but further testing is required.
Apparently, one of my hobbies is making updates to my ergonomic setup, then blogging about it from an Amtrak train. I've gone and done it again.
When you're just getting started with music, you have so many skills to learn. You have to be able to play your instrument and express yourself through it. You need to know the style you're playing, and its idioms and conventions. You may want to record your music, and need all the skills that come along with it.
While reading Real-World Cryptography , I came across the "million message attack" . This is an attack that Daniel Bleichenbacher demonstrated in 1998, which effectively broke RSA with a particular encoding function called PKCS #1 . It was only mentioned briefly, so I dug in and decided to try to understand the…
The job of a software engineer is not to produce code, but to solve problems; we just happen to solve most of those problems by producing code. Ultimately, producing code is hard, and we need help. That's why GitHub's Copilot is exciting, but it's far from ideal, and it's the tip of the iceberg of what's been done and…
My wife's alarm clock has been acting up lately. Sporadic at first but then every day, it wouldn't blare in the morning at the set time. Instead, when it was supposed to go off it would... reset itself. The time would start flashing in that "I'm confused because the power went out" sort of way.
If you're building an application that needs to scale—and we all tell ourselves that we are—then at some point you have to figure out if it does or not. This is where load testing comes in: if you want to see whether or not your application can handle scale, just generate scale and see if it can handle it! It sounds…
I've got a reputation at work as being a skilled debugger. It's a frequent occurrence that the weird stuff lands on my desk [1] after it goes through another skilled engineer or two. To say my job is substantially "debug the weird shit" would not be an understatement and I'm here for it.
It's hard to make progress on side projects sometimes. Getting started is easy when we see the bright future of the project. Then somewhere in the middle, we get stuck in lists of tasks to do, a long way in and still a long way from the finish line.
If you have a blog, you've probably gotten those emails that want to "collaborate" on a guest post—which often means "let us post sketchy links for SEO purposes." Recently, I got one which was a little different flavor than the usual spam, so I bit and replies. The end result was at the same time fascinating…
I've been using GitHub Copilot on personal projects since March. It's been an interesting experience, and one that I realized I have to change. Using Copilot nearly full time has had some positive and negative impacts on me, and it's time to take control of how I interact with it.
One of the first types we learn about is the boolean. It's pretty natural to use, because boolean logic underpins much of modern computing. And yet, it's one of the types we should probably be using a lot less of. In almost every single instance when you use a boolean, it should be something else.
It's time for me to leave GitHub behind and move to another forge. I'm not necessarily advocating for anyone else to do the same, but if my reasons resonate with you then you may want to consider it. I also don't expect this post to... matter, if that makes sense [1] . I'm not a major open-source maintainer or…