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

I’ve known developers who’ve put up with the struggle with the expectation that one day it will go away: one day they’ll be an expert and never have to struggle again. This day never arrives, and so they bail out of the field.

Unfortunately, I don’t think the struggle ever goes away. I’ve been doing this professionally for 14 years now and I still have to deal with the struggle almost every work day.

If you can be comfortable with the struggle and build up your tolerance for it. If you’re able to sit in that moment and be okay without drama or a total crisis of confidence, I’m fairly sure you’re going to do just great.

The Struggle comes in multiple shapes and sizes too. Here is a short list of my experiences with The Struggle from this week alone:

• Impostor syndrome
• Anxiety about breaking a physical connector
• Frustration with unclear objectives
• Being overwhelmed by unfamiliar technologies
• Debugging something and being unable to find an answer

After 12 years of professionally dealing with The Struggle, I’m still able to handle many aspects of it, but my tolerance is quickly diminishing.

Dealing with The Struggle is much easier when you feel like there’s a reward for you at the end of it. Right now, I’m trying to restore my old iPod fifth gen with an SD card, and no matter what I do, I cannot get it to work right.

I’ve been all over forums, digging into the sixth and seventh pages of search results, desperately looking for clues as to why I’m not getting it to restore.

But I can picture myself playing that brick breaking game soon, and that first game is gonna be so much fun after all of this work.

Two years ago, the New Mexico Department of Transportation decided to spice up a particularly desolate stretch of Route 66 between Albuquerque and Tijeras by adding grooves in the road that will play music when you drive over them. If you drive the speed limit of 45 mph for the quarter-mile stretch, you can hear "America the Beautiful" play through the vibrations in your car's wheels.

Some delightful engineering here. I wonder what happens if you hit it at faster or slower speeds?

I saw this article referenced while reading Bill Mill’s recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.

I am almost certain I’ve read Dan’s piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.

In particular, the ending here sums up my experience consulting with many different tech teams:

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.

The teams which move the fastest are the ones who are aligned on a vision for what is being built.

Often, these teams hold a “strong opinions, loosely held” mentality where they decide what tools they’ll use, and they’ll use them until they no longer solve the problem at hand.

Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.

Your focus should be on what you are building rather than how you’re building it.

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.