This post deeply resonates with me.

Never give up seeking truth, however uncomfortable it is. Search for knowledge. Adjust your worldview. Ask. Rewrite outdated code. Drop faulty hypotheses and unreliable foundations.

Software author is, first of all, a writer. They are a person who stands upright and says: “that’s what I know for now, and that’s my best attempt to explain it.” Having this stance, preferring it to everything else, and hiding behind terms, concepts, and authority are invaluable qualities for long-term project success.

Or, basically, for any long-term human activity success.

Though Nintendo employs more-modern technologies now, they are still criticized for not having the most-modern technologies that their rivals are all-too-happy to include, often at the cost of compatibility, affordability, and energy efficiency.

This is not a condemnation of using cutting-edge technology. But if given the choice, I prefer “lateral thinking with withered technology.” I think that’s a great philosophy to consider when making anything.

“Lateral thinking with withered technology” is how I approach building websites. Use battle-tested, slow moving frameworks that don’t depend on a cornucopia of vulnerable third party plugins. :cough cough wordpress react cough sneeze:

HTML and CSS are going nowhere, and vanilla JS can do virtually anything you need these days. Render your stuff server side and keep the client side lightweight.

Nothing is black and white. Code is not precious, nor the be-all end-all. The end goal is a functioning product. All code is eventually thrown away. LLMs help with some tasks, if you already know what you want to do and give you shortcuts. But they can’t help with this part. They can’t turn on the radio. We have to build our own context window and make our own playlist.

When LLMs can stream advice as clearly and well as my Alphabet Radio, then, I’ll worry. Until then, I build with my radio on.

A significant contributor to my depression last year was a conviction that LLMs could do what I could do but better.

I’m glad I’ve experimented with them heavily over the past couple years, because exposure to these tools is the only real way to understand their capabilities.

I use LLMs heavily in my job, but they are not (yet) able to replace my human teammates.

Canadian engineers graduating college are all given an iron ring. It's a symbol of professional responsibility to society. It also recognises that every discipline must earn its social license to operate. Lastly, it serves as a reminder of the consequences of shoddy work and corner-cutting.

I want to be a part of a frontend culture that accepts and promotes our responsibilities to others, rather than wallowing in self-centred "DX" puffery. In the hierarchy of priorities, users must come first.

What we do in the world matters, particularly our vocations, not because of how it affects us, but because our actions improve or degrade life for others. It's hard to imagine that culture while the JavaScript-industrial-complex has seized the commanding heights, but we should try.

And then we should act, one project at a time, to make that culture a reality.

I started a new job as a software engineer last month.

It’s the first job I’ve ever had where all I need to do is write code. I don’t need to worry about finding customers, protecting the company from lawsuits, ensuring the product is the correct product to build, or making payroll.

All I need to do is write code.

This is the first time in my career where I can actually focus on the art of writing good code.

I came across this article from Simon Willison’s blog, and boy, there are a lot of great pieces of advice for folks in my position here.

As a junior engineer, there's simply no substitute for getting the first 100K lines of code under your belt. The "start over each day" method will help get you to those 100K lines faster.

You might think covering the same ground multiple times isn't as valuable as getting 100K diverse lines of code. I disagree. Solving the same problem repeatedly is actually really beneficial for retaining knowledge of patterns you figure out.

You only need 5K perfect lines to see all the major patterns once. The other 95K lines are repetition to rewire your neurons.

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

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.

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