Starting to think Product Management will be overtaken by Product Engineering. Engineers are learning product. PMs aren’t learning how to build. Reminds me of “information architects” in the old days arguing that nobody understood how important they were. Then they disappeared.

“The difference between an idea and a product is that you’ve solved the problems.” - Jony Ive mckinsey.com/capabilities/mc…

Everybody has a text editor. This is my work editor. Here's what it looks like to kick off a new project. Private alpha version.

Tools like Cursor hint at where AI-driven user interfaces are going. Chat is only 10%. Most of the output (and UI) is a domain-specific representation of the state of the work. In the case of AI coding, 90% of what you're looking at and thinking about is the IDE, the diffs, the PRs, the tasks, etc. The representation of the actual work. How does this generalize? Think of a calendar for example. Meaningful decisions will involve looking at a visual representation and seeing options. The back and forth chat over what to change or what to see is the 10%. The actual work state (in terms of UI) is the 90%. Quick breadboard below to describe this.

I'm starting to think the UX field is overdue for a good primer on how to really *do* interaction design. Current education is way too focused on polished deliverables. Not enough on-your-feet skills and thinking techniques.

Interesting asymmetry. When shaping, it's important to have one narrow problem and multiple paths to solving it. Agreeing on the problem prevents us from getting frustrated. Finding multiple paths ensures we don't miss opportunities.

I have officially been through enough loops to say this now: Doing Figma LAST really works. What devs need to start is the wiring. Not the final interior. Just like the contractors building your house need to know where the sink is, not the color of the tile or the faucet fixtures. And guess what? In a software system, a lot of the UX is IN THE WIRING. That means: what do you see where, how do you get there, what is shown, what is not? What's the business logic, what's the interaction, what's the flow? High fidelity matters. The final polish matters. And it's SUCH a better experience to do this ON TOP of working software. Because then you don't have to throw away work. A visual artist can put their heart and soul into every pixel, matching the wiring 1:1. This leads to extremely fast turnaround and buildup of momentum. Like when you finally see the drywall going up and the house becomes real. And what if the designer should make contributions to the core interactions or flow, and not only the surface? No problem — we can collaborate during shaping. We can spike interfaces, sketch ideas, and breadboard our conclusions in a whiteboard. But we don't the need to "lock in" the "final, final, final" Figma just to get started. Not at all. Wire it up, click on it, figure out if it does what we want, THEN we can go the extra step to make it beautiful. This really works. It's a way faster kickoff. And the designers are happier too. What about Lovable, v0, etc? The same pattern applies. If you try to give a high fidelity prototype as the "input" to the build step, there will be trouble. Lots of time bombs. Lots of business logic and interaction issues we couldn't see behind the illusion of the finished sheen. Vibe coding is fantastic for trying out ideas. But before we start "construction", better to strip back to the essential wiring that we are really sure of and that we understand. Then layer on the polish later.

Excalidraw is good for making a breadboard while shaping. Faster than hand-drawing, and the rough look communicates that it's work-in-progress.

Palantir's "Forward Deployed Engineer" role. Good example of engineering taking more responsibility for problem definition and shaping. Opposite of ticket takers. Palantir's Ted Mabrey said "We think of the FDE model as one of our greatest secrets." jobs.lever.co/palantir/dab39…

When projects take longer than expected, people usually think the problem was at the end of the project. The problem is almost always at the start. The team didn't have a process for breaking apart the work, seeing how the pieces fit, and choosing what to do first.

Async collaboration is essentially additive. It’s easy to add a comment, add an objection, add more code, add to the scope. That works when implementing pieces of an agreed concept. It doesn’t work when we need to change direction, remove something, or make trade-offs.

Looks like Figma's idea of improving designer-developer relations is helping designers dictate MORE decisions up front. They're even helping designers create Jira tasks from inside Figma! Be suspicious when 8000 designers in a room clap for features made for developers to use.

FINISHED filming my new course "Shaping in Real Life." Comprehensive, detailed, REAL how-tos on every phase of product development: from framing problems, carving time, shaping, spiking, to hand-off and delivery. Even more content than Shape Up, and for a wider variety of teams.

I didn’t understand what he meant by “kernel” at first. Looking it up in Statistical Consequences helped.

A deep point about design that took me a while to appreciate: Requirements are chosen, not “real.” The things we accept as requirements reflect our perspective on the problem. Research and data are inputs to that. But making something into a requirement is an act of alignment.

