Alex Russell wrote another great piece on the decay of the web at the expensive of over-use of JavaScript frameworks and it's definitely worth a read. A core concept of this piece (and his other writing) is about native apps vs web apps, but I don't think anyone actually cares—or understand—the difference.

At a past job, one of the team members would frequently want us to make "an app". I was the entire engineering team. We had very little funding. There was just no way to build and maintain an iOS app in the iOS App Store with the time and budget that we had. There was also, in my mind anyway, no reason to do this. But he was insistent.

I started asking more probing questions about what he meant. He had even done user research that he interpreted meant that existing and potential customers preferred "an app". But what did that mean to him, or to the survey participants?

An App is An Experience, Not Bytes You Download

Before Stack Overflow, programmers at the time had to learn things by knowing someone who had the info, reading documentation, or going through code (if it was available). Stack Overflow, Google, and now ChatGPT provide more direct solutions to our problem, allowing us to get unstuck and move forward more quickly than before.

But, you end up not knowing if the solution is actually the best way to solve the problem, and usually don't
have any real insight into why the presented solution works. Practically speaking, Stack Overflow and AI
chatbots are typically out of date and can give answers that were correct, but now aren't.

Here's how I deal with this problem without abandoning these valuable tools.

Example

Every so often, you'll see someone complain that developers "don't know their fundamentals" or that they only want to hire developers who have "good fundamentals". A lot of this can be arbitrary gatekeeping, but within a context like web development, there are fundamental bits of knowledge than can serve a developer well throughout their career.

Let's talk about those fundamentals, what they are, and how important it is that your average web developer understand them.

What is Fundamental?

When I say "fundamental" as a noun, it means "something fundamental [as an adjective]" (thanks, English!). If something is fundamental, I mean the primary definition:

A friend is switching jobs and asked my thoughts on participating in an exit interview or giving the company feedback. I don't think this is worth doing, but I do think there are some good things to do on your way out of a job, even one that's toxic and unpleasant.

Don't Do Exit Interviews, but Be Nice About It

There's a lot of advice on not doing exit interviews and it's spot on. There's no upside to doing them. The company does not care. I honestly don't know why companies even bother doing them at all. But, if you are asked for forced, don't be a jerk. Just politely say you don't have any feedback.

What you should do is give individuals and their managers feedback.

Hello! This is a short one to let you all know that my new book, “Sustainable Dev Environments with Docker and Bash” is now available. This book is the result of getting tired of broken dev environments for my personal projects. I went on a somewhat deep dive to understand Docker and put that into the book.

As a subscriber to this newsletter or someone who signed up on the book's website, you can buy the electronic version right now for $14.99 if you use the code DEVLIST at checkout, which will be valid until the end of May. You can buy it now or learn more about the book at devbox.computer, including seeing the full table of contents and reading a sample chapter.

The book is also available in print for $29.99 from Amazon. Unfortunately, I cannot give discount codes for that.

I've been a proponent of putting engineers on call for their software. You learn so much being on call that you can't learn any other way. But you can't just have people on call without consider the entire system they are in. Without the ability to address issues found, even the most stalwart engineer will burn out.

On Call that Never Ends

Right now, I'm on call 24/7 for my parents, both of whom are cognitively and physically impaired. They can't use email, can barely use computers and thus use the phone. Almost every phone call I get is related to them in some way. Sometimes the calls are mis-dials. Sometimes it's serious and one of them is on the way to the emergency room. But usually, it's something about the TV or computer isn't working how they expect.

But, no matter what, I not only can't stop getting these calls—they are my parents after all—and I can't address the underlying issues that spawns them. Advanced age can be extremely difficult.

