I wanted to tinker with llm and “AI engineer” up a humble tool for working with my notes, writings, highlights, etc. Emphasis on humble: if I could tinker with any one of those datasets quickly and iteratively, I would mark it as a win. (Previously, Scaling down native dev.) Medium story short, I exported some of my reading highlights, loaded it into a database, and wrapped a quick UI around it to navigate my highlights via embeddings rather than keyword search. A few short sessions later, maybe a few hours total, I had something interesting working. 💪🏻

1. Data

For several years, I’ve used Readwise to capture highlights and search/review them later. Handily, Readwise has CSV (and tree-of-Markdown files) exports of all one’s highlights. As data formats go, CSV is nearly perfect for this exercise. It’s structured, so parsing is not required to shoehorn it into a low-ceremony data pipeline. That said, Readwise’s export isn’t perfect: notably it lacks URLs the highlights started with. But for experiments, it’s a start.

2. Pipeline

Thanks to sqlite-utils, I can generate a SQLite database from the export CSV. This all happens by convention with the sqlite-utils command line.

db:
    sqlite-utils insert \
      highlights.db \
      highlights \
      data/readwise-data-2.csv \
      --csv \
      --pk id

No bespoke (Python) code is required in this whole pipeline process. I ended up encapsulating the steps in a Justfile, but anything that can run shell commands would have done the trick.

Step two is to generate embeddings. With the right install, this is another one-liner, this time with llm. We query the database generated in the previous step to give us content to pass through to a text embedding model. The generated vectors are stored into the same SQLite database.

embed:
    llm embed-multi \
      docs \
      --database highlights.db \
      --store \
      --sql 'select id, highlights."Book Title" as title, highlights."Highlight" as content from highlights' \
      --model mpnet

There is no step three! The data is ready to query for “semantic”, not keyword, similarity search. To prove to myself I had an end-to-end working proof of concept, I used this snippet to query the data:

# $ just query "now is not the time for notes"
query q:
    llm similar \
      docs \
      --database highlights.db \
      --content '{{q}}'

3. Prototype

Next, I put it all together in a FastHTML app. This was fun! FastHTML is great for this kind of bespoke, informal hacking. Caveat, some of this may not be idiomatic Python. I’m just coming back to Python after not having written it in seriousness for twenty years.

• Using the dataclass decorator on a class and a method for converting an object to a “FastTag”, love this for low-ceremony but typed data modeling.
• I finally got the grasp of Python’s generator syntax. I want to like itertools, but it’s a pain to use. (🌶️ Ruby’s Enumerable remains undefeated.)
• JSX-like syntax to structure UI in code is great. This approach falls down every time I put a designer in front of an editor, but I’m going to call it: this is the mark-up/UI-construction ergonomics developers crave.
• There’s no need for a layered web-app approach here. There’s a similar function that turns query text into similar highlight “model” objects. That’s a nice affordance for working quickly and loosely.

Conclusions

Python’s has pleasant things going on lately. Even a career Ruby developer like myself can find kind things to say. 😉

The trickiest part to building with LLMs and generative AI is source data. Prompting a model as-is is not much more interesting than using ChatGPT or Claude. Ergo: look to one’s notes, posts, highlights, etc. to find compelling data to build upon.

Variations on RAG (this is probably a bit short of calling itself RAG, but it’s very close) produce more appealing results than keyword indexing, but not by much. I don’t think it’s the center of a product yet; more of a sidebar or enhancement.

All of this took less than five hours to build. I’ll probably end up spending a couple of hours total writing it up. This is the kind of “working with the garage door up” kind of thing I want to do. 💯📈

Can’t live with ‘em, can’t live without ‘em🤷‍♂️

A product team (at least the ones that have been working for more than three weeks) has a backlog of work they’d love to tackle, but now’s not the right time. Maybe it’s not the most important, a practical solution isn’t in-hand, the technology isn’t ready yet, or a dependency hasn’t started work yet. Either way: a growing, somewhat discouraging list of things they want to do but can’t yet.

Over time, a backlog evolves to many forms. None of them are ideal. We have to look at backlogs for what they are: an artifact of time’s finite-ness and our finite ability to do work in the present.

A “big pile of sadness backlog” doesn’t acknowledge limitations in time and capacity. It imagines a future where we can do everything we’ve ever wanted. The backlog actually gets shorter. All those problems we once wanted to solve, we can. We are also a bit taller, more attractive, and feel a bit younger while we’re at it.

But that day never comes, and we’re left with a sad backlog of things. Almost (and this is the nefarious part) all of them less important than what we’re currently doing, but still, we think, important. So it stares at us from the shadows, a bit sad and discouraging us that we are failing at our job by having this large backlog of ideas and promising projects. At least we think they’re promising! More likely, in my experience, attempting to triage the pile of sadness backlog yield two more meta-projects around organizing the sadness to highlight the truly sad from the merely unfortunate. 😮‍💨

It’s more helpful to look at a backlog as numerous maybe-good ideas sent to our future-selves. By definition, a backlog is speculation. We thought executing on these projects and tasks would improve things, but we won’t know until we do. Schrödinger’s cat and all that. Storing all that speculation away in a pile is healthy. If it turns out one of these ideas is the right starting point for the next most important problem we face, we’ll pull it out of the backlog and give it a think. Otherwise, it stays there, putting no current work at risk.

The contents of a backlog are frozen in time. The tasks, projects, docs, designs, screenshots, diagrams, etc. all reflect a point in time. Some call this rot, implying “hey, we should have been better about keeping this campsite clean and used our (infinite 😜) time to tend it”. IMO that’s not the best approach; better to regard aging tasks as issues and solutions from a point of time. They may no longer reflect the circumstances the product and team currently face. Items in a backlog necessarily need updating by a PM or developer to figure out if they still make sense, would solve the problem, or are a direct solution to that problem.

I have quite the extended personal backlog of items to read and project ideas. When I regard them as missed opportunities, as evidence that I could have been at least a little more diligent in managing my time, it’s stressful and discouraging. When I instead regard it as a pile of ideas in reserve for mornings I wake up and none of my current hobby projects are enticing or what I’m reading isn’t doing it for me, then those backlogs are useful. Granted, said lists aren’t getting much shorter.

Perhaps, a backlog is a defense mechanism. They are, at times, a way to deliver a soft no, to ourselves or collaborators. “Not a bad idea, but not something we can get to right away. It’s in the backlog. Maybe someday we’ll come upon it.”

Or, you may have an impeccable backlog! All killer, no filler; like a “no-skips” album, but in product backlog form. If you’re out there, please let us know how you got here and how much effort it takes. 😆 (Really, if you’re out there, I’m intrigued!)

The flip side is no backlog at all. The project work is a river and if something interesting floats past, you seize upon it. Otherwise, you let it float downstream and don’t worry about it too much. Or, there’s no team backlog, but the team members keep a list of ideas/task/projects that might be interesting in the future and bring them up at opportune moments. That works too!

🌶️ Hot-take: if you’re a manager and find you¹ miss building…then build²!

• On your time: mornings, weekends, national holidays.
• Whatever you want: tools for yourself, something frivolous, something practical.
• However you want: in an esoteric technology, in a boring technology, in a domain you’ve always wanted to explore, with LLM copilots, building every piece from scratch, without using conditionals, whatever!

Avoid:

• Swooping into your team’s current projects³.
• Imposing your discoveries/ideas on unrelated code reviews.
• Inventing projects and putting yourself on the critical path.
• Building and handing off a proof-of-concept to an unsuspecting teammate to finish.
• Thinking the grass is greener on the hands-on/IC side.

Don’t react to the bad parts of your previous role. It’s increasingly tricky to ride the pendulum between IC and leadership roles. You may only get to pull that lever once. Maybe building something for yourself will temper the temptation to go back to an IC role.

Instead, see if you can scratch whatever hands-on building/coding/designing itch you have in your time. You’ll necessarily have to scale it down. Honestly, that’s a great constraint! If you tried to build something big, you’d have to lead and manage it and, if you recall, that’s what we’re taking time away from in the first place here.

Follow your curiosity. The very best part about building on your time as a manager is you don’t have to make great decisions. Whatever is of interest, go with it.

Want to build a compiler, but you work in web apps? Go for it. Want to build a game, but you work in compilers? Go for it. Want to build an asset tracking web app in a really particular way, but you work in games? Go for it. Want to write in Haskell, but you work in Ruby? Go for it.⁴

Go for it.

A couple of lessons on leadership in ​Herbert’s Dune​:

“Give as few orders as possible,” his father had told him…once…long ago. “Once you’ve given orders on a subject, you must always give orders on that subject.”

Avoid, whenever possible, making decisions for people and teams. It may end up discouraging or preventing them from making any decisions for themselves in the future.

Frequent top-down decisions are the autonomy-killer, they might say. 🤓

Hawat arose, glancing around the room as though seeking support. He turned away, led the procession out of the room. The others moved hurriedly, scraping their chairs on the floor, balling up in little knots of confusion. It ended up in confusion, Paul thought, staring at the backs of the last men to leave. Always before, Staff had ended on an incisive air. This meeting had just seemed to trickle out, worn down by its own inadequacies, and with an argument to top it off.

This is what bad meetings feel like; they deflate like a balloon. Worse than indecision, they bring confusion about how to proceed, where efforts really stand, or if the current approach is the right approach. Not necessarily because of debate or disagreement. But, the lack of consensus or direction certainly doesn’t help.

Reader, I want to (once again) talk to you about the life-changing power of making a list and putting it in order.

Ambiguity of like, “what are we gonna build?” or “how are we supposed to build this?” Or was it supposed to be A or B or why did we make this decision? So having the checklist of “this is the thing,” it is a very, very cheap way to eliminate most of the ambiguity.

– Kristján Pétursson, Human Skills 018 — Creating Clarity From Ambiguity

Tasks lists are great for capturing and organizing what you want/need to do. They are sometimes good for thinking through how to execute on those tasks and projects.

Ordinarily, I’m too focused on all those incomplete items The empty check boxes, the lines that aren’t crossed through. So much potential. It’s exciting and overwhelming!

I rarely use my task list to reflect upon what I’ve done. To retrospect on how much I accomplished any given day or capture a post-hoc note or two on follow-ups, what worked, or to merely pat myself on the back for a day of honest work.

So I’m trying this right now! But, applications could stand to add more affordances for looking back in time too. This goes for applications like Things as much as it goes for Jira, etc. It’s probably our work and hustle culture. 🤷‍♂️ Always looking forward and rarely slowing down to say “hey, I did this, let’s get excited about that!”

One of the nice things about Kanban boards is you eventually end up with a giant pile of things that were done, and that’s a nice way to feel the momentum building that a bunch of stuff got done. Let’s get more of that.

“Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person”.

Corollary: any group size approaching 150 people (Dunbar’s number) includes at least one person who knows about Dunbar’s number.

To paraphrase a classic joke, “How do you know if someone knows about Dunbar’s number? They’ll tell you!” I’m telling you, right now, I know about Dunbar’s number. 🙃

Practically, I think this implies:

• If you’re designing an organization close to but not exceeding Dunbar’s number, you can hand-wave the details of when it grows to exceed Dunbar’s number. Someone will enthusiastically let you know that the organization has exceeded Dunbar’s number and might need reconsideration. 🥸
• For organizations as small as 10% of Dunbar’s number (15), there’s a pretty dang good chance that someone knows about Dunbar’s number. For organizations any multiple of that size, you don’t need to go around telling everyone about Dunbar’s number. Chance are, someone is telling everyone about Dunbar’s number. 😆

My experience in (software) teams is there are breakpoints far smaller than Dunbar’s number that matter even more.

FWIW, these are all folk rules. I haven’t seen rigorous work that backs any of this up!

Permit me to throw shade at the Emmy Awards for a moment.

Reservation Dogs is a better kinda-comedy than The Bear. Dogs is consistently funny and finds ways to explore the lives, relationships, and histories of the characters in rewarding ways.

The Bear is equal parts endearing and yelling. Once or twice a season, it speaks to craft and intensity. Those are my favorite episodes. The Fak family is the only undeniably comedic element of The Bear. Give us a spin-off of that and let it legitimately win all comedy awards.

The Bear belongs in the drama category, but isn’t the length of a drama because no one could sustain watching an episode of that show for that long. 🙃

By kinda-comedy, I mean “22-minute shows that are eligible for comedy awards at the Emmy’s”. The real solution here is for the Emmy’s to fix their categories in two ways:

• Don’t call “dramatic” shows that are shorter than 44 minutes comedies. This is absurd and an easy fix.
• Unrelated to The Bear, currently: create separate categories for “returning shows” and “ending shows”. Emmy voters have a tendency to award shows in their last season disproportionate to their competition.

In short: Reservation Dogs was the comedy that Emmy voters think The Bear is. 🌶️

The function key, on iOS and possibly Mac keyboards, is bound¹ to show the emoji picker.

Apple has chosen to bind a whole key, no modifiers or anything, to “convey an emotion”. A (cartoonish) picture is worth a thousand words.

🧠 Smart!

(I could go on for at least five minutes about Apple’s recent design advantage is in introducing big features without making them shout-y in the UI. Granted, the marketing is very shout-y.)

As I write this, it’s late-2024 and the job market is tough for jobseekers. If one finds a job within three months, they’re considered lucky. Some folks go 2–3 times longer in-between jobs. If you’re on this boat, break a leg!🫠

If you’re not actively seeking a job, here’s a thing that helped me go from “well this market sucks” to “welp, job seeking is my full-time job now, the only way out is through”:

I started warming up my professional network when things got spooky at my current job.

Caveat, I could have done even more than I did¹. Despite not taking more steps, the simple act of thinking through “what would I do if the worst happened and my job disappeared?” put me one step ahead, and I was a little more calm after my job did disappear.

1. The network is the work²

A strong, active professional network is the most important tool in this scenario. This is true whether the job market favors job-seekers or employers.

