{36} Morphing Shapes, Reversibility & Prompting
Discover more from The Daily Subset
{36} Morphing Shapes, Reversibility & Prompting
Featuring Jared Spool, algorithmic, Martin Fowler, Damon Chen, and Nick St. Pierre
Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.
NPS: Alternative
Jared Spool
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
Animating paths in SVG isn’t too difficult, but there are caveats.
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.
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
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:
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.
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
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
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.
{36} Morphing Shapes, Reversibility & Prompting
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.