Jim Nielsen’s Blog
Theme: This feature requires JavaScript as well as the default site fidelity (see below).

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Reading Notes, July 2021

Article: “DX, to me”

A lot gets written about DX. It’s likely we’re misunderstanding each other because we don’t agree on the definitions baked into our assertions.

That’s why I like this post by Dave.

What I love the most, though, is his ending:

Written into the ethos of the Web is “Users over Authors over Implementors…” and I believe we must preserve this principle even in our tools. Otherwise we’re building an internet for developers and not an internet for everyone.

Article: “npm audit: Broken by Design”

Dan talking about why npm audit is broken. I’ve been there: you run a fresh, up-to-date install of create-react-app and on install npm tells you your app is already vulnerable.

While an interesting read, what I really liked were these two phrases:

The best time to fix it was before rolling it out…The next best time to fix it is now.

I like that. Applies to my designs and my code.

And then this:

in theory there is no difference between theory and practice. But in practice there is.

Article: “On Permalinks and Paradigms…”

There are some things that become so ubiquitous and familiar to us – so seemingly obvious – that we forget that they actually had to be invented. Here’s a case in point – the weblog post’s permalink…

[the permalink] added history to weblogs…before you’d link to a site’s front page if you wanted to reference something they were talking about – that link would become worthless within days, but that didn’t matter because your own content was equally disposable. The creation of the permalink built-in memory – links that worked and remained consistent over time, conversations that could be archived and retraced later.

Tweet: @andybudd

I enjoyed this whole thread, but this particular tweet was razor-sharp:

As a result, we need to view products over a 5+ year lifespan, rather than through the lenses of a release or a series of sprints. Something that’s very difficult to do when we bounce between jobs every 18 months.

Some other pieces of the thread I liked:

[the tension:] Designers generally believe in exploring the problem space, iterating towards a solution and then launching. Founders often believe in launching, seeing how the market reacts and then iterating/pivoting if needs be.

What you build in the early days is almost certainly wrong, and will most likely get thrown out later on…In the early stages of a new venture, neither the company or the market are really ready for quality yet.

But we do need to understand that for a large part of a product’s life, the process is optimised around speed and efficiency over solution fit. That the most successful designers are essentially pragmatists.

[the designer’s role] isn’t necessarily to come up with the perfect solution right out of the gate, following the structure of the double diamond. But is instead to put something out into the world that’s better than what existed before.

As Obama says: “Well, better is good. Nothing wrong with better.”

Article: “Adding is favoured over subtracting in problem solving”

the bias towards additive solutions might be further compounded by the fact that subtractive solutions are also less likely to be appreciated. People might expect to receive less credit for subtractive solutions than for additive ones.

Article: “The web didn't change; you did”

Framework fatigue definitely exists. It's also known as innovation in this particular area of software development.

Web development did not change. Web development grew. There are more options now, not different options.

Websites have become business, hence all the features and advancements to support business:

But there's no doubt that it's entirely possibly (and likely) that you're working on a project with a complicated pipeline of tech all connected up. Maybe it's some tools to check your code for errors (linting), and some tools to build and transform your code (like JSX to JavaScript, etc), and some aspect of CI (for tests or automated accessibility checks) and then some provisioning and staging environment (Netlify, Google Cloud, etc) and then some end point analytics or smoke tests.

But that's because the businesses online have evolved and grown. In 1997, if your company was exclusively online you were either an innovator or a fool that was going to be quickly parting with their investment. Today, an exclusively online business is completely normal - so it's understandable that the parts that go into supporting that business are larger and more involved.

And then this point:

if you wanted to sell an old monitor on a site like ebay, you're not going to set up a limited business, file for VAT registration, appoint an accountant, get insurance and all the other very involved complicated tasks.

What’s sad is that business web development eventually becomes the norm. Extending Remy’s metaphor, yeah, you wouldn’t setup a business to sell a monitor online. And yet—have you ever felt come tax time you need your own accountant? The tax rules have become so complex, you feel you’re losing out if you don’t have someone in your corner who knows the rules and can dance with them?

Remy’s main point is not lost on me: the web didn’t become more complicated. It grew. The simple stuff is still simple, but now there’s the more complex stuff too. But you’re not beholden to use it.

Tweet: @letterpress_se

I use hand sketches as long as I can to communicate concepts to stakeholders and teams.

I believe in showing the work at the fidelity of the thinking.

The higher the fidelity of the image, the higher fidelity the perceived thinking is behind it.