Especially when seeking a job without one in-hand, people are happy to respond and help out³. Fifteen minutes of writing and responding to messages could kick-start the process for your next job.

Some helpful questions I asked myself in contemplating how to warm my network back up:

• Who would I work with (again)? If former colleagues were especially easy, awesome, or delightful to work with one, a second outing is worth pursuing.
• What kinds of places would I like to work at? I find myself particularly interested in finance-adjacent endeavors.⁴ Tooling is also of interest, anything that makes people’s work lives better resonates with me.
• Why not aim for the bleachers in my next role?⁵ If I could work anywhere or hold any kind of role, where would it be? Perhaps there’s a role out there with all the upsides I’m looking for and very few trade-offs on the downside. Who could connect me to those roles?

2. Take a stroll down accomplishments lane

Another easy thing to do⁶ is get (back) in the resumé writing mindset. That is, the self-promotion mindset where you’re talking about all the things you’ve done, how great they were, putting numbers to how much they improved customer outcomes, and generally putting maximum shine on your work.

This is the point where I wish I had kept a good brag doc.

In lieu of a record kept in the moment, I took out some stickies and wrote out what I’d done in each of the last 6+ years at work. The goal here was to shake the dust from my brain and remember all the cool projects we shipped, excellent people I’d worked with, and improvements I’d made across the board. Keep in mind, no feat is too small and the sequence of projects doesn’t matter much! I’m only getting in the groove here. The two-ish page limit on practical resumés is forces compressing this list later.

Don’t feel bad about taking time to do this. At any high-functioning organization with a performance management cycle, what you’re doing here looks exactly like what you’d do for your regular performance review ceremony.⁷ Two birds, one stone!

2a. There must be 50 ways to write your resumé

An updated resumé is a pre-requisite. I’m not (yet!) so internet-famous that I can get by without one. I didn’t start rewriting my resumé right off the bat. Instead, I dusted it off and considered how I’d change it when the time came that I needed it.

Writing about oneself is challenging. It feels awkward, like something one is supposed to avoid. A few insights helped me here:

• My resumé is the marketing/advertising that will yield the job I hold for several years of my life. Multiplied out by annual pay, this document is a tool I’m using to generate the next several hundred thousand dollars that fund my life. Basically, any time I spend on it is worthwhile.
• Ergo, it’s worth spending days, all day, iterating, improving, and trying new things. It was this iteration that helped me get over the cringe of writing about myself.
• Cover letters seem to have fallen entirely out of fashion.⁸ Your resumé now has to do even more work. All the more reason to keep at iterating and customizing it.
• If it helps, write your resumé like you’ve already landed the hiring manager interview.⁹ Convince the reader that they were right to pull your resumé out of the stack. Tell them about all the great stuff you’ve done. This is where you want to refer to all your accomplishments, emphasizing the most recent and those most relevant to the kind of role you’re seeking.

3. One job is plenty

Looking for a new job is an exhausting endeavor. Iterating on resumés, tweaking LinkedIn profiles, and updating online presence consumes a lot of time and emotional energy. That’s not to mention actually finding promising jobs, customizing your resumé to suit the job descriptions, filling in application tracking system forms, responding to leads, and scheduling of interviews. Phew!

If you can avoid it, don’t seek a new job whilst trying to hold down another one. Especially one that has “gone spooky”. Granted, there’s a lot of luck and privilege wrapped up in that advice!

If your luck affords it, make the search for one’s next full-time job a full-time job. That is, give yourself a few month sabbatical to recharge and focus on the job search. Granted, don’t take this route in a market that heavily favors employers and make sure your savings are topped off in case of surprises.

All this said, preparing for seeking a job is not the same as seeking a job. It took me longer than I’d have liked to realize this. Actively seeking a job, for me, looks more like marketing and sales than building or leading. It’s playing a “numbers game”: the more people you network with and the more jobs you apply for, the better. Thinking through how I would execute that helped!

But there was a hump I had to get over, entirely in my head, about actively/explicitly putting myself out there. Some social barriers I had to let go of, like not “reaching out” to folks via email or LinkedIn. Doing sales-y things, it’s a big growth area for me. 🙃

Finally, a thing I’m learning about this most-difficult job search of my career: every step on the job search is one step closer to finding that job.¹⁰

If you find yourself actively seeking a job, or merely feeling the spider-sense tingle about your current role, good luck! I hope this helped.

Jeff Triplett, Please publish and share more:

You don’t have to change the world with every post. You might publish a quick thought or two that helps encourage someone else to try something new, listen to a new song, or binge-watch a new series.

…

Our posts are done when you say they are. You do not have to fret about sticking to landing and having a perfect conclusion. Your posts, like this post, are done after we stop writing.

I have found it’s not enough to journal, capture notes, save bookmarks, write in a notebook, post to a blog, participate in a cozy group chat, or engage in public discussion on social media.

Revisit what I wrote. Resurface old ideas. Try to put old ideas together with new ideas. Remixing ideas with new thoughts. Repackage into a new medium. That’s how the compounding of writing and thinking hits the road, per se. At least, for me.

Set activation energy low and steer into repetitiveness. I never know which combination of words is going to hit someone’s mental jackpot.

Kent beck, Coupling and Cohesion:

The only way to be able to describe something well is to describe it badly 100 times.

I’m forever feeling this one. Many times, I’ve felt the idea or plan is so clear in the document or the whiteboard. And yet, when other folks try to read the idea or execute the plan in their heads, the connection isn’t made. Back to the drawing board. 🙃

FWIW, “describe something well” is directly related to building software. A good domain model or intuitive UX interaction is as tricky to describe as a great movie or poem.

All problems are shallow under iteration; the real limitation is producing iterations and collecting feedback.

Hurry up and lose your first 50 games.

— Go proverb

Case in point: I’ve probably written some variation on this blog post nearly a dozen times. Perhaps some day, I’ll get it just right.

In short: I want to build low-road applications for myself. They will have a very narrow function. I may use them for as little as a week or so, finish the task at hand, and move on to the next thing. Think about it like Simon Willison’s work using Claude to generate tools.

This feels like it demands something besides my usual full-stack web app (i.e., Rails) approach¹:

• I would like to launch these apps instantly and operate on local data.
• In particular, files and folders; not database rows.
• I would rather not dig up a folder or terminal to run these applications; they should launch like I’d run anything else (i.e., via Raycast).

Tauri seems like it fits the bill here. It wraps a native web view in a small platform-specific host application. The “host” application is a Rust program that wraps a platform-specific web view, e.g., Safari on macOS. You can write native code in Rust, web/front-end code in HTML/CSS/JS, and easily call functions between them. In other words, a better Electron.

Strengths become weaknesses. In theory, “JavaScript everywhere” is a lovely concept. One language across the web, backend services, command-line scripts, embedded systems, even desktop applications. In practice: it’s a thousand cuts, especially if you’re trying to avoid accepting the whole JS build system/framework ecosystem into your life. Which I was, in this case.

It’d be extremely great to have Deno save the day here. Write backend/host-native or front-end code in JS and very little need to drop to Rust. In practice, it doesn’t seem like anyone is doing that. 🤷🏻‍♂️

What I want to build for myself is a gizmo for re-categorizing my old blog posts. These are all hosted on Micro.blog as of this year. Because of idiosyncrasies in the Micro.blog API, interacting with all posts seems to require using XML-RPC. The REST+JSON APIs don’t provide access to more than one page of posts, so they’re unsuited to working with one’s entire blog archive².

Doing this from JavaScript, running in the web view, is where I ran into troubles. All the libraries I found assumed the code is hosted in Node, which maybe would have been fine. Node isn’t drastically different from browsers in this regard, if I understand correctly. Except that loading the actual library used the Node require mechanism instead of the browser-based import mechanism. And, it’s been a minute since I cared about the details of code loading in JS (did I ever really care?). It wasn’t really the problem I wanted to solve, so I “just tried things”, despite this being one of my pet peeves about how intermediate-level developers work.

Reader: I was not feeling like a badass user at this point.

I wanted to write some tests with Jest. But, Jest deeply assumes you’re using some kind of code transformation (webpack, Babel, etc.) scheme. Which I was trying pretty hard to avoid. I did get a very basic test working, but I didn’t feel good about it.

I might consider using QUnit and live with in-browser tests if I choose “no build step” as a tent pole principle on a real project.

Long story short, I did manage to get an XML-RPC call working from a test in Jest. I never tried integrating it into the web-view code. I fought the module system enough for the week. Maybe if I revisit this approach, I’ll get my story straight here. 🤷🏻‍♂️

My next foray was attempting to write the networking calls to Micro.blog in Rust. I’ve previously struggled with Rust in the form of extended arguments with the compiler. I like the idea of the language, type system, and lifetime/borrowing scheme. But taken together, I haven’t yet reached a place of confidence working with it. My last serious attempt at using Rust, several years ago, was stymied by a combination of generics, number towers, and getting lifetimes right.

I did not run into those particular challenges this time around. Armed with an LLM, it feels better than several years ago! I didn’t spend the whole time arguing with the compiler. With Claude 3.5 Sonnet (IIRC), I was able to get a rudimentary XML-RPC call working.

I’m in favor of writing the backend/host-executed stuff in Rust. The jury’s still out on whether this is a plausible approach. I’ve never argued with the Haskell compiler about, e.g., JSON and walked away with a successful compilation.

pico.css is perfect for my needs. I included it with a link tag and mostly used classless HTML tags. That’s about it. No scheme of semantic, functional, or utility class names to learn. No build step. It’s good enough that looks aren’t the weakest link or distracting. That’s a good tool.

Similarly, I tried using Alpine to layer some interaction logic into the UI. I got hung up on declaring a data structure and then using it from any old element. I think this was a load order issue or misunderstanding on my part. Instead, I should have tried starting with basic interactions and then gone for the fancy stuff.

The verdict, after a few hours of hacking:

• Tauri has a lot of promise for problems shaped like “I want to build a quasi-native desktop app, but I would rather not get caught up in native ecosystems”.
• Rust, in combination with LLM copilots, is easier to navigate than it was without them and I spent less time arguing with the compiler than I’d feared I would.
• Small, low-customization CSS libraries: they’re good for me!

From that point on, well, there’s only one, maybe two great nail salons in Amsterdam.

I was rewatching Ocean’s Twelve, because empty calories and fantastic faces. Having watched it a dozen times, I was struck by how it doesn’t fit together like a Major Motion Picture.

Many of the scenes are vignettes. They’re structured around one as little as one laugh or minor plot beat, like I’d expect from an unscripted show. Especially in the back half of the movie, many of the scenes watch like they’re built around a single punchline, often with background action advancing or distracting from the heist-puzzle.

I know this isn’t High Art or Cinema™️, but I love it.

Simon Sarris, Reading Well:

You should start many books and complete few. You should never feel beholden to completing them, there are simply too many worthwhile works to read.

I’m a completionist. I don’t like leaving books, let alone series of books, unfinished. But, endorsements from Sarris (and Austin Kleon) on leaving books unfinished, possibly by throwing them across the room, is a strong-enough signal. 🙃

🔥I wish I’d heard this advice when I was reading The Black Swan.

1. Safari is (on macOS) the only good application and web browser. Chrome is a remarkable feat of engineering but a mediocre application.
2. Arc is extremely promising. Reimagining the shape, function, and purpose of a web browser for our current computational surplus is a worthwhile endeavor. On the flip-side, I hope that grassroots efforts like the Ladybird browser and browser jams will produce more diversity in how browser engines operate and what it means to construct a browser engine in the first place.
3. Web browsers, as application platforms and as document viewers, are an incredible technological accomplishment. Trillions of renders per day, things mostly work, and the security/sandboxing model works without embarrassing flaws. Viewed over years and decades, progress in web browsers has been remarkable.

To paraphrase Winston Churchill, web browsers are the worst cross-platform application framework except for all the other ones that have been tried.

1. Make a better meeting when you can, and the best of a meeting when you can’t.
2. The choice to avoid holding a meeting may snowball into problems that require even more meetings.
3. Ensure every meeting worth the person-time, assuming organizational dynamics allow for it.
4. Recurring meetings have to earn their continued existence.
5. Steer meetings away from sidebars, confusions, digressions, and distractions.
6. Meeting are an opportunity to go deeper than documents and chats allow.

Bonus: meetings are the work.

Ben Brooks, Thinking Analog:

The way this works is simple: use a notebook and a pen when you need to work through a problem of any kind.

Not a tablet with a stylus. Not a notetaking app. Not a pencil. Paper and pen.

…

I typically juice the cycle by writing a heading, a date, or any one liner associated with what I want to think about to get things moving. From there the mess happens, scribbles and words. They are disjointed but reconfigured with arrows. In all of that, my thinking solidifies, and the idea takes hold.

(via Patrick Rhone)

Endorsed! Apps, “tools for thought”, etc. are great – don’t get me wrong. But, we all contain multitudes.

Some issues are well-defined and suited to computer-thinking. Other problems are wily and demand a hands-on approach. These thrive on “offline” thinking, gesturing to ourselves, thinking aloud, feeling the texture of paper, and engaged limited interaction modes (🤓).

Previously, taking notes on paper vs. glass:

The sensation & constraint of paper still beats glass. There is something about the resistance, the scratch, of a good pen across a finite sheet of paper. It’s easier for me to write “well” (opinions on my penmanship vary) on paper than on glass; something about the permanence of the ink or that my eyes are considerably higher resolution than glass displays. Filling notebook after notebook over the years and decades is vastly fulfilling in a way digital notes and writing aren’t.

George Saunders, A Swim in a Pond in the Rain:

“What does an artist do, mostly? She tweaks that which she’s already done. There are those moments when we sit before a blank page, but mostly we’re adjusting what’s already there. The writer revises, the painter touches up, the director edits, the musician overdubs.”

I’m filing this one away for future reference when I’m feeling less-productive. Even if the day’s toil was tweaks, edits, rewrites, or failed rewrites, it checks the box.

