Jim Nielsen’s Blog

You found my experimental HTML feed (there are also other ways to subscribe).

I HTML

Recent posts

Successive Prototypes Bridge the Gap Between Idea and Reality

View

Dismissing an idea because it doesn’t work in your head is doing a disservice to the idea.

(Same for dismissing someone else’s idea because it doesn’t work in your head.)

The only way to truly know if an idea works is to test it.

The gap between an idea and reality is the work.

You can’t dismiss something as “not working” without doing the work.

When collaborating with others, different ideas can be put forward which end up in competition with each other.

We debate which is best, but verbal descriptions don’t do justice to ideas — so the idea that wins is the one whose champion is the most persuasive (or has the most institutional authority).

You don’t want that. You want an environment where ideas can be evaluated based on their substance and not on the personal attributes of the person advocating them.

This is the value of prototypes.

We can’t visualize or predict how our own ideas will play out, let alone other people’s. This is why it’s necessary to bring them to life, have them take concrete form. It’s the only way to do them justice.

(Picture a cute puppy in your head. I’ve got one too. Now how do we determine who’s imagining the cuter puppy? We can’t. We have to produce a concrete manifestation for contrast and comparison.)

Prototypes are how we bridge the gap between idea and reality. They’re an iterative, evolutionary, exploratory form of birthing ideas that test their substance.

People will bow out to a good persuasive argument.

They’ll bow out to their boss saying it should be one way or another.

But it’s hard to bow out to a good idea you can see, taste, touch, smell, or use.


Reply via: Email · Mastodon · Bluesky

Consistent Navigation Across My Inconsistent Websites, Part II

View

I refreshed the little thing that let’s you navigate consistently between my inconsistent subdomains (video recording).

Animated gif of a dynamic-island like control that expands smoothly up when clicked to reveal additional selection options.

Here’s the tl;dr on the update:

  • I had to remove some features on each site to make this feel right.
    • Takeaway: adding stuff is easy, removing stuff is hard.
  • The element is a web component and not even under source control (🤫). I serve it directly from my cdn. If I want to make an update, I tweak the file on disk and re-deploy.
    • Takeaway: cowboy codin’, yee-haw! Live free and die hard.
  • So. Many. Iterations. All of which led to what? A small, iterative evolution.
    • Takeaway: it’s ok for design explorations to culminate in updates that look more like an evolution than a mutation.

Want more info on the behind-the-scenes work? Read on!

Design Explorations

It might look like a simple iteration on what I previously had, but that doesn’t mean I didn’t explore the universe of possibilities first before coming back to the current iteration.

Screenshot of a Figma canvas with lots of artboards too small to see but denoting a lot of iterations.

v0: Tabs!

A tab-like experience seemed the most natural, but how to represent it? I tried a few different ideas. On top. On bottom. Different visual styles, etc.

3 mobile-sized UI mockups of a blog post with different navigation bars.

And of course, gotta explore how that plays out on desktop too.

Three desktop-sized UI mockups of a blog post with different navigation bars.

Some I liked, some I didn’t. As much as I wanted to play with going to the edges of the viewport, I realized that every browser is different and you won't be able to get a consistent “bleed-like” visual experience across browsers. For example, if you try to make tabs that bleed to the edges, it looks nice in a frame in Figma, and even in some browsers. But it won’t look right in all browser, like iOS Safari.

Mobile UI mockups showing a folder-style segmented tab control. One is in the frame of an iPhone where the control bleeds up into the restricted space where the dynamic island lives as well as down into the website. Whereas the other mockup is in a frame in Figma, so the highlighted tab only bleeds down into the website.

So I couldn’t reliably leverage the idea of a bounded canvas as a design element — which, I should’ve known, has always been the case with the web.

v1: Bottom Tabs With a Site Theme

I really like this pattern on mobile devices, so I thought maybe I’d consider it for navigating between my sites.

But how to theme across differently-styled sites? The favicon styles seemed like a good bet!

Mobile-sized mocksups with a bottom tab bar whose active highlight color changes with the active color of each subdomain.

And, of course, what do to on larger devices? Just stacking it felt like overkill, so I explored moving it to the edge.

Desktop-sized mocks with tab controls on the far left of the page and the active site is higlighted according to the site's active theme color.

I actually prototyped this in code, but I didn’t like how it felt so I scratched the idea and went other directions.

v2: The Unification

The more I explored what to do with this element, the more it started taking on additional responsibility.