Key difference between Miro and Lucid Spark. Miro is multi-scale. Here I'm zoomed all the way out to 2% and I can still add readable structure at high altitude. Multi-scale UIs are rare. Other than Miro and Google Maps I don't know many examples.

I've started saying "prototyping" more, instead of "iterating", after I learned something from @bmoesta. Prototyping means trying wildly different options that cover more possibilities to discover what works. Iterating implies gradual change down one path we're already on.

Apple: "We present Ferret-UI, the first MLLM designed to execute precise referring and grounding tasks specific to UI screens, while adeptly interpreting and acting upon open-ended language instructions." arxiv.org/abs/2404.05719

v0 / Lovable aren’t replacing programmers, they’re replacing Figma files and Framer mockups. They are prototyping tools.

Two broad patterns that nearly every information system UI is missing today: 1. Let me draft the thing first, instead of "here are fields, now give your final answer." 2. Let me explore parallel options A, B, and C of the thing when I don't know the answer. Examples...

New video! "Shaping in a Nutshell" Now when someone asks "what is Shape Up?" you can just send them this. Coming next: "Shaping in Real Life" — a course to solve the disconnect between product and engineering, w/ concrete how-tos on framing and shaping. piped.video/watch?v=h_8M23wV…

Been thinking about learning Clojure for years. I saw pitch.com is built in Clojure/ClojureScript and decided it's a good time to start. Just did the first hour of @jacekschae's course at learnreagent.com. Very refreshing and fast-paced experience.

It's easier to move furniture than to move walls. But today most software teams bundle all the design — walls, paint, and decor — into a single high-fidelity mockup at the start. Better to get the rooms right first. Do the pieces connect? Do they create the value we expected?

There’s no better teacher than a real project on a real deadline.

I use a little tool called the "fit check." Here's how it works. (Thread)

At the start, writing isn't writing. It's figuring out what to say, where to begin, and how the dots will connect. Same for UI. Somebody can say "sketch a concept for this feature." But at first, sketching isn't sketching. It's figuring out what the thing is supposed to do.

Design means answering: What are the parts and how do they connect so that they fit the purpose. When we're building and we discover we don't know what parts to include, that's a signal to flip back into design.

Man, the progress I'm making with Claude Code makes me want to just jump out of my chair. Amazing.

Love these visualizations of running different async processes with @EffectTS_ . By @kitlangton.

Feeling productive with Hotwire, Stimulus and vanilla JS on this Rails app. No heavy React stuff. After a few days of hacking, it replaces the Miro board I've been using to scope and sequence development work.

Very good intro to @remix_run by @samselikoff. Love the format. Like a cooking show, he fast-forwards through the slow parts (you never watch him type) and shows the highlights, take-aways, decisions. Agree to the Rails comparisons. Especially w/ Stacks. piped.video/watch?v=RwVrEQRI…

Starting building an app in @remix_run (on the Blues stack). Rails folks talk about "Javascript sprinkles" — using just a little when needed. Remix feels like "React sprinkles." 90% of the code is rendered server-side, and the React interactivity is great for specific UI bits.

My mental shortcut for thinking about Vision Pro: it’s like headphones, but for all computing. I think about all the times I use headphones instead of speakers (privacy, traveling, not annoying others, no speakers where I am, signaling “leave me alone”…) and they all map over.

Order of operations — the sequence we choose to solve design and build problems — is a huge progress multiplier. 10x more impactful than choice of framework.

I’m productive in Rails, but I started dabbling in Clojure and I can’t “unsee” it. Now I just want to deal with data literals at every opportunity.

As designers, it can be hard to feel secure and confident about our individual taste, style and judgement. What's "good" and what's "bad"? So we naturally look to our peers. This can lead to clustering and in-group out-group distinctions. And, being human, some emotions get mixed in. Like, if my work doesn't look like theirs, maybe I'm not going to be respected. And if someone's work doesn't look like mine, and they're succeeding, does it mean I have a problem? Do I need to defend the "right way" somehow? Interaction and functional aspects of design are easier to treat objectively, because instead of good/bad, we can talk about fit and misfit. Does it produce the outcome or not, at what cost, how robustly, etc. Styling is much more social and emotional. I had an eye-opening lesson about this once from a speaker at the By Design conference in Bratislava. He did some high-end work for Nike, purely on the visual/graphic/styling side of design. I asked him where he gets his inspiration and how he stays ahead. He said: "Look at fashion. They're at the cutting edge." This blew my mind at the time, because I was really insistent on seeing everything as an objective optimization problem. Now it's exciting to see how there are these very different universes that get integrated in product design: not just the functional, but also the social and emotional.