Austin Kleon, A Few Notes on Daily Blogging:

“With blogging, I’m not so sure it’s about quantity as much as it’s about ​frequency​: for me, there’s something kind of magical about posting once a day. Good things happen. Something small every day leads to something big.”

But also this! Frequency generates as much quality as does quantity. Show up, every day!

At its best, social media is like jazz — there’s an improvisational, multi-player quality to it. Following threads, riffing, and quipping creates a collaborative rhythm all its own. I love that!

Then, add in the “threaded style” of social media writing and thinking. There’s a give-and-take, a call-and-response. Ideas build on each other, it’s even more like jazz.

Sometimes, riffs are refined via “collaborating with the network” to the point they become coherent, standalone ideas. And, like an improvisation becoming a composition unto itself, they become standalone essays. Fantastic.

Related: I miss Layer Tennis.

Related: jazz as cinematic universe.

Within me are two musical opinions, constantly at tension.

😇 “You can make pretty dang good music with only a few, excellent musicians. Sometimes, even pretty dang good and loud music.”

🤵🏻‍♂️ “Look, if you want to make dang good and loud music, you’re gonna need a twenty-person band or a Mahler-sized orchestra, at least. Amplifiers and drum kits are crutches. The true path to volume of sound is volume of performers.”

Henrik Karlsson, Swimming in July:

There is something so frivolous about water. It makes you float like you are in outer space! And no matter what you do—whatever shape you make of yourself—it will instantly fit itself around you!

Water didn’t have to be this good.

You forgot it for years while you lived in the city. But here it is: that one day in July when it storms but the water is lukewarm and you tumble inside the waves. You lose yourself in the sensation of being a body submerged in another body. Your back against the concrete pillar under the pier; the waves cresting, crashing over you—you can do this for hours.

Nothing beats a soak, in a pool or otherwise, in the heat of July (and August).

“Try jumping from the cliff over there,” the guard would say. “And then you shape yourself like a cannonball before you hit the surface.”

Alan Jacobs, The Homebound Symphony:

Station Eleven had the Traveling Symphony: I’m trying to be the Homebound Symphony. Just one person sitting in my study with a computer on my lap, reading and listening and viewing, and recording and sifting and transmitting – sharing the good, the true, and the beautiful, with added commentary. The initial purpose of this work is to repair, not the whole culture, but just my own attention. On a daily basis I retrain my mind to attend to what is worthy. It is the task of a lifetime, especially in an environment which strives constantly to commandeer my attention, to remove it from my control, to make me a passive consumer of what others wish me to look at or listen to.

Take care to monitor your attention, especially regarding social media. It’s easy to get lost in nostalgia and repetitive feedback loops. Make sure that at least some of your influences – be they people, feeds, or algorithms — encourage a forward-looking, forward-thinking mindset. Otherwise, you risk stagnation, cycling through the same thoughts and experiences.

I love when jazz album covers list all the players. Herbie Hancock! Your favorite drummer. A couple of sax players you think are pretty good. A bassist you’ve never heard of!

It’s a bit like Marvel comic book covers: “Iron Man, okay I’m interested. With Thor? Okay that works. Wolverine? And introducing an ‘Ant Man’? Okay what’s going on here – I gotta know!”

Jazz and comic books are more alike than you’d expect. Both revolve around a densely connected cast of characters, epic story arcs, a few cash grabs, and some amazing cross-over events.

I’m dabbling in building, again. I felt the energy of XOXO for nostalgia of a web of the past, making one’s own thing, and indulging in (socially good) weird whilst doing it.

It’s been a while since I built a Rails app from scratch, and I don’t have a big, ambitious business plan to go with. So a blog seems like a fine place to start. 🙃🤷🏻‍♂️

Vibes and observations follow.

Document-style editing in browsers is a reality

I’m tinkering with ProseMirror as an editor. I’m curious what setting a Very High-Quality bar looks like for an individual developer in late 2024. In short, it seems like document-style editing in web browsers (i.e., not Markdown or hobbled “click-to-style” editors) are close to table stakes for high-quality applications. There are many options out there, it’s probably time to get good (at one of them).

The default for new Rails app is to use import maps for managing JavaScript dependencies. However, ProseMirror’s docs assume you’re using a bundler like esbuild. In particular, ProseMirror wants to import stylesheets into scope via JS imports and not CSS @import. AFAICT, importmap doesn’t gracefully bridge this gap. I’d love to be wrong about this!

I considered using TipTap as a wrapper around ProseMirror. A few things put me off:

• I’m generally wary of open source and component systems with a pricing page. I want to build, not decipher plan structures. I’m not opposed to the phenomenon entirely, but I would rather not join the vanguard of using it either.
• I like the idea of going back to less build tooling for JS. But most of these component libraries, TipTap included, are React-centric. I’m not sure how to win here.
• Some component libraries support React and Vue. My understanding is the latter doesn’t always require a build step. Again, I don’t know how to win here.

Data narratives

I like the idea behind Oaken as an object mother/fixtures replacement. In particular:

• Telling stories instead of describing isolated data is a winning pitch.
• Building upon Rails’ idea of seeds and using it for development and testing is worth trying!
• I don’t have any beefs with FactoryBot, but Oaken imposes less syntax and only a slightly different mental model, which seems like progress.

Kasper is building a track record as a Rails developer with a good sense of taste!

I like class-less CSS frameworks

My CSS skills are “barely good enough”. I’d like to master Tailwind or CSS, in an ideal world. I like that idea better than carefully coding up a UI via Swift, in theory. In practice, I’m the ideal audience/user for mvp.css. Write HTML that mostly makes sense, get on with the building. 🤷🏻‍♂️

Markup

I have forgotten so much about using ERB, Rails form helpers, and HTML together. 🤷🏻‍♂️

That’s it, for now.

Founder Mode. The discourse (algorithm) demands we discuss it.

My hot-take: the original article is, honestly, not PG’s best work and is best viewed as a jargon land-grab. That said, pointing to a blank space (fancy word: lacuna) and saying “there’s something missing here, and I have a name for whatever it is” is slightly productive. 🤷🏻‍♂️

I’m a relieved that, so far, the discussion is about execution and thinking. It’s not about power dynamics and executive victimhood (🙄). Excessive org flattening, overloading managers with dozens of reports, and “efficiency” aren’t central to the discussion. Hopefully, those are forgotten trends of late 2022. 🤞🏻

Kent Beck points out that all leadership interventions on work-in-progress, from higher-status individuals in particular, yield a new mindset in which the team/startup operates. Neglect this tradeoff at your own peril. 👍🏻

Rands in Repose focuses on the philosophy that leadership comes from everywhere in a startup. Everyone is accountable for improving the product and company__. The org chart and hierarchy are, to some extent, guidelines and not rules. 💪🏻

My approach to writing on the web in 2024:

• Write (to think, riff, share, or publish) every day.
• Post anything over about one hundred words to my blog. Don’t worry about scheduling, publish when it’s done.
• Every couple weeks, schedule up a bunch of social posts. Some of these are links to the blog posts from the past couple weeks. Many are ideas I haven’t figured out how to turn into longer posts yet.
• Every month or so, roll up all the stuff that went out to socials and blogs in a newsletter.

Robin Sloan, Stock and Flow:

You can tell that I want you to stop and think about stock here. I feel like we all got really good at flow, really fast. But flow is ephemeral, while stock sticks around. Stock is capital. Stock is protein.

And the real magic trick is to put them both together. To keep the ball bouncing with your flow—to maintain that open channel of communication—while you work on some kick-ass stock in the background. Sacrifice neither. The hybrid strategy.

Jim Nielsen, Blog Posts vs. Social Posts:

Generally speaking, the attention you get with a good post on social media is like a firework: it can light up fast and burn bright, but just as fast it disappears.

On the other hand, the attention you get from a good blog posts can be like a forest fire: it starts small but when it catches fire it rages for some time, burning longer and more intense than any firework.

Matt Webb, 15 rules for blogging:

Give up on trying to be popular. I try not to filter myself based on what I believe will be popular. Some of my favourite posts get ignored. Some posts get popular and I have no idea why. Besides, terrible posts get buried fast if I’m posting three times a week. So post with abandon.

Give up on trying to be interesting. Readers will come to my site for what’s interesting to me, or not, it’s fine, just say what I think about whatever I’m thinking about.

If you waste less time, you’ll make more stuff without increasing time outlays.

• Find more leverage, you’ll make more stuff in the same amount of time
• Get better & faster at a task, it will cost less, you can do more of it (see below)
• Figure out where anxiety, dawdling, etc. happen and how to bypass it; less wasted time, more fruitful time

But don’t eliminate waste. Or, deity forbid, margin.

This isn’t about optimization and efficiency. There’s plenty of time to recapture from outright mis-use of time and space.

Nor is it about reducing waste to zero. It’s difficult to tell the difference between waste, play, and escaping local maximums in the moment.

Note to self: next time I’m tempted to get up just a little earlier or stick with work just a little later, ask myself what I did that was obviously a foolish use of resources.

Squeeze shortcomings before squeezing schedules.

James Somer, Speed Matters: Why Working Quickly Is More Important Than It Seems

“The obvious benefit to working quickly is that you’ll finish more stuff per unit time. But there’s more to it than that. If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more." (James Somers, Speed Matters: Why Working Quickly Is More Important Than It Seems)

Dan Luu, Some reasons to work on productivity and velocity:

It’s true that the gains from picking the right problem can be greater than the gains from having better tactical execution because the gains from picking the right problem can be unbounded, but it’s also much easier to improve tactical execution and doing so also helps with picking the right problem because having faster execution lets you experiment more quickly, which helps you find the right problem.

Author’s commentary track: this post started because the title was too great of a rhyme to go to waste. I would say that I did not write this with haste. Probably several weeks passed from writing down the turn of phrase to trying to make this a short post suitable for social media to deciding it was really a blog post and wrapping it up.

Recently, I found myself in need of a contact form for my website. Luckily, I didn’t let myself fall to the temptation of rolling my own! 🙃

My good enough pals at Good Enough have built a modest little app just for this occasion, Letterbird. It was super easy to sign up, set up my form, and embed it on my website. It does the one thing nicely and is delightful to use.

I can’t emphasize this enough: it does the one thing and is delightful. It didn’t immediately encourage me to onboard my team, click through a guided tour, or immediately ask me to consider the generous discount of signing up for twelve months instead of one month.

I just used the thing, solved my problem, and kept going. Recommended!

Unrelated: I had to work really hard to write this so it doesn’t sound entirely like a podcast ad read. 🙃

Commonly shared/held wisdom: leadership is flowing decisions down and information up. What if this is (slightly) untrue? Or at least, in need of contextualizing.

Strategy, direction, and context are set by leadership teams based on intuitions, abstractions, and trailing and leading numbers.

The bottom of the org chart has a far better idea of how to get things done than the top. And possibly, what to get done such that customers can succeed. This information _should_be passed up, but it’s not not decision-making.

Seems to me there’s a disconnect and opportunity here for tactics to meet strategy. When things are going well, decisions are guided and informed, but rarely does the middle layer take decisions on its own, instead delegating to the team or below or leadership above. When ambiguity is ascendent and clarity or confidence wane, decisions could flow down.

Contrary: information up, context down is the central conceptual model of middle management. The Fundamental Purpose of Middle Management: Context Down, Information Up:

This brings us back to the fundamental job of middle management: push context down, and information up. The job of a middle manager is to gather as much information from your reports as possible, synthesize it, and pass it up to their manager. At the same time, they should be collecting as much context from their management chain and peers, and passing that important context back down the chain. If you’re a middle manager this should be your guiding principle.

Context-down should provide a coherent backdrop for whatever steering of execution a manager does.

Garrett Dimon, Organizing Rails Code with ActiveRecord Associated Objects:

At the simplest level, associated objects come in handy mostly by helping organize and compartmentalize related logic so we can better avoid the junk drawer or God object “patterns.” But that’s an over-simplification because the benefits can be almost invisible–it just disappears into the background and does its job.

Associated objects have an excellent effort-to-benefit ratio. The implementation is less than a few hundred lines of code. The docs, which fit entirely in the readme, may outweigh the actual code! From that, you get a multipurpose and surprisingly deep tool for designing and modeling your system.

I’m excited to tinker more with this one.

Nat Bennett, How to write:

• Write a lot
• Just Write
• Read a lot
• Write every day
• Walk
• Have a time and a place for writing
• Take it less seriously
• Have an audience

At least as good as any advice I’ve ever given!

There’s lots of reasons that this works but I personally believe that writing is a mechanical skill as much as it is a mental one. Sometimes you just need to run a bunch of words through your writing engine — practice the whole process, from forming a sentence in your brain down to driving the motion of your fingers — to reduce the friction to a point where you can do “real” writing.

As above for writing, so goes for any iterative, world-building creative activity. p.s. coding is an iterative activity wherein a world of thought-stuff is created (and sometimes checked against a computer by executing it and seeing if it all blows up.)

Ben Kuhn, Categories of leadership on technical teams:

More importantly, though, we often want to somehow split these responsibilities between people. Team leadership covers a huge array of things—as you can see from how long this post is—and trying to find someone who can be great at all of them is often a unicorn hunt. Even if you do find someone good-enough at all of them, they usually spike in 1-2 areas, and it might be higher-leverage for them to fully focus on those.

If you find yourself in a wholly new team, this might help you find your way to traction. If you find yourself confused by the (rapidly) changing nature of work and need to zoom out on the team/role you find yourself leading, this will help!

Even if you’ve been in your job/team/organization for a while, to paraphrase David Byrne, “You may tell yourself, this is not the job I signed up for! / My god, have I have I done?”, in which case this mental model is also helpful. (And, good luck!)

Herein, a napkin sketch on producing creative work, ideas on finding the spark(s) that consistently lead us to assemble new things, and the hand-wavy stuff in-between.

Production is connecting the dots

Extensively, manically, collect ideas (i.e., dots). Collect ideas, put ‘em in order. This is the tricky-but-fun part!

