[HN Gopher] Do something, so we can change it
___________________________________________________________________
Do something, so we can change it
Author : ingve
Score : 124 points
Date : 2023-08-03 14:54 UTC (1 days ago)
(HTM) web link (allenpike.com)
(TXT) w3m dump (allenpike.com)
| yieldcrv wrote:
| 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
| xsmasher wrote:
| 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 wrote:
| 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.
| iterativve wrote:
| > 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_ wrote:
| 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]
| slewis wrote:
| I call this "keep the fingers moving".
| shadowgovt wrote:
| 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.
| robertlagrant wrote:
| > 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-
| micros...
| echohack5 wrote:
| 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.
| em-bee wrote:
| _There 's no solving this problem because it is fundamentally
| human in nature._
|
| the solution is unity. you are right that with a someone in a
| position in power making decisions it can be very difficult to
| change that, but when the whole team makes a decision then the
| whole team can also change that decision.
|
| what is important here is to develop that mindset that
| everyones input to a decision is valuable. the challenge is
| that this requires trust that needs to be developed
| majormajor wrote:
| 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 wrote:
| 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.
| jahewson wrote:
| Well now this is what we call a false dichotomy.
|
| The version that I've always experienced in practice is "we
| spent six months fixing bugs and it's still broken, because
| we did not read the first page of the docs. No we do not want
| to read the docs now. Look I found a stack overflow post
| where some unknown, unqualified fool who is also incapable of
| reading the docs says to do it this way".
|
| Weeks of bug fixing can save you literally hours of planning.
| tikhonj wrote:
| I mean, if it was a good decision, it was a good decision.
| But there are a lot of ways for a decision to be bad without
| _legibly_ causing a _legible_ problem--and the "business"
| might be happy with that--but that doesn't make it a good
| idea!
|
| A common pattern I've seen is a team or organization getting
| in the habit of collecting little papercuts where no
| individual problem is bad enough to register but, over time,
| the codebase becomes slow and painful to work on. What's
| especially dangerous is that the state of the system informs
| people's expectations: what's easy, what's hard, what's
| possible at all. You get to the point where changes that
| should be easy are seen as inherently difficult and people
| start making strategic decisions that implicitly compensate
| for this, masking the accumulated problems even further.
| OkayPhysicist wrote:
| Currently working on a project like this.
|
| It's a 20 year old codebase, so it's gotten so bad that we
| spend 2 weeks planning something that could take me 1 week
| to write in the current codebase or 1 day to write in a
| sane codebase, on a product that I could probably re-write
| from scratch in a month.
| Buttons840 wrote:
| > 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?
|
| The flip side is often to ask the people doing the work for
| input, there's a good chance they know what's best. There's
| often a group that can make decisions and implement the
| decisions, and another group that can only make decisions,
| and so naturally we divide the work so that those who cannot
| implement the decisions make the decisions and those who can
| do both don't ever get to make decisions.
| NewEntryHN wrote:
| While I agree with the sentiment, I can see 2 counter-points:
|
| - "Nothing bad happens" might be the accumulation of risk
| until something _very_ bad happens.
|
| - Something bad might actually be already happening, only
| silently. For example, teams suffering unnecessary difficulty
| whenever they need to work on some part of the codebase, but
| it's considered "normal" because that's life now.
| jahewson wrote:
| This is so true. It still shocks me and I don't know why. The
| most frustrating version for me is when the original author of
| a solution didn't care all that much and would admit it was a
| hack but they're no longer around - and their successor thinks
| that what they've inherited is some sort of sacred object built
| on infinite and unknowable wisdom. So this obvious design flaw
| must actually be a carefully designed feature that were simply
| not capable of understanding. Maddening.
| hashmush wrote:
| I try to always add comments to such code that explicitly
| says exactly that. Something like:
|
| > This is a best effort hack based on X and Y. It might not
| be 100% correct. Feel free to improve it.
|
| > - Name, 2023-08-05
| wpietri wrote:
| > it is fundamentally human in nature. The egos are invested in
| the existing thing
|
| That is one thing that can happen, because it is _part_ of
| human nature. But it is not _the whole_ of human nature. if you
| have a culture of experimentation and two-way doors, people
| learn to invest not in one particular experiment, but the
| process of experimentation. They invest their egos not in one
| particular outcome, but in the team and their long-term
| success.
|
| I get that the dominant culture in American business is
| managerialism [1], where we all have to pretend that people
| currently holding power are brilliant, while they have pissing
| contests over their place in the corporate dominance hierarchy.
| But that's not the only way things can possibly work. I've
| lived different approaches, as has the author of the piece.
|
| [1] https://www.amazon.com/Confronting-Managerialism-Business-
| Ec...
| vlod wrote:
| Or take a risk and just replace the printer cartridge?
|
| i.e. the classic line "It's Easier to Ask Forgiveness Than It
| Is To Get Permission" ...Rear Admiral Grace Hopper
| robertlagrant wrote:
| The other thing the Rear Admiral said, which is applicable
| here, is, "Why does everyone keep attributing quotes to me?"
| [0][1]
|
| [0] https://quoteinvestigator.com/2018/06/19/forgive
|
| [1] https://spectrum.ieee.org/did-you-know-edison-coined-the-
| ter...
| vlod wrote:
| haha. fab, didn't realize that!
| golemotron wrote:
| > 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.
|
| Maybe. It can be as simple as loss aversion.
| micromacrofoot wrote:
| The concept of line-worker software engineers seems like the
| problem in this parable. People need the ability to have some
| small amount of override and the ability to make decisions
| without risking their jobs, even if it's somewhat boxed to
| their experience level. Leaving everything up to management
| only is a way to ensure that little gets done and no one's
| happy doing it.
| munificent wrote:
| I agree completely. Path dependency is such a huge component of
| how the world is built and many people are oblivious to its
| effects.
|
| Even the freeest "two-way door" decision becomes one-way over
| time because every day is a step farther away from that door,
| and another step you have to backtrack in order to go back
| through it.
| SomaticPirate wrote:
| Anyone know the subtext? What is the $44 billion dollar mistake
| the author is referring to?
| julianeon wrote:
| The acquisition of Twitter, which, to be fair, has done down a
| lot in value since then.
| Brendinooo wrote:
| 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.
| progmetaldev wrote:
| 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!
| chuckhend wrote:
| 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!
| robofanatic wrote:
| what if the cost of undoing is too high?
| xaellison wrote:
| everything is reversible for the right price. Too high a price
| = 'irreversible'
| staplung wrote:
| 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-
| functiona...
| hgsgm wrote:
| That's the person who launched Vista and fled to Amazon?
|
| He's also the person who once approved some request for money
| and complained that it was a waste of his time to ask for so
| little. I agreed, but, corporate policy.
| majormajor wrote:
| 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.
| irrational wrote:
| The majority of arguments I've seen at work turn out to be
| people taking past each other because they are using
| different definitions for the same words or they are starting
| with different assumptions. Eventually someone says, "When
| you say X, do you mean Y?" And "Are you assuming that Z?".
| Suddenly the argument goes away or is greatly simplifies. But
| it takes so much to get to that point. I don't know why
| humans are so poor at communicating.
| entropicdrifter wrote:
| Communication is NP-hard and the difficulty scales
| exponentially with each added layer of complexity.
|
| On top of all that, people in specialized roles tend to
| invent jargon, then use it as an excuse to treat others as
| inferior or outsiders instead of putting their ideas to the
| test by explaining them to the rest of the world. People
| who do that tend to be interested in maintaining an upper-
| hand status-wise rather than actually getting shit done.
| nine_k wrote:
| Communication is only NP-hard if you have zero prior
| context.
|
| In most cases, you already have 99.9% of the common
| language, including an acceptable common metalanguage
| embedded into it. Coming up with mutually understandable
| definitions is a bit of work, but it's far from
| unsurmountable.
|
| Note how many legal papers and even scientific papers
| start with definitios. Other technical communication
| should, too.
| progmetaldev wrote:
| One of the best things I ever did was to come up with a
| straight-forward definition of UI components in our CMS,
| so our designers and front-end developers could speak to
| each other and be on the same level. When new features
| were developed, and new components introduced, we would
| all agree upon what made up that component and document
| it.
| m463 wrote:
| 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 wrote:
| 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 wrote:
| 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
| excalibur wrote:
| > 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 wrote:
| 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.
| daniel_reetz wrote:
| "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 wrote:
| > 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 wrote:
| Really a great example of this strategy, which also shows up
| in metrology.
| tracker1 wrote:
| 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 wrote:
| Doesn't just go for software, but absolutely everything. A
| temporary solution is always the most permanent.
| denvaar wrote:
| 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 wrote:
| 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...
___________________________________________________________________
(page generated 2023-08-04 23:00 UTC)