“What if I unified its position with site-specific navigation?” I thought.

This led to design explorations where the disparate subdomains began to take on not just a unified navigational element, but a unified header.

Mobile-sized UI mocks for Home, Blog, and Notes on jim-nielsen.com

And I made small, stylistic explorations with the tabs themselves too.

Mobile-sized UI mocks for Home, Blog, and Notes on jim-nielsen.com

You can see how I played toyed with the idea of a consistent header across all my sites (not an intended goal, but ya know, scope creep gets us all).

Different header + navigation styles for submdomains on jim-nielsen.com including a hamburger button.

As I began to explore more possibilities than I planned for, things started to get out of hand.

v3: Do More. MORE. MORE!!

Questions I began asking:

  • Why aren’t these all under the same domain?!
  • What if I had a single domain for feeds across all of them, e.g. feeds.jim-nielsen.com?
  • What about icons instead of words?

Four mobile-sized mockups for subdomains on jim-nielsen.com, each one getting a different highlight color.

Wait, wait, wait Jim. Consistent navigation across inconsistent sites. That’s the goal. Pare it back a little.

v4: Reigning It Back In

To counter my exploratory ambitions, I told myself I needed to ship something without the need to modify the entire design style of all my sites.

So how do I do that?

That got me back to a simpler premise: consistent navigation across my inconsistent sites.

Dynamic-island-like navigational pill for the subdomains on www, blog, and notes subdomains of jim-nielsen.com

Better — and implementable.

Technical Details

The implementation was pretty simple. I basically just forked my previous web component and changed some styles. That’s it.

The only thing I did different was I moved the web component JS file from being part of my www.jim-nielsen.com git repository to a standalone file (not under git control) on my CDN.

This felt like one of the exceptions to the rule of always keeping stuff under version control. It’s more of the classic FTP-style approach to web development. Granted, it’s riskier, but it’s also way more flexible. And I’m good with that trade-off for now. (Ask me again in a few months if I’ve done anything terrible and now have regrets.)

Each site implements the component like this (with a different subdomain attribute for each site):

<script type="module" src="https://cdn.jim-nielsen.com/shared/jim-site-switcher.js"></script>
<jim-site-switcher subdomain="blog"></jim-site-switcher>

That’s really all there is to say. Thanks to Zach for prodding me to make this post.


Reply via: Email · Mastodon · Bluesky

Bottomless Subtleties

View

Jason Fried writes in his post “Knives and battleships”:

Specific tools and familiar ingredients combined in different ratios, different molds, for different purposes. Like a baker working from the same tight set of pantry ingredients to make a hundred distinct recipes. You wouldn't turn to them and say "enough with the butter, flour, sugar, baking powder, and eggs already!"

Getting the same few things right in different ways is a career's worth of work.

Mastery comes from a lifetime of putting together the basics in different combinations.

I think of Beethoven’s 5th and its famous “short-short-short-long” motif. The entire symphony is essentially the same core idea repeated and developed relentlessly! The same four notes (da-da-da-DAH!) moving between instruments, changing keys, etc.

Beethoven took something basic — a four note motif — and extracted an enormous set of variations. Its genius is in illustrating how much can be explored and expressed within constraints (rather than piling on “more and more” novel stuff).

Back to Jason’s point: the simplest building blocks in any form — music, code, paint, cooking — implemented with restraint can be combined in an almost infinite set of pleasing ways.

As Devine noted (and I constantly link back to): we haven’t even begun to scratch the surface of what we can do with less.


Reply via: Email · Mastodon · Bluesky

Just a Little More Context Bro, I Promise, and It’ll Fix Everything

View

Conrad Irwin has an article on the Zed blog “Why LLMs Can't Really Build Software”. He says it boils down to:

the distinguishing factor of effective engineers is their ability to build and maintain clear mental models

We do this by:

  • Building a mental model of what you want to do
  • Building a mental model of what the code does
  • Reducing the difference between the two

It’s kind of an interesting observation about how we (as humans) problem solve vs. how we use LLMs to problem solve:

  • With LLMs, you stuff more and more information into context until it (hopefully) has enough to generate a solution.
  • With your brain, you tweak, revise, or simplify your mental model more and more until the solution presents itself.

One adds information — complexity you might even say — to solve a problem. The other eliminates it.

You know what that sort of makes me think of? NPM driven development.