Boom, that’s something new! Like this essay. Collect, connect, write, post, again and again.

Austin Kleon, It’s not inside you trying to get out, it’s outside you trying to get in:

I never feel like I have a book in me. I always feel like there’s a book around me. It’s like I’m a planet and there’s all this space junk orbiting me, and all the junk starts smashing together and forming book chapters. My job is to grab that stuff around me and shape it into something.

Production is making social connections

So you’ve got a routine of journals and notes and active reading and such. You’re turning those into blog posts and thinking with the network, right?

In particular, using networked writing (hypertext, social media) as an attractor for ideas and likeminded folks. Repeatedly engaging with those folks until a new, boring status quo/local maximum is reached. Iterate and seek ever higher peaks.

Tom Critchlow, Small b blogging:

Small b blogging is learning to write and think with the network. Small b blogging is writing content designed for small deliberate audiences and showing it to them. Small b blogging is deliberately chasing interesting ideas over pageviews and scale. An attempt at genuine connection vs the gloss and polish and mass market of most “content marketing”.

Henrik Karlsson, A blog post is a very long and complex search query to find fascinating people and make them route interesting stuff to your inbox:

The reason I’m spelling out this dynamic is twofold. First, you can get out of this mess if you want to. You do that by writing online (or publishing cool pieces of software, or videos, or whatever makes you tickle—as long as you work in public). Second, if you want to get out of the mess the key lies exactly in understanding that you are not the only person who has no one to talk to about the things you get obsessed by.

Production is a second-order outcome from consuming/reading

Consider two sorts of people: “Really Into Notes” or simply “An Enjoyer of Reading”. Either way, making things and ideas comes from connecting an idea from what you read, enthusiasm for making, and the discipline to turn that enthusiasm into action. How and what you turn that action into is left as an exercise or implementation detail up to the reader.

Andreas Fragner, Writing Summaries Is More Important Than Reading More Books, if you’re a third kind, “Extremely Okay With Marking Up Your Objects”:

One thing I’ve learned over time is to read fewer books but to take the time to write summaries for the good ones. The ROI of spending 2h writing a synopsis is much higher than spending those 2h powering through the next book on your list. Reading is not about page count or speed [1]. What matters is how it changes your thinking and what you take away from it. Optimize for comprehension, not volume."

Production is doing the thing you can’t not do, a vocation

Maybe it’s writing, but it’s cool if it’s not. Putting all these ideas together yields something new in the world, literal creativity. That calling, no matter the ambition or profitability or fruitfulness, is different for all of us. But we can all work the skills that support that creation.

Jared Henderson, AI won’t replace you, unless you let it:

Similarly, there are men and women for whom being an artist if their vocation. It is what they most suited to do. I believe that determining and pursuing your vocation – even if your vocation is not your job – is crucial for a good human life, because it puts work in its proper place. Work ceases to be toil when you are pursuing your vocation.

Tools for thought are nothing without producing ideas and publishing them.

It’s been so long since we spoke, /now-page aficionados.

I’ve been moving to Portland, buying a house therein, and selling a house in a bizarre hyperlocal real estate situation. Some of these I have a lot of control over, some I am frustratingly very much in the passenger seat on.

I’m still leading engineering teams holistically, acting true to “we can go further together than we can alone”, and writing about it (more for myself than others than I’d like).

Some days, I’m just trying to ignore the recursive news screwball that is 2024.

Actually, baseball is a fair metaphor here. It’s curveballs all the way down. I’m fouling off most of them, though. 🤷🏻‍♂️

There are things you can only learn by negative experience. In these cases, you just gotta go out there and suffer:

• Lose your first 50 games as soon as possible (Go proverb)
• Struggle through your first 50 interviews (hiring or seeking)
• Awkwardly run your first 50 meetings
• Flail at leading your first 50 projects
• Bomb your first 50 jokes

I won’t keep you waiting or give you false confidence with a snappy conclusion. Get out there and make some mistakes!

Robert Fripp via Austin Kleon, The Meaning of Discipline:

The musician has three instruments: the hands, the head, and the heart, and each has its own discipline.

So, the musician has three disciplines: the disciplines of the hands, the head and the heart.

Ultimately, these are one discipline: discipline.

Bear with me as I try to apply this lively metaphor of emotion and musical creativity to dry-and-boring engineering leadership¹.

The leader’s hands gesticulate, often for the aid of the speaker more than the listener. Sometimes, the hands conduct the thoughts to written words through the keyboard. Not too dissimilar from a musician’s hands through which, crucial for (most) musicians to make their sound, but equally a bit of flair.

The head thinks, and overthinks. Sees patterns and connects the dots. Listens to what people say and answers their questions directly and honestly. Is convinced it sees patterns in randomness, or that folks are hearing and understanding a message that they find confusing but don’t know how to address the issue.

The heart, for the leader, is there to mediate the head. There are other people on the other side of the decisions and decrees leaders make. A process or strategy is only good if it does right by those carrying it out.

Discipline is our capacity to make a commitment in time.

Discipline, in leadership, is to make a decision and then support the people executing that decision. All the while, seeking new information by which you might update, revise, or set the decision aside, if necessary.

To have sitzfleisch means the ability to sit still for the long periods of time required to be truly productive; it means the stamina to work through a difficult situation and see a project through to the end.

✋🏻 management by walking around

👉🏻 leadership by sitting down² and engaging with the people doing the work

Even better: leadership by sustaining long period of assimilating what the team and meetings are telling you into a slightly better way of working. And sometimes, memos and slides, etc to send out and socialize ideas for you.

Mike Hoye, Fifty Years of Diff:

My friend Greg Wilson has argued, and I absolutely believe, that you can divide the entire computational universe into who has diff and patch, and who doesn’t. It’s the seed crystal of all workable open collaboration, and people living without it don’t even have the language to recognize how bad they’ve got it.

Re:re:RE:DRAFT-draft-V7-FINAL-FINAL2.doc is just no way to live, and if you live in word processors, spreadsheets, slides, art, anything without diff and patch you’re definitely feeling this pain, even if you don’t have a term for it.

Yep. diff, along with its trusty companion patch is a developer superpower. (Even though patch came 10 years later, apparently, TIL.)

diff made source control possible, so I have to think it’s in the top 5 accelerants to software development of all time¹. Let alone using diff or patch under the hood in systems to move changes around.

Even the concept of diff is a big deal!

Part of the superpower of being a developer is the idea that you can analyze two pieces of data with a common lineage, extract the changes, and work with/reason about the changes as first-class data. Were it only that more non-developer tools had this capability!

Writing from notes is a bootstrapping problem. Anything you can do to get started, overcome static friction, and “defeat” the first blank canvas is the best thing you can do.

I started with journaling. Don’t worry about the quality or quantity — yet. Just write. Start with recollections of your day(s) and branch out from there.

There is a trough of despair, at some point. It may feel like you’re just writing into a void. Don’t reach for a “crushing your notes” course on YouTube. You’re writing now, it’s not unusual for it to take a moment (days, even weeks) to click.

Next, I started reading actively and taking highlights. Tools don’t matter here. The outcomes you’re looking for are 1) getting more out of the reading than if you didn’t mark the passages that grab you, 2) coming back to the good stuff later. It’s nice that highlighting, even on mouse-and-keyboard computers, gets your hands moving and involved in the reading process.

Once I crested about a hundred notes/journals/highlights/etc., the next level was resurfacing past notes and revisiting/rewriting/reworking. I use random resurfacing of notes¹, “on-this-day” resurfacing of journals², and spaced repetition of highlights via Readwise. These generate insight, nostalgia, and (sometimes) the spark to connect the dots of enough ideas that a new draft comes into existence. That’s a big win! Honestly, even writing up a new note connecting some older notes or highlights feels like the system is working _for _me.

On a great day, the combination of resurfacing mechanisms and a bit of luck leads “a perfect post”. That is, one that connects old insights to new ideas, a quote that backs up the new insight, and a recently generated idea that ties it all together delightfully³.

Now I had a compounding loop of making new stuff (journals) and revisiting old stuff (highlights). Time to look for connections between them, and notice how the quality of the more recent stuff is improving over the older stuff. The temptation, particularly in a world of influencer media on note-taking⁴, is to get a Big System to Lead You Right To The Big Connections in Your Thoughts. You don’t need that, you’ve got one sizzling away in your noggin, right now.

The revisiting and revising and rewriting is how you end up making the connections. The last generic tool I’ll recommend here is a good-old blog. For me, the insights and connections first came to me in short form, link posts and asides⁵ if you will. Over time, my insights grew into a ton of notes, journals, and some short-to-medium length⁶ writing on this blog.

In other words, what you require is not just a blog, but a blogging habit. Not just a journal, but a journaling habit. Not just the desire to connect the dots, see your ideas compound, and point proudly at a volume of work, but the habit to make all those things happen.

Possible next levels in my process, use the blog:

• as an iterative series of first drafts (see 15 rules for blogging) and
• as a way to figure out _what I think_by writing my way through it.
• worrying less about writing down what I already know⁷

Slash pages:

…are common pages you can add to your website, usually with a standard, root-level slug like /now, /about, or /uses. They tend to describe the individual behind the site and are distinguishing characteristics of the IndieWeb.

This sort of thing is what makes personal/humane-scale websites the greatest. So many adventures to choose from!

My favorites, already in place here:

• /about – “a page all about you”
• /blogroll – “a list of other sites that you read, are a follower of, or recommend”

And the ones I need to get off my butt and implement:

• /uses – “details of the things you use on a daily basis”
• /colophon – “a page that describes how the site is made, with what tools, supporting what technologies”
• /hello – “a single page listing the ways that you prefer to keep in touch”
• /now – “a page that tells you what this person is focused on at this point in their life”

Adjacent: Microfeatures I Love in Blogs and Personal Websites.

Steph Ango, Style is consistent constraint:

“Collect constraints you enjoy. Unusual constraints make things more fun. You can always change them later. This is your style, after all. It’s not a life commitment, it’s just the way you do things. For now.

Your constraints generate your style. 🧠

Yet again, the grass was not greener. I did learn a little more of simplicity-by-reduction. I asked myself, what Obsidian plugins or idioms am I using because someone else seemed to benefit a lot from it? Then I stopped using the ones that weren’t actually doing much for me. 💪🏻

I don’t need daily notes. That’s for the journal, which happens elsewhere. Daily notes might actually make my note-writing worse because I’m not above a perfunctory streak-preserving note.

It might even be the case that Muse is the right connecting-the-dots notes tool for me and Obsidian is more like a long-term development tool for preserving, archiving, and evolving ideas. 🧠

One of Obsidian’s advantages is the data is not opaque, its files in folders. I should use Finder more! It’s very good for dragging files around and considering organizational hierarchies. 🤷🏻‍♂️

I thought just buying Bear (it’s not expensive!) would cut the envy knot. It sorta did, so that was nice for about a day. Then, almost immediately afterward, I caught word that Obsidian’s previously-vague “mobile improvements roadmap” turned out to be “improved load-time” which is half of what I wanted. Timing is everything, folks! That said, native macOS/iOS apps are just excellent and I hope the Obsidian developers can close that gap.

As far as how to use Obsidian without getting nerd sniped: Tom MacWright and Matt Stein have the right idea. At least, not too nerd sniped. 🤦🏻‍♂️

Should internal narratives, and the philosophies they generate, be among the guarded proprietary info within a company¹? The stories the company tells the outside world are more about marketing and serving a purpose. Not those stories.

In particular, the stories the company tells itself to generate the culture and conditions for its success (or not). How it really happened, and what does that mean for where the company is now? They’re not exactly running to the press to tell the story².

Te scar tissue, what caused it, how that’s reflected in the process today? That’s guarded info, not eagerly shared in blog posts and conference talks. At least, not the entire truth.

Granted, many stories are used for building an image and marketing. To investors, competitors, potential hires, professional communities, etc. Or even to help teams internalize the purpose and goal of what they’re building today.

There’s a term for the people who’ve been around to witness these events and craft these stories — the old guard. They’re almost literally guarding the stories or narrative, but also guarding the way of working that made those stories a success.

These stories are often divorced from the reality of how the much bigger company now operates!

Narrative is powerful. Makes sense to guard it³. Both for alignment, but also for preserving myths that hold that purpose up. Myths that come from true stories. Myths that were constructed/embellished for marketing or aiming throughout the company’s existence.

Tall tales and fables by the campfire: now for corporations, too!

Thorsten Ball with a great reference to Comedians in Cars Getting Coffee. Be findable:

You’re in your apartment watching TV, and they knock on the door, like “Jerry, I’m Dave Addison from the Show Business Commission. We understand you got enormous talent and tremendous potential and you don’t know what to do with it, and there’s really no bridge or no other conduit which will carry you over to the next level, which is why we’re here. We’re the Show Business Commission. We’re here to sort of collect you up.”

No one is going to discover your work spontaneously. Making your work discoverable is part of the work. It’s not bragging or obnoxious. Unless you’re habitually obnoxious, in which case a little self-promotion is the least of your problems!

100 Tips for a Better Life:

95. Some types of sophistication won’t make you enjoy the object more, they’ll make you enjoy it less. For example, wine snobs don’t enjoy wine twice as much as you, they’re more keenly aware of how most wine isn’t good enough. Avoid sophistication that diminishes your enjoyment.

Teaching someone the depth to something like cars or pens or literature is a gift and a curse. On one hand, you’re showing them a new, deeper world that they might really enjoy and find fulfillment in. On the other, they might realize something like “a true classic Porsche 911” is out of reach or that the pen they like is kinda middle-ground or that their favorite sci-fi author is kinda schlocky.

Maybe the gift is “this is amazing, but it’s a bit of a forbidden-knowledge hazard to know you could have this thing.”

The classic knowledge hazard for me, is One car to do it all. If that video hadn’t re-awoken my excitement for Porsches I would have a much more boring car, a lot more time back in my life, and mid-five figures of money spent otherwise. But maybe I’d have missed out on a fun hobby. 🤷🏻‍♂️

