7 ms·

Do something, so we can change it

228 points by ingve 3y ago

Brendinooo 3y ago
I like this. The first and last ten percent of the work is usually the hardest. If you have someone get something out, it gets you to that next stage.
- chuckhend 3y ago
  A lot of times its a more productive debate over the tangible 'something' thats out there too (even if its wrong), rather than the theoretic or a design!
- progmetaldev 3y ago
  Or you're like me, and the beginning of a project is crippling (mentally), and you analyze every "what if" leading to a mental use of 20% of your actual production time. Then deadlines kick in, and I work late and put extra time outside of office hours in. The software actually ends up being better because I've examined as many situations as I can, but it can't be good for my long-term health. I feel like I'm not the only one to suffer this curse. Yay anxiety, and booooo anxiety!
daniel_reetz 3y ago
"Action produces information". If you "do something, so we can change it" be sure to do it strongly in one direction or the other, so that you set the direction of exploration, too.
- apike 3y ago
  > be sure to do it strongly in one direction or the other, so that you set the direction of exploration, too. This reminds me of a game design technique Blizzard learned to use back in the day when balancing their RTS games. Sometimes they'd make a small change – say increasing damage by 4% – and playtest the result. It seemed, maybe better? So they'd ship it. Some time later, they'd realize they had way undershot, and the ideal increase would have been 25%. They sometimes found themselves buffing or nerfing the same thing over and over, trying to get it right. The approach that worked better for them was to err on the side of first overcorrecting – say, try increasing damage by 40%. This way, in playtesting they could clearly see the effects of having gone too far, then back off the change as appropriate.
  - daniel_reetz 3y ago
    Really a great example of this strategy, which also shows up in metrology.
  - commonlisp94 3y ago
    This is binary search/bisection.
  - PebblesRox 3y ago
    I’m familiar with this principle as “Alternate your mistakes.”
  - bemmu 3y ago
    Sid Meier also wrote the following in his memoir. One of my big rules has always been, "double it, or cut it in half". Don't waste your time adjusting something by 5 percent, then another 5 percent, then another.. just double it, and see if it even had the effect you thought it was going to have at all.
staplung 3y ago
A Joel on Software post[1] has this: A terribly common error is having a debate over how something should be designed, and then never resolving the debate. Brian Valentine, the lead developer on Windows 2000, was famous for his motto “Decisions in 10 minutes or less, or the next one is free.” [1]:https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/#:~:text=A%20terribly%20common%20error%20is,the%20next%20one%20is%20free.%E2%80%9D https://www.joelonsoftware.com/2000/10/02/painless-functiona...
- m463 3y ago
  I keep thinking about this - how microsoft's culture has led to its continual survival. They respond quickly to the market and ship features. The products work for people, but nobody loves the products, they tolerate them.
  - paulryanrogers 3y ago
    Windows 95 and 7 may be exceptions. I recall both being refreshing and met with enthusiastism and praise. Early versions of Microsoft Office as well were (at least at one time) considered a step up.
    - applied_heat 3y ago
      Corel shit the bed with WordPerfect 5 or 6. Non stop crashes. All word had to do to kill WordPerfect was not lose your work
    - brightlancer 3y ago
      Windows 95 was revolutionary over Win 3.11, but it also crashed _a lot_ and began the habit of reinstalling Windows as a general fix. Win 7 was stable and user-friendly, as was Win2k years earlier -- but for some reason, MSFT directed consumers to ME and Vista, which were garbage.
- majormajor 3y ago
  Yeah, I'm a big believer in finding 2-way decisions and starting fast, but even for 1-way decisions there's a pretty pervasive problem at a bunch of places of meetings that are arguments instead of decisions. Ego stroking for engineers instead of getting something done.
