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.

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.

In my opinion, security is one of the most forgotten aspects of software engineering. It rarely gets focused on until it’s too late. Even though at least one incident lands on HackerNews every week where some data gets leaked or someone gets hacked — people still think, “Nobody cares about my little startup.” You might think you're too small to be noticed by the big, evil hackers. Wrong. Size doesn't matter. You're always a target; there’s always data to leak and ways to exploit your business.

This is a great primer for the security-related items you need to consider when you’re building software.

Some takeaways:

First, any human-built product is going to be insecure. Nothing is 100% secure, ever. The best you can do is make the bad guys earn it by making it difficult to break into.

Second, your biggest vulnerabilities are almost always human. You can build Fort Knox, but if I’m able to trick your guard into opening the door for me, then what’s the point?

Third, I’m grateful for frameworks like Ruby on Rails which handle a good chunk of the author’s “step 0” items out of the box. Picking the right tool (and keeping that tool sharpened) is the best first step.

Fourth, there’s never a moment with software when you can dust your hands and say, “ope, we’re done!”

Security is especially an area in which you can’t sit still. If you build an app and let it sit for a decade without any updates, I can almost guarantee you that there’ll be a vulnerability in one of your dependencies which I could exploit to take over your system.

Finally, if you reach a certain size of organization, you need someone thinking about this stuff full time and orchestrating all the pieces needed to keep a secure system.

I have this dream for barefoot developers that is like the barefoot doctor.

These people are deeply embedded in their communities, so they understand the needs and problems of the people around them.

So they are perfectly placed to solve local problems.

If given access to the right training and tools, they could provide the equivalent of basic healthcare, but instead, it’s basic software care.

And they could become an unofficial, distributed, emergent public service.

They could build software solutions that no industrial software company would build—because there’s not enough market value in doing it, and they don’t understand the problem space well enough.

And these people are the ones for whom our new language model capabilities get very interesting.

Do yourself a favor and read this entire talk. Maggie articulated the general feeling I have felt around the promise of LLMs within the confines of a concise, inspiring talk.

A friend approached me a few months back and asked me to help him build an app to facilitate a game he likes to play with his friends in real life.

I told him that a good first step would be to experiment first with facilitating the game using good ol’ fashioned paper, and use the lessons learned from that experience to eventually build an app.

A few weeks later, he came to me with a fully baked version of the app in a prototyping tool called AppSheet.

I was stunned at how much he was able to get done without any professional development support.

He’s a prime example of a barefoot developer. I don’t think he has any interest in crossing the “command line wall,” but as these tools get more capable, it’ll enable him and scores of others to build software that’ll solve their problems for them.

Helping more “normal people” to become barefoot developers is a cause I’d love to be part of.