Riffing on this idea:

“If you want to upset a person for a day, tell them their car sucks. If you want to upset them for life, show them how to appreciate the automotive experience in a way that they will plumb the depths of for the rest of their days.”

“If you want to upset a person for a day, tell them their taste in music sucks. If you want to upset them for life, show them the first step in the journey to seek out and appreciate the depths of really great music despite the knowledge that the most popular music is an entertainment business and will never reach the levels which you aspire to.”

Enjoy things, seek out the finer details of what makes them nice. Not too much. Mostly things that don’t cost more than your monthly mortgage/rent.

Previously:

The only way to finish writing, planning, coding, designing, etc. is to do the thing.

Rarely will new tools, larger scope, a different approach, another section, more tidy, or any other number of not doing the thing finish the job.

Finishing is the skill. Finishing is The Way.

Conjecture: the last 90% of a project is 90% of the effort because we rarely develop the skill of finishing.

It’s easy to think “this project was doomed from the start, let’s start a new project to right our mistakes”, and boom you’re starting instead of finishing.

Finishing may incur damage to pride, reputation, etc. OTOH building a reputation for finishing is a tremendous asset in teams and careers.

You probably haven’t heard of many people who didn’t finish their thing.

Schubert had to write nine symphonies so he could write “The Unfinished” Symphony and have it live on hundreds of years later. Is there a writer who is only known for one unfinished novel or screenplay?

Starting a new thing is more fun than finishing an existing thing. This is always the temptation! The interesting things in a project usually happen when you’re starting and when you’re getting feedback from people interacting with it. The finishing phase is often the “canyon of disillusionment” where all the mundane or tedious tasks end up.

Updating another earlier thought:

✋ We’re not here to work on things.

👉 We’re here to finish things.

Corollary: we’re not here to push JIRA issues/Trello cards/etc. around. We’re here to make something and share it with the world.

Don’t neglect those issues/card¹. Finishing is important, but communicating that progress counts for a lot too! There’s no sense in finishing if no one else knows.

Austin Kleon, A few notes on daily blogging:

With blogging, I’m not so sure it’s about quantity as much as it’s about frequency: for me, there’s something kind of magical about posting once a day. Good things happen. Something small every day leads to something big.

Maybe it’s not so much quantity that builds the quality, but frequency and consistency.

The traditional prescription for keeping software easy to work with and amenable to change is “refactoring”. As we’re fixing bugs, adding features, and making new possibilities, we investigate how to change the structure of code so that correcting, changing, or adding behavior is easier. In reverse order — we should make the change easy, then make the easy change to achieve the desired results¹.

I may not surprise you in suggesting that’s often not how things actually work out.

Some code, processes, or data are inherently complex or crystalized in path dependence. After our first urge to simplify is stymied, move on to the second possibility: live with and document the complexity, then keep moving². Everyone wins.

Documenting code is a great forcing function for simplifying it. When I look at code with the intent of writing down how to use or understand it, my perspective shifts, and I’m more aware of the missing affordances. A clarifying parameter name or perhaps a simpler calling sequence. So I make that change (aka refactoring) as part of the process of documenting the code. Everyone wins.

The same goes for processes and data. Writing down how to fix an unprocessed payment or restore data after an accidental deletion flips my perspective enough that I’m not seeing it in the weeds. I can see opportunities for automation, so I take them. Or I can see how to improve a data structure such that errors are obvious to humans or detectable by computers. I make that change, everyone wins.

It’s not always possible to find these little wins. Occasionally, we don’t win!

Some systems, especially the older and critical ones, resist change. The volume of data may be the resistance to change, the process may touch too many people to casually change, the risk of updating code may be too great. If you’ve worked on a billing system, I bet you’re hallucinating memories of it at the mere mention of data, process, people, and code resisting even the smallest change in course.

In that case, the next best way to improve the situation is to improve everyone’s knowledge of the system by writing it down. Document how it works. Even better, elaborate on how it’s supposed to work and how it actually works in some important but problematic circumstances.

Go from tricky code to refactoring. If you’re stymied by refactoring, switch to documenting it instead. Everyone wins.

Alan Jacobs, the attention cottage (Via Austin Kleon). I was not expecting to quote an attention metaphor involving the cardiovascular system and cottages, and yet:

To care only for things temporal is to lose the things eternal; but to attend rightly to things eternal is the royal road to constructive thought and action in the temporal realm. The great artists and thinkers cultivate a systolic/diastolic rhythm, tension and release, an increase and then decrease of pressure. In the latter phase they withdraw, by whatever means available to them, to their attentional cottage for refreshment and clarification — and then they can return to the pressures of the moment more effectively, and in ways non-destructive to them and to others.

But most of us, I think, get the rhythm wrong: we spend the great majority of our time in systolic mode — contracted, tensed — and only rarely enter the relaxed diastolic phase. Or, to change the metaphor: We think we should be living in the chaotic, cacophanous megalopolis and retreat to our cottage only in desperate circumstances. But the reverse is true: our attention cottage should be our home, our secure base, the place from which we set out on our adventures in contemporaneity and to which we always make our nostos.

I often think how much easier, how much more naturally healthy, life was even just a couple of decades ago, when the internet was in one room of the house, when the whole family had one computer connected to a modem that was connected to a landline, and movies arrived in the mailbox in red envelopes.

I love a cottage/workshop/garage metaphor. Doubly so when they recall a time when distraction had yet to pervade our homes and lives.

The past is gone, we’re not going back to Netflix DVD mailers. So how do we carry the idea of inhale/exhale and space forward? I’m trying a few things currently ¹:

Minimize apps with an adversarial agenda. Currently: YouTube is only on my iPad, but the intent is I mostly watch via AppleTV. Twitter, Ivory, and Instagram are only on my phone. Reading apps (Books, Kindle, Reader, Reeder) are on all my devices. In other words, the apps aligned with my goals (read more of what I choose, think bigger thoughts) are everywhere and the ones that want to direct my attention to advertisements (mostly) are only present where my attention is (probably) already scattered.

Hold devices to a purpose. The intent here is that I’m holding my iPad largely for reading, focus, and writing. My laptop is largely for writing, publishing, and collaboration. The Kindle is, obviously focused on reading alone, despite the predations of Amazon into all possible revenue streams elsewhere.

Treat the transition to focus with reverence, if not physical space. When I’m reading or writing, I try to keep my phone out-of-reach. If not in another room. My laptop sits in a (part of the) room where I’m only focused on writing, ideas, publishing, or keeping those things operating smoothly. Whether I’m in my home office or making do on a roadtrip, this is the attention cottage Jacobs mentions above.

It’s not quite as quaint as an actual cottage. But, it does an okay job balancing the pastoral with the modern.

It’s the only way to survive as an engineering leader.

1. Hand off tasks/work to the team
2. Give guidelines, execution tactics, or constraints to keep things on track
3. Set an expectation of what to deliver and when
4. Get out of the way

Delegate not only the main/critical path work, but also “the toys” and interesting/exciting work. Give away your toys.

Even more difficult: don’t tell someone how to do it. Give context (“why”) and constraints. A few style guides perhaps (i.e., codified influence!). But, work with the team to develop the style guide, raise the standard, and enforce the standard. Provide constraints that keep them on track and/or reduce the problem space.

Leadership is about executing through other people. To some extent, that means influencing your team to do the right work efficiently and effectively. That’s delegation in a nutshell.

“In the beginner’s mind, there are many possibilities. In the expert’s mind, there are few.”

— Shunryo Suzuki

The trick being, how can an expert help a beginner, given they know all the false paths. And how can the expert encourage the beginner to help them find new ideas, knowing all the paths they’ve followed in the past?

The distinguishing quality of beginner-ness is that every rock turned over has something surprising or interesting under it. It’s all rabbit holes to fall down or rakes to step on.

When there are no time constraints present, it’s fine to explore these ideas, some of which may not be fruitful. Or, to figure out exactly why the result was surprising and not intended.

When time is of the essence, being a beginner is sometimes pretty dang stressful. Doubly so when the path to productivity is littered with novelty.

Ergo, Make Failure A (Safe) Option.

I feel lucky that I was able to learn a lot about software development in high school and college. Mostly, self-directed; I used Linux during college, spent a lot of time compiling Enlightenment and tinkering with up-and-coming languages you may have heard of, namely Python and Ruby (and to some extent, Lisp and ML).

Beginners today are thrown straight into narrowly guided tutorials and online courses. Then they’re dropped into the wilds of innumerable Unix minutiae, source control, relational databases, multi-paradigm programming languages, styling in browsers, and agile methods. I realized I was firmly in the “expert developer” camp when I could spot all the rabbit holes and rakes-in-leaves three moves ahead. I deftly maneuvered in the dark, knowing by feel where the potential problems were and how to avoid them.

It’s difficult to impart that knowledge to beginners. It’s not principles, it’s compounded experience. Worse, beginners find themselves amidst a hustle culture of “ship a side project alongside your day job and somehow do that whilst traveling the world”. Or, become a “content creator”. Most importantly, I knew a side-hustle and creator¹ lifestyle were not for me.

I’m certain beginners can help me find new and interesting angles. But it’s difficult to thread the needle between listening for insight and skipping ahead to what I know will work. It’s tempting to say, “I see where you’re going, but there are hazards ahead and here’s all the ways your approach could stymy us.” For one, failing is a pretty dang effective way to learn! For another, “don’t do that, I’ll tell you why later” is a pretty lousy way to acquire knowledge.

One lesson I’ve learned from beginners is that probably we should design systems without reliance on understanding the full depth and breadth of the computing world. Folks don’t have the time or energy to get Very Good at ./configure; make; make install² like I did in college.

Beginners are pretty good at working incrementally. They have to, lest they get lost in all the stepping on rakes and learning of minute! Many experienced developers have forgotten how to build incrementally. They glimpse the glass castles in the sky and plow ahead to realizing them, only to find themselves stepping on different kinds of rakes hidden in the leaves.

Expert mistake number one: try to skip past all the beginner’s insights. That is, the beginner’s mind.

Teammates new to software development and new teammates on the team, accidentally or intentionally, can both reveal useful information about your team, process, and software. Information that is otherwise difficult to come by. There are things everyone is accustomed, and thus blind, to that a beginner can tell you straight away.

I have to remind myself that this is a critical moment. Don’t skip straight to “onboarding them onto the team’s culture” by explaining the history and the why-or-why-not. I should listen to the insight, evaluate the idea, and bias to act on it if I can.

A group of experts can make great things. But a group of experts with a beginner alongside can assimilate new ideas and make great and interesting things.

See also:

• Austin Kleon, Show Your Work
• James Clear, This Zen Concept Will Help You Stop Being a Slave to Old Beliefs 

I’m trying to change up my blogging style: write without telling people what to do. Show, don’t tell. It’s a stronger writing position to take. It’s the difference between writing social media “content” and writing from a place of earnestness/honesty.

• Advocate by telling a compelling story.
• Motivate by strength of logic alone.
• Change minds by revealing an obvious truth that was once obscured.
• No shortcuts.

The way I read him, Kurt Vonnegut (might) want it that way. Who knows, he can’t tell us now!

“Try harder” is the worst kind of plan. It’s basically not a plan, a small resistance to planning. An anti-plan that signals virtue but instead reflects shallow thinking.

Don’t say “try harder”.

“Try harder” implies that folks haven’t been working hard enough. It leaves the door open to come up short again, for all the same reasons, with little to show for it.

It assumes folks can throw themselves at a project/problem/task even harder without consequences, like exhaustion, burnout, diminished performance, letting important part of their lives suffer, etc. Not only that, but it’s a terminating thought, the kind of thing you can say, and few people will say “well no, we can do better than that” and end up not solving any underlying issues.

“Try harder” is trying to avoid a tough question: why did I/we come up short last time? “Try harder” is resignation to learning nothing and plowing head-down anyway.

Try harder is literally working harder, not smarter. I highly recommend the latter.

Two prolific, internet-known travelers:

• Craig Mod: writer, walker, photographer, software-adjacent
• Brock Keen: photographer, car camper, road-tripper, Porsche-enthusiast

These gentlemen are particularly good at two things that I am not: getting outside and unplugged, and photography. (Also: walking and camping.) From the outside, their projected life/identity seems like a vacation¹. In particular, they take quite different sort of vacations than I do: not Disneyland nor dog agility-adjacent.

They go out into the world, force a little disconnection. Setting aside this is part of their thing, they are separate from whatever knowledge work they might do.

I often want to better disconnect from my knowledge work, even for a couple of hours each night. And, it occurs to me that I can achieve that on any particular kind of vacation. A trip to a Disney resort is a fine opportunity to shift my mind to the present and to my intellectual/reading/writing interests².

Disengagement en route to thinking

Mod and Keen generate a desire to think by converting walking/driving mileage into boredom and then, alchemy!, better thoughts.

Maybe our generally less-stimulated existences, before pervasive computing and social media, correlate with thinking better thoughts. i.e., does it require some kind of disengagement to be a Great Thinker in the age of pervasive networking and computing?

Keen is not specifically about thinking, whereas Mod is thinking adjacent. Possibly, more about disengagement. Yet, something about it makes me think I could do better thoughts in something like that existence.

Disengagement as precondition to creativity

What if some degree of disengagement is already table stakes? Not disengagement like Waldenponding. More like returning to a clear mind and thinking one’s own thoughts. Like, you have to say no to all the distractions that you said yes to in the first place (whether accidentally over optimistically) to do a great thing/thought. Jenny O’Dell has written the book on this, recommended.

Vacation is a tool for disconnection and disengagement adjacency

I wrote A Vacation is a Tool For Disconnecting amidst a few weeks wherein we vacationed in Disneyland and stayed in a friend’s RV at a public park while Courtney did dog agility. Despite this not being the most disconnected (I was, in fact, very connected) or disengaged (Disneyland is quite stimulating), my mind reached a good place.

