I’ve been dreaming of building my own electronics since I was a kid. I spent so many afternoons at Radio Shack, and even tried my hand at the occasional kit, with limited success. Every few years in adulthood, I’ve given it another try, observing a steady downward trend in difficulty.

I’m telling you: we’re at a special moment here. The labor savings of open source, the composability, the fun: all of it has come to hardware. You can build things that solve real problems for yourself. I first imagined my heat pump devices over a year ago, and I have been frustrated they didn’t exist every day since.

Now my dreams are real, and the largest energy consumer in the house can be automated and remotely controlled.

That’s amazing.

As soon as I gain employment again, the very first thing I’m buying is a 3D printer, and I’m gonna start building stuff.

I don’t quite know what yet.

But I’ll find something.

We tried to hang a pretty picture on a wall, but accidentally opened a small hole. This hole caused the entire building to collapse. While we did not intend to create a hole, and feel terrible for all the people impacted by the collapse, we believe it’s also worth investigating what failures of compliance testing & building design could allow such a small hole to cause such big damage.

Multiple parties involved, myself included, are still students and/or do not code professionally. How could we have been allowed to do this by accident?

It’s certainly no laughing matter, neither to the people who rely on npm nor the kids who did this.

But man, it is comical to see the Law of Unintended Consequences when it decides to rear its ugly head.

I applaud the students who had the original idea and decided to see what would happen if you installed every single npm package at once. It’s a good question, to which the answer is: uncover a fairly significant issue with how npm maintains integrity across all of its packages.

But I guess the main reason I’m sharing this article is as a case study on how hard it is to moderate a system.

I’m still a recovering perfectionist, and the older I get, the more I come across examples (both online like this and also in my real life) where you can do everything right and still end up losing big.

The best thing you can do when you see something like this is to pat your fellow human on the back and say, “man, that really sucks, I’m sorry.”

The worst thing you can do, as evidenced in this story, is to cuss out some teenagers.

Seabound’s carbon capture technology diverts a ship’s exhaust gas into a container full of small pebbles of calcium oxide, which chemically react with CO2 in the exhaust gas to form calcium carbonate. In other words, we make limestone onboard ships, effectively locking the CO2 into small pebbles. When the ship returns to port, we offload the limestone and either: 1) sell it for use as a building material, or 2) recycle the pebbles to separate the CO2 from the calcium oxide so that we can reuse the calcium oxide to capture more CO2 on another ship, and then sell the pure CO2 for clean fuel production or geological sequestration.

Our process is unique because we only capture the CO2 onboard and leave it locked in limestone, rather than trying to separate and liquefy the pure CO2 from the limestone onboard as well. These steps of separation and liquefaction are typically the most complicated, expensive, and energy-intensive for carbon capture technologies, which is why we’ve shifted them to shore where we can leverage economies of scale and land-based energy infrastructure.

This is the sort of solution I want to be a part of. How cool of a concept is this?!

If somebody would’ve shown me this video when I was 12 or 13, I think computer programming would’ve been way easier for me to understand, and I think I would’ve been more motivated to stick with engineering school.

That being said, I’m glad I’m at a point in my life where it all now kinda makes sense why binary is a thing.

This whole video was a pleasant way to appreciate the ingenuity of people. It also fixed a core analogy of mine: it’s not that we tricked rocks into thinking, rather it’s that we tricked atoms into moving whichever direction we want.

If you're trying to pass the class, then pass it with minimum effort. Anything else is wasted motion.

If you're trying to ace the class, then ace it with minimum effort. Anything else is wasted motion.

If you're trying to learn the material to the fullest, then mine the assignment for all its knowledge, and don't fret about your grade. Anything else is wasted motion.

If you're trying to do achieve some combination of good grades (for signalling purposes), respect (for social reasons), and knowledge (for various effects), then pinpoint the minimum quality target that gets a good grade, impresses the teacher, and allows you to learn the material, and hit that as efficiently as you can. Anything more is wasted motion.

Ah, an engineer’s approach to optimizing life.

There is a good section in here as well about how to deal with the associated guilt when you take this approach.