While I still have a public @gmail.com email, I recently moved off of Google Workspace (or whatever it's now called) and haven't had any real issues with the replacement set of tools. I want to talk about why—and how it relates to systems thinking—as well as what I did.

Anyone Remember POP?

I signed up for Google Workspace a long time ago to handle email for my naildrivin5.com domain, which is my primary home on the Internet. I love the way GMail works, and as long-time POP and IMAP user, it was a breath of fresh air. Email is the center of my digital life and the primary tool I use for organizing information. GMail felt tailor-made for me.

Over time, I grew heavily dependent on Google Calendar, but also used Docs quite a bit. The only other Google service I used was Google Voice, which was initially a free way to have a phone number I could use in situations where I had to provide a real number, but knew I'd be getting a ton of spam and sales calls.

Perhaps you saw that Wired article "Tech Job Interviews are Out of Control"? If not, the very short summary is that now that employers are back in the driver's seat on hiring, they are bringing back long, complex interview processes that make it hard on candidates.

Tech hiring is a deeply complex topic, because each company has different needs for new hires, has a different culture, and operates in totally different environments. There really can be no on-size-fits-all interview process.

This leads to today's topic, which is "there is no such thing as a good programmer". Most myopic and abusive hiring practices are based on the opposite: that there is some general notion of a "good programmer" and that their process will filter out the bad ones.

A Programmer is Part of the System

I know a lot of programmers play music. I do—not all that well—but I've been struck by something I've started to enjoy about retro music gear: immediacy.

Synthesizers and Tweakability

Here is a synthesizer that was very popular in the early 2000's called the Alesis Micron (note: this is not considered "retro" :).

Three of the 12 Factors factors are closely related and I want to cover them here as they collectively may seem remedial to some of us, but are historically important.

All services/apps are:

• Stateless Processes…
• …that bind to a Port…
• …and are Disposable

Prior to working at Stitch Fix—where everything was hosted on Heroku and thus followed the 12 factors—I had very little experience operating apps in production. Most of my experience was working on Java enterprise apps.

No language, framework, tool, technique, person, or computer program operates on its own. They are all part of a system, and that system exerts influence over all that it encompasses. I want to talk about this concept in the context of various best practices and aphorisms.

Experienced developers can benefit from highly compact or highly abstracted code. But, is this the best way to write code when considering the overall system, which incudes the business, team, and recruiting process?

It could be that verbose codes that is built from fewer concepts may sever the system better, even if it feels a bit too simple for the experienced developers.

A Tiny Example

Quick Announcement: I'm working on a short book about building dev environments using Docker, called Sustainable Dev Environments with Docker and Bash. I'll mention it here again when it's 100% done, but if you want early access, please let me know at https://devbox.computer (which also contains more details on the book).

No language, framework, tool, technique, person, or computer program operates on its own. They are all part of a system, and that system exerts influence over all that it encompasses. I want to talk about this concept in the context of various best practices and aphorisms.

It's hard to disagree with the phrase "use the best tool for the job". But, it's also hard to know exactly what it means. What is "best"? What is "the job"? When building software, these concepts aren't so clear.

I find that both debugging production issues as well as designing to avoid them requires being able to think about code as it behaves over time, including cyclically.

It's often necessary to think of the present as what you want to achieve, like charging a customer's credit card. You must then travel to the past and consider the conditions required to do that, especially if you are coming from the future, repeating the operation. Then, in the future, figure out what message to send to the past to make it work.

This is a common need anytime there is a background job in play, but it also can happen when users are impatient and keep clicking. You simply can't control that an operation is performed more than once.

Revisiting the 12 Factors: Config from the Environment

It's been a while since the Twelve-Factor App was created. Does it still hold up?

When your app needs secrets, like API keys, managing them in files can be difficult. That's why the 12-factor app architecture recommends using the UNIX environment.

The UNIX Environment is Still Great

Happy New Year!

Every engineering decision comes down to "it's a trade-off". But what are we trading off?

The best way I've found to quantify a trade-off is to talk about the opportunity cost and the carrying cost.

Opportunity Costs vs. Carrying Costs

It's been a while since the Twelve-Factor App was created. Does it still hold up?

Let's look at the Codebase factor, which states the app should be in exactly one root repo for version control. This factor gives a stronger definition of app.

If there are multiple codebases, it’s not an app – it’s a distributed system.

I find this clarifying, though it does create confusion outside an engineering team. "App" is often thought of as the entire thing a company does, but behind the scenes that "app" is really a distributed system.

This post by Evan Hahn shows how static typing in Crystal can result in removing some validations you might need in Ruby and thus static types can be a way shorten code.

Sure, sometimes! But, his example of Ruby code that could be shortened leaves some room for improvement. Ruby can be used to create rich and powerful data types, even if they aren't checked by a compiler.

Here's his code (formatted to not be so wide):

def initialize(min_length)
  unless min_length.is_a?(Integer) && 
         min_length >= 0 &&
         min_length <= 255
    raise "Minimum length has to be between 0 and 255"
  end

  @min_length = min_length
end

This is my newsletter, that should contain useful and short distillations of information around sustainable web development. Not just with Rails or JavaScript, but anything I might come across or want to share.

TIL

It's hard to keep up with everything, and sometimes I learn something that has been common knowledge for a while. Maybe this happens to you.

While setting this up, I learned that when you create an internal anchor link with e.g. <a name="some_anchor"> you no longer—as of like more than a decade—have to use <a name="some_anchor"> to tell the browser where to send the link. You can just put id="some_anchor" on any element.