I wasn’t dwelling on things. I could stop thinking about work once as soon as it snuck into my thoughts. I enjoyed quiet moments and didn’t rush to fill them with distractions. I photographed and journaled and jotted down ideas on the spot and posted photos to blogs. It was pretty dang good.

But I still found myself sitting there, half-writing and half-journaling, sort of feeling like I’m not prolific enough, even on vacation/disconnection. So maybe disconnection/disengagement isn’t the central thing. Or, ambition and aspiration are orthogonal to personal/work life splits and balances and how they manifest as some degree of “going offline”.

Possibly, if I were on a road trip or walking or in nature or disengaged or whatever, I would find this feeling/vibe anyway. Is that the disengagement or disconnection talking?

Anne-Laure Le Cunff, 4 science-backed ways to build your own mental gym:

Building mental strength is not too different from building physical strength. It’s all about consistency. The same way you would take a few minutes to do a few push ups, you can incorporate mental pushups in your daily routine.

Be curious:

The last one is extremely powerful. Multiple research studies show the positive impact teaching someone else has on the comprehension and recall of any material.

Get creative:

There is evidence that practicing activities such as music, drawing, arts and crafts stimulate our brain in a way that enhances our health and well-being. These activities also have a positive impact on our emotional resilience.

Be mindful:

Choose a topic. It should be personal, emotional, and important to you. Write for yourself. Do not imagine your writing being read by other people. Let go. Don’t worry about style, spelling, punctuation, or grammar.

Get some rest:

A great way to combine short breaks and sleep are, of course… Naps! If you’re fortunate enough to work in an environment where taking a nap during the day is possible, do take that opportunity.

I can’t overstate how good naps are. Second only to easy access to comfort from a dog, naps are the best of work-from-home benefits.

Is a personal blog or general-purpose more like a small shop or your local garage?

They’re a bit of a calm business.

A corner store with a friendly owner/operator. Never grows beyond its means. Operates at relatively-human scale. Greet every customer, have a nice conversation, send them away with something interesting. Aims for an infinite game, not limitless growth. It may not ever turn a profit, but that’s okay; neither do most restaurants or start-ups.

A good neighborhood store might make me think, “I wonder if Sam has anything interest in stock this week?” A good blog should make me hope Sam has new posts, with confidence that they’re probably pretty good.

But, a personal web space is a bit of a sports car in a workshop too.

It’s meant to enjoy, for driving. But also for nostalgia, for looking and remembering. Showing it off is important! It’s not quite as good as what you could go out and buy new, but that’s most of the charm. Working on it is part of the fun, but often a source of frustration and expense.

An interesting garage might make me think, “Hey I wonder what car Hank is working on this week?” A good blog makes me think, Hank’s site is so fascinating, I should go talk to him about it or make my own.

A lovely thing, personal websites are!

Matt Stein, How I Use Obsidian:

It’s also just a heap of Markdown I’ve carried around and put Obsidian in charge of sometime late in 2021. Those plain text files are mine and they don’t need Obsidian to be useful; I can open the same folder with iA Writer or Sublime Text and get right to work.

This is The Way to think about notes apps. Not a principle or lifestyle, but a layer of leverage over a big bucket of text.

Don’t fret if it starts off as an unimpressive pile of ideas or an overwhelming and unorganized collection of disconnected ideas. Use tools to organize and resurface the ideas, but don’t let that be the end goal. The end goal is to think better thoughts!

My recent experience with GitHub Copilot Chat (non-autocomplete assistance) and Raycast’s ChatGPT-3.5 integrations lead me to think that prompting will be a crucial skill for most knowledge workers. (I’m hardly the first person to this observation!) Not quite so obtusely as using a Unix shell and command-line programs is for programmers. But, still a thing one will want to know how to get the most out of.

A few examples:

• Talking/prompting a model into doing permutations and set math. This one is still blowing my mind a little. How does a word predictor do symbolic math? Not so much a stochastic parrot in this case!
• Coaching a model to write like me, provide useful feedback, and not use the boring/hype-y voice of Twitter or whatever a model was trained on. Hitting “regenerate” a few times to get options on different prose to include. Using the model as an always-available writing partner. In particular for “help me keep going/writing here…”.
• Building up programs from scratch with the assistance of a Copilot. Incrementally improving. Asking it for references on how to understand the library in question. Asking it for ideas on how to troubleshoot the program. I’ve used this to generate the boilerplate to get started with CodeMirror, with some success.

Elsewhere

Simon Willison, Building and testing C extensions for SQLite with ChatGPT Code Interpreter:

One of the infuriating things about working with ChatGPT Code Interpreter is that it often denies abilities that you know it has.

A non-trivial share of the prompting here is to remind ChatGPT “this is C and gcc, you know this”. I am not sure whether to eye-roll or laugh. Maybe part of the system prompt is “occasionally, you’ll require a little extra encouragement, just like a less-experienced human.” Simon did manage to give ChatGPT enough courage to build the extension, though!

Despite needing to encourage the thing, this bit is promising:

Here’s the thing I enjoy most about using Code Interpreter for these kinds of prototypes: since the prompts are short, and there’s usually a delay of 30s+ between each prompt while it does its thing, I can do the whole thing on my phone while doing other things.

In this particular case I started out in bed, then got up, fed the dog, made coffee and pottered around the house for a bit—occasionally glancing back at my screen and poking it in a new direction with another prompt.

This almost doesn’t count as a project at all. It began as mild curiosity, and I only started taking it seriously when it became apparent that it was likely to produce a working result.

I only switched to my laptop right at the end, to try out the macOS compilation steps.

Ilia Choly, Semgrep: AutoFixes using LLMs:

Although the built-in autofix feature is powerful, it’s limited to simple AST transforms. I’m currently exploring the idea of fixing semgrep matches using a Large Language Model (LLM). More specifically, each match is individually fed into the LLM and replaced with the response. To make this possible, I’ve created a tool called semgrepx, which can be thought of as xargs for semgrep. I then use semgrepx to rewrite the matches using the fantastic llm tool.

I’ve yet to land a big automated refactoring generated solely by abstract syntax tree-powered refactoring tools. By extension, I definitely haven’t tried marrying AST-based mass refactoring with an LLM. But it sounds neat!

The ability to focus on one concern at a time is the mark of a senior developer. It takes experience to ignore other factors as noise. It takes time to learn how to avoid tripping on distractions and side-quests.

Ben Nadel, Only Solve One Problem at a Time:

This lesson hits me hard in the feels because when I reflect on my own work history, some of the biggest mistakes that I’ve made in my career revolve around trying to solve multiple problems at the same time. Perhaps one of the most embarrassing examples of this is when I was attempting to learn OOP (Object Oriented Programming) on a new project. This was two problems: I had to build a new application; and, I tried to do it in a new programming paradigm.

Needless to say, the project ended up coming in months late and was a horrible mess of hard-to-maintain code. Trying to solve two problems at the same time ended in disaster.

Nearly universal advice for developers of all experience levels!

The trick for juniors is, they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up a development server, but then something weird happens with Unix. It’s the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time.

Perversely, a senior who can see the whole feature/change in their head is sometimes tempted to push the whole thing through in one (large) change. They’re tempted to make the entire thing happen in one outburst of crisp thinking.

Developers who have learned to avoid pitfalls and gotchas sometimes have to relearn how to work incrementally. Juniors (frequently) don’t have this problem. If they don’t work incrementally, they won’t make progress at all! (Caution: juniors that try to work like the seniors they see around them will fall into this trap.)

That said, juniors and seniors both tend to struggle with:

• deciding when to focus vs. when to jump out of a rabbit hole
• building their own feedback loops with tests/compilers, jigs/scaffolding
• imagining and applying constraints
• using first-principle thinking to reduce the overwhelming possibility space of programming

These skills don’t come with simple experience. One has to decide to apply them and then build up experience using them to keep development on-track, focused, and effective.

In America, the 2024 election cycle is unlikely to amuse anyone. Maybe this is a rallying point for “unifying” the country: a near-universal loathing of our politicians, how they get themselves elected, and the outcomes they deliver to us. Let alone the new media that reports on them.

Ahead of the inevitable hell-cycle, I’ve trimmed my attention sails a bit. The general idea is to remove feeds and notifications from my daily routine which are monetized primarily by writing doom-y, grab-y headlines. I’m looking at you in particular, New York Times. But it applies to just about everything with headlines. I’ve disabled all notifications from The Economist and Apple News. I read them once a week. That’s plenty.

Unrelated to the election, I deleted the Twitter and Instagram apps. The web app is mostly equivalent in Twitter’s case, no loss there. Instagram’s mobile web app is surprisingly mediocre. The point, in both cases, is to put a few more steps, a bit more friction, between me and randomly scrolling an algorithmic, attention-hungry feed. I’ve since found that the friction of loading these two as web apps is great. I do indeed look at them far, far less. On the other hand, their web apps are intentionally just-okay. It seems to me that any organization that can put together an excellent iOS app should be able to do the same on mobile web. Reader, let me tell you, they don’t.

I found the settings in Lyft and DoorDash that prevent them from sending advertisements-as-push-notifications. They do exist! Highly recommended.

Mute lists, they’re also fantastic. All the names and teams and keywords that tend to mean “here’s a post about the political horse-race” are scrubbed from my timeline. Even better, I can see when they’re scrubbed and dip in to see if things are as unproductive as I remember. (Thanks for that little detail, Ivory.)

Previously: Think Your Thoughts.

Manuel Moreale, Why I write:

But the reason why I started is long gone at this point. I started the blog as some sort of public accountability tool and it’s now everything but that. I don’t write to be accountable. I probably should.

Manuel asks a lot of folks about why they started writing their blogs. It’s a great question! Some folks want to get weird, others can’t not write and putting it online as good as anything, still others want to connect with a community.

That last one, connecting with a community, is closest to my answer. I started because there was so much excitement, energy, and connection in the early 2000s blogs. It was a real scene. And, plenty of invention! Before there was centralized social media and web 2.0 there was decentralized blogging. An earnest attempt to take the technology of peer-to-peer file sharing and build something besides music sharing on it. It was a fun moment.

Allow me a bit of a soapbox-rant. A spicy take, as we might say these days.

You’re using the ternary operator wrong in Ruby, JavaScript, and almost everything else. It’s for expressions, not control flow.

My personal ternary journey of discovery, delight, and distaste:

• In the old C days: what is this noise? What does a colon even mean in this language? Is this even syntactically valid?
• Later, in verbose languages like Java: oh I get it, let me show off by using it. I like that I can compress five simple lines of conditional down to one.
• Currently, seeing how it’s used in shell and React code: actually this is awful let’s never use this. Delineating the arms of a conditional with one character is awful for scanning and discovery code.
• Even when it’s appropriate, I feel a little bad.

The nuanced take: a one-condition ternary with no more than 4 tokens is maybe okay. If I can’t fit my ternary expression in 80 characters, switch to an if/else conditional. (It’s not that bad!)

// fine, I guess
foo = bar ? baz : quux

// stop this, I'm begging you
msg = bar ? ...dozens of lines of code
          : ...dozens more lines of code

Why I try to avoid it:

• in the year 2024, your editor can write conditionals for you
  • some folks can’t even keep your ternaries at 10 tokens, let alone 5
  • and it’s literally showing
  • hence, I’m here writing about it
• the ternary operator is not for control flow, stop that
  • the ternary operator is really only suitable for assigning values based on other values
    • for example, in the expression val = foo ? bar : baz
    • val depends on foo
    • the ternary operator is a good way to represent dependency/correlation!
  • I don’t care what React’s conventions are anymore
    • they’re not good in this regard
    • use conditionals for control flow
    • use variables to assign meaningful names to big chunks of markup
    • please, stop with the boolean and ternary logic
  • I’m literally writing this before the sun rises, asking you to stop
• ternaries don’t airlift/refactor well
  • you can’t pluck one bit of code out of a ternary and drop it somewhere else
  • I feel this one in my bones but can’t think of a short example
  • (citation needed)

Bonus track: stop adding conditional clauses!

// fine
if safe-to-release
  launch-the-missiles
else
  reset-to-ready
end

// bad, you got some refactoring to do
if safe-to-release && target-acquired && something-that-seemed-right-once && tuesday || national-holiday
...
end

I’m guilty of this temptation to add “just one more conditional!” I regret it.

It makes code difficult to reason about. It’s basically impossible to tell people when the thing will happen in the “bad” example.

If you manage to get something right in multiple conditions today, you’re probably only making it harder for yourself (or someone else) tomorrow.

I will support you 90% of the time if you want to take 30 extra minutes to turn a multi-clause condition into a simpler structure. Your teammates will hail you as a hero later when they need to read or modify said simpler structure!

A disproportionate percentage of bugs hide in conditionals. If they’re easier to read and change, hopefully we’ll write fewer bugs!

Taylor Troesh’s pseudoprose is a notation for writing/note-taking/thinking:

How to

• Write in English, Spanish, whatever.
• Grammar is optional.
• Markdown is encouraged.
• Embed in any document with [[…]] brackets.
• Use {…} for comments.
• Use <<…>> for LLM instructions.
• “tk” means “todo”.

Why

• Jot down notes/ideas quickly.
• Focus on semantics over syntax.
• Less text to edit.
• Offload grunt work to LLMS.

Notably, also a notation for annotating LLM/AI/Copilot interactions directly into your text. For the wonks, a GPT-4 prompt is included to convert psuedoprose to well-formed Markdown without any code. What a world.

Other folks’ ways of writing and taking notes are endlessly fascinating.

Every experienced Rails developer should pick up Garrett Dimon’s Frictionless Generators. Generators are an often overlooked piece of the Rails puzzle. The book shines a light on getting the most out of generators in your Rails projects. It’s an amazing-looking digital object too, the illustrations are great.

(Before I go further, it’s worth noting that Garrett Dimon sent me a review copy, acted on my feedback, and is generally a pal.)

