Tradeoffs exist; improving one aspect of a system can make other aspects worse. As projects grow, our control over them shrinks. Ugly truths abound, and beauty is a luxury we can rarely afford.

Knowing this, however, does not mean accepting it. Confronted with this dissonance, this ugliness, we inevitably gesture towards a better future. We talk about better design, better practices, better processes. We await better abstractions. We imagine a world in which we cannot help but make something beautiful.

This belief in the future, in an unending ascent towards perfection, is a belief in progress. The flaws in this belief — its internal tensions, the fact that it is closer to a theology than a theory — have been pointed out for centuries. It is, nevertheless, an inescapable part of the software industry. Everything we do, whether design or implementation, is oriented towards an imagined future.

This is a beautiful sentiment about software systems which could easily apply to most any system (like, our political and social systems, for example).

Engineers are not fans of technologies.

They are also, of course, not dispassionate Vulcans who get every assessment perfectly rationally correct at all times, trivially proved by how much even relatively rational engineers can disagree with each other.

But engineers should never be fans.

There was a moment not too long ago where I closely followed every single Apple rumor, watched every single keynote, and could tell you the names of every single executive.

It’s mid-October and I’m still not exactly sure when Apple intelligence is coming to my iPhone 15.

Maybe part of growing up is being less fanatical about tools and more fanatical about solving problems.

The problem with software is that it's too powerful. It creates so much wealth so fast that it's virtually impossible to not distribute it.

Think about it: sure, it takes a while to make useful software. But then you make it, and then it's done. It keeps working with no maintenance whatsoever, and just a trickle of electricity to run it.

Immediately, this poses a problem: how can a small number of people keep all that wealth for themselves, and not let it escape in the dirty, dirty fingers of the general populace?

Such a great article explaining why we can’t have nice things when it comes to software.

There is a good comparison in here between blockchain and LLMs, specifically saying both technologies are the sort of software that never gets completed or perfected.

I think it’s hard to ascribe a quality like “completed” to virtually anything humans build. Homes are always a work in progress. So are highbrow social constructs like self-improvement and interpersonal relationships.

I think it’s less interesting to me to try and determine what makes a technology good or bad. The key question is: does it solve someone’s problem?

You could argue that the blockchain solves problems for guaranteeing the authenticity of an item for a large multinational or something, sure. But I’m yet to be convinced of its ability to instill a better layer of trust in our economy.

LLMs, on the other hand, are showing tremendous value and solving many problems for me, personally.

What we should be focusing on is how to sustainably utilize our technology such that it benefits the most people possible.

And we all have a role to play with that notion in the work we do.

I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently.

My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:

• get the source from github on a new computer
• make some changes
• put it on the internet

But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again.

I have websites that I made in middle school that I’m able to get up and running in roughly as much time as it takes to find the old folders.

I also have websites that I am unable to run on my new laptop because the dependencies are too out of date and now supported on my new architecture.

In summary:

• Facebook is a [redacted] company with a terrible web interface.
• React is a technology created at Facebook to administer its interface.
• React enables you to build web applications and their interfaces the way Facebook does.
• I am not calling Facebook "Meta"
• JavaScript-first interfaces built on ecosystems like React’s are cumbersome and under-performing.
• React prevails because its evangelical proponents and apologists have convinced developers that Facebook’s success can be attributed to technological quality and not aggressive capitalism.

Over the past fifteen years, I feel like I’ve had a pretty good track record of knowing which technologies to pay attention to and which technologies to confidently let pass by me.

When React first dropped, I thought the setup process seemed so onerous and filled with so many dependencies that I slowly backed away and haven't really needed to look back.

It would be irresponsible of me to have zero experience in React, so of course I've inherited projects that others have started on top of it. But every time I jump into a React project, I feel like I’m Homer jumping into his unchlorinated pool.¹

Perhaps we can define “junior developer” this way: it’s somebody who needs human supervision to accomplish the things a full-fledged member of the technical staff should be able to do using only AI assistance.

If we can’t make room in our taxonomy of technical work for someone who still needs human training, we are just doing the same old thing IT has been doing for decades: borrowing from our future to cash in on the current hype. AI, “chat-oriented programming”, whatever tomorrow’s buzzword is—they’re fascinating, they may be productivity enhancers, but they won’t remove the need for experienced human generalists in the loop.

And every experienced generalist starts out inexperienced. They start as a junior developer. That’s not where software engineering dies: it’s where it’s born.

This talk helped me articulate a few key arguments that I can use to counter myself when in the throes of impostor syndrome-related attacks from my inner monologue.

Basically, a “staff-plus engineer” is anyone in a technical role that is higher than a senior engineer. These are sometimes referred to as principal engineers, staff engineers, etc.