Solving problems with LLMs is like solving front-end problems with NPM: the “solution” comes through installing more and more things — adding more and more context, i.e. more and more packages.

  • LLM: Problem? Add more context.
  • NPM: Problem? There’s a package for that.

Contrast that with a solution that comes through simplification. You don’t add more context. You simplify your mental model so you need less to solve a problem — if you solve it at all, perhaps you eliminate the problem entirely!

Rather than install another package to fix what ails you, you simplify your mental model which often eliminates the problem you had in the first place; thus eliminating the need to solve any problem at all, or to add any additional context or complexity (or dependency).

As I’m typing this, I’m thinking of that image of the evolution of the Raptor engine, where it evolved in simplicity:

Photograph of three versions of the raptor engine, each one getting progressively simplified in mechanical parts.

This stands in contrast to my working with LLMs, which often wants more and more context from me to get to a generative solution:

Photograph of three versions of the raptor engine, but the image is reversed showing the engine get progressively complicated in mechanical parts over time. Each engine represents an LLM prompt.

I know, I know. There’s probably a false equivalence here. This entire post started as a note and I just kept going. This post itself needs further thought and simplification. But that’ll have to come in a subsequent post, otherwise this never gets published lol.


Reply via: Email · Mastodon · Bluesky

Choosing Tools To Make Websites

View

Jan Miksovsky lays out his idea for website creation as content transformation. He starts by talking about tools that hide what’s happening “under the hood”:

A framework’s marketing usually pretends it is unnecessary for you to understand how its core transformation works — but without that knowledge, you can’t achieve the beautiful range of results you see in the framework’s sample site gallery.

This is a great callout. Tools will say, “You don’t have to worry about the details.” But the reality is, you end up worrying about the details — at least to some degree.

Why? Because what you want to build is full of personalization. That’s how you differentiate yourself, which means you’re going to need a tool that’s expressive enough to help you.

So the question becomes: how hard is it to understand the details that are being intentionally hidden away?

A lot of the time those details are not exposed directly. Instead they’re exposed through configuration. But configuration doesn’t really help you learn how something works. I mean, how many of you have learned how typescript works under the hood by using tsconfig.json? As Jan says:

Configuration can lead to as many problems as it solves

Nailed it. He continues:

Configuring software is itself a form of programming, in fact a rather difficult and often baroque form. It can take more data files or code to configure a framework’s transformation than to write a program that directly implements that transformation itself.

I’m not a Devops person, but that sounds like Devops in a nutshell right there. (It also perfectly encapsulates my feelings on trying to setup configuration in GitHub Actions.)

Jan moves beyond site creation to also discuss site hosting. He gives good reasons for keeping your website’s architecture simple and decoupled from your hosting provider (something I’ve been a long time proponent of):

These site hosting platforms typically charge an ongoing subscription fee. (Some offer a free tier that may meet your needs.) The monthly fee may not be large, but it’s forever. Ten years from now you’ll probably still want your content to be publicly available, but will you still be happy paying that monthly fee? If you stop paying, your site disappears.

In subscription pricing, any price (however small) is recurring. Stated differently: pricing is forever.

Anyhow, it’s a good read from Jan and lays out his vision for why he’s building Web Origami: a tool for that encourages you to understand (and customize) how you transform content to a website. He just launched version 0.4.0 which has some exciting stuff I’m excited to try out further (I’ll have to write about all that later).


Reply via: Email · Mastodon · Bluesky

Sit On Your Ass Web Development

View

I’ve been reading listening to Poor Charlie’s Almanack which is a compilation of talks by Charlie Munger, legendary vice-chairman at Berkshire Hathaway.

One thing Charlie talks about is what he calls “sit on your ass investing” which is the opposite of day trading. Rather than being in the market every day (chasing trends, reacting to fluctuations, and trying to time transactions) Charlie advocates spending most of your time “sitting on your ass”. That doesn’t mean you’re doing nothing. It means that instead of constantly trading you’re spending your time in research and preparation for trading.

Eventually, a top-tier opportunity will come along and your preparation will make you capable of recognizing it and betting big. That’s when you trade. After that, you’re back to “sitting on your ass”. Trust your research. Trust your choices. Don’t tinker. Don’t micromanage. Don’t panic. Just let the compounding effects of a good choice work in your favor.

Day Trading, Day Developing

As a day trader your job is to trade daily (it’s right there in the job title). If you’re not trading every day then what are you even doing? Not your job, apparently.

I think it’s easy to view “development” like this. You’re a developer. Your job is to develop programs — to write code. If you’re not doing that every single day, then what are you even doing?