Whatever comes next must take responsibility for that legacy, while also articulating something new and perhaps even bolder than what came before. There is a useful lesson drably concealed in the MTA’s maintenance facility in Queens: What we inherit comes with responsibility. Vintage machines are owed our best efforts, and our ingenuity in keeping them running should at least be equal to our ingenuity in forging them. 

The work of maintenance is ultimately a way of parsing and knowing a thing and deciding, over and over, what it’s worth. “Maintenance should be seen as a noble craft,” said Rossmann, the boot-strapping repair man who learned the secrets of the iPhone’s circuits. “It should be seen as something that teaches people not just how to repair, but how to think.”

This article reinforced one of my core tenets of software engineering: the simpler, the better.

It also supplies an important distinction between repair and maintenance. Repair is when you fix something that’s broken. Maintenance is about making something last.

The article calls for finding a way to better incentivize acts of maintenance in our economic system, and the more I reflect on that, the more I find it reasonable.

Building new stuff is cool and often necessary, but finding a way to make our old stuff last longer is equally cool.

Not just with our bridges and train cars and iPhones, but with our elderly too.

This is preposterously nerdy stuff, but if you are into understanding how you could run Windows software on a Linux machine, this article is for you!

The most complicated reasoning programs in the world can be defined as a textual I/O stream to a leviathan living on some technology company’s servers. Engineers can work on improving the quality and cost of these programs. They can be modular, recombined, and, unlike typical UNIX shell programs, are able to recover from user errors. Like shell programs living on through the ages and becoming more powerful as underlying hardware gets better, prompted models become smarter and more on task as the underlying language model becomes smarter. It’s possible that in the near future all computer interfaces that require bespoke negotiations will pay a small tax to the gatekeeper of a large language model for the sheer leverage it gives an operator: a new bicycle for the mind.

I have a fairly lengthy backlog of Instapaper articles that I’m combing through, and I prefer to consume them in reverse chronological order.

This article is roughly 10 months old, and it’s funny how out of date it already feels (remember when GPT-3 was state of the art?).

But more importantly, the conceit of the article is still spot on. The internet (hell, pretty much all computers) are built on thousands of tiny programs, each programmed to do one specific task extremely well, interoperating together to do something big.

It’s like an orchestra. A superstar violinist really shines when they are accompanied by the multi-faceted tones of equally competent bassoonists, cellists, and timpanists.

Saying “use the right tool for the job” is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.

But that’s all part of the work.

And if you “just use Go” or “just use React” or “just use Postgres” for every problem that crosses your keyboard, you’re just not putting in the work.

I’ve only worked in agencies my entire professional career, and that work has honed two important traits of a good engineer: curiousity and agility.

Being curious gives you the ability to explore new tools and understand how they work.

Being agile (not in the project management sense, but the “moving freely and quickly” sense) gives you the ability to deploy those tools to solve increasingly complex problems.

It’s not that I don’t have a standard set of tools I reach for when solving a wide swatch of problems (Rails, Postgres, etc.), but as I get older, I’m finding that I am more willing to engage with newer tech.

I come from a background of writing Javascript by hand, but I'm starting to play more with Vue and React, and I can see why people like these tools.

Same thing with CI/CD pipelines. I always thought they were more fiddle-y and brittle than they were worth, but that's because I've generally been a lone wolf. In a team context, they are extremely useful.

If you keep hearing noise about a new technology, it's probably worth taking a look over the fence to see how that tool could be used.

Let the mastering engineers do their thing, using whatever technology they find best. Get the reproduced music however you can. And focus on the analog component you are going to have to add to the chain in the end, no matter what: your ears.

A while back, NPR had a test that allowed you to tell whether you could tell the difference between various levels of audio compression.

Even though I did decent on that test, I’ve still never really been able to discern the difference listening to an album on vinyl versus a 320kbps MP3 rip.

That could be because I’m not listening to it on amazing headphones or speakers, but I think the main reason I enjoy listening to vinyl records is that it forces me to focus.

Having a majority of the music ever recorded at our fingertips is incredible, but taking time to really listen to an artist’s work from front to back feels like a luxury. The ceremony of selecting a record, setting it on the table, and dropping the needle feels more special than shouting into the air for Siri to start it.

(Shouting into the air to summon music is also supremely dope, though… don’t get me wrong.)