Lately I've talked a lot about building software like building a house: getting the walls, wires and pipes in place before the interior design details. Here's an example of what that looks like. I'm building out a new website. Instead of starting pixel-perfect, I shaped a concept on a whiteboard. Now I'm implementing the moving parts in Ghost. These standardized "stub" classes let me focus on the wood walls and wiring without getting distracted by the drywall, paint, and decor too early.

Christopher Alexander wrote a lot about “unfolding.” Unfolding is the process of learning what something should be by working on it.

Improving a messy product is hard. The closer you look at the ugliness, the more you want to throw it all out and start over. But that's not always possible. We can't stop the world and redesign everything. What helps us make meaningful progress is a watertight "frame" — a narrowly defined problem, outcome, and time frame. When we know why we are changing this, what will be different, why it should happen now, we can hold our noses and make the hard trade-offs. The opposite also holds. Without a tightly framed problem/outcome, without a sense of urgency, the illusion of the giant redesign too easily seduces.

The first order-of-operations hack to learn: Instead of starting with a high-fidelity mockup, use the "parts on the floor" approach. Figure out (1) the data you need, (2) the raw affordances for the UI (buttons, fields, links), then (3) wire them together with no styling.

LLMs make much more sense if we stop thinking of them as intelligence, and instead think of them as media. They are basically a new kind of media with very different storage and retrieval properties. The pattern matching is so rich that this medium can "store" behaviors.

Documented every step of shaping this project, from analysis and problem definition all the way to writing a pattern language w/ example sketches. Many thinking tools used along the way to wrangle the problem, plus some mocking and spiking to remove rabbit holes.

Christopher Alexander passed away at age 85. What a good example of what one can do with a life: making gifts to the world. May his idealism and insistence that our lives be made meaningful through kind actions inspire many.

There is no measure of developer productivity, as Martin Fowler and others have shown. But there is an alternative: developer credibility. A simple credibility test: does an individual or team (1) set expectations and (2) actually meet them.

Christopher Alexander on fixed time, variable scope. Here he calls his method of building “system-A.”

Lots of people have asked about that primer on Christopher Alexander that I shared in 2020. It's back up on YouTube now.

Trying a new scoping exercise at kick-off. After shaping, before any UI/code. Programmer: "I haven’t written any code, but my feelings have drastically changed about am I going to be able to deliver this well within the timeframe and am I gonna deliver everything that’s wanted."

Freeform on iPad is the app that comes closest to the experience of whiteboarding of any I’ve tried so far.

A programmer on our team reflected on how we're working: "What I've learned is... when something is unknown, the first thing to do is place restrictions on it so it doesn't take over the project." "Constantly whittling scope makes it easier to understand the moment I'm in now."

The first thing I'm looking for when mentoring a junior UI/UX designer is the shift from "is this what you want?" to "this solves the problem because [reasons]." Then the second shift is from generic to specific reasons. "This is better because [generic design rule]" doesn't get you far enough. It means you're not solving the unique problem. Situation-specific reasons sound like this: "When you're trying to [perform task in situation] you need to see [info] but we don't have enough space there, and if we do it like this, [other info] is in the way, so the idea here is to cut this out and move it over here ..."

Suspecting software architecture decisions like monolith vs. micro-services are less about code and more about management hopes. Hard interfaces imply — perhaps misleadingly — that teams will work in parallel, without collaborating. The economics of interfaces are such that they are costly to set up and pay off through repetition. If the repetition isn’t there — if we rarely just “plug” things together but usually end up crossing the boundary — the net result will just raise the cost of getting work done.

Highly recommend Grokking Simplicity by @ericnormand. This bit in Chapter 8 reads like a fresh take on "Composed Method" from Kent Beck's classic Smalltalk Best Practice Patterns.

Someone looked over my shoulder and said "Visual Studio! So you're programming. What are you doing, front-end or back-end?" This project is in @remix_run, so I said "both."

We don't only "do" work. Sometimes we unpack work — figure out what's involved. Sometimes we factor work — pull out things to do separate from the rest. Sometimes we shape work — design an approach that fits our constraints.

Just finished a small demand-side research project. Interesting to view it as a series of rescaling operations, like the renormalization group in physics. From ~6 hrs of interview data to 49 causal factors to 13 dimensions to 3 jobs to be done.