From this perspective, it becomes easy to think that writing endless code for ever-changing software paradigms is just how one develops websites.

But it doesn’t have to be that way. Granted, there’s cold-blooded and warm-blooded software. Sometimes you can’t avoid that.

But I also think there’s a valuable lesson in Charlie’s insight. You don’t have to chase “the market” of every new framework or API, writing endless glue code for features that already exist or that will soon exist in browsers. Instead, you can make a few select, large bets on the web platform and then “sit on your ass” until the payoff comes later!

An Example: Polyfills

I think polyfills are a great example of an approach to “sit on your ass” web development. Your job as a developer is to know enough to make a bet on a particular polyfill that aligns with the future of the web platform. Once implemented, all you have to do is sit on your ass while other really smart people who are building browsers do their part to ship the polyfilled feature in the platform. Once shipped, you “sell” your investment by stripping out the polyfill and reap the reward of having your application get lighter and faster with zero additional effort.

A big part of the payoff is in the waiting — in the “sitting on your ass”. You make a smart bet, then you sit patiently while others run around endlessly writing and rewriting more code (meanwhile the only thing left for you will be to delete code).

Charlie’s business partner Warren Buffett once said that it’s “better to buy a wonderful company at a fair price, than a fair company at a wonderful price”. Similarly, I’d say it’s better to build on a polyfill aligned with the future of the platform than to build on a framework re-inventing a feature of the platform.

Get Out Of Your Own Way

Want to do “Day Trading Development”?

  • Jump tools and frameworks constantly — “The next one will solve all our problems!”
  • Build complex, custom solutions that duplicate work the web platform is already moving towards solving.
  • Commit code that churns with time, rather than compounds with it.

Want to do “Sit on Your Ass Development”?

  • Do the minimum necessary to bridge the gap until browsers catch up.
  • Build on forward-facing standards, then sit back and leverage the compounding effects of browser makers and standards bodies that iteratively improve year over year (none of whom you have to pay).
  • As Alex Russel recommends, spend as little time as possible in your own code and instead focus on glueing together “the big C++/Rust subsystems” of the browser.

In short: spend less time glueing together tools and frameworks on top of the browser, and more time bridging tools and APIs inside of the browser. Then get out of your own way and go sit on your ass. You might find yourself more productive than ever!

Update: 2025-08-11

Dave Rupert mentioned which web platform features he’s jumping on the bandwagon for:

  • view transitions
  • scroll-driven animations
  • popover
  • masonry
  • web components
  • carousels

And I would add to that my own (at the time of this writing):

  • http imports / importmaps
  • css / json modules
  • URLPattern
  • css nesting
  • relative color syntax
  • HTML INCLUDES!

Reply via: Email · Mastodon · Bluesky

Writing: Blog Posts and Songs

View

I was listening to a podcast interview with the Jackson Browne (American singer/songwriter, political activist, and inductee into the Rock and Roll Hall of Fame) and the interviewer asks him how he approaches writing songs with social commentaries and critiques — something along the lines of: “How do you get from the New York Times headline on a social subject to the emotional heart of a song that matters to each individual?”

Browne discusses how if you’re too subtle, people won’t know what you’re talking about. And if you’re too direct, you run the risk of making people feel like they’re being scolded. Here’s what he says about his songwriting:

I want this to sound like you and I were drinking in a bar and we’re just talking about what’s going on in the world. Not as if you’re at some elevated place and lecturing people about something they should know about but don’t but [you think] they should care. You have to get to people where [they are, where] they do care and where they do know.

I think that’s a great insight for anyone looking to have a connecting, effective voice. I know for me, it’s really easily to slide into a lecturing voice — you “should” do this and you “shouldn’t” do that.

But I like Browne’s framing of trying to have an informal, conversational tone that meets people where they are. Like you’re discussing an issue in the bar, rather than listening to a sermon.

Chris Coyier is the canonical example of this that comes to mind. I still think of this post from CSS Tricks where Chris talks about how to have submit buttons that go to different URLs:

When you submit that form, it’s going to go to the URL /submit. Say you need another submit button that submits to a different URL. It doesn’t matter why. There is always a reason for things. The web is a big place and all that.

He doesn’t conjure up some universally-applicable, justified rationale for why he’s sharing this method. Nor is there any pontificating on why this is “good” or “bad”. Instead, like most of Chris’ stuff, I read it as a humble acknowledgement of the practicalities at hand — “Hey, the world is a big place. People have to do crafty things to make their stuff work. And if you’re in that situation, here’s something that might help what ails ya.”

