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.)

For most companies, accessibility isn’t a priority, or worse, something that they pay lip service to while doing the bare minimum to meet regulatory compliance. Ojala’s pet peeve is people thinking that accessibility is a feature, a nice-to-have addition to your product. When they tack on accessibility later, without thinking about it from the very beginning, Ojala can tell — it feels haphazard. (Imagine first creating a product with a colorless UI, then to add colors later as an afterthought, only to use the wrong color combination.)

I heard long ago that the reason developers should start testing software with accessibility in mind is that everyone, at some point in their life, will benefit from accessible technology.

At a minimum, as your eyesight gets older with age, an increase in font size will make it more comfortable to read things.

Any story that revolves around a few people banding together to solve an actual problem, and how that solution literally changed people’s lives, is so inspiring to me.

It’s what I yearn for at this point in my life. I don’t mind making money and building apps which drive business value. The stability of my job has done wonders for my mental health, and I am supremely grateful that I have it.

But boy, wouldn’t it be fun to get to work on something that has an outsized positive impact on people’s ability to live productive lives?

A friend recommended this video to me while I was out with Covid a few months back and I just got to watch it.

Now I get to recommend it to you!

If you are a nerd for process, you will love this. Just one small fact to entice you to watch this: did you know Waffle House employs their own meteorological staff?

You may be thinking: “there is nothing I ever wanted to know about semiconductors.”

I assure you: there is.

This video, created by the excellent Farnam Street, dropped my jaw several times around a topic that is crucial to our way of life, yet is virtually invisible to the vast majority of us.

Take an hour and watch it. It may put many things (including the geopolitical tensions around Taiwan) into better perspective for you.

No. 2: Focus on the Fundamentals

Technology constantly changes, but some fundamental approaches to software development transcend these trends. Here are six fundamentals that will continue to be relevant for a long time.

• Teamwork — Great teams build great software. Don’t take teamwork for granted.
• Trust — Teams move at the speed of trust. Be the kind of dependable person you would want to work with.
• Communication — Communicate honestly and proactively. Avoid the curse of knowledge.
• Seek Consensus — Take the time to bring your whole team along. Let discussion and disagreement bring you to the best solution.
• Automated Testing — Well-tested code allows your team to move fast with confidence.
• Clean, understandable, and navigable code and design — Think of the next engineer that will take over your code as your customer. Build code that your successor won’t have any trouble reading, maintaining, and updating.

Super astute observations, many of which seemed to be hard-earned.

Here are the secret rules of the internet: five minutes after you open a web browser for the first time, a kid in Russia has your social security number. Did you sign up for something? A computer at the NSA now automatically tracks your physical location for the rest of your life. Sent an email? Your email address just went up on a billboard in Nigeria.

These things aren’t true because we don’t care and don’t try to stop them, they’re true because everything is broken because there’s no good code and everybody’s just trying to keep it running. That’s your job if you work with the internet: hoping the last thing you wrote is good enough to survive for a few hours so you can eat dinner and catch a nap.

As poignant, true, and depressing as it was back when it was 2014.

If you engage engineers, you don’t know what you are going to get. You may be unlucky and get nothing. Or their solution may be so outlandish that it is hard to compare with other competing solutions. On average, though, what you get will be more valuable than the gains produced by some tedious restructuring enshrined in a fat PowerPoint deck.