Cool description of forward deployed engineers (FDEs) from Nabeel Qureshi’s post on his time at Palantir:

Going onsite to your customers—the startup guru Steve Blank calls this “getting out of the building”—means you capture the tacit knowledge of how they work, not just the flattened ‘list of requirements’ model that enterprise software typically relies on.

It goes like this. Get people who can code web apps, send them to the client’s workplace to sit in with the client’s employees, get them to watch how they work and come up with new ways to build a web app that solves what the engineer deduces the client needs. Quoi?

The Palantir solution to “the system is the problem” is to parachute engineers into context to create an “end-to-end solution to [their] specific problem, and to hell with generalizability”.

The ability to deduce solutions steps from observation (ie. “design”) is something every thoughtful and driven person can do—even and especially engineers—and it mostly starts with being immersed in the problem space. From there, with the knowhow of standard software patterns and flows at hand, defining the needs and relations between said needs can start to make up a good solution.

“Asana, but for building planes”. You took disparate sources of data—work orders, missing parts, quality issues (“non-conformities”)—and put them in a nice interface, with the ability to check off work and see what other teams are doing, where the parts are, what the schedule is, and so on. … These are all sort of basic software things, but you’ve seen how crappy enterprise software can be—just deploying these ‘best practice’ UIs to the real world is insanely powerful.

“Just deploy best practice UIs to the real world” is a great doormat for those “right under my nose” opportunities we’ve all thought of in the shower.

If Nabeel’s post resonates, you should also read this linked from his footnotes:

If you want to order the wrong wine with the fish, the wait staff will simply tell you no.

Rummaging through notes, found Chris Beier’s excellent summation of John Dewey’s ideas about experiencing art.

Dewey claims we should be looking at not the physical work (an urn, a painting) but the experience of engaging with it. … all experiences take place over time, and no experience can be instantaneous. …though (paintings) are physically, static objects, they’re experienced through the exploration of the composition over time.

This means that “the emotional unfolding of an experience is fundamentally ordered”. Furthermore, the ordered unfolding of the recollected experience accounts for how we “explain the orderings that are enjoyable in stories” because the building, plateauing, and unwinding of narrative stuctures mirrors the process of evolutionary fitness.

Fitness is a continuous scale, which we can understand as a growing and shrinking delta between a complete unity with the environment—that is, the ideal state for the creature—and the actual state of the creature. Narratively-satisfying emotion is produced by the rhythm of that delta growing and shrinking over time.

Satisfying experiences mostly follow a “need → effort → fulfillment → satisfaction” cycle because they “come from the process of taking actions that have the effect of improving fitness”.

Fitness moving back towards equilibrium produces narratively-satisfying emotion.

Experiences are driven by and judged on fulfillment rather than mere enjoyment. In the age of mass distraction and mediocre art, this is renewing rhetoric not just for the cornered artist, but also the cornered product manager, the cornered service provider, the cornered designer, the cornered engineer.

Scott Walker from the “30th Century Man” documentary (turn the sound on):

So, there’s spaces in TILT, but more spaces than this, for silence and for language to emerge. And that’s why the words are important, because you have to feel the phenomenon of the words coming out of silence.

Such a fabulously vulnerable invocation. I’m thinking a lot about language, speech and silence as AI gathers pace, and I keep referring back to this little snippet.

Ps. If you don’t yet know his music, you should try it. It’ll take time, and then it’ll change your life.

Bob Dylan on Rimbaud, from “Chronicles: Volume One” (published 20 years):

I came across one of his letters called “Je est un autre,” which translates into “I is someone else.” When I read those words the bells went off. It made perfect sense. I wished someone would have mentioned that to me earlier.

That is, without love and theft, new things can’t happen:

“If I hadn’t … heard the ballad ‘Pirate Jenny,’ it might not have dawned on me … that songs like these could be written. In about 1964 and ’65, I probably used about five or six of Robert Johnson’s blues song forms, too, unconsciously, but more on the lyrical imagery side of things. If I hadn’t heard the Robert Johnson record when I did, there probably would have been hundreds of lines of mine that would have been shut down — that I wouldn’t have felt free enough or upraised enough to write.”

The Rolling Stones—like Bob Dylan, also named from love, in their case, Muddy Waters—same thing:

They wanted the Chess sound … to be exactly like the originals. But it came out like the Rolling Stones. Marshall Chess

Zadie Smith says the same thing:

I am fascinated to presume, as a reader, that many types of people, strange to me in life, might be revealed, through the intimate space of fiction, to have griefs not unlike my own. And so I read. Fascinated To Presume

Lewis Hyde summarises:

Dylan seems to me to be saying, “If I am anything, it is because I have allowed others to inhabit me.”

Via Oliver Gilan’s The Cloud Hasn’t Been Won, the context is PaaS cloud companies:

Beating the hyperscalers on convenience and developer experience is a good idea because when it comes to those things the hyperscalers tend to be dogshit. The hyperscalers are basically APIs over physical infrastructure but most companies care more about building their product and solving customer problems than they do about infrastructure so it’s an attractive proposition if you can simplify that for them.

But this strategy is a trap for a number of reasons. Being more convenient and easy to use usually means being simple. … But the moment you want to do something outside the beaten path then the simple platform makes it extremely difficult or impossible and as a company grows bigger the likelihood that they need to do something outside the beaten path grows.

Between the backwards pricing model and the lack of functionality, platforms that focus on simplicity end up directly incentivizing their most successful customers to churn.

Also applies to any infrastructure pace layer within a tech stack: your UI library, your database, your CI/CD pipeline, how you write UI styles, etc.

Defaults kick-start momentum. As the project progresses, it’s easy to find that convenience means you’re locked the system that enabled you in the first instance. It can be hard to affect change within that system without extracting yourself from it entirely, which is costly. Easy start now, pay later.

Been thinking about this in relation to the Convention over Configuration mantra and how Tailwind’s success was built on it (sure, not as complex as PaaS but it applies). Defaults/convention/convenience is a good thing until it isn’t.

See also this post.