This article was originally published on gopheradvent.com

reflect can be intimidating to new Go programmers because it’s very generic and you lose access to many niceties in the language. But it doesn’t have to be. Let’s build some programs that use reflect as a way to demystify the package and illustrate the power and pitfalls that come with using it.

In the last blog, I wrote a few things that software is for:

• putting people on the moon
• safely deploying airbags
• making my bank account add up

…

Once a month or so, this idea comes rambling out of the programming community¹:

Software is prose. It is written to communicate ideas to others, it has the interesting side effect that it can be transformed into something a computer can execute.
- Chet Hendrickson

This sounds nice on paper. It makes for a good conference talk about how to structure software, how to design programming languages, and how to collaborate. I agree with what I think is the intent: write software so that other people can understand it and change it as they need to.

At work I’ve been building a new program on top of an SDK that’s under very active development. After about 6 weeks without updating the version, the SDK had deleted some code I was using and had a ton of breaking changes. If I’d simply updated the library, my entire program would fail to build, and it also wouldn’t be clear how to get it back to a good state. Following in the spirit of Branch by Abstraction, I’d rather introduce the new code side-by-side with the old and incrementally migrate without breaking the program.

I recently read this Washington Post Article (archive.org) titled Caroline Ellison wanted to make a difference. Now she’s facing prison. After the first read-through I was incredulous at the sympathetic presentation in the biography. It reads like a resume, like a “it all spun out of control!” story about someone who got in over her head. I tweeted:

Lol how do you get such a sympathetic bio after stealing billions of dollars @GerritD

JSON deserialization is Go seems easy, but there are a lot of tricky parts. Come and see!

I was reading about Phoenix today, looking at guides and documentation. It’s great to see in a guide when it’s easy to quickly set up a project, that makes it fun to get started and explore. The most exciting thing about Phoenix is that “reactivity”, or live updates, are a core part of the system, not an add-on. Nowadays I find any software without reactive updates frustrating and annoying to use.

There’s been a lot of restrospecting lately, lamenting the loss of the “indie web” and its subsumption by content platforms like Facebook, Instagram, Reddit and Twitter. (I’ve always wondered where Tumblr fit in - more indie than any of these, but still - owned by Yahoo!). A few casualties that fell by the wayside: blogs, web comics, and independent, topic specific forums.

All of these media still exist, much diminished and publishing social posts to route you to their sites, but they are still self-hosted, free of editorial control and in their author’s hands. To some degree, these forms will probably stay on the web until millenials die out.

I love squash merging. I think it’s the simplest way to maintain a legible commit history on main, a shared dev branch, etc. It’s easy for most people to follow, and it doesn’t require you to be too Big Brained about git. GitHub even provides a convenient interface for doing this, right in the pull request UI!

But GitHub’s squash merge workflow undermines the biggest benefits of squash merges: clear, simple, atomic commit messages that explain what each commit does.

Dan Luu tweeted about some great work interns that he has mentored accomplished at Twitter:

One intern did https://t.co/nsFW20j9Hm and another did interesting data analysis then built a working prototype for across the fleet profiling that others were able to use to find real inefficiencies.

Those are things that could go into a staff promo packet as a major project.

— Dan Luu (@danluu) August 31, 2022