You should customize generators and write your own

Conventions, in the form of assumptions that are woven into the framework’s code but also exist as a contract of sorts, are essential to Rails. Following those conventions would not work well if creating a new model, resource, etc. wasn’t made easy and consistent without our friends rails generate resource/model/etc. These generators have been present in Rails since the beginning. I’ve used them hundreds of times and thought nothing of it.

A few years ago, I realized that generators had become a public API in Rails and that re-use was encouraged. The guide is a good start. I was able to knock out a simple generator for a novel, but conventional, part of our application. In the process, I realized a couple of things.

No one likes boilerplate and tedium. Generators automate the tedium of boilerplate. This is particularly helpful to less experienced developers, who are likely a bit overwhelmed with trying to comprehend decades of Rails evolution and legacy code (from their perspective) quickly.

Rails developers are under-utilizing this leverage. Every system that makes it past a few thousand lines of code (or several months in use) develops bespoke conventions. These are easier to follow if you can reduce the mental burden to “when you add a new thingy, run rails g thingy”. Added bonus: starting new conceptual pieces in your app from generators encourages consistency, itself an under-appreciated sustaining element in long-lived Rails applications.

Luckily, someone was thinking the same thing I was…

Garrett knows more about generators than anyone I know

The Rails guides for generators are okay. They whet the curiosity and appetite. But, they aren’t particularly deep. When I first tinkered with generators, I mostly learned by reading the code for rails generate model/resource/etc.

Frictionless Generators does not require one to jump right into reading code. It opens with ideas on the possibilities of developing with custom generators. Then, it moves onto the practicalities of writing one’s own generator and crafting a good developer experience. From there, it’s down the rabbit hole: learning about the APIs for defining generators, implementing the file-creation logic therein, writing help and documentation for them, generating files from templates, and customizing the built-in Rails generators.

Garrett goes into as much depth on generators as any other technical author I know, on any topic. Did you know you can make HTTP requests and use their responses in generators? I did not, but Garrett does! Did you know that generators apply the same kind of “oh, yeah, that’s common sense” convention for copying files from generators into applications? I did not, but Garrett does! I don’t think I’d use all these ideas on every generator, but I like the idea that I can return to Frictionless Generators should I have an idea and wonder how the existing, low-friction APIs can help me.

Further, Garrett offers frequent insights into the developer experience and leverage of building generators. On building generators for “fingertip feeling” so developers can easily (and frequently!) use them:

I like to aim for no more than one value argument and one collection argument to keep generators easier to use. Everything else becomes an option.

On approaching generators as high-leverage side-quests:

Remember that the ease of use is generally inversely proportional to the length of your documentation. Assistance first. Brevity second. Content third. Or, be helpful first, concise second, and thorough third. That said, there are a few other categories of information that can be helpful.

For me, a good technical book balances presentation of technical information, the right amount of detail, and wisdom on how to apply the two in practical ways. Garrett succeeds at striking that balance while keeping things moving and easy to follow.

In short, recommended! Rails generators are underrated, whether you’re aware of their existence or not. Smart teams are customizing generators and writing their own bespoke generators. There’s a book on this now, which you should check out if any of this resonated.

Dave Rupert, Play at work:

I’ve talked about this before in the context of prototyping and play and how we worked at Paravel. It’s a lot like playing baseball; each member of the team showing up to practice, volleying work (in screenshots, short videos, or demos), pushing changes, communicating thoughts and challenges in the moment outside the confines of slotted meeting times. Me and my coworkers, having a catch.

Several years ago, when I was doing improv, I was rehearsing for a musical, of all things. At the same time we were getting started with table reads and gel’ing as a cast, two other shows were rehearsing in the same theater. One show was about to open, very much having their thing dialed in. Another cast was somewhere in the middle, having figured out what they were about but still trying to get the execution just right. Everywhere in the theatre, there was creation and exploration energy and it was one of the most awesome things I’ve done. This despite not liking musical theater much!

I don’t like the idea of “return to office” and I don’t think you could make it work anyway. The social momentum that kept a critical mass of people in one office has been broken, you can’t put that toothpaste back in the tube.

That said, I have yet to feel that same energy in remote work that I did in a local theatre on rehearsal night while various groups were making something together, in the moment, and iterating on it as quickly as they could share a glance or read through a scene.

I bet some teams have figured out how to feel this way in remote/async setups. But, it feels like most are still running the old in-person playbook that we learned, and sometimes thrived with, over the past years and decades of our careers.

As engineers, we often face the consequences of shallow ideas embraced exuberantly. Despite those experiences, we should try to solve future problems instead of re-litigating problems-past.

Engineers put too much value on their ability to spot flaws in ideas. It’s only worth something in certain situations.

— Thorsten Ball, 63 Unpopular Opinions

Don’t be edge-case Eddie, wont-scale Walter, legacy code Lonnie, or reasons Reggie. At least try to think around those issues and solve the problem.

This is very much a note to my previous self(s).

Pay attention to intuitive negative emotion…If you’ve been asked for quick estimates a bunch, you might have noticed that sometimes the request triggers negative emotions: fear, anxiety, confusion, etc. You get that sinking feeling in the pit of your stomach. “Oh crap”, you think, “this is not going to be easy.” For me (and most experienced software engineers), there are certain kinds of projects that trigger this feeling. We’re still pattern matching, but now we’re noticing a certain kind of project that resists estimation, or a kind of project that is likely to go poorly.

– Jacob Kaplan-Moss, The art of the SWAG

Jacob recommends noting how intuition and emotion are natural and not entirely negative influences on the process of evaluating ideas. The trick, he says, is to pause and switch to deeply thinking through the idea (or estimate) you’re presented with.

This, again, is very much a note to my previous self(s).

Now, if you’ll excuse me, I need to get back to brainstorming and estimating this time machine, so I can deliver this advice to my former self.

Julia Galef, The Scout Mindset:

The “self-belief” model of motivation assumes that if you acknowledge the possibility of failure, then you’ll be too demoralized or afraid to take risks. In that model, people who believe that failure is unthinkable are the ones who try the hardest to succeed. Yet in practice, things often seem to work the other way around—accepting the possibility of failure in advance is liberating. It makes you bold, not timid. It’s what gives you the courage to take the risks required to achieve something big.

One of the most impactful ways I’ve adapted my thinking over the years, if only modestly successfully, has been to fear failure less and accept small downsides more easily. There’s way more world out there for those willing to trip or even fall now and then.

…even if some days working in corporations or under unwanted pressure makes it considerably less fun.

I also just don’t especially want to stop thinking about code. I don’t want to stop writing sentences in my own voice. I get a lot of joy from craft. It’s not a universal attitude toward work – from what I can tell, Gen Z is much more anti-work and ready to automate away their jobs – but I’ve always been thankful that programming is a craft that pays a good living wage. I’d be a luthier, photographer, or, who knows, if those jobs were as viable and available. But programming lets you write and think all day. Writing, both code and prose, for me, is both an end product and an end in itself. I don’t want to automate away the things that give me joy.

– Tom MacWright, The One About AI

What a great distillation of what makes working on software great! It’s an opportunity to think all day, earning a good wage doing so. Sometimes, to make something of value. Even more rarely, to make something of lasting value. Most of all, to be challenged every day. On the good days, it’s the future we were promised!

Other days, it’s a bit much. Corporations and all their baggage will get ya down. Deadlines, communication, coordination are how one makes big things, but they have their drawbacks. They (can) drain all the energy and excitement of making something.

There are jobs that sound exciting from the outside or on paper. Driving race cars and being around motorsport, sounds exciting! But it’s probably a lot of toil, intense competition, and very little invention. Imagineering at Disney is likely immensely rewarding when an idea makes it all the way to the real world or a theme park, every several years. Between those years, it’s likely equal amounts of frustration and the friction of working at a giant company.

So, for me, building software it is. Even on the days when deadlines and coordination have got me down. Thinking them through to put a bit of the magic of software into the world, it balances out.

Rob Walker via Austin Kleon, More search, less feed:

I’ve been thinking a lot about the search box versus the feed,” he said. “Let’s take Twitter. When I open it, everybody wants me to think about something.

A Ponzi ecosystem of hustle, reality distortion and projection, outright misinformation and propaganda. Plus, folks who just want to tell you the world is miserable. On the other hand, some funny takes and the occasional wholesome content. As goes social media, so goes humanity.

That bit of (attempted) gallows humor aside, the linked article has a good angle: search for more information and do actual research rather than letting algorithmic-people filter it towards you. Caveat: this may have been more useful when that post was written in 2019 than it is in the reality of junky internet search that is 2024.

Reminder: think your own thoughts.

Thorsten Ball, Which command did you run 1731 days ago?:

Recipe for living a good life in the shell:

1. Make sure it’s fast.
2. Make sure its history can grow nearly infinitely and you can fuzzy-search through it.

A sage developer once told me he didn’t maintain dotfiles at all. He worked across so many machines and servers that keeping a shell configuration working across many systems was folly. Instead, the most important thing for him was making sure his shell history was synced across all those computers.

At first, I thought this was merely amusing. But the more I thought about it, the more I realized how deeply wise it is. Dotfiles, in the form of functions and aliases, abstract and ossify, the commands you think you’ll run frequently. But reverse searching through your total shell history provides you with access to commands you have run and lets you quickly edit/adapt them in-situ.

This makes the history file for your shell (possibly) the most significant file on your computer. Not just because it’s useful, but as a working memory and a reflection of your journey.

Virtuosity and speed are nice, in music and life. But you leave some space between the notes or slow things way down? Make some space in between the music for the music to happen? Now you’re cooking something good. For example:

• Aretha Franklin, the greatest of all time at making the most of the space between notes. As I’m fond of saying: there is no song Aretha Franklin could not perform slower and better than anyone else. Compare the tempo of Otis Redding’s Respect to Aretha’s version, both recorded in the same year.
• AC/DC, “Back In Black” or “Highway To Hell”. This is where I’d start rock and roll songwriting 101.
• D’Angelo, “Untitled (How Does It Feel?)”. Most of his work is an exemplar, he’s a master of making songs feel spacious.
• Joe Cocker, “With A Little Help From My Friends”. Take a jaunty, mid-tier Beatles song and draw it way out. This makes room for the huge, stacked vocals chorus. Suddenly, it’s right in the feels.

Related: the funk is the notes you don’t play.

David Hoang, Should managers be technical?:

Career development looks more like unlocking attributes for a different subclass in a role-playing game, than picking a distinct class that can never change. It’s not a path. It’s a collection of skills and attributes focused on certain outcomes. Applying foundational skills is heavily contingent on your role and responsibility.

👍🏻 Careers, management or not, aren’t straight lines. The skills you need for your career aren’t a tree with one root. You can skip between various skill trees, if you like! You can go deep, but wide is an option too. The more you know, the more you can delegate!

You should check out David’s newsletter too.

A wise person from a Destiny 2 Slack:

I guess when you’re done with the main quest, you go back and do side quests

Careers (and lives) are non-linear. Occasionally their trajectories don’t make sense. They may even outright disappoint, in the moment. The silver lining is, they give us unique skills and experience that someone in the world wants if only we can find them. 📈

David Crawshaw, jsonfile: a quick hack for tinkering. 114 lines, including comments. Nothing revolutionary here. Just a nicely written and well-thought-out “classic hack” for storing data in toy programs and prototypes.

Regarding Leó Szilárd, a theoretical physicist who first conceived of the possibilities of nuclear chain reactions, nuclear power, and nuclear weapons:

The bath was down the hall. “I remember that I went into my bath…around nine o’clock in the morning. There is no place as good to think as a bathtub. I would just soak there and think, and around twelve o’clock the maid would knock and say, ‘Are you all right, sir?’ Then I usually got out and made a few notes, dictated a few memoranda.”

— Richard Rhodes, Making of the Atomic Bomb

Shower thoughts, bath thoughts, lawn mowing thoughts. Great minds think alike, i.e., in similar repose.

Suppose you’re on a computer provisioned by a corporate IT department. They’ve restricted the software you can install. On principle, you’ve decided that even signing in to websites on a personal account is nice to avoid, where possible.

Given those constraints, how do you transfer interesting web stuff you’ve come across from the sphere of corporate IT into your sphere of IT? Normal tools like bookmarking sites or iCloud sharing are out. Emailing it to yourself is also out, too many steps and too janky.

What I came up with is:

1. Find a bookmarklet that will convert the current location’s URL to a QR code. This Codepen worked for me, but I bet there are others!
2. Hold my personal phone up to the monitor like a weird person and scan said code
3. Now the location is on my phone and I can do as I like

Turning a big idea into a more manageable one has second-order consequences:

Remember, the more complex the issue, the more prone communication is to being lost.

– Andrew S. Grove, High Output Management

Communicating complexity is compression. Compressing ideas is loss-y. Can’t get around that. There’s ​no way to convey a complex idea and maintain fidelity​. To work with an idea amongst abstractions is to ​accept that rabbit holes will develop​. And, that sometimes problems will hide in the depths and mazes of those rabbit holes.

When you compress air, it heats up. The molecules are literally squeezed together, they collide more, and the air gets hotter.

In combustion engines, compressing air coming into the engine to a higher pressure means you can add more fuel to it and get more power without increasing engine size. But, doing so requires extra machinery, turbochargers or superchargers, and requires an intercooler to cool the air down before it reaches the combustion chamber so it doesn’t explode prematurely. Second-order consequences!

I haven’t (yet) thought of a snappy analog to compressing ideas — yet. A way to integrate this with a mental model continues to elude me.

Abstraction, in the every-day software development sense, is compression. All the cautions and mythology programmers tell themselves about abstraction distill down to “compression is great if you can accept the trade-offs”.

First: use them! Most frameworks have a project boilerplate and that’s it. Rails’ ability to quickly lay down a conventional resource, model, or anything else is a productivity booster. Use it!