Adding is easy, because adding isn't changing. Changing is hard because it requires untangling all the stuff that's already in there to know how it works.

Put together a mini user guide for the alpha users of the Handoff tool I'm building. It lets senior programmers do something they didn't think was possible: help junior engineers get better at breaking down work. Catches problems early in the cycle and prevents blowups later.

Learning to distrust workflows that look like this: "Do the work > Review to see if it's what we wanted" Need to flip it around: "Define what we want > Do the work" And, importantly, prepend this: "Do the work of figuring out what we want > ..."

I can't remember the last time I saw an enterprise software offering so far ahead of everyone else in its category. For 20 years the enterprise has been stale and innovation has come up from the bottom. With Foundry, the story looks very different. piped.video/watch?v=bPGnvfyM…

Gave a spontaneous short lecture yesterday on how to start in UI/UX design from absolute zero knowledge. Started w/ patterns, then connected to real-world component systems (Swift UI, raw HTML, Tailwind, etc), then lego-building, then breadboarding. It might become something.

Head of a design agency in Brooklyn just told me he makes every new design hire read this piece from 2012: medium.com/@rjs/managing-pro… Why? So the designers learn to "clear one room at a time" instead of trying to solve everything at once. "It's a focusing agent."

Almost no software today lets you prototype — play with options for the same slot of data before deciding. In a calendar, you can't capture trip plan A *and* alternate plan B and decide later. In Keynote, duping a slide to try something while keeping the original.

Clojure + Shape Up at @whimsical: whimsical.com/general-intere…