The big difference between staff-plus and individual contributor path is that an IC role is one you go down when you truly want to contribute as an individual, often acquiring such an expertise in a specific domain that you just do your thing alone.

A staff-plus role requires collaboration, often leading teams, but always being the lynchpin which helps be the voice of technical leadership across multiple teams.

The responsibilities of a staff-plus role include (probably) writing and (definitely) reviewing code, providing technical direction, mentoring and sponsoring other engineers, providing engineering context to non-technical people, and being involved in strategic projects which aren’t shiny but are critical to the success of an organization.

I think I came across this talk at a timely point in my career. I have been tasked with doing staff-plus engineering work ever since starting my first company, and it’s honestly the stuff I love the most.

I’m not a developer who loves to write code. I love writing code because it results in a tool that makes someone’s life easier. What brings me joy is in doing the discovery work needed to clearly articulate the problem and charting a course that’ll lead us to a solution.

Of course you’re having problems keeping up with everything that’s happening in web dev. Of course!

You’re expected to follow half-a-dozen different specialities, each relatively fast-paced and complex in its own right, and you’re supposed to do it without cutting into the hours where you do actual paid web development.

Worse yet, you’re not actually expected to use any of it directly. Instead you’re also supposed to follow the developments of framework abstractions that are layered on top of the foundation specialities, at least doubling the number of complex fields a web dev has to follow and understand, right out of the gate.

This is immense – an expectation so mind-boggling that we need to acknowledge just how remarkable it is that each of us has managed as well as we have.

This entire article is an excellent summary of the state of the software development industry from the perspective of a web developer. I think Baldur hit the nail on the head several times here.

I first learned Javascript from a book I got from the library somewhere around 1999. This predated XMLHttpRequest, debuting with IE5 in 2001, which literally enables every single subsequent Javascript framework out there.

In just the last ten years alone, I’ve worked with React, Typescript, Coffeescript, Vue, Angular, Backbone.js, Ember.js, Next.js, ES6, and maybe another dozen Javascript variants that I can’t recall right now… but I wouldn’t consider myself an expert in any of them.

Like Baldur says in this article, “framework knowledge is perishable.” I don’t want to spend all my time learning a framework which, if history is any indicator, will be obsolete in a few years.

The underlying Javascript knowledge, though, is not ephemeral. I can dig up webpages I built in fifth grade and render them in moments with ease on my modern day Macbook, whereas dashboards built on React from only five years ago can only be brought up if I spend an entire day setting up an environment with a billion dependencies.

I can do that because the vanilla Javascript that worked in IE5 still works great in any modern browser.

I do have to be a realist, though… the jobs out there today do require you to use these frameworks because the software pipeline is way more complex than it was in 2000. Frameworks provide a standarized way of building software within this modern landscape. For the record, I have no problem picking one up in the course of my work and figuring it out.

I wish more organizations would simpilfy rather than move towards increasingly complex ways of writing and delivering software. I feel like so much more value could be realized by paring back the staggering amounts of dependencies that these frameworks use. Codebases would be much thinner, deploy times would be faster, your footprint for potential security threats would be smaller, etc. etc.

Anyway, I also think the way he wraps up this article is grimly astute:

The tech industry will never be a genuinely free market as long as big tech companies are allowed to be as big as they are today.

What we have today is a centrally-planned economy by MBA sociopaths, operated as a looting ground for the rich.

It will never function on normal competitive, supply-and-demand market principles.

Because, even though a healthier market is the only thing that has a hope of a return to the fast-growing tech industry of prior decades, it would also require big tech companies to accept a smaller slice of the overall pie and allow new competitors to grow.

Why do that when you can strangle the market and keep the entire corpse for yourself?

Literally laughed out loud at “centrally-planned economy by MBA sociopaths.”

Enbies and gentlefolk of the class of ‘24:

Write websites.

If I could offer you only one tip for the future, coding would be it. The long term benefits of coding websites remains unproved by scientists, however the rest of my advice has a basis in the joy of the indie web community’s experiences.

I love the reference to Wear Sunscreen, one of the great commencement speeches.

There is amazing advice and inspiration for building websites in here. It also reminded me of POSSE, meaning “Publish (on your) Own Site, Syndicate Elsewhere.”

I saw Simon Willison share this article and thought it was too good not to share it myself.

We respect wildlife in the wilderness because we’re in their house. We don’t fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we can’t always predict what outcomes our interactions with nature might have.

In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. It’s super common for a new leader to come in, see something they see as “useless”, and get rid of it – without understanding the implications. Good leaders make sure they understand before they mess around.

Or, as the footnote succinctly puts it: “find out, then fuck around.”

This article also taught me about Chesterton’s fence, a principle that says “don’t destroy what you don’t understand”.