As a general rule, large established codebases produce 90% of the value. In any big tech company, the majority of the revenue-producing activity (i.e. the work that actually pays your engineering salary) comes from a large established codebase. I’ve seen multiple cases where a small elegant service powers some core feature of a high-revenue product, but all the actual productizing code (settings, user management, billing, enterprise reporting, etc) still lives in the large established codebase.

So you should know how to work in the “legacy mess” because that’s what your company actually does. Good engineering or not, it’s your job.

This was a great read as I’ve been immersed inside a large (but not too large) codebase at my new gig for the past few months now.

It’s funny: I never wanted a job as an engineer. But it turns out I kinda actually like this work? 🤔

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.

I’ve implemented OAuth in both directions, and I still learned something new from reading this article about how OAuth works.

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.

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