Working on some teaching material to help a wider variety of real-world teams implement Shape Up. (Took inspiration from Kathy Sierra's work and replaced abstract iconography with more brain-tickling photos.) A couple key ideas...

So cool to see Shape Up in the Brot Books Deli in Bratislava (brot.sk), from the people behind the excellent By Design conference (bydesignconf.com).

Love this UI.

Funny and also meaningful on many levels. grugbrain.dev/

Prototyping a super lightweight way to shape and track work. Here's a little one-week project I'm doing with a programmer. Using techniques from "13. Beyond to-dos."

Important programming skill: stopping to question what we're doing. When we're pecking at things, not making progress, ask: Do I know what I'm actually trying to do right now? If no, step out of the code to shape an approach. If yes, refactor so the next step becomes clearer.

13. Beyond to-dos "When smart people tackle work, they do work *on* the work to figure out what the work is. They do it in their heads or on paper or on a whiteboard, not a to-do app. To-do apps are made to account for work, not figure out what it is." world.hey.com/rjs/13-beyond-…

I am very granular and specific about what I want it to do. I'm not asking it to do a lot by itself. But it's still 5-10x faster than if I were doing these steps myself. Here's the actual prompts I used from a stretch of work just now: "> When searching with the sidebar search component, centers and countries are combined into one category of results. How are they combined?" [ it shows me] "> Okay. For the dedicated search I don't want to take the same approach. Instead of combining them in the view, and keeping them separate in the data, I want to unite them into a single filter. So if you are on the 'centers' filter, it also fetches countries. This would mean changing the code that gets results for all categories, as well as the code that fetches data when the 'centers' filter is chosen for one page of detailed results." [it does a substantial change to how the data is pulled from the backend for the view] "> Okay now we're going to change the way that the filters are rendered. When you are using the Search Widget and you filter, we are going to stop showing the filter buttons. Instead we are going to render a text headline on the top of the page that indicates the currently applied filter name. Because we aren't showing the filters anymore, we need a way to go back to the 'all' state. To do that, we'll have a "back" button that is functionally equivalent to the current "all" button. Is that clear enough to act on?" [it shows me it understands and does the change] "> There are duplicate headers in some cases. Like when you choose the "Letters" filter, the new headline says "Letters" on top and then there is an additional headline that says "letters" above the results themselves. Can you find any cases where a headline is being rendered above the detail results (other than the new headline we just added in the changes above) and make sure this duplication doesn't happen on any of the filtered states?" [this duplication wasn't a mistake from the previous steps. it was a natural next thing to solve] "> Can you extract a helper function for the view that handles all the responsiblities of the "See all [104]" link that appears on the 'all' page after each category title? The helper function should let us provide a result object (like 'centersResult') and a filter ref ('centers'), and do all the usual things necessary like check if there are more hits than results, link to the detail page, etc as you see in the current examples." [it does, but it doesn't go far enough] "> Yes that's a good start but there should be one function that generates all the HTML and uses those two other functions you just made. I want to replace all of that HTML for the headline and the see more link with one thing." [it finishes it the way I meant] "> Each one of those new calls to the sectionHeader template has a set of things that are defined: the title, result, filterRef, etc. Lets predefine all of those in a map, and use the filterRef as the key to get at them. That way, we only need to specify the filterRef in the template call." [it does the refactoring and shows it to me for acceptance] "Actually ... can we repurpose the existing Filter configuration for this?" [it gets what I mean and redoes the whole refactoring correctly] "Do you see how each of the result blocks for each of the filters in the HTML template uses the same pattern? There is a loop over the searchTile template. We should be able to extract that and just use the filterRef to render the right thing." [it refactors the view code to remove a ton of boilerplate duplication]

Just saw the most brilliant app integration at a Moscow restaurant. A QR code on the table lets you pay the bill and leave whenever you want. Totally solves trying to flag the staff, waiting around for the check, splitting the bill, and tipping in one fell swoop.

“Stop treating your frontend as some generic API client, and start treating it as a half of your app.”

After 20 minutes of describing a task ... "so, when do you think you can get this done? By next week?" Funny how we often put the question of time and capacity at the *end* of the ask. To make work actually happen and ship, the first requirement is capacity to do it.

My talk from #RailsWorld about "Shaping in the Real World" is online. The talk dispels some misunderstandings about what it means to shape, how it's done, and how to give teams more autonomy without taking unrealistic leaps of faith. piped.video/watch?v=mYbxQwQA…

PMs often prioritize work by something called "impact." But usually what a PM considered "high impact" doesn't actually get the green light from leadership. Why? One big piece of this problem is about the unit. What's a "unit" of impact? How do we weigh two projects against each other? You can't when the unit is too abstract. It's like saying "goodness" or "desirability." Sometimes, it's about money. Then we need to show that this change earns X $ more or reduces cost by Y $ over time T because of pressures we're under. Sometimes, it's about buzz. Nobody has talked about us in a while, so we'll choose something that will get people talking over something that silently improves things. Sometimes, it's about morale. If we don't throw a bone to this team or stakeholder after a certain amount of time goes by, they're going to be outraged and it's going to be hard to work together — even though it's hard to objectively make the case for that thing. And sometimes, it's about buying time. We're working on something big in terms of potential $ or buzz, but it needs more attention to shape. Meanwhile, teams need new work to do. So we can choose things that are smaller optimizations in the above categories — not necessarily big impact — that are still wins and don't require much attention while the bigger thing is baking. None of these are good/bad. They are all responses to different situations that come up in a company. And the same company will have different needs at different times. As leaders, it helps to be more explicit about why we're doing something. And if we're a layer down, we'll find we get many more wins and "yeses" by tuning in to the changing pressures that leadership is facing at a given time.

"The new @tldraw is designed to be a primitive for infinite canvas applications." Eager to follow this, alongside @reactflowdev. Tons of potential for innovative UI when 2D dragging of elements is no longer a development hurdle. tldraw.substack.com/p/tiny-l…

The difference between hacking and proper coding is whether you are working against or with a design.

Just found this app in the Atlassian Marketplace for doing the delivery side of Shape Up in Jira. If anyone tries it, I'd be interested to hear how it works. Info here: curiouslab.io

When it comes to product, "management" and "ownership" are popular terms. What we don't hear as much is "execution." Execution requires going further than saying what *should* be done. It means making trade-offs about what *can* be done under the constraints we have.

To do fixed time/variable scope, you need to be clear on what’s NOT variable. Variable scope doesn’t mean “figure it out during execution.” It means “here’s what’s truly important about the concept” and giving latitude for the rest. Most of the “variation” happens in shaping.

Yes. From @thorstenball

Very often the way to get a task done is to explicitly decide what about it you aren't going to do now.

I'm fascinated by this image from Mark Spitznagel's "Safe Haven". You hear about exponential growth all the time. His focus is on "logarithmic cost". When we take losses in a growth process, we fall down a curve that requires exponential gains to climb up again.

By far my most important takeaway from studying @bmoesta’s Demand-Side Sales 101 was learning to tell the difference between when I should describe a solution (active looking) vs. when I should tell a story about how someone else solved the problem (passive looking).

Just did the new kick-off scoping exercise in Miro to start building an app to do the kick-off exercise. 🌀 (Kick-off exercise explained here: world.hey.com/rjs/15-systemi…)

I've been using Miro for almost every step of the shaping process lately. It's fast (few clicks) and the defaults are usually what I want. I can copy/paste work at each step into future steps to make a long chain of history, showing how I got to where I got.

I really like how canvas apps let me "step back" from the work. Apple's productivity apps are pretty good at this too. You can do it in Numbers, Pages, etc.

Shaping isn't writing. It's not filling out a template or creating a document. It's getting to that "a-ha" moment together where the parts and their connections crystalize and we have something that will work. feltpresence.com/shaping-isn…

I'm writing a post on how to use a chain of tiny tools to incrementally shape a project. I wasn't sure how to start. The post felt big and complicated. Too many things to say. So what did I do? Shaped it incrementally with a chain of tiny tools... 🌀

In product development for manufacturing, gross margin is one of the important constraints up front. In software, we aren’t used to thinking about margin because the marginal cost of duplication is effectively zero. But that doesn’t mean we don’t have production costs! While we don’t cast tooling and build assembly lines and transform raw materials for each feature, there IS a production process, where we do work to get the new functionality from zero to one. When teams jump straight into building and pile up sprint after sprint after sprint — nobody weighs the cost vs. the outcome of the whole effort. No wonder so many teams now have to shrink and rethink their process! Not only was so much time and energy wasted, there was never a step in the process when anyone could look at the whole, decide what the effort was worth, and shape a solution to fit! This is why framing, setting the appetite, and shaping before committing to a project are so important. It’s not only about setting clearer direction and giving teams more autonomy — it’s about controlling costs and being strategic about our time.

Knowing the end state someone should be in and knowing the specific steps they should take next are two very different things. Applies to teaching, advising, UX. Moving forward requires taking steps. Designing those steps requires understanding where the person stands right now.

Made a lot of progress unpacking UX over the last year into different layers that need attention at different times. The first separation is between the architecture and the interior design, just like in a house. Consider a bathroom. The decision about where to place it is very much a matter of “experience”: the flow through the house, privacy, time to get there from other places, light, spaciousness of the room. These architectural decisions aren’t local to the room. They’re interdependent with the rest of the house. We’re talking about pipes and walls. They need to be figured out early, and entail major technical decisions. Contrast that to the tile in the bathroom, the color of the wall, the choice of tap fixture, the hardware on the cabinets, the decor. These are of course also matters of “experience” and they’re important. The interior decisions are local to the room, except for their interfaces with the pipes and walls. They can be changed many times without influencing the rest of the house. That means they can be done later, after the walls and pipes are in place. We can mirror this difference in the way we build software. Since walls and pipes come earlier, it makes sense to involve technical people up front in the shaping process. The output of our shaping can be more about wiring and how it’s connected than the pixels and how it looks. Since the interior design comes later, it means pixel-perfect Figma work can be constrained by the wiring that’s already built, instead of carte blanche. “Choose any fixture, but it has to connect to the pipe that’s there.” This helpfully constrains the detailed design, so the work that designers put their heart and soul into doesn’t get thrown away and hacked to pieces at the last minute.

Q: Our product is 15 years old, with legacy code ... four platforms. Our engineers say the minimum time they need to ship anything of real value is about three months. How can we apply Shape Up in a situation like this? A: Question everything. ryansinger.co/when-engineers…

Best programming book I’ve read in a long time: “Getting Clojure: Build Your Functional Skills One Idea at a Time” by Russ Olsen Makes functional ideas seem natural and simple. Very little theory, lots of real-world how-to. Well paced and sequenced. pragprog.com/titles/roclojur…

⭐️Thrilled to announce I'm now accepting applications for the first group of early-adopters for my new, intensive video course: SHAPING IN REAL LIFE Full outline of the course, dates and details here: feltpresence.com/srl

A well defined task isn't a boolean (checked, unchecked), it's a vector. Unknown → known. Known → implemented. Implemented → verified. Etc. It's like a diff in the future. From this to that. It answers the question: How will we know that this was done? Where will it take us?

Instead of starting with hi-fi designs, I prefer to start by laying the parts on the floor and wiring them up. First, get affordances on the page, wired to code, in an ugly way. Verify that it works and is useful. Then rearrange, style, and finish. Example from a WIP project.

I still believe this Theory of Twitter to be true: Twitter is where you go to say things that no one in your actual vicinity wants to hear. Explains both the terribleness and awesome niche-ness.

Working on a new app, with no MVC framework. Started to feel tangled. I couldn't see the tangles well enough from inside the code, so I zoomed out and refactored it visually. Better topology, better design.