echohack5 3y ago
I want to agree with this post, but I don't. This person is in a position of power over their product. Instead, I have found that decisions work by "path dependency". If something works, even if it is a poor implementation, the path to get there is holy ground and the amount of effort to change a 10 minute decision that was made flippintly by two business people chatting in the urinals on a Wednesday is like trying to siege the walls of Jehrico. There's no solving this problem because it is fundamentally human in nature. The egos are invested in the existing thing -- so improving the proof-of-concept-that-is-now-hastily-shoved-into-production problem requires that you unravel every person's thoughts and pride on the current thing, regardless of the seriousness of the problem. And so the problem cannot get solved and change cannot happen unless something catastrophic occurs. Thus, the line-worker software engineer, who has no real organizational power, has to hope that the proverbial printer falls down a flight of stairs "accidentally" so that they can swap out the black ink cartridge to a new one that doesn't make weird bleed lines on the edge of every page. That way, when the new printer comes in, and someone complains that the ink bleed is gone and how they liked that, that you can feign ignorance.
- majormajor 3y ago
  Devil's advocate: if nothing bad happens resulting from the path chosen with that 10-minute-decision solution, is it fair to call it poor from the business perspective? Or even if something "mildly bad" happens, if the flip side was spending 3 weeks doing research until finally arriving at a 24% better approach, which of those costs is higher? If the team/org is too high-ego to actually treat 2-way decisions as 2-way decisions after they get made, I think that's a bit of a different problem. The org has to invest in the "so we can change it" part of the plan.
  - tra3 3y ago
    In my experience, a quick decision is often a poor decision. Most of the time it’s suboptimal but occasional it’s outright damaging. Most places I’ve worked at, claim that decisions are reversible, but they aren’t. Unless a process or a piece of software is actively and visibly misbehaving, nobody refactors it. There’s gotta be a balance between waterfall and fake agile, but I haven’t found it yet.
tracker1 3y ago
I have found that in general, the simplest thing that works, that is easy to replace tends to be some of the longest lived software I've worked on.
- moffkalast 3y ago
  Doesn't just go for software, but absolutely everything. A temporary solution is always the most permanent.
xsmasher 3y ago
I like this. I call it "making something solid enough to argue about." Once you get out of the realm of design docs and create something people can poke at the next steps become clear. Just do something to move the ball up the field.
dclowd9901 3y ago
I spent a minute at Amazon so I'm familiar with the one/two way door paradigm. It was one of the big takeaways I got from my time there, especially the aspect of trying to make more one way doors into two way doors. Often you don’t even consider this path because you’re so hung up on thinking through all the consequences of the one way door that you don’t just… stand back and check the frame, to extend a metaphor.
slewis 3y ago
I call this "keep the fingers moving".
SomaticPirate 3y ago
Anyone know the subtext? What is the $44 billion dollar mistake the author is referring to?
- julianeon 3y ago
  The acquisition of Twitter, which, to be fair, has done down a lot in value since then.
excalibur 3y ago
> Should we pay billions to buy a company, then systematically obliterate its accumulated reputation and userbase in an attempt to inflate our overgrown yet still incredibly fragile egos? Author explicitly said he was talking about Amazon, but I don't think he was talking about Amazon.
- sentientslug 3y ago
  That part was referencing Twitter, not Amazon. See the following (44bn number is a giveaway): > Maybe you put some conditions on your $44 billion acquisition offer, and – if the deal goes through – maybe you refrain from repeatedly permanently sabotaging it, like some kind of ridiculous gibbon. You know, that kind of thing.
robofanatic 3y ago
what if the cost of undoing is too high?
- xaellison 3y ago
  everything is reversible for the right price. Too high a price = 'irreversible'
iterativve 3y ago
> Do something, so we can change it This is what musicians do - put in nonsensical filler lyrics until they work out the rest of the song. Sometimes the throwaway lyrics are even kept. The Beatles did this to great effect in the Get Back documentary. It was so cool to see how the now legendary songs took shape. You got to start somewhere. Everything is iterative.
- Cthulhu_ 3y ago
  Video games are like that too, just put in default models, textures, placeholder music, and iterate until it's done. Mind you, some placeholders have copyright protection, IIRC a game shipped recently with copyrighted music that was used as a placeholder.
  - deleted 3y ago
    [deleted]
yieldcrv 3y ago
This matches my successful approaches too I’ve had many potentials partners be stuck in the “we support what you’re doing, let’s talk, and keep talking” phase and when I put them in the slide deck or team page that’s how I learn who is really with me everything from “use this picture instead, let’s rock!” to “Omg my firm can’t be involved in this!” Its much faster of a resolution than waiting for an undetermined ambiguous level of comfort that may never come
- neilv 3y ago
  > “we support what you’re doing, let’s talk, and keep talking” I was talking with a first-time co-founder recently, and had to break the news to them that many people in startup space will always say they're interested, and never say no. I've guessed it's to keep their options open, and to avoid/delay negative associations with the speaker that would come from saying no. (I suppose some might also do it for selfless reasons, of not wanting to discourage someone.) > and when I put them in the slide deck or team page that’s how I learn who is really with me I like that general idea, for cutting through some of the noise. I'll have to think about how to adapt it to my style.