I want to work on developing that kind of a voice because I love reading voices like that.


Reply via: Email · Mastodon · Bluesky

A Few Things About the Anchor Element’s href You Might Not Have Known

View

I’ve written previously about reloading a document using only HTML but that got me thinking: What are all the values you can put in an anchor tag’s href attribute?

Well, I looked around. I found some things I already knew about, e.g.

  • Link protocols like mailto:, tel:, sms: and javascript: which deal with specific ways of handling links.
  • Protocol-relative links, e.g. href="//"
  • Text fragments for linking to specific pieces of text on a page, e.g. href="#:~:text=foo"

But I also found some things I didn’t know about (or only vaguely knew about) so I wrote them down in an attempt to remember them.

href="#"

Scrolls to the top of a document. I knew that.

But I’m writing because #top will also scroll to the top if there isn’t another element with id="top" in the document. I didn’t know that.

(Spec: “If decodedFragment is an ASCII case-insensitive match for the string top, then return the top of the document.”)

Update: HTeuMeuLeu pointed out to me on Mastodon that you can use #page= to deep-link to a specific page in a PDF, e.g. my-file.pdf#page42 would like to page 42 in the file.

href=""

Reloads the current page, preserving the search string but removing the hash string (if present).

URLResolves to
/path//path/
/path/#foo/path/
/path/?id=foo/path/?id=foo
/path/?id=foo#bar/path/?id=foo

href="."

Reloads the current page, removing both the search and hash strings (if present).

Note: If you’re using href="." as a link to the current page, ensure your URLs have a trailing slash or you may get surprising navigation behavior. The path is interpreted as a file, so "." resolves to the parent directory of the current location.

URLResolves to
/path/
/path#foo/
/path?id=foo/
/path//path/
/path/#foo/path/
/path/?id=foo/path/
/path/index.html/path/

Update 2025-08-15: as pointed out by @AmeliaBR on Mastodon, “reloads the current page” probably isn’t the best terminology for this. It’s more like “loads the default index page for the current directory, based on the URL structure” which might be a reload, but might be something else based on the current URL (see my note and table above).

href="?"

Reloads the current page, removing both the search and hash strings (if present). However, it preserves the ? character.

Note: Unlike href=".", trailing slashes don’t matter. The search parameters will be removed but the path will be preserved as-is.

URLResolves to
/path/path?
/path#foo/path?
/path?id=foo/path?
/path?id=foo#bar/path?
/index.html/index.html?

href="data:"

You can make links that navigate to data URLs. The super-readable version of this would be:

<a href="data:text/plain,hello world">
  View plain text data URL
</a>

But you probably want data: URLs to be encoded so you don’t get unexpected behavior, e.g.

<a href="data:text/plain,hello%20world">
  View plain text data URL
</a>

Go ahead and try it (FYI: may not work in your user agent). Here’s a plain-text file and an HTML file.

href="video.mp4#t=10,20"

Media fragments allow linking to specific parts of a media file, like audio or video.

For example, video.mp4#t=10,20 links to a video. It starts play at 10 seconds, and stops it at 20 seconds.

(Support is limited at the time of this writing.)

See For Yourself

I tested a lot of this stuff in the browser and via JS. I think I got all these right.

Thanks to JavaScript’s URL constructor (and the ability to pass a base URL), I could programmatically explore how a lot of these href’s would resolve.

Here’s a snippet of the test code I wrote. You can copy/paste this in your console and they should all pass 🤞