Second: experiment with the commands before you run them. Try Harrison Broadbent’s, RAILSG · Ruby on Rails Generator Reference and Command Builder:

RAILSG is a collection of Ruby on Rails generator command references, and command builders.

Third, write your own. When your app gets traction, you’ll probably invent a couple of conventions of your own. Use generators to quickly write new code consistently. Garrett Dimon has become the expert on this, Creating Custom Rails Generators:

Rails generators can help remove significant friction from the process of spinning up new ideas, but you don’t have to limit yourself to the included generators. You can also create custom generators as long as you’re familiar with the available APIs and know where the speed bumps are.

And check out his forthcoming book on the same topic!

Focus and attention are inputs to producing excellent things. All the talent in the world won't get me far if I’m not focused or attention isn't working in my favor. Beyond my skills at whatever I’m making (software, teams, products, essays, etc.), I need attention and focus.

In other words: I want to make what’s important to me: teams, writing, and software. I need focus to decide what to write/build with excellence. I require attention to sustain that focus.

Henrik Karlsson on multi-armed bandits and focus. First, explore to find what I might want to focus on:

The trick is to collide your mental model with the outside world as often as possible. This is what exploring does. You think you know the distribution of payoffs of the slot machines, but you try something new. You discover that you were wrong. You update your model.

This is a life design thing. Get out in reality, seek novelty, try plenty of things, “touch grass” with the world outside my mental model, the more the better. Experience a bunch of things, surround myself with intriguing, intense, or impactful people.

Surely things could have gone differently for me if I’d done more exploring when I was twenty-something. But, much less of the world was available to me then. More important that I figure out the world needs exploring now and then and that I can explore even with the responsibilities of my forty-something years.

After the exploration, “exploit” what I’ve found. Choose a few things and go deep on them. Things which resonate with me and make me think “this is a thing that I can do or invest my time and effort in”. I start doing it and that is focus.

But, really choose those “pillars” of focus. If I pick seven things, I haven’t really chosen. Pick a few of these things, leave several on the cutting floor. Don't construct some wild productivity system where I can spread my energy out over the seven days of the week, over seven areas of alleged focus and get nothing done (except possibly create a wobbly ideology and maybe a video course selling it 🌶️).

May I recommend the rule of three? It’s great.

Focus-and-exploit lets the brain work the problem even when offline, away from keyboards and tools. Pro-tip: mundane chores are an excellent tool here. e.g. take a shower, mow the lawn, go for a walk.

Why would focus compound? Part of it is time. If you care about less, you spend more time doing what you care about most. Also, you are always nonconsciously processing the thing you focus on. So cutting priorities means you work even when it looks like you’re not working. These days, I’ll spend the afternoon playing with the kids, doing the dishes, repairing the houses—being busy in a mind-clearing way. Then, when I sit down to write the next morning, I can type 700 words without thinking. The ideas have been churning in my head, just below the surface of conscious thought, and come fully formed.

If you're really focused, your brain is always working on those three pillars. It's thinking about whatever it is you're doing, turning over problems, processing that information, compiling it, organizing it while you sleep, and while you do mundane things.

Austin Kleon suggested a similar approach. When he runs out of writing/creative energy, he cleans his pool. Basically, he takes his thinking mind out of the loop. Lets his physical body do something routine and mundane to invite the creative mind to return. (Sorry, I can’t remember which Austin Kleon thing I saw this as a comment on. 🤦🏻‍♂️)

If you like this explore and exploit stuff, you’re going to really dig Kent Beck’s ideas about explore, expand, exploit.

On the other hand, allowing ideas into my sphere of thought from social feeds designed to put me in a bad mood or get me to buy stuff breaks the focus. I need attention.

Craig Mod, How I Got My Attention Back:

If I tell people I went offline for a month, it’s like telling them I set up camp on Mars. It hints of apostasy, paganism. Tribes seem to find pleasure in knowing all members suffer equally. But, really, is the situation so dire that we can’t wrangle a little more control? We’ve opted into this baffling baseline of infinite information suck, always-availability. Nobody held a gun to our head. We put our own mouths on the spigot every single day.

But it’s so delicious. That spigot goo — buoyed by pull-to-refreshes and pings and wily dots. Giving up attention, so seductive.

I can’t focus if my attention has me thinking of “5 amazing one-takes by Scorsese” or “INSANE Porsche 911 builds”. 🧠🫠 Too much social media feed is an inescapable gravity well of wandering thoughts. Modern, programmed attention makes it difficult to think our thoughts or sustain them.

However, disconnection is a luxury, and a bit ascetic. The real tactic requires figuring out how to thread the needle, striking a balance between connectedness and Waldenponding.

So I need guidelines, even when discipline wanes:

The internet goes off before bed. The internet doesn’t return until after lunch. That’s it. Reasonable rules. I’m too weak to handle the unreasonable.

What works for me:

• Remove the glaring offenders in my “attention” life. Mute, unfollow, etc.
• Set coarse rules that protect my time to focus. e.g., I take the first hour of my day for a writing routine, while my energy is high and the world is mostly asleep instead of eager to distract me.
• Remove decision-making. I listen to the same album on repeat during my writing session (currently, A Love Supreme). I work through the same five-item to-do list every time to get my energy going.
  

Attention and energy are finite. Don’t worry when one or both dwindle. At the end of the day, after numerous meetings, the weekend after a long week. That’s when it’s basically okay to allow a little temptation into your day. Don’t succumb to hustle culture! I encourage you to take a break from crushing it now and then.

Excellence. This bit started with trying to figure out how focus and attention generate excellent work. In particular, I need more than acumen and experience to make exceptional things, teams, organizations. I need to choose the right thing to focus on. But, tying up excellence with identity can cause misery or generate path dependence. I require honesty with myself when I’m doing great work and when I’m going through the motions to keep the work going. Focus and attention are preconditions for making excellence.

I Swear, I Really Wanted to Make a 'Rap' Album but This Is Literally the Way the Wind Blew Me This Time – Andre 3000

It’s all works in progress. Many posts are rough drafts I put out there to keep myself going. I have no idea which ones will stick and which ones will bounce. Plenty of drafts and following the way the wind blows me.

I know that if I let my attention wander, I will put less out there. Ergo attention. And I know that if I try to make several kinds of things, I will put less out there. Ergo focus.

Teams and organizations have focus and attention, too. Builders — developers, designers, etc. — focus on their slice of a problem. Teams focus on the problem as a whole. Organizations focus on solving problems that generate an impact on the metrics or goals they’re chasing.

Priorities are the attention of a team or organization. The negative space in those priorities reflects problems and impacts the group will say “no, thanks” to. That suggests a tidy way to think of personal and group attention; we should say “no, thanks” to attention-sinks which aren’t aligned with our personal goals and priorities. “No, thanks” to algorithmic feeds when our goal is to write, for example.

(Time to land this thing.)

Focus is a capacity to get stuff done. To choose a problem and put many hours and days into it. A sense of purpose, if that’s your thing.

Attention is deciding what the mind is thinking about. Attention can complement focus, or derail it. It’s how minutes turn to hours, in good ways (or bad).

Shallow focus and attention see us bouncing from one idea to another. Often, without our intention to intervene (i.e., dopamine hits). The good focus and attention turns minutes into hours of engagement and days of interesting work into the weeks and months of a notable career or legacy of work.

Funk is unique amongst musical genres, in my perspective, due to the importance of the notes you don’t play. The space between notes, and not “shredding” every possible moment, is important in all genres. But I find that the funkiest stuff gets that way from missing expected notes and shifting expected notes to moments where they shouldn’t be.

Funk was a rhythmic system of tension and release over time, but also simultaneous tension between some players exercising maximum restraint and others exhibiting maximum expressiveness. Most of all, funk was a science of subverted expectations, syncopation taken to its ultimate destination. With funk, things weren’t always where you thought they’d be.

– Dan Charnas, Dilla Time

Digital Underground, Rhymin’ on the funk. Recommended.

Funk not only moves, it can re-move, you dig?

– George Clinton, P-Funk (Wants to Get Funked Up)

LFG: looking for game. An ad-hoc scheme, often forum-esque, where strangers looking to play an online game that lacks matchmaking find each other and coordinate starting a game.

No matter how famous they get, the forward-thinking artists of today aren’t just looking for fans or passive consumers of their work, they’re looking for potential collaborators, or co-conspirators. These artists acknowledge that good work isn’t created in a vacuum, and that the experience of art is always a two-way street, incomplete without feedback. These artists hang out online and answer questions. They ask for reading recommendations. They chat with fans about the stuff they love.

– Austin Kleon, Show Your Work!

This is how I found so many of my online pals and past/future collaborators. The wonder of blogs, “web 2.0”, and then Twitter. We were out there posting, finding tribes, and, occasionally teammates.

Jim Nielsen, Blogging and Composting:

But as a byproduct of whatever you’re building you undoubtedly learned, observed, or cursed at something along the way.

And if you blog, you can make good use of that experience!

Show up (almost) every day, stack some drafts. Write down what you learned or what surprised you or what amazed you. Sooner than you know it, you’ve got a thing going. Maybe even a thesis or long-running schtick. Works for any kind of writing, not just blogs. 📈

Day two: breakfast, books, public transit! Tina Fey and Amy Poehler (surprise guest: Maya Rudolph!) put on an excellent show. (Not pictured: very, very cold.)

Grits ’n Gravy. Enjoyed.

Powell’s Books. Enjoyed, transacted.

The light rail line back to our Airbnb. It’s nice to get around sans car now and then!

Dinner plates say what we meant to say at Bottle and Kitchen.

Seeing lady comics at a concert hall, not a bad way to spend a night out of town.

I’ve had this sitting prominently in my Muse workspace for a while. Seems like a good time to deploy it now.

Barry Hess, You’re a Blogger, Not an Essayist:

I’m not going to look down on you for micro-posting on your blog, either. Heck, I might do it myself. I don’t prefer it, though. A blog isn’t Twitter. Just like I don’t think of a blog as something containing 2,000-word, heavily researched posts.

You don’t have to be an essayist. (Though you can be one if you want!) Don’t let those essayists discourage you from blogging.

Just write. Just blog.

Cosign.

Day one, travel day. Air travel is fine. Green carpets are green. It’s cold and dreary, as expected. There may be snow. We persevere.

My experiments (with obsidian-copilot) have yet to yield a satisfying intersection between LLMs and Obsidian. I generally find OpenAI’s models write too much like breathless clickbait instead of an interesting human. I don’t want a summary or rewrite of my notes generated in that style. For querying/searching/discovery, OpenAI’s notebook-esque web interface is fine.

I’m still hoping to come across something that uses indexing and embedding to help me organize and connect notes I wrote, by my hand, in intriguing and novel ways. 🤞🏻

That said, if you’re already running an LLM locally via llama, obsidian-ollama looks like an excellent way to integrate it into your note-writing/knowledge management scheme. The code of this plugin is easy to follow and nicely structured, making it a good one to look at when the temptation to write Obsidian plugins comes. (Which, for me, arrives as a potential distraction more often than I’d like!) Disclaimer: I haven’t tried this one yet!

Ray Grasso, Long Live the Work Journal:

Keep a journal for work, champions.

It’s pretty easy to get started—just create a text file.

Throw in a new heading each day and write down whatever you did—a single line for each task is usually enough. I put the newer dates at the top so it’s less scrolling to get to the most recent content. Over time you end up with your own little private reverse-chronological blog-in-a-file.

Each day, dump in commands you’ve run; links to documents you’ve created, reviewed, or read; tasks you want to get done; or goals you want to achieve.

You’re building a little outboard brain where your work history is just a short grep away.

Endorsed. Journals are the best PKM impact-to-effort ratio out there. I like DayOne, been using it for more than ten years and thousands of entries. But, anything works! Your notes app, a text file, a document in your preferred word processor. Anything you can search later and access anywhere is good!

The most important thing is to turn what’s in your head into “words on paper”. That’s when the magic happens!

Most fascinating game there is, keeping things from staying the way they are. – Kurt Vonnegut, Player Piano

The status quo is a hell of a thing. Path dependence makes this a challenging game.

The biggest challenge you could take on in life: change it for even the slightest better. A virtuous challenge too, in an Aristotelian virtues sense?

I like the idea and execution of Tailwind. That said, there’s something nice about dropping a CSS library reference into a new HTML file and getting styled content without adding any classes or other legwork.

The nice thing about these libraries is they imagine, to some extent, a world where the stylesheets browsers use as defaults didn’t look so bland.

• new.css – if browser defaults looked real nice
• mvp.css – if browser defaults looked like Bootstrap or the Tailwind examples
• nes.css – if browser defaults said “heck, we’re going with it” and emulated the look of classic Nintendo game menus
• tufte.css – if Edward Tufte had been put in charge of default browser stylesheets

Rands in Repose, Seven Steps to Fixing Stalled To-Do Tasks:

The never-ending question you must ask regarding whatever productivity system you’ve built is, “Does this system make you more productive?”

The purpose of all this software is to get stuff done (make things), not to fiddle and shuffle tasks around! (This goes for individuals and teams, FWIW)

• Places visited
  • Marfa, Texas
  • Las Cruces, New Mexico
  • Tucson, Arizona
  • Disney World (Orlando, Florida)
  • Disneyland (Anaheim, California)
  • Prunedale, California
  • Salinas, California
  • Monterey, California
  • Dallas, Texas
• Writers enjoyed
  • Craig Mod
  • Henrik Karlsson
• Music re-discovered
  • John Coltrane A Love Supreme
  • Return to Forever The Mothership Returns
• Concerts attended
  • Bruce Springsteen and the E-Street Band,
  • Lyle Lovett and his Large Band
  • Thundercat
• My best writing
  • My summer at 100hz
  • I got better at estimating projects
  • Err the Blog, revisited
  • Turn the pages, read the code, hear the words
  • Natasha Lyonne is my generation’s Joe Pesci
  • A vacation is a tool for disconnecting
• Previously revisited
  • 2022
  • 2021