shadowgovt 3y ago
As a solid manager once described it, "It's a lot easier to argue over an implementation prototype than to argue over a design doc." This was not an argument in favor of not writing design docs, but instead an argument in favor of moving towards prototype while waiting for people to weigh in on a design instead of doing nothing with that downtime.
denvaar 3y ago
I'll admit I only skimmed this article, but I think that I have noticed this sentiment as a boon during software development: Sometimes I will find myself in a position where I need some level of sign-off or approval from the team about something I'm trying to do. If I ask for opinions without showing anything concrete it's often crickets. However, if I make a pull request (or even a couple pull requests show casing different options) then it's much easier to find out people's thoughts. It may be more work for me, but it's better than the paralysis feeling of not being able to move forward, and it also helps me really understand some of the options at hand.
- Wxc2jjJmST9XWWL 3y ago
  I'm sorry if my comment isn't regarded as constructive... but you skimmed an 'article' consisting of three paragraphs, that takes maybe two minutes to read, but bothered to leave a comment on it? When I read "I'll admit I only skimmed this article" I though maybe due to blocked JavaScripts the article didn't load for me and I only read the preface of the actual article or something...
robertlagrant 3y ago
> maybe you refrain from repeatedly permanently sabotaging it, like some kind of ridiculous gibbon Great wording. I'll pick a forgotten reference, from not really that long ago. Anyone remember the Kin[0]? [0] https://www.engadget.com/2010-07-02-life-and-death-of-microsoft-kin-the-inside-story.html https://www.engadget.com/2010-07-02-life-and-death-of-micros...
ozim 3y ago
I do agree, most of the time I find people arguing about theoretical issues - once we get something built it is so much easier to improve it because it is so much easier to point and describe what needs to be changed or removed. Discussion on something that is actually done is much easier than the discussion about the theoretical issues.
deleted 3y ago
[deleted]
Animats 3y ago
For an opposing view, go read the showrunner rant.[1][2] The rant against "I'll know it when I see it." Well... it is true that not everyone believes that knowing what they want, and reaching out to those who need to know it in order to perform, is a necessity for success in the world of television... and this is the part where they come out from their slimy, shit-stained hole and excuse their lack of vision (or their unwillingness to impart that vision) with a defense I consider to be the most cowardly and thieving seven words in the showrunner's lexicon: "I'll know it when I see it." If you ever find yourself saying that, kindly consider the possibility that - and I mean this, from the heart - your impostor syndrome is most likely real and you are, in fact, a shrill, shrieking fraud. Here's what "I'll know it when I see it" means to me and to everyone who hears it from a showrunner: "I have no original ideas of my own but am perfectly willing to let everyone else spin their wheels and exhaust themselves emotionally and creatively so that I can eventually cherry-pick the best of their genius and claim it for my own." [1] https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_of_showrunning.pdf https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_o... [2] https://news.ycombinator.com/item?id=34867166 https://news.ycombinator.com/item?id=34867166
neilv 3y ago
> The director blinked. “Well, do something, so we can change it!” Related, but maybe distinct... I don't know how common it is among choreographers, but a methodological tool of at least one modern dance choreographer, working on a new piece, is to have a session with the dancers, and have them individually improvise a particular part, under some direction. Then she'll do things like, "Oo, everyone try what Jane is doing."
svilen_dobrev 3y ago
well, life is Change. More, Change is the only permanent thing (until universe cools to 0'00. Noone knows what's next anyway). But that eternal changing .. difficult to accept.. btw. there's a related pattern in the Organisational patterns of Agile book [1] - "Someone always makes progress".. [1] Organizational Patterns of Agile Software Development - James Coplien, Neil Harrison
sebastianconcpt 3y ago
The problem is that you can do that when is safely and reversible, the half of the advise that is missing is: fail fast[1] and safely[2] so you can improve[3] over the feedback[4] you get from a source that has the best interest in mind for your success[5]. 1 is the easiest. 2 should keep you out of "failing fast" with irreversible decisions or ones that have consequences of causing permanent damage or giving up your freedom or power. 3 are you coacheable enough to embrace the required level of mindset change? will you develop mastery for the next iteration at the required speed? 4 collecting quality feedback is not always trivial or cheap. 5 this is the hardest to get, are you surrounded/listening to true friends (celebrators of your success) or fake ones (envy in disguise poisonig misleading advice so they don't feel outshined by your success)?

228 points by ingve 3y ago

I like this. The first and last ten percent of the work is usually the hardest. If you have someone get something out, it gets you to that next stage.

chuckhend 3y ago
A lot of times its a more productive debate over the tangible 'something' thats out there too (even if its wrong), rather than the theoretic or a design!
progmetaldev 3y ago
Or you're like me, and the beginning of a project is crippling (mentally), and you analyze every "what if" leading to a mental use of 20% of your actual production time. Then deadlines kick in, and I work late and put extra time outside of office hours in. The software actually ends up being better because I've examined as many situations as I can, but it can't be good for my long-term health. I feel like I'm not the only one to suffer this curse. Yay anxiety, and booooo anxiety!

daniel_reetz 3y ago

"Action produces information". If you "do something, so we can change it" be sure to do it strongly in one direction or the other, so that you set the direction of exploration, too.

apike 3y ago
> be sure to do it strongly in one direction or the other, so that you set the direction of exploration, too. This reminds me of a game design technique Blizzard learned to use back in the day when balancing their RTS games. Sometimes they'd make a small change – say increasing damage by 4% – and playtest the result. It seemed, maybe better? So they'd ship it. Some time later, they'd realize they had way undershot, and the ideal increase would have been 25%. They sometimes found themselves buffing or nerfing the same thing over and over, trying to get it right. The approach that worked better for them was to err on the side of first overcorrecting – say, try increasing damage by 40%. This way, in playtesting they could clearly see the effects of having gone too far, then back off the change as appropriate.
- daniel_reetz 3y ago
  Really a great example of this strategy, which also shows up in metrology.
- commonlisp94 3y ago
  This is binary search/bisection.
- PebblesRox 3y ago
  I’m familiar with this principle as “Alternate your mistakes.”
- bemmu 3y ago
  Sid Meier also wrote the following in his memoir. One of my big rules has always been, "double it, or cut it in half". Don't waste your time adjusting something by 5 percent, then another 5 percent, then another.. just double it, and see if it even had the effect you thought it was going to have at all.

staplung 3y ago

A Joel on Software post[1] has this: A terribly common error is having a debate over how something should be designed, and then never resolving the debate. Brian Valentine, the lead developer on Windows 2000, was famous for his motto “Decisions in 10 minutes or less, or the next one is free.” [1]:https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/#:~:text=A%20terribly%20common%20error%20is,the%20next%20one%20is%20free.%E2%80%9D https://www.joelonsoftware.com/2000/10/02/painless-functiona...

m463 3y ago
I keep thinking about this - how microsoft's culture has led to its continual survival. They respond quickly to the market and ship features. The products work for people, but nobody loves the products, they tolerate them.
- paulryanrogers 3y ago
  Windows 95 and 7 may be exceptions. I recall both being refreshing and met with enthusiastism and praise. Early versions of Microsoft Office as well were (at least at one time) considered a step up.
  - applied_heat 3y ago
    Corel shit the bed with WordPerfect 5 or 6. Non stop crashes. All word had to do to kill WordPerfect was not lose your work
  - brightlancer 3y ago
    Windows 95 was revolutionary over Win 3.11, but it also crashed _a lot_ and began the habit of reinstalling Windows as a general fix. Win 7 was stable and user-friendly, as was Win2k years earlier -- but for some reason, MSFT directed consumers to ME and Vista, which were garbage.
majormajor 3y ago
Yeah, I'm a big believer in finding 2-way decisions and starting fast, but even for 1-way decisions there's a pretty pervasive problem at a bunch of places of meetings that are arguments instead of decisions. Ego stroking for engineers instead of getting something done.

echohack5 3y ago

I want to agree with this post, but I don't. This person is in a position of power over their product. Instead, I have found that decisions work by "path dependency". If something works, even if it is a poor implementation, the path to get there is holy ground and the amount of effort to change a 10 minute decision that was made flippintly by two business people chatting in the urinals on a Wednesday is like trying to siege the walls of Jehrico. There's no solving this problem because it is fundamentally human in nature. The egos are invested in the existing thing -- so improving the proof-of-concept-that-is-now-hastily-shoved-into-production problem requires that you unravel every person's thoughts and pride on the current thing, regardless of the seriousness of the problem. And so the problem cannot get solved and change cannot happen unless something catastrophic occurs. Thus, the line-worker software engineer, who has no real organizational power, has to hope that the proverbial printer falls down a flight of stairs "accidentally" so that they can swap out the black ink cartridge to a new one that doesn't make weird bleed lines on the edge of every page. That way, when the new printer comes in, and someone complains that the ink bleed is gone and how they liked that, that you can feign ignorance.

majormajor 3y ago
Devil's advocate: if nothing bad happens resulting from the path chosen with that 10-minute-decision solution, is it fair to call it poor from the business perspective? Or even if something "mildly bad" happens, if the flip side was spending 3 weeks doing research until finally arriving at a 24% better approach, which of those costs is higher? If the team/org is too high-ego to actually treat 2-way decisions as 2-way decisions after they get made, I think that's a bit of a different problem. The org has to invest in the "so we can change it" part of the plan.
- tra3 3y ago
  In my experience, a quick decision is often a poor decision. Most of the time it’s suboptimal but occasional it’s outright damaging. Most places I’ve worked at, claim that decisions are reversible, but they aren’t. Unless a process or a piece of software is actively and visibly misbehaving, nobody refactors it. There’s gotta be a balance between waterfall and fake agile, but I haven’t found it yet.

tracker1 3y ago

I have found that in general, the simplest thing that works, that is easy to replace tends to be some of the longest lived software I've worked on.

moffkalast 3y ago
Doesn't just go for software, but absolutely everything. A temporary solution is always the most permanent.

xsmasher 3y ago

I like this. I call it "making something solid enough to argue about." Once you get out of the realm of design docs and create something people can poke at the next steps become clear. Just do something to move the ball up the field.

dclowd9901 3y ago

I spent a minute at Amazon so I'm familiar with the one/two way door paradigm. It was one of the big takeaways I got from my time there, especially the aspect of trying to make more one way doors into two way doors. Often you don’t even consider this path because you’re so hung up on thinking through all the consequences of the one way door that you don’t just… stand back and check the frame, to extend a metaphor.

slewis 3y ago

I call this "keep the fingers moving".

SomaticPirate 3y ago

Anyone know the subtext? What is the $44 billion dollar mistake the author is referring to?

julianeon 3y ago
The acquisition of Twitter, which, to be fair, has done down a lot in value since then.

excalibur 3y ago

> Should we pay billions to buy a company, then systematically obliterate its accumulated reputation and userbase in an attempt to inflate our overgrown yet still incredibly fragile egos? Author explicitly said he was talking about Amazon, but I don't think he was talking about Amazon.

sentientslug 3y ago
That part was referencing Twitter, not Amazon. See the following (44bn number is a giveaway): > Maybe you put some conditions on your $44 billion acquisition offer, and – if the deal goes through – maybe you refrain from repeatedly permanently sabotaging it, like some kind of ridiculous gibbon. You know, that kind of thing.

robofanatic 3y ago

what if the cost of undoing is too high?

xaellison 3y ago
everything is reversible for the right price. Too high a price = 'irreversible'

iterativve 3y ago

> Do something, so we can change it This is what musicians do - put in nonsensical filler lyrics until they work out the rest of the song. Sometimes the throwaway lyrics are even kept. The Beatles did this to great effect in the Get Back documentary. It was so cool to see how the now legendary songs took shape. You got to start somewhere. Everything is iterative.

Cthulhu_ 3y ago
Video games are like that too, just put in default models, textures, placeholder music, and iterate until it's done. Mind you, some placeholders have copyright protection, IIRC a game shipped recently with copyrighted music that was used as a placeholder.
- deleted 3y ago
  [deleted]

yieldcrv 3y ago

This matches my successful approaches too I’ve had many potentials partners be stuck in the “we support what you’re doing, let’s talk, and keep talking” phase and when I put them in the slide deck or team page that’s how I learn who is really with me everything from “use this picture instead, let’s rock!” to “Omg my firm can’t be involved in this!” Its much faster of a resolution than waiting for an undetermined ambiguous level of comfort that may never come

neilv 3y ago
> “we support what you’re doing, let’s talk, and keep talking” I was talking with a first-time co-founder recently, and had to break the news to them that many people in startup space will always say they're interested, and never say no. I've guessed it's to keep their options open, and to avoid/delay negative associations with the speaker that would come from saying no. (I suppose some might also do it for selfless reasons, of not wanting to discourage someone.) > and when I put them in the slide deck or team page that’s how I learn who is really with me I like that general idea, for cutting through some of the noise. I'll have to think about how to adapt it to my style.

shadowgovt 3y ago

As a solid manager once described it, "It's a lot easier to argue over an implementation prototype than to argue over a design doc." This was not an argument in favor of not writing design docs, but instead an argument in favor of moving towards prototype while waiting for people to weigh in on a design instead of doing nothing with that downtime.

denvaar 3y ago

I'll admit I only skimmed this article, but I think that I have noticed this sentiment as a boon during software development: Sometimes I will find myself in a position where I need some level of sign-off or approval from the team about something I'm trying to do. If I ask for opinions without showing anything concrete it's often crickets. However, if I make a pull request (or even a couple pull requests show casing different options) then it's much easier to find out people's thoughts. It may be more work for me, but it's better than the paralysis feeling of not being able to move forward, and it also helps me really understand some of the options at hand.

Wxc2jjJmST9XWWL 3y ago
I'm sorry if my comment isn't regarded as constructive... but you skimmed an 'article' consisting of three paragraphs, that takes maybe two minutes to read, but bothered to leave a comment on it? When I read "I'll admit I only skimmed this article" I though maybe due to blocked JavaScripts the article didn't load for me and I only read the preface of the actual article or something...

robertlagrant 3y ago

> maybe you refrain from repeatedly permanently sabotaging it, like some kind of ridiculous gibbon Great wording. I'll pick a forgotten reference, from not really that long ago. Anyone remember the Kin[0]? [0] https://www.engadget.com/2010-07-02-life-and-death-of-microsoft-kin-the-inside-story.html https://www.engadget.com/2010-07-02-life-and-death-of-micros...

ozim 3y ago

I do agree, most of the time I find people arguing about theoretical issues - once we get something built it is so much easier to improve it because it is so much easier to point and describe what needs to be changed or removed. Discussion on something that is actually done is much easier than the discussion about the theoretical issues.

deleted 3y ago

[deleted]

Animats 3y ago

For an opposing view, go read the showrunner rant.[1][2] The rant against "I'll know it when I see it." Well... it is true that not everyone believes that knowing what they want, and reaching out to those who need to know it in order to perform, is a necessity for success in the world of television... and this is the part where they come out from their slimy, shit-stained hole and excuse their lack of vision (or their unwillingness to impart that vision) with a defense I consider to be the most cowardly and thieving seven words in the showrunner's lexicon: "I'll know it when I see it." If you ever find yourself saying that, kindly consider the possibility that - and I mean this, from the heart - your impostor syndrome is most likely real and you are, in fact, a shrill, shrieking fraud. Here's what "I'll know it when I see it" means to me and to everyone who hears it from a showrunner: "I have no original ideas of my own but am perfectly willing to let everyone else spin their wheels and exhaust themselves emotionally and creatively so that I can eventually cherry-pick the best of their genius and claim it for my own." [1] https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_of_showrunning.pdf https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_o... [2] https://news.ycombinator.com/item?id=34867166 https://news.ycombinator.com/item?id=34867166

neilv 3y ago

> The director blinked. “Well, do something, so we can change it!” Related, but maybe distinct... I don't know how common it is among choreographers, but a methodological tool of at least one modern dance choreographer, working on a new piece, is to have a session with the dancers, and have them individually improvise a particular part, under some direction. Then she'll do things like, "Oo, everyone try what Jane is doing."

svilen_dobrev 3y ago

well, life is Change. More, Change is the only permanent thing (until universe cools to 0'00. Noone knows what's next anyway). But that eternal changing .. difficult to accept.. btw. there's a related pattern in the Organisational patterns of Agile book [1] - "Someone always makes progress".. [1] Organizational Patterns of Agile Software Development - James Coplien, Neil Harrison

sebastianconcpt 3y ago

The problem is that you can do that when is safely and reversible, the half of the advise that is missing is: fail fast[1] and safely[2] so you can improve[3] over the feedback[4] you get from a source that has the best interest in mind for your success[5]. 1 is the easiest. 2 should keep you out of "failing fast" with irreversible decisions or ones that have consequences of causing permanent damage or giving up your freedom or power. 3 are you coacheable enough to embrace the required level of mindset change? will you develop mastery for the next iteration at the required speed? 4 collecting quality feedback is not always trivial or cheap. 5 this is the hardest to get, are you surrounded/listening to true friends (celebrators of your success) or fake ones (envy in disguise poisonig misleading advice so they don't feel outshined by your success)?