const assertions = [
  // Preserves search string but strips hash
  // x -> { search: '?...', hash: '' }
  { href: '', location: '/path',               resolves_to: '/path' },
  { href: '', location: '/path/',              resolves_to: '/path/' },
  { href: '', location: '/path/#foo',          resolves_to: '/path/' },
  { href: '', location: '/path/?id=foo',       resolves_to: '/path/?id=foo' },
  { href: '', location: '/path/?id=foo#bar',   resolves_to: '/path/?id=foo' },
  
  // Strips search and hash strings
  // x -> { search: '', hash: '' }
  { href: '.', location: '/path',              resolves_to: '/' },
  { href: '.', location: `/path#foo`,          resolves_to: `/` },
  { href: '.', location: `/path?id=foo`,       resolves_to: `/` },
  { href: '.', location: `/path/`,             resolves_to: `/path/` },
  { href: '.', location: `/path/#foo`,         resolves_to: `/path/` },
  { href: '.', location: `/path/?id=foo`,      resolves_to: `/path/` },
  { href: '.', location: `/path/index.html`,   resolves_to: `/path/` },
  
  // Strips search parameters and hash string,
  // but preserves search delimeter (`?`)
  // x -> { search: '?', hash: '' }
  { href: '?', location: '/path',              resolves_to: '/path?' },
  { href: '?', location: '/path#foo',          resolves_to: '/path?' },
  { href: '?', location: '/path?id=foo',       resolves_to: '/path?' },
  { href: '?', location: '/path/',             resolves_to: '/path/?' },
  { href: '?', location: '/path/?id=foo#bar',  resolves_to: '/path/?' },
  { href: '?', location: '/index.html#foo',    resolves_to: '/index.html?'}
];

const assertions_evaluated = assertions.map(({ href, location, resolves_to }) => {
  const domain = 'https://example.com';
  const expected = new URL(href, domain + location).toString();
  const received = new URL(domain + resolves_to).toString();
  return {
    href,
    location,
    expected: expected.replace(domain, ''),
    received: received.replace(domain, ''),
    passed: expected === received
  };
});

console.table(assertions_evaluated);

Reply via: Email · Mastodon · Bluesky

How to Make Websites That Will Require Lots of Your Time and Energy

View

Some lessons I’ve learned from experience.

1. Install Stuff Indiscriminately From npm

Become totally dependent on others, that’s why they call them “dependencies” after all! Lean in to it.

Once your dependencies break — and they will, time breaks all things — then you can spend lots of time and energy (which was your goal from the beginning) ripping out those dependencies and replacing them with new dependencies that will break later.

Why rip them out? Because you can’t fix them. You don’t even know how they work, that’s why you introduced them in the first place!

Repeat ad nauseam (that is, until you decide you don’t want to make websites that require lots of your time and energy, but that’s not your goal if you’re reading this article).

2. Pick a Framework Before You Know You Need One

Once you hitch your wagon to a framework (a dependency, see above) then any updates to your site via the framework require that you first understand what changed in the framework.

More of your time and energy expended, mission accomplished!

3. Always, Always Require a Compilation Step

Put a critical dependency between working on your website and using it in the browser. You know, some mechanism that is required to function before you can even see your website — like a complication step or build process. The bigger and more complex, the better.

This is a great way to spend lots of time and energy working on your website.

(Well, technically it’s not really working on your website. It’s working on the thing that spits out your website. So you’ll excuse me for recommending something that requires your time and energy that isn’t your website — since that’s not the stated goal — but trust me, this apparent diversion will directly affect the overall amount of time and energy you spend making a website. So, ultimately, it will still help you reach our stated goal.)

Requiring that the code you write be transpiled, compiled, parsed, and evaluated before it can be used in your website is a great way to spend extra time and energy making a website (as opposed to, say, writing code as it will be run which would save you time and energy and is not our goal here).

More?

Do you have more advice on building a website that will require a lot of your time and energy? Share your recommendations with others, in case they’re looking for such advice.

Update 2025-08-22

This post made it to Hacker News and there were a few comments with additional handy suggestions:

Always use ORMs...[they] promise to abstract the database but end up being just another layer you have to fight when things go wrong. 🔗

Acquire as much vendor lock-in as possible 🔗

Put a cryptocurrency miner on it; that will literally require lots of time and energy. 🔗

Also a few statements on coding generally:

Engineers love to solve problems. If there are no problems readily at hand, they will create some 🔗

we lack the discipline to keep something simple. Is self-control in coding just a lost art now? 🔗


Reply via: Email · Mastodon · Bluesky

Occupation and Preoccupation

View

Here’s Jony Ive in his Stripe interview:

What we make stands testament to who we are. What we make describes our values. It describes our preoccupations. It describes beautiful succinctly our preoccupation.

I’d never really noticed the connection between these two words: occupation and preoccupation.

What comes before occupation? Pre-occupation.

What comes before what you do for a living? What you think about. What you’re preoccupied with.

What you think about will drive you towards what you work on.

So when you’re asking yourself, “What comes next? What should I work on?”

Another way of asking that question is, “What occupies my thinking right now?”

And if what you’re occupied with doesn’t align with what you’re preoccupied with, perhaps it's time for a change.


Reply via: Email · Mastodon · Bluesky