The Daily Subset

Share this post

{36} Morphing Shapes, Reversibility & Prompting

www.dailysubset.com

{36} Morphing Shapes, Reversibility & Prompting

Featuring Jared Spool, algorithmic, Martin Fowler, Damon Chen, and Nick St. Pierre

Dane Lyons
Mar 2
2
2
Share this post

{36} Morphing Shapes, Reversibility & Prompting

www.dailysubset.com

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.


NPS: Alternative

Jared Spool

Twitter avatar for @jmspool
Jared Spool @jmspool
Looking for an alternative to NPS that could tell you if your design changes are improving your user’s experiences? This is an example of something that might work. (You’d want to tailor the answers to real problems you’re trying to address in the design work.)
Image
2:18 AM ∙ Dec 30, 2020
22Likes4Retweets

People are generally pro-NPS (net promoter score), so this opinion is unpopular, but I don’t like it. It’s a low-effort survey that produces a weak signal for determining how well your product is performing.

Managers might be motivated to implement NPS because good results can justify a raise. If the results aren’t great, they could be used as an accountability tool to punish the product team and get people to work harder.

To be fair, feeding a manager’s ego isn’t the only way to use an NPS score. It is possible to follow up with detractors and do things to activate promoters. But I can almost guarantee this doesn’t happen in practice. I’ve clicked 0 on many NPS surveys over the years, and I’ve not had a single follow-up.

Why are we wasting time doing the easy thing that doesn’t tell us anything meaningful about our products? With a little more effort, we can ask much more meaningful questions.

Directionally, I like what Eastern Bank is doing by asking more specific questions. People often avoid giving negative feedback because they worry about potentially causing someone to lose their job. So I’d opt for more positive wording. Here is an example:

Thanks for using our app! How can we improve? (check all that apply)

  • Faster load times

  • More intuitive instructions

  • More responsive customer service

  • Improved design or layout

  • New functionality (we’ll follow-up over SMS)

  • None of the above, great job 🙌

A survey like this would still be low-friction, but I’d be much happier to see it as a user. It would make me feel like my input is valued and I’m not just a number from 0-10. Product teams would also get a lot more value from the results.


SVG: Morphing Paths

algorithmic

Twitter avatar for @algoritmic
algoritmic @algoritmic
Smoothly interpolate between variations of SVG paths github.com/Minibrams/svg-…
2:11 PM ∙ Jun 28, 2022
2,788Likes309Retweets

Animating paths in SVG isn’t too difficult, but there are caveats.

  1. A basic CSS animation with paths really only works when you transition between 2 paths. If you need to combine more than 2 paths, you’ll likely need a JS solution that involves iterating over points and doing the math to determine new x/y coordinates. I assume that’s what this library does.

  2. I’ve found it difficult to work with paths that don’t have the same number of points. The transition is usually pretty janky.

The demo looks smooth. I’ll have to think about use cases to test it out.


Product Philosophy: Reversibility

Martin Fowler & Kent Beck

Twitter avatar for @martinfowler
Martin Fowler @martinfowler
Extreme Programming provides an undo button, a game-changer for a single team - @KentBeck . But multiple teams need ways to manage inter-dependencies. I particularly like that he indicates the importance of Slack
tidyfirst.substack.comScaling Extreme Programming: Dependencies(This will be the first in a series of posts about XP. I’m publishing them here because the overlap with Tidy First? readers seems substantial & the subscriber list is long. Please lmk if you’d rather I had channel/topic.) I have written before about Professor Zaninotto’s framework for understanding…
7:36 PM ∙ Feb 20, 2023
141Likes25Retweets

I’m not an extreme programming expert. I’ve probably spent 1 week of time in an XP environment over the last 20 years. But I find Kent’s article to be intriguing because it hits on 2 key concepts that teams should pay more attention to:

  1. Reversibility – It’s shocking to me how teams act as if every decision is permanent. If a decision actually is irreversible, take more time making sure you get it right. But the vast majority of decisions are reversible. For those decisions, you don’t need 100% confidence before taking the leap. Just do it, learn, and revert if needed.

  2. Dependencies – Kent really seems to embrace the idea that dependencies are just a fact of life when writing software. If your team is trying to move fast, you don’t always have the luxury of waiting for a design to finalize before you start building. He offers a lot of tips on working around that constraint such as merging teams to maximize communication or automating processes so people are less likely to become bottlenecks.

    I think it’s possible to remove a lot of dependencies without going full-on waterfall for project management. I should probably write a whole blog post about this but fundamentally developers should try to work in small iteration cycles and avoid projects with outstanding dependencies.

    For example, if a design is in progress and you are starting a new development cycle, avoid work related to the design. Go work on a project that doesn’t have dependencies. Bug fixing is always an option. If the design is ready when you start your next development cycle, pick it up and run with it.

    An autonomous workflow is required to minimize dependencies. A manager friendly environment with tight deadlines, no “slack”, and a focus on utilization will be dependency heavy.


Deployments: Bugs!

Damon Chen

Twitter avatar for @damengchen
Damon Chen @damengchen
Old me working in a big tech company: 'Oh no, it's a bug!' New me working for my own startup: 'Let's just ship it!
10:33 PM ∙ Mar 2, 2023

There is no obvious answer for determining when a deployment should be held up by bugs or code cleanup. Sometimes you should delay and “do it right”. Other times it’s better to deploy. I agree with Damon. The more experienced I get, the more likely I am to ship a bug.

Here is a question you can ask yourself when you find a last minute bug “Am I delaying the deploy purely because of my ego?”. If you are trying to avoid the embarrassment of someone seeing something that isn’t perfect, then you should get over it and ship the bug. Only hold things up if there is a good reason not related to your ego. An example might be a broken form that prevents users from accomplishing a key task.


Generative Art: Additive Prompting

Nick St. Pierre

Twitter avatar for @nickfloats
Nick St. Pierre @nickfloats
Here's a compilation of my Midjourney threads so far, including tutorials on how I use my Additive Prompting framework to generate characters/models, design sets, & more. Taking today off Twitter to work on animations & visuals for my YouTube series (link in bio) 🧵Thread
Image
5:32 PM ∙ Mar 2, 2023
349Likes40Retweets

If you find it frustrating trying to achieve a certain effect with generative art and Midjourney in particular, check out this thread. Nick goes into exhaustive depth covering a lot of common use cases.

His examples are primarily high resolution photos. But many of the techniques could be used for generating illustrations, sketches, and other styles.

2
Share this post

{36} Morphing Shapes, Reversibility & Prompting

www.dailysubset.com
Previous
Next
2 Comments
Austin Pocus
Writes The Pocus Files
Mar 3

I generally agree with the sentiment that we should defer decisions and avoid dependencies as much as possible, although I’m not sure that dependencies can be avoided as easily as all that once a project gets beyond the initial growth stages.

There aren’t just external dependencies to worry about — we have to consider internal dependencies in the code and architecture as well. In other words, there are some decisions that have to be made which will inherently affect other parts of the code, and sometimes those can’t be avoided once a project gets beyond a certain size.

This makes me wonder: can we keep projects small forever? Can we create only small projects that communicate with one another via well-defined interfaces, such that any given project never goes beyond a critical mass of complexity? If we can, I think it means we can avoid dependencies almost entirely.

What do you think? Can it be done? My mind immediately goes to Unix command line tools, though I’m sure there are other examples.

Expand full comment
Reply
1 reply by Dane Lyons
1 more comment…
TopNewCommunity

No posts

Ready for more?

© 2023 Dane Lyons
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing