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

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.