Constraints generate style

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


I switched notes apps (and back) (again) (and here’s what I learned)

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. 🤦🏻‍♂️


Corporate stories

Should internal narratives, and the philosophies they generate, be among the guarded proprietary info within a company1? 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 story2.

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 it3. 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!


  1. Depending on the company, losing this information is a crisis, possibly existentially:

    1. Data, esp. customer lists

    2. Source code

    3. How it really happened/what that means

    Surprisingly, not all of this has the best access control. Most companies choose productivity over secrecy. Theories of friction, agency, and firms being what they are, etc. ↩︎

  2. e.g. Musk would very much like everyone to forget he didn’t start Tesla. ↩︎

  3. Hence, how far venture capitalists and cryptocurrency/AI/hype-cycle founders will go to nudge narratives to suit their needs and away from what the technology actually does, cannot do, or is intended to do. ↩︎


Be findable

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!


Seek the good (enough) things

100 Tips for a Better Life:

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


Finishing is the skill

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/card1. Finishing is important, but communicating that progress counts for a lot too! There’s no sense in finishing if no one else knows.


  1. Me from several years ago would not believe I’m writing this. 😆

    New conjecture: communicating via cards/issues is as important as communicating via pull requests. The interaction of the former is stakeholder to engineer, the latter interaction is engineer to engineer. ↩︎


Frequency instead of quantity

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.


Everyone wins: document whatever resists simplification

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

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


  1. Thanks, Kent Beck, for that whopper. ↩︎

  2. It may end up making the change easier! ↩︎


Pastoral and modern approaches to attention

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 1:

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.


  1. Caveat, “currently” is on a long road-trip. Read about it↩︎


Delegate, don’t dictate

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.


Beginners helping experts

“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 creator1 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 install2 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:


  1. Spoiler: creators weren’t even a thing! There was barely developer marketing, even. ↩︎

  2. This is how you installed most Linux software back in the day. In the snow, uphill both ways, etc. ↩︎


Humble writing

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 smarter, not harder

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


The leisure/disconnection/creation circuit

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 vacation1. 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 interests2.

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?


  1. Of course, it is not. It’s a lot of work to put that many photos and words on the internet. ↩︎

  2. Assuming Disney parks don’t become my work. 🤞🏻 ↩︎


Show up every-dang day

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.


Personal websites are corner stores and neighborhood garages

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!


A big bucket of text

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!


Recently in pair programming with AI

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!


Juniors/seniors and incremental/vision development

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.


Trim the attention sails

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.