[HN Gopher] It's time to embrace slow productivity (2022)
___________________________________________________________________
It's time to embrace slow productivity (2022)
Author : rbanffy
Score : 221 points
Date : 2023-05-19 20:45 UTC (1 days ago)
(HTM) web link (www.newyorker.com)
(TXT) w3m dump (www.newyorker.com)
| 01969279809 wrote:
| [flagged]
| dang wrote:
| Discussed at the time:
|
| _Embrace slow productivity_ -
| https://news.ycombinator.com/item?id=29893695 - Jan 2022 (203
| comments)
| knodi wrote:
| I'm not sure what you mean by slow. A little push every day, is
| that slow?
| Chris_Newton wrote:
| I like the saying "slow is smooth and smooth is fast" as applied
| to software development. For all the talk of Agile processes and
| breaking creative work down into bite-sized chunks and
| prioritising collaboration and team productivity over individual
| contributions, ultimately our work is about _thinking_ and
| fundamentally it requires that each individual doing the work
| understands what needs to be done. Not investing enough time in
| gaining that understanding early on means wasting far more time
| later.
|
| IME, a huge amount of rework in modern software development
| results from diving into the implementation before the
| requirements were properly understood, a reasonable design was
| created and both were recorded in some useful form and reviewed
| by the relevant people to make sure everyone was on the same
| page.
|
| We seem to have gone from one extreme to another with our
| processes. We realised that waterfalls that start with months of
| requirements capture followed by months of BDUF aren't a great
| idea. But now we often seem to have one-paragraph tickets, maybe
| spend a few minutes thinking of some class names that look about
| right for each one, and then dive into coding. And then a week
| later we find that two developers working on three tickets have
| implemented the same concept four different ways and each of them
| was a different 75% of what the customer actually needed.
| [deleted]
| turtledragonfly wrote:
| > slow is smooth and smooth is fast
|
| Another phrase with similar meaning (and interesting history)
| is "festina lente" ("make haste slowly," in Latin). I named my
| company after it (:
|
| It's certainly an ancient concept. I feel like software is
| ultimately about humans organizing complex activities, and
| humans haven't changed that much in the past few millennia,
| even if the activities have gotten more complex and abstract.
|
| I feel like the ones-size-fits-all approach of trying to say
| approach X or Y is superior (eg: scrum vs. kanban vs.
| waterfall, etc) is totally off the mark. Different sorts of
| work require different sorts of effort. Creative and full-of-
| unknowns work is different from assembly-line sort of work is
| different from maintenance work, etc.
|
| On a meta level, I think part of the "slow is smooth..."
| philosophy is to take a deep breath at the beginning and think
| about what sorts of approaches are going to be best suited for
| the tasks at hand. As opposed to some mindless "scrum is in, so
| we'll do that for everything". Or "everyone is using NoSQL now,
| so we should too" or any number of other cargo-cult-y
| behaviors.
|
| Festina Lente!
| natmaka wrote:
| Fast is fine, but accuracy is everything. In a gun fight...
| You need to take your time in a hurry. -- Wyatt Earp
| mkoubaa wrote:
| My mom has a saying in Arabic that roughly translates to "he
| who rushes is delayed"
| sdoering wrote:
| The German press agency (DPA) has (had?) a saying/motto:
|
| > Be first, but first be right.
| narag wrote:
| Another one for the collection: _visteme despacio que tengo
| prisa_.
| rtp wrote:
| Another saying "work smart not hard", i.e. you can save a lot
| of time by thinking things through before jumping into
| executing.
| kiliancs wrote:
| I like the Spanish saying "Visteme despacio, que tengo
| prisa": "dress me up slowly, since I'm in a rush".
| GuB-42 wrote:
| Another one is Blue Origin's motto: "Gradatim Ferociter",
| which translates to "Step by step, ferociously".
| namaria wrote:
| >I feel like software is ultimately about humans organizing
| complex activities
|
| Organizations are much like software: embodiment of domain
| knowledge. It needs to be codified, and if you're not
| actively cultivating it locally, you're outsourcing the one
| thing that matters: learning.
|
| It's a 100% in the interest of incumbent players to divulge
| ready-made pretenses of universal solutions. It precludes
| competition.
| JJMcJ wrote:
| The famous UCLA basketball coach John Wooden used to say "be
| quick but never hurry".
| tpoacher wrote:
| The directly equivalent proverb in English is: "Less haste;
| more speed."
| jcrben wrote:
| One problem of delaying the coding is that it takes 5 minutes
| to dream up requirements that could take a millennia to
| complete. Coding is often the hard part actually, especially in
| some of the large slow moving corporations where coding is
| often delayed by lots of requirements brainstorming.
| josephg wrote:
| Right; but the problem is that you usually don't really
| understand what you're building until you're halfway through
| building it. Specs inform code, and code also needs to inform
| the spec. Both because we learn more about how it will be
| used, and because there's usually a clean, simple,
| straightforward way you can build something that won't
| exactly match up to feature list in front of you.
|
| Worse, I never seem to get those abstractions quite right
| until I've gotten them wrong a few times. If you don't take
| the time to iterate and build some knowledge of the solution
| space, anything you make will be a bit of a buggy, fragile
| mess.
|
| And I think it's much easier (and more efficient) to do that
| iteration during development than spend years building
| something messy and then try and remake it from scratch,
| cleaner, later. But that means it takes more time to get to
| market, and that's a really hard pill to swallow (for good
| reason).
| fzeindl wrote:
| > ultimately our work is about thinking and fundamentally it
| requires that each individual doing the work understands what
| needs to be done.
|
| Usually the individuals doing the work do understand that, but
| it is really hard to properly divide work and describe
| requirements. Why people try do divide it in even smaller tasks
| which increases this kind of complicated creative-writing work
| is beyond me.
|
| > We realised that waterfalls that start with months of
| requirements capture followed by months of BDUF aren't a great
| idea.
|
| What we should have realized by now is that we never did
| waterfall right because it's inventor Winston Royce required it
| to be done TWICE for each project. Two iterations.
|
| What this world needs is Atlassian hiring a number of work
| psychologists and theorists and have them streamline JIRA based
| on their learnings. Not in a UX "I want to create a
| story"-story sort of way. But in a "How do I deal with 50
| tickets that are vastly different in quality?" sort of way.
|
| They should answer questions like: "How can we make it so that
| the user always immediately knows whether to put this text in
| JIRA or confluence"?
|
| Then Microsoft needs to hire the same people and improve text
| creation in outlook.
| namaria wrote:
| >What we should have realized by now is that we never did
| waterfall right because it's inventor Winston Royce required
| it to be done TWICE for each project. Two iterations.
|
| Reading the original waterfall paper was eye opening for me.
| I saw that we're falling into patterns that are decades old.
| Someone insightful tries to explain that learning and
| building are two sides of the same coin, and companies read
| it as "ok, I need a learning team and a doing team" and run
| with it in the wrong direction. Taking the conceptual
| structure of some paper of manifest and applying it cookie-
| cutter style is missing the point entirely.
|
| What Conway and Royce were trying to convey is that the
| social process that underlies software matters. What people
| do with it on the field is using the examples employed in the
| explanation and mistaking them for the solution to their lack
| of respect for the intricacies of social processes.
| fzeindl wrote:
| You might like the book "The heretic's guide to best
| practises".
| namaria wrote:
| Looks very interesting, thanks for the tip!
| uoaei wrote:
| A somewhat related tangent is the idea that "writing is
| rewriting". Hardly, if ever, is a first draft suitable for
| publication, not just because it's rough-hewn or unrefined
| but also because requirements for some chapters change once
| others are written. The feedback loops between dependent
| parts of a written piece are dynamic, not static.
|
| (Yet another reason why LLMs are so limited: they take
| their earlier writing as sacred and unchanging as a direct
| consequence of their autoregressive structure.)
| talideon wrote:
| People keep saying Royce invented Waterfall, but he didn't.
| At most, he used it as a straw man. What Royce actually
| advocated was an iterative model. You're right that his
| approach recommended _at least_ two iterations, but not that
| his approach was the Waterfall model.
| datavirtue wrote:
| Waterfall also uses an iterative model. Inescapable when
| building software. The myth needs to die so we can
| progress. Waterfall, as a typical corporate tech fad, WILL
| emerge eventually.
| jamies wrote:
| I love that you quoted "slow is smooth and smooth is fast" -- I
| learned it as a volunteer firefighter! It's a great saying, and
| can be applied to just about anything.
| JackMorgan wrote:
| Another wacker in the wild! I'm taking Fire 1 (final burn
| today actually) and the instructors are always yelling "don't
| run, just move with purpose. MORE PURPOSE THAN THAT NUMBER
| 14"
| nonethewiser wrote:
| Sex?
| datavirtue wrote:
| The typical waterfall assumptions are very overblown. We are
| doing ourselves a great disservice by throwing it away. Hardly
| anyone developing today has ever used waterfall much less
| agile.
|
| The waterfall:bad, agile:good trope is really tiring. Like
| listening to a teenager that knows jack shit explain how the
| world works.
| Falkon1313 wrote:
| >breaking creative work down into bite-sized chunks
|
| In my decades of experience in multiple companies doing
| 'agile', that's something that we've always ostensibly strived
| for, but in practice it almost never happens in reality. At
| least not as intended. Occasionally it happens, but only by
| pure chance.
|
| It seems the 'agile way' is to attempt to manage a project by
| taking a sizable but coherent and cohesive
| concept/feature/requirement/design/plan, shatter it into a
| thousand incohesive random fragments of varying sizes (all
| estimated to be bite-sized, but true size unknown until they're
| actually done).
|
| Then everybody grabs a few fragments and works on them, placing
| them somewhere more-or-less where they're hopefully supposed to
| be, hoping that in the end everything will come together
| somewhat similar to the picture on the box. Then everybody has
| to try to duct-tape and glue them all back together again on a
| herky-jerky schedule, like doing a puzzle with constant
| interruptions and distractions for the agile rituals.
|
| The results aren't necessarily worse than waterfall/BDUF, but
| not necessarily better either. There is in truth a lot more
| potential to course-correct along the way. But since everyone's
| spastically going different distances in different directions
| at different speeds on as-yet-unconnected fragments of varying
| sizes, and no one can see the big picture, that theoretical
| course correction en-route is not nearly as powerful as it
| sounds.
|
| I've seen some debates about shorter vs. longer sprints. The
| die-hard agile people tend to push for the shortest sprints
| possible or even shorter, leaving no time whatsoever to clarify
| requirements, work out integrations, or do any QA/testing. No
| time for thought at all, just spit out some code, any code, as
| fast as possible and then it's review/demo/retro time. The
| veterans push for longer sprints, with time to understand and
| coordinate, experiment and test. But that gets a lot of
| pushback for not being agile enough, so we usually end up
| somewhere in the middle. And a lot of things don't fit neatly
| into that timeframe.
|
| Which in my opinion is not the worst thing, but also nowhere
| near as efficient or as effective as it could be if things were
| not broken into bite-sized chunks with arbitrary deadlines, but
| instead developed as parts of a cohesive whole. Whether from
| the foundation up (risky) or by building vertical segments and
| linking them together.
|
| "Move fast and break things" indeed. That's the state of the
| art - breaking things as fast as possible. We could do better.
| chii wrote:
| It all stems from the desire by stakeholders (who are paying
| the money) wanting to know when something is gonna ship,
| before committing the money.
|
| I think it should just be accepted that it is not possible to
| know. Unlike building a building, you cannot know. It is
| possible to do a feasibility study, or a prototype, and time
| box it, but that is as good as it gets.
|
| The stakeholders don't want to hear this unfortuantely. They
| refuse to believe it isn't possible to know ahead of time how
| much work is needed. In order to appease, the engineers and
| managers have developed a set of "practises" such as agile,
| but in the end, it is a lie.
| ResearchCode wrote:
| Yes. Nobody asks a mathematician to "story point" the
| conjectures they are working on. Nobody asks them for daily
| status updates. This is pure and harmful micromanagement
| because software engineers are not saying stop it.
| ResearchCode wrote:
| The optimal sprint length is none. It's an awful concept that
| is misused to micromanage highly skilled professionals that
| often didn't learn to say no. You want to work on three to
| six month projects, not two week "sprints".
| _gabe_ wrote:
| I couldn't disagree more. The worst codebases I've seen in my
| career have been codebases that were religiously planned
| upfront, and then religiously adhered to The Plan. Irregardless
| of the revelations that popped up in the midst of development.
|
| This usually takes the form of pattern driven developers: the
| developers that must fit the entire problem into a
| predetermined pattern (which is ridiculous because every
| problem is unique and there are very few patterns that are
| truly applicable everywhere). This will also take the form of
| Amazon's famous 6 page design upfront. It's funny, they wanted
| me to prescribe what the expected latency of a system that
| would be running over an unreliable network was and figure out
| an SLA based on that, _before I wrote an ounce of code_! How in
| the world are you even supposed to begin getting accurate
| measurements, _without measuring_!
|
| So, planning is good yes. But the reality is every problem is
| unique. Unless you have somebody who's solved the exact problem
| you're trying to solve, planning is going to do no good and
| you're better off _exploring_ first. Once you became a domain
| expert in your tiny niche domain you just explored, then you
| get to make a plan.
|
| But enough with this nonsense that we can magically figure out
| what the exact requirements are for a problem before we've even
| begun to measure the appropriate metrics associated with the
| problem. And one of the key ways we can measure stuff is by
| exploring the problem space with code.
| tornato7 wrote:
| I've recently become a big believer in Python notebooks to
| plan out these sorts of designs. It allows you to quickly
| mock up and iterate on a few prototypes to build your
| expertise, and then actually document a proposed design
| alongside working code that demonstrates the functionality.
|
| The bonus is, being a Python notebook, you usually avoid the
| common pitfall of shipping crappy prototype code to
| production; you are forced to rewrite it because putting a
| Python notebook into prod would make any software engineer
| shudder.
| jokethrowaway wrote:
| Agile processes is an oxymoron.
|
| "Agile" coaches scammed you
| kqr wrote:
| Not at all. There are repetitive elements of agile
| development too. Or do you invent a new way to e.g. deploy
| your code every time you put it into production? Come up with
| a new format for retros? Vary the lengths of sprints and the
| check-in points in them?
| lloydatkinson wrote:
| One paragraph tickets? At my previous job that would be
| considered a miracle!
| atoav wrote:
| Fast and stressed is where _The Mistakes(tm)_ happen, and
| depending on the thing you are working on those may not be
| recoverable in time.
|
| When I am under time pressure I slow down a notch. Over the
| years my slow speed has gotten faster as well.
| hinkley wrote:
| MVP works when everyone on the team is seasoned. All of the
| members of the Agile Manifesto were seasoned. As were many of
| the people they tended to work with.
|
| For the rest of us "slow is smooth" means you should work on
| something that is analogous to the most important functionality
| first, to build your ability to do that work. Then as you gain
| skill, tackle harder and harder problems.
|
| Sometimes the rule of three lets you go back and fix so,e of
| that early poor ordering, but that doesn't always trigger at
| all and sometimes triggers when you still don't know what
| you're doing. And then everything you do later is hampered by
| getting things wrong up front.
| benji-york wrote:
| Might I suggest that instead of working on "the most
| important functionality first" you consider identifying the
| riskiest aspects of the project and working on those first?
|
| Some times those are the same, but often the part of a
| project that sinks it isn't the core functionality but some
| prerequisite that turns out to be much harder than
| anticipated.
| hinkley wrote:
| No that's the problem. The riskiest bits stay risky forever
| if you tackle them before you understand how. Junior people
| or new problem domains require exploratory development
| before committing to a strategy.
|
| In an 18 month or three year project, it doesn't affect
| your deadline much if you do the hardest bits in month one
| or month four. Except in how much rework you end up doing
| to those parts that have already started to cement bad
| habits.
|
| When we have a Rule of Three situation in the product
| backlog, I usually recommend one of two strategies. Do the
| hardest one second, or do it third and allocate very little
| time for the first two - you're going to rework the whole
| thing when you get to #3 anyway.
|
| On one project, no matter what order we did them in, the
| third one took the longest time. Even when we tried to take
| our time on the second. Took me a year to train them to
| stop doing that. I've never seen a team so sure of their
| abilities yet with such a low opinion of their product. Big
| ol' echo chamber.
| atchoo wrote:
| > slow is smooth and smooth is fast
|
| I've been in enjoying the converse of this i.e. "fast is
| smooth". It was provoked by using an ultra-fine fountain pen
| nib - too slow and it would be scratchy and dig into the paper
| with poor ink flow but using it very fast and lightly and it
| would be really smooth and delightful.
|
| I am prone to perfectionism, overthinking, procrastination,
| majoring in the minors and getting derailed by little hiccups.
| I get motivation by seeing progress. If I pause I can struggle
| to get started again so momentum is really important or I fall
| into a negative spiral.
|
| For my personal productivity, it helps to force a pace and do
| things faster than I naturally want. I need to keep up momentum
| and quickly do the known things and discover the problems early
| that need time to percolate in the back of my mind to reach a
| creative solution.
|
| I guess we all need productivity epithets that counter our
| dysfunctional traits - too slow then speed up! too fast then
| slow down!
| m3kw9 wrote:
| Sometimes software engineers forget coding should be the final
| step, and not the main step. Defining as much as you can,80/20
| before starting will save you time. Certainly there are cases
| where you have an idea and you dive right in and it will work
| out but usually that won't work out well from my experience
| geraldwhen wrote:
| For me it's the main step. Decision making up front would
| require literally 40+ people, none of whom claim they have
| authority but all of whom say they MUST be involved in
| planning.
|
| Or, I could deploy something to QA and ask for feedback and
| forgiveness. Then a 3 week discussion becomes a 30 minute
| demo + a few small notes.
| prox wrote:
| On this theme I can heartily recommend SovietWomble's essay
| on the game the Forest (Soviet was a QA specialist in a
| former capacity)
|
| https://www.youtube.com/watch?v=PUWg905fGTA
|
| Both funny and insightful for anyone starting a project.
| liamN wrote:
| For me, as a rookie developer, I find I often have little to
| no clue what needs to be done until I've started coding and
| figured out through trial and error how to implement it and
| what the requirements even should have been up front.
| jon-wood wrote:
| Just because I feel more people should hear this early in
| their career, that's perfectly normal. I fairly routinely
| answer questions about how long a piece of work is going to
| take by saying I'm going to need n days to work out what
| needs to be done, after which I'll be able to give an
| estimate.
|
| That sort of exploratory work is really good because you'll
| end up reading relevant documentation, then actually trying
| to use whatever it is you're learning about. Often I'll
| throw together a hacky version of what we're aiming for,
| but ignore anything but the happy path. No error handling,
| no UI beyond the bare minimum, just the very core of what's
| being done.
| ess3 wrote:
| And on that note the "trick" to being more experienced is
| being able to anticipate what's coming up next and
| already have a mental model for how to solve that.
|
| Easier said than done though
| proper_elb wrote:
| Heh, I don't think that will ever _really_ change. What
| changes in my experience is your knowledge and confidence
| when it comes to translating requirements into maintainable
| technology. The real world stuff seems to be always messy.
| My attitude is to try to locate areas of potential unknown
| risk, plan how to deal with the known risk and then hack
| away, knowing that no matter how much time spent, the plan
| will be flawed. During this whole process, communication is
| really important (i.e. 30% feedback, where I just write
| comments of what I would change in the codebase and then
| talk about it with a collegue)
| com2kid wrote:
| On the flip side, a lot of exploratory coding is often
| necessary to learn exactly what needs to be done. "Oh this
| API sometimes returns garbled garbage results, guess we need
| to write a sanitizer for its output" isn't something that is
| going to be known until at least some code is written.
| Chris_Newton wrote:
| Definitely, exploratory coding can be very useful. It's
| essentially writing code to help identify the requirements
| or design instead of to help implement them. As long as
| management understands that you might be writing different
| code for each case and you can't necessarily turn one into
| the other...
| asdfman123 wrote:
| At my company we have a nightmarish combination of a lot of
| docs and meetings but also the pressure to produce a lot of
| artifacts, so we have "planning" but it could be a lot better,
| uh, planned.
| crazygringo wrote:
| > _and fundamentally it requires that each individual doing the
| work understands what needs to be done_
|
| Which is precisely what agile is about, specifically the
| estimation process. No story enters the sprint unless there is
| unanimous consensus among the engineers as to its point value,
| and it's the process of coming to that unanimity that makes
| sure each individual understands what needs to be done.
|
| A lot of people like to complain that agile slows down their
| coding, and this is by design -- to achieve exactly what you're
| asking for.
|
| > _But now we often seem to have one-paragraph tickets, maybe
| spend a few minutes thinking of some class names that look
| about right for each one, and then dive into coding._
|
| That isn't agile. If you're estimating a new story the team
| hasn't discussed before, it's usually going to take between 5
| and 30 minutes to come to consensus on its size and what it is
| conceptually.
|
| So the main problem you're describing is what Agile _solves_.
|
| Then you seem to have a secondary problem which is about
| different team members working in incompatible ways in terms of
| coding architecture. That require a team lead who is in charge
| of architecture decisions, that team members consult with
| whenever they start a story that there's no precedent on how to
| build. And code review ensures code is written as planned.
| uhtred wrote:
| >No story enters the sprint unless there is absolute
| consensus among the engineers as to its point value, and it's
| the process of coming to that point value that makes sure
| each individual understands what needs to be done.
|
| I call bs.
|
| Are you telling me that the less experienced / less confident
| devs on the team don't cave to pressure from the team lead or
| whoever happens to be the most forceful / loudest to agree
| that, ok, this is only a 5 pointer and we all understand what
| needs to be done, because DAVE says it's easy, 30 minutes
| work tops, and DAVE is tired and has better places to be.
|
| You write as if the team is all top engineers with equality
| and not one leader and his minions.
| crazygringo wrote:
| Well, yes, I'm telling you exactly that. That's how
| planning poker works, you have to speak up. You don't even
| have a choice because the process requires you to.
|
| It sounds like you have a very dysfunctional team if you're
| characterizing it as a team leader and his "minions".
|
| I'm sorry that's your situation.
|
| Some larger corporations have agile facilitators precisely
| to nip this kind of problem in the bud.
| ResearchCode wrote:
| Playing "poker" at work and having agile helpers sounds
| like extreme dysfunction.
| [deleted]
| crazygringo wrote:
| Well sure, anything can "sound like" extreme dysfunction
| if you don't actually know what it is.
|
| Do you know what planning poker is, and are you aware
| it's not a game for fun?
| ResearchCode wrote:
| To be fair having demeaning names for the engineers' work
| activities is not the worst part of corporate agile.
| Unfortunately.
|
| I have heard some third tier companies and lower play
| "planning poker" at work. It doesn't sound like any fun
| or efficient but a cheap paycheck for an "agile helper".
| I am not sure how many of them have remained employed
| during these layoffs.
| crazygringo wrote:
| It's not supposed to be fun. It's work, not a game. It's
| productive because it results in more accurate estimation
| of tasks, and a better understanding of the work
| entailed.
|
| Are you against those things? "First tier" companies use
| planning poker as well, you know.
|
| You seem to be oddly hostile to the concept without
| seeming to understand it at all.
| ResearchCode wrote:
| I don't think there's much evidence if any at all that it
| provides more accuracy or understanding. First tier
| companies tend not to use "sprints" at all.
|
| There's nothing to understand, the agile manifesto or
| worse the "scrum" pamphlet can be read on a lunch break.
| Somehow engineers who put ten-thousand hours into their
| craft need a layman agile helper to understand it?
| crazygringo wrote:
| Every sentence of your comment is factually incorrect or
| irrelevant. I'm not going to continue a conversation with
| someone who doesn't have an interest in facts.
| ResearchCode wrote:
| What you might actually mean is that you are going to try
| to sell agile snake oil to someone who knows less. Try a
| middle manager without technical background? They tend to
| be more receptive.
| re-thc wrote:
| That's not an agile problem so where's the bs? If your team
| is not following agile you can't just blame it.
| omginternets wrote:
| You can certainly criticize a methodology for being
| difficult or impossible to follow.
| crazygringo wrote:
| But it's easy to follow if a scrum master, facilitator,
| PM or team lead actually just does it.
|
| There's nothing difficult or impossible about it at all.
|
| But it's true that if the leader doesn't _want_ to follow
| it that it 's not going to work. It requires the person
| in the position of authority in the room to buy into it.
| No process will ever work if it's not actually being
| implemented by anyone.
| asdfman123 wrote:
| And also, do people actually plan it out or do they just
| approve every idea that doesn't sound terrible?
|
| Software is complicated. Half the time I don't know what
| the hell anyone is talking about due to labyrinthine
| requirements, but I'm not going to stop the meetings to ask
| questions unless I'm the main guy working on it.
| crazygringo wrote:
| But nobody knows who will work on it and you'll stop the
| meeting during the blind estimation process because you
| have to estimate points and you don't know what anybody
| else is estimating.
|
| All of the points you're raising are solved inherently by
| the way points estimation works with the points playing
| cards.
|
| You're not stopping the meeting. But it will be your turn
| to explain why you think it's the number of points you
| chose, so you'll do that.
| Mizoguchi wrote:
| Isn't changing requirements one of the key principles of the
| Agile manifesto?
|
| If so, why do we want to dive so much into requirements that
| are likely to change anyways?
|
| Not saying we should jump into design without understanding the
| requirements, but sometimes requirements are incomplete or not
| clearly defined and we cannot sit and wait until a new revision
| is out or someone becomes available to answer our questions.
|
| I guess this really depends on the area we operate.
|
| In my business domain we call requirements "wish lists" as the
| solutions we build are for complex hardware that generally
| doesn't exist yet and there's a good chance the requirements
| spec you got today will be rewritten in six months, yet we need
| to start working as soon as the project is launched.
|
| So we have learned to design things that are reasonably easy to
| adapt, replace and test, we even developed an entire framework
| for this very purpose that has become some sort of spinoff
| business as some customers wanted to use it for their in house
| development.
| Chris_Newton wrote:
| _Isn 't changing requirements one of the key principles of
| the Agile manifesto? If so, why do we want to dive so much
| into requirements that are likely to change anyways?_
|
| Who says all the requirements are likely to change anyway?
| That's a whopping great hypothetical on which the entire
| premise rests, but YAGNI applies to development processes as
| much as to code!
|
| Yes, requirements often evolve and we often start with some
| gaps or ambiguities in the spec. However, that's a very
| different situation to having no detailed requirements at
| all. In one case, you know where you're trying to go right
| now and can set a course that will take you there. Even if
| the destination is changed a bit during the voyage, you can
| adjust your course to compensate and still be heading in
| roughly the right direction. In the other case, you literally
| don't know which way to start.
|
| Moreover, jokes about skyscrapers turning into spaceships
| aside, the central requirements for a software project
| usually evolve relatively slowly. Business priorities or some
| of the details might change faster, but in most fields the
| underlying domain concepts and actors that the software
| models are going to be relatively stable.
|
| Big pivots where you're effectively trying to build a
| completely different product afterwards do happen. However, a
| team that pivots so often that it never really understands
| where it's trying to get to before changing direction again
| won't last long because it can never get far enough in any
| direction to deliver real value.
| kqr wrote:
| The tricky bit, in my experience, is that when you straight
| up ask the customer for requirements you get a list full of
| details around specific functionality -- basically all the
| stuff that's going to change in a month.
|
| It takes skill and effort to abstract from these detailed
| wishlists into generalised primitives which remain somewhat
| constant. This work is similar to the fuzzy logic social
| scientists work with, and that's exactly the sort of thing
| most techies are not very good at.
| Chris_Newton wrote:
| _It takes skill and effort to abstract from these
| detailed wishlists into generalised primitives which
| remain somewhat constant._
|
| 100% agreed. It's well worth doing it if you have the
| chance, though. Understanding how your customer sees
| their world and what problems they're _really_ trying to
| solve is valuable both for building a useful product and
| for keeping that customer happy!
| knodi wrote:
| The changing requirements part is mystifying part of Agile.
| How do you build the a proper foundation without knowing the
| base requirements it needs to support day one and plan for
| day 30/60/90/365 days needs. Its almost like its written by
| the PO/PM without really understanding anything else but
| their slice of work and how they can make it easier for them.
|
| Money and time (for us humans) are finite, big things at
| lease have to be targeted precise efforts, a good plan and
| architecture that maps back and supports the requirements.
| MichaelRo wrote:
| In 20+ years I don't think I ever worked on a "well-defined
| problem".
|
| It's always a fuzzy nebula and the only way to get insight is
| to build some prototype, see how it behaves and improve upon
| it. With the inevitable "suboptimal" early design somehow
| enduring and adapting through successive iterations, never
| have time or be able to afford a full rewrite from a business
| perspective: stuff works for the client, regardless how
| terrible the engineers view the build process. So people love
| to lament how awful the early choices were and how far in
| outer space we'd be, should some shiny late-stage idea have
| been applied. But it's a lot more like the x86 CPU
| architecture, in spite of all the detractors, it endures.
|
| Ahh, and I've also worked for a company that did rewrites. A
| lot of them. Like every time the product reached some 80-90%
| of functionality, they'd throw everything away and redo from
| start. Never shipped anything in my entire stay there. Again
| in my life I never seen such a thing, it's like the managers
| were not right in the head and developers were lacking any
| common sense. So it shouldn't come as a surprise that now
| (after some 5+ years of this) they closed and fired everyone.
| camjohnson26 wrote:
| On the flip side the code bases I've worked with that were
| built with exploratory coding, instead of deeply
| understanding the problem and designing a solution, tend to
| be buggy, slow, and stressful to work on. I think it's a
| balance like anything else.
| btbuildem wrote:
| One of my faves, for sure. I find the "slow is smooth"
| transition to "smooth is fast" especially holds true for
| physical tasks. Learning how to do something for the first time
| - carefully, slowly, awkwardly - you lay the initial record
| grooves of muscle memory, and if these are "right" the first
| time around, then you don't have bad habits to unlearn once you
| become proficient enough for them to matter.
| wonderwonder wrote:
| Its the lack of consecutive days off, 2 is not enough. 3 would
| really be a change. I bet I would accomplish just as much during
| the week as I do now, workplaces would just have to reduce the
| number of useless meetings. I spend 4 - 5 hours a day in meetings
| and am still expected to deliver actual code. Kill the meetings,
| my code generation would be through the roof. There are several
| things wrong with the American knowledge work place. Trapping 10
| - 15 people on calls for half their day is a huge waste of
| resources and productivity and leads to less work delivered and
| more stress overall.
|
| Cut my meetings in half and give me Friday, Saturday and Sunday
| off and I will show you a 5x developer.
| mlsu wrote:
| My theory is that most people don't actually want to get
| anything done, they just want to hang out. Meetings is how you
| just hang out.
|
| They want to just hang out at work because work is a very
| convenient and structured social apparatus with very well
| defined rules, boundaries, and hierarchies -- in a world where
| such things are becoming more and more rare.
| [deleted]
| rozap wrote:
| I halfway agree, but I think at some point most people hit
| diminishing returns. I went from a regular job at a medium
| large company (though I didn't have 4 hours of meetings each
| day...) to a job where there are 4 people and none of the
| software ceremony. I definitely produce a lot more code, but I
| found that the limiting factor is that writing code is just
| more mentally draining than sitting in meetings which aren't
| productive. I get more done quicker, but hit a wall sooner.
| Fortunately there's no pressure to fill up the rest of the day
| with fluff just to maintain the illusion of productivity.
| Overall it's a huge win, but I don't think it's totally linear
| for me.
| toomuchtodo wrote:
| Picking up traction.
|
| https://www.4dayweek.com/
|
| https://www.cnbc.com/2023/04/14/countries-that-are-embracing...
|
| https://www.google.com/search?q=4+day+week+pilot
|
| https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
| jasonpeacock wrote:
| If you're not a presenter or decision maker, then decline the
| meeting and say "If there's something I need to do as a result
| of this meeting please let me know".
|
| If you're still forced to attend then update the development
| schedule to reflect the impact of that time.
|
| Managers can't change physics no matter how much they want -
| you're either writing code or attending meetings, not both.
| datavirtue wrote:
| They believe what they feel, and they feel like the physics
| behave differently than they actually do.
| greymalik wrote:
| More code isn't better. As an engineering manager I don't want
| 5x as many lines of code. I want the code you work on to be
| solving the right problems. Figuring out what the right
| problems and solutions are and making sure everyone on the team
| understands them is why you're in meetings.
| wonderwonder wrote:
| This is not accomplished by holding developers in 15+ people
| meetings over and over again. Opening my calendar and seeing
| that I have 8 or 9 30+ minute meetings means I am going to
| get nothing accomplished today due to context switching. Its
| every day. I have almost no 2 - 3 hour periods where I can
| just focus
| candiddevmike wrote:
| Very rarely does that happen during meetings, in my
| experience it happens async during RFCs, pull requests, and
| chat conversations. Fostering async communication is slow
| productivity to me, and it results in better outcomes than
| forcing decisions in meetings.
| srcreigh wrote:
| This isn't really what tends to happen in meetings ime.
| Usually the problem is well understood and the meetings are
| spent with architecture types micromanaging the
| implementation of the solution.
| closeparen wrote:
| This almost never happens in official scheduled meetings or
| in the presence of any kind of manager. Instead it takes
| place randomly around the office, in Slack chats that
| escalate to ad-hoc Zoom calls, in documents and their comment
| threads, in putting eyes and hands on the actual product
| (underrated!), or in deep-diving data.
| goostavos wrote:
| I don't think more meeting are the solution here. Most
| meetings are a complete and utter waste of time. They
| meander, they lack focus, and beget more meetings as a
| result.
|
| I am obsessive about correctness, I _want_ to build the right
| thing, but meeting culture is fundamentally broken. It 's
| faux productivity. Humans getting together on a call -- often
| many of whom have no real stake in the game -- is just about
| the slowest way possible to get alignment on something. And,
| more often than not, that alignment ends up wrong, because
| spoken word sucks at precision -- even when aided by Word /
| Excel.
|
| I've become increasingly bullish on using formal methods for
| business requirements. The dev side can spent time modeling
| their understanding of the problem, then use small *focused*
| meetings with the business to move that understanding of the
| current model forward.
|
| tbh, my experimenting with this approach is still early. But,
| initial results are really promising. It feels really good to
| be able to concretely model (and machine check!) something
| amongst a small group, and then only schedule/attend a
| meeting when you need to confirm that your invariant are
| correct.
| engagthe wrote:
| I agree!
|
| I do think if you cut ALL meetings, you may miss out on
| some important relationship building stuff that is helpful
| when necessary conflict arises. Formalizing business
| requirement gathering may help reduce conflict, which is
| great, but you inevitably will have some.
|
| That said, I don't think meetings are a good way to build
| relationships or trust, and there are more efficient and
| enjoyable ways to do that!
|
| If in person, at least go for a walk, get some food
| together, talk about hobbies, etc. Give some freedom to
| "waste time" just getting to know people, especially if the
| relationships will come in handy later! If you kill
| unnecessary meetings, you should have plenty of time for
| this!
|
| People need down time to de-stress, and to recharge, but
| meetings are not the way.
| re-thc wrote:
| No 1 says you have to have the meeting in the meeting
| room. You could do it in a cafe or elsewhere. Not
| everything has to be so strict. Depends on your team and
| environment.
| wonderwonder wrote:
| I wish. Many of us work from home now though so its just
| zoom meeting after zoom meeting.
| JohnFen wrote:
| > Figuring out what the right problems and solutions are and
| making sure everyone on the team understands them is why
| you're in meetings.
|
| That's the idea, but does it work in practice? From what I
| can see, very little of that takes place in actual meetings.
| It takes place in emails and chats, because meetings don't
| allow you the time or space to really think about the issues.
| [deleted]
| WrtCdEvrydy wrote:
| >I spend 4 - 5 hours a day in meetings and am still expected to
| deliver actual code.
|
| The problem is that meetings are considered work and there's no
| output from those other than long term planning that can't be
| measured day to day.
| Bang2Bay wrote:
| it is really odd to only discuss long term plans in a
| meeting.
|
| Meetings help individuals present their idea/code and
| reviewer to critically/loudly think about the solutions. If
| that does not happen, thinking happening offline is not
| likely.
| JohnFen wrote:
| I know that I would much prefer to work 4 10 hour days than 5 8
| hour days. I want to have as many days in a row as I can that I
| don't have to give to an employer.
| sph wrote:
| Hear me out. 40 hours dedicated to your employer, however you
| slice them, is modern slavery. Why the hell are we creating
| all this technology to slave even more, with only energy to
| drool in front of Netflix and repeat the next day?
|
| People should have the time to explore their passions,
| projects and families more than a couple hours every day. Not
| dedicate _half of their waking life_ , their mental and
| physical prime, to someone else's idea for food money.
|
| Something snapped for me the past few years, but I'd rather
| eat ramen, than get $250k a year and expected to be at my
| employer's beck and call 8am-5pm. Go be an hungry artist. Go
| work for yourself on the things you care about.
|
| The fact that pretty much no one seems to see anything wrong
| with this terrifies me. Being a corporate drone has become
| the norm.
| mym1990 wrote:
| Wow, 250k a year to go to work 8-5 is "modern slavery". On
| a bit of a high horse there.
| sph wrote:
| Slavery is quite a loaded word, agreed.
|
| My point is your time on this Earth is more valuable than
| $250k. It is not being a slave, but it is not being a
| free man either.
|
| There are people in abject poverty that do not have to
| ask for permission to anyone to spend two weeks doing
| whatever they want, or to end the day early today.
|
| I do not believe freedom is one-dimensional, on one side
| the Egyptian slave, on the other, the FAANG engineer. The
| latter has only a theoretical ownership of their time,
| but in reality, to keep a roof over their head, society
| pretty much favours only one choice: As much time as you
| can give, for as little money as you would take.
| janalsncm wrote:
| 250k is peanuts compared to the value that developer
| creates for the company.
| sph wrote:
| "Boss makes a dollar, I make a dime, that's why I read HN
| on company time."
| slily wrote:
| Seriously. I'll take that job any day. I am in the same
| boat for <$150k and consider myself blessed when I'm not
| reading HN commenters bragging about their salary. At
| least you have a shot at retiring early in exchange for a
| set of responsibilities that plenty of people share for
| much less money.
| emerongi wrote:
| You don't think $250k comes with high expectations as
| well? Salary doesn't always correlate with stress - min.
| wage workers are probably just as stressed, if not more
| -, but from my experience, my stress level has increased
| the more I earn. I also used to think that I'd do
| anything for that kind of money, but I now realize that I
| wouldn't.
|
| This discussion probably reeks of "first world problems"
| to people who have different stress tolerance levels or
| preferences in life. However, be mindful of the people
| around you who are functionally capable of earning $250k,
| but mentally more fragile to the stressors that come with
| that level of responsibility. There's many of us who
| would turn that money down, happily.
|
| I'm in my 20s and I've realized that there is little
| point in killing myself to retire early at 40. By that
| time, the best years of my life have passed. For what?
| All to earn a high salary and be proud, while hating my
| life.
| wonderwonder wrote:
| You are right, every job I have had has come with more
| money for the most part and more stress.
| sph wrote:
| It was a figure pulled out of my ass. I've never earned
| half that, and these days I'm eating ramen because I am
| not accepting the status of modern society and trying to
| spend all my time and mental energy to find a third way.
| Hence this rant.
|
| I am not prescribing anything to anybody. It is just sad
| that criticising the status quo is seen as proof of
| privilege. It is ungrateful of me to entertain the idea
| that life can be much more, as I have at times enjoyed
| the fruits of our modern society... Seems like a
| convenient ad hominem.
| emerongi wrote:
| For what it's worth, there's many people who agree with
| you, myself included. Modern society has created
| unnecessary work, stressors and pressures that are quite
| artificial. Everybody goes along without questioning it,
| at least not aloud.
|
| I will admit that I am by nature someone who takes the
| alternative path. It's entirely possible that the world
| is working just fine and I am unable to adjust to it.
| However, I can't change my nature and have to find a
| different way to live, because there is no other option
| for me.
| sph wrote:
| > the world is working just fine and I am unable to
| adjust to it
|
| It is not. Believing that everything is just fine would
| be actual proof of privilege. Because the average
| Westerner has a roof over their head, heating, food and
| are chronically dissatisfied, depressed, purposeless,
| powerless against their bosses and those in high power
| that rule over us (yet they tell you your vote counts!).
| But somehow they are shamed by their peer if they voice
| their dissatisfaction, and told "oh, you would prefer a
| life of subsistence? Because that is the only path!"
|
| Where have all the philosophers, activists, idealists of
| the 19th century gone? Those that thought of a better
| world, workers to be respected, a fair economy? Many
| would like to think we have arrived, that this is the
| fated utopia they have worked for.
|
| Nonsense.
| wonderwonder wrote:
| My theory is that anyone that attempts to negate
| another's opinion based on their 'privilege' is not worth
| having a conversation with. It quickly turns into a
| downward spiral where eventually the only ones with a
| valid point of view are the poorest and most wretched
| amongst us. Its like the people that do a stolen land
| acknowledgement before a meeting and then drive home in a
| 100k Tesla feeling smug that they made a difference.
| mym1990 wrote:
| It's totally reasonable to criticize the status quo, and
| to me at least it is totally okay if that is coming from
| a place of privilege. But there are also so many out
| there(most even) who can't afford to think about anything
| but the next paycheck to put food on the table for their
| family or for themselves. I think replacing "modern
| slavery" with "modern society" is a great improvement!
| They don't call it the rat race for nothin!
| JohnFen wrote:
| Oh, we agree more than we disagree.
|
| The only part I really take issue with is the notion that
| working for someone is modern slavery. I don't think it's
| anything even close that. Slaves can't quit and do
| something else. They can't even change who their "owners"
| are.
|
| > I'd rather eat ramen, than get $250k a year and expected
| to be at my employer's beck and call 8am-5pm.
|
| I know a lot of people who make that exact choice.
|
| > The fact that pretty much no one seems to see anything
| wrong with this terrifies me.
|
| I think lots of people see the problem and fundamentally
| agree with you. The issue is that solutions to the problem
| are difficult for most people.
| sph wrote:
| > Slaves can't quit and do something else.
|
| I discussed the slavery point below, but here let me
| defend its usage: it is slavery if you consider the
| society as a whole, not just your job.
|
| Chances are, if you don't want to work for a year, you
| probably can't afford housing because you are renting.
| Statistically, you do not even have money to support
| yourself for a year. Culturally, we do not share food
| with strangers and neighbours, unless it's a particular
| event.
|
| One side of my family is from equatorial Africa. My
| great-grandfather had a hut made with his own hands, and
| readily available food. If he wanted he could have spent
| his time philosophising on nature.
|
| We have invented machines so our quality of life is much
| higher than him, but in exchange our time is not our own.
| Statistically speaking, the average Westerner, if they
| don't think about earning money for a year, they end up
| without a house, possibly starving. That fate, the
| spectre of that inhuman life, is the metaphorical whip of
| our master.
|
| The choice is made for us.
| sixstringtheory wrote:
| I get you, because I've been down this line of thought as
| well. But I've concluded the whip hand is not even that
| of society, but nature itself. Everyone is driven by the
| biological need to eat, at the end of the day.
|
| So how did your great grandfather eat? Where did this
| readily available food come from?
|
| Would other people provide him with endless food while he
| did this philosophizing? I imagine that any society,
| whether advanced megalopolis or tribal village, has a
| limit to their generosity towards complete nonproducers
| and would eventually demand something out of them, even
| if it's just the output of that philosophizing. Someone
| had to work to produce that readily available food, I
| would think.
|
| If he grew/harvested his own food, then he'd be lucky if
| he never experienced a stressful or even deadly event of
| pestilence, drought, or even injury to himself rendering
| him incapable of doing the quite hard work of growing and
| harvesting it.
|
| Producing food is hard work and modern technological
| capitalism can be seen as a process of creating more and
| more layers of abstraction between food producers and the
| mouths that need to be fed, and doing it more efficiently
| at that to generate more spare time for other activities
| like leisure or philosophizing.
| sph wrote:
| Those are very good questions, but here's the thing.
|
| What even is the point of all this technology is the only
| option is a free life of prehistoric subsistence, or the
| drone life of a desk worker?
|
| I refuse to accept this false binary choice. We are not
| made into drones because the machines and industry needs
| constant maintenance. Society with its artificial
| busywork and bullshit rules is the reason one has to work
| 40 hours a week. We have to earn a ton of money because,
| at the end of the day, half of it goes into the pocket of
| plutocrats, not to keep the gears oiled.
|
| This is a huge topic for a comment on a forum thread, I
| am just trying to understand why other people deep into
| technology, automation, like us, are unable to visualize
| a world where technology _works_ for us. Frees us from
| nature. Because right now we are using technology against
| ourselves. To control us, to make us more productive, to
| make our bosses more rich and politicians more powerful.
|
| Technology is a tool. A force multiplier. But we are not
| using to increase our living standards, only to keep this
| circus turning, at our expense.
| sixstringtheory wrote:
| FWIW I agree with everything your saying, I think. I
| started out pr and only recently have had enough money to
| consider investing and high yield savings and bonds and
| all that shot, but it still gels zero sum, like inflation
| or the next black swan will just wipe it all out anyways
| if I ever try to retire and live off of what I've
| squirreled away, as sibling comment puts it.
|
| It feels like there is no escape from work. Either you'll
| spend every minute fishing for berries and hunting, or
| tilling sowing and reaping, or working at a desk and
| grocery shopping.
|
| I truly admire the ascetics that give it all up and put
| their fate at the mercy of chance.
| zamnos wrote:
| Because _money_ , when you have enough of it, works for
| you. So we do our best, in the system we were born into,
| to squirrel away as much money so as to be able to retire
| ASAP, while remaining as sane as can be.
|
| Technology these days is just icing on the cake. We don't
| need faster computers or ChatGPT to be able to feed all
| of humanity. We've been there for decades.
| wonderwonder wrote:
| Was saying to my wife the other day that its impossible
| to just quit the world in the west. Even if I save enough
| to buy a plot of land and build a hut and can grow all of
| my own food. Property tax is due every year. The
| government refuses to allow people to just disconnect.
| capitalsigma wrote:
| Would you prefer subsistence farming?
| wonderwonder wrote:
| I don't disagree with you in principal but its hard to tell
| my kids to say goodbye to their friends and that we are
| selling the house and moving to a cheaper area where they
| will attend a rougher school because daddy has a
| philosophical objection to working for a boss.
|
| If you are single and just responsible for yourself though,
| more power to you. Before I had kids I did something
| similar. I hit an absolute wall. Took a 50% paycut and left
| development. It was pretty good for a a couple years and
| then I started getting promoted and then got screwed over
| by office politics and started hating it. I went back to
| programming after that and the first job back was awesome.
| Very low pay but no crazy deadlines, small team, etc. Then
| I had kids and needed more $ so started job hopping. Now
| its just the suck every day.
| Animats wrote:
| Not to be confused with "quiet quitting".
| UberFly wrote:
| It should be called sustainable productivity. The 4 day (4-10's
| are ok) work week would be a nice start. It's hopefully moving in
| that direction.
| shrimp_emoji wrote:
| Lmao 4-10s would NOT be okay.
|
| I can basically be a dead drone for ~60% of the week so that
| I'm recovering in the other 40%?
|
| "The 4 day work week" means "working 32 hours per week (as
| opposed to 40) with no cut in pay"[0], not "cramming the 5 day
| work week into 4 days".
|
| 0:
| https://www.latimes.com/california/story/2022-04-08/proposed...
| wnolens wrote:
| I've struggled over the past year to reduce my working hours from
| over 40 to under 40. But it doesn't matter much because the
| stress is still there. Volume of work and all that. The best I
| can do is live frugally, save my chips, and move on someday.
|
| Time blocking for specific tasks has been helpful though. Also
| seniority has helped a lot. I say "no" a lot more without fear of
| repercussion (or maybe just with indifference to..)
| TensorPoint wrote:
| I'm not sure that reducing from 40 to 32 hours would have a big
| impact on salaried workers unless it became standard to take an
| additional day off during the weekend like Friday.
|
| It would actually be a 10% minimum pay increase for hourly
| workers that work at least 40 hours per week. If they already
| work overtime then double time could kick in.
| bluSCALE4 wrote:
| I remember my first difficult project as a consultant. We were
| missing every deadline due to sprint timetables and stress. The
| client was basically letting us go while we migrated to Angular
| but wanted to keep maintaining Ember code while this all
| happened. I was charged with managing the Ember code and was
| essentially removed from the sprint cycle. I flourished and have
| fought to stay out of the sprint cycle ever since. :P
| gerbilly wrote:
| I myself never liked agile or this idea of "iterating" towards a
| better solution.
|
| Every time I've designed a software system that ended staying in
| production for years, it was a system that I'd thought about a
| lot up front before implementing it.
|
| I think we could benefit a _lot_ from doing a bit more design up
| front. Nowadays it's almost as if people think it's impossible to
| get it right the first try.
|
| It's not. Professionals can do it if you let them.
| atleastoptimal wrote:
| More importantly, I think, with AI automation coming in full
| force, we need to decouple one's working hours with their right
| to live a comfortable life, especially for the lower and middle
| class.
| macawfish wrote:
| Seriously. Yet the political will to make this happen gets
| polluted by bitter, vindictive narrative. I hope we can find
| clarity soon to let go of our collective fixation on these
| foolish narcissistic "leaders" who continue to divide and
| conquer us. Though I suppose that fixation is a symptom of
| unresolved junk that might just take generations to work out.
| charlie0 wrote:
| I don't think this is going to happen. Increases in
| productivity eventually lead to race to the bottom in terms of
| prices. Which means whoever owns the means of production are
| not incentivized at all to just let their workers work less.
| The demands of workers will stay the same, if not increase
| because of lowering barriers to entry on the supply side of job
| seekers.
|
| I wish we as a society would just accept less work as
| productivity increases, but that is not the way the system is
| setup to work. One positive thing is that we do end up with
| more things as it becomes cheaper to produce them.
| moffkalast wrote:
| So in short, seize the means of automation.
| teaearlgraycold wrote:
| Yes, comrade
| georgemcbay wrote:
| There are a few ways in which the system is self-correcting,
| though not in a clean or happy-path way.
|
| First there's just the fact that when a significant
| percentage of a population is unable to participate in an
| economy in a meaningful way the economy falls apart from
| within. What's the point in controlling the "means of
| production" when almost nobody can afford what you produce
| because they are not generating value within that economy?
| This is something that the industrial era capitalists (who
| were generally terrible people, don't read this as me trying
| to make heroes of them) understood enough to deal with in
| some proactive ways but which for whatever reason we seem to
| be mostly blind to currently as we rush toward another
| inflection point for modern capitalism.
|
| Secondly, there's the reality that when a significant
| percentage of the population is becoming unhoused and
| starving there will be revolt and those owning the means of
| production will be violently eliminated by any means
| necessary (absent some sort of collective agreement to keep
| the majority comfortable). Large masses of people wanting for
| basic necessities for themselves and their families don't
| just disappear through the cracks like they do on a smaller
| scale when a relatively small number of have-nots (relative
| to the whole of the economy) are easy for society to
| marginalize and ignore.
|
| So it is really in everyone's interest (even the interest of
| the increasingly consolidated group with the 'means of
| production') that we figure this stuff out moving forward and
| sooner rather than later. I'm not confident we will do so
| before widescale bad outcomes for everyone begin to occur,
| but when the system begins to become unbalanced enough to
| start shearing itself apart nobody will be unscathed, so it's
| rather silly that we aren't already working on real
| solutions.
| golergka wrote:
| > whoever owns the means of production
|
| This 19th rhetoric century doesn't work in modern world,
| especially when you're talking about creating software. To
| "produce" most of what HN readers do, you don't need anything
| more than a laptop and some cloud services -- which you would
| need to scale up proportionally to load, and, therefore,
| revenue. If you need capital to hire others, it's also never
| have been more easily available than in the last 10 years.
| charlie0 wrote:
| You are proving my point. Advances in productivity have led
| to a lowering to the barrier of entry. Anyone can code now.
| So why,(in theory) would a business owner let their workers
| work less when someone else is willing to work longer
| hours?
| latency-guy2 wrote:
| I think you'd take anything anyone says as proving your
| point just on the basis someone is responding to you at
| all.
| golergka wrote:
| If somebody else is willing to do the same job for less,
| it means your asking price for your services is too high.
| Americans love to complain about stagnation of wages,
| while in reality it just means that people in other parts
| of the world have reason out of poverty competing with
| them on a labour market. If you value a Chinese life just
| as much as an American one, the fact that American worker
| can now afford one car per family instead of two but a
| Chinese worker can now eat meat on a regular basis
| clearly is a benefit to humanity.
| charlie0 wrote:
| I fully agree, but what does this have to do with letting
| workers work less as productivity increases? Are you
| implying that stage would only occur if productivity
| gains are spread equally across the world?
| golergka wrote:
| Letting? Nobody is forbidding workers from taking less
| shifts. It's workers themselves who decide that higher
| compensation is more important for them than leisure.
| goofy_goober wrote:
| An interesting development as cloud services become
| increasingly more important (if they aren't critical
| already for businesses looking to get big) would be cloud
| services providers structured as mutual companies, like we
| see in some insurance and financial services companies
| (Vanguard, State Farm, etc).
|
| This would create a fiduciary duty to not soak the customer
| for everything they've got (no more sky-high public
| internet egress charges!), but also a structure where the
| customers of the company are the company's legal owners, so
| both workers and external customers could technically own a
| piece of the means of production if they use the services
| for their hobby projects or business.
|
| I would not be surprised if this comes to exist in the
| future as people want downward pressure on public cloud
| prices, and it would be an interesting development seeing
| legal ownership of "the means of production" (public cloud
| infrastructure) and earnings from it titled to anyone who
| uses it.
| layer8 wrote:
| The LLMs driving the current AI hype aren't very suitable for
| implementing automations, so I don't see how that would come in
| "full force".
| refurb wrote:
| Right to live a "comfortable life"?
|
| What does that mean?
| JohnFen wrote:
| That is important. It's also something that simply isn't going
| to happen, at least not for a generation or two (to be
| optimistic).
|
| In the meantime, AI automation is more likely to increase
| people's struggle by eliminating a whole lot of jobs.
| efitz wrote:
| I didn't read the whole article because it had too many words.
| Probably some editor was demanding a certain length by a certain
| deadline.
|
| I think that the last 100 years or so have seen the west
| frequently go too far in optimizing everything, not just
| productivity.
|
| From time motion studies on early assembly lines to modern voice
| response driven customer service, the ability to measure things
| has caused us to often optimize for the wrong things, or fail to
| balance optimizations, or over-optimize past the point where it's
| good for humans as well as the business.
|
| And it's catchy- nowadays with half the people you talk to, you
| have to constantly speed up to avoid attention wandering. Maybe
| I'm just a long winded old fart but honestly attention spans have
| gone to shit. Maybe that's not an optimization per se but it
| evokes the same feelings as IVR mazes and long queues everywhere
| (airports etc.). It's the feeling that I'm a burden or tax on
| someone's attention rather than a valuable interaction.
| tlamponi wrote:
| No offense and agreeing on the there's too much "optimizing
| everything", often even in a misguided way going on, but
| reading both: > I didn't read the whole article
| because it had too many words.
|
| and > Maybe I'm just a long winded old fart but
| honestly attention spans have gone to shit.
|
| was a bit funny. Or did you mean the attention span in general,
| including yours, has gone to shit?
| efitz wrote:
| I hate hypocrisy in others :-)
|
| I did not fail to notice this. But in failing to read every
| word of the article I was not causing any other human to have
| a bad experience.
| tjr225 wrote:
| [dead]
| Ginger-Pickles wrote:
| https://archive.ph/fEoP7
| Kalanos wrote:
| Icelandic people barely work as it is. I can't imagine them on a
| 4 day work week. Asia is going to wipe the floor with the west if
| we get soft.
| TheGigaChad wrote:
| [dead]
| AllegedAlec wrote:
| I'm not so sure. I've seen particularly the Chinese have _real_
| issue that 's not rote drone-like work. In the research
| department I've seen chinese exchange students perform back to
| back tests for 10-12 hours per day like a machine. However, if
| you'd ask them _why_ and _what_ they 're testing you'd find out
| that most of them are effectively just shotgunning until they
| find something that is different.
|
| Having a good work life balance keeps your mind fresh, allows
| you to think more thoroughly and more creatively. Doing the
| _right_ work will beat doing all the work until by accident you
| did the right work every date of the week.
| gffrd wrote:
| This glosses over the fact that jobs are a central piece--if not
| _the_ central piece--of many people's identities in the States.
|
| We've lost religion and communities as things that define and
| provide structure and purpose, leaving us clinging to jobs.
|
| Is this good? No! It's terrible! We should fix this!
|
| However, I'm not convinced that workplace stress is a matter of
| hours ... it may be a symptom of lack of life beyond work--and I
| don't mean in the "there's not enough time" sense.
|
| I appreciate what Cal Newport advocates for, but it always feels
| a little surface.
| screwturner68 wrote:
| Hours aren't usually the problem I think where a lot of the
| stress comes from the fear of getting laid off, losing your
| health insurance and having your car/home repossessed. People
| that have lived through these employee purges never recover
| fully.
| Taywee wrote:
| Many people I've met really could use more fulfilling hobbies.
| petsfed wrote:
| How many of those people feel like they have time to pursue
| more fulfilling activities?
|
| Speaking only for myself, my more fulfilling hobbies feel
| like a zero-sum proposition when I factor in taking care of
| myself, my kids, my home, etc. What little leisure time
| activies I pursue are almost all pursued between the hours of
| 9 and 11pm, because _that 's the time I have_.
|
| I think the OP is right in a lot of ways, that work has
| replaced our other social outlets. But its also the case that
| just existing costs more, so time formerly spent on hobbies
| is now spent on basic lifestyle maintenance, and the time
| formerly spent on basic lifestyle maintenance is spent
| working, or commuting to/from work (because a lot of people
| can't afford to live near they work).
| JohnFen wrote:
| > How many of those people feel like they have time to
| pursue more fulfilling activities?
|
| And yet, most people have hours every day available to
| spend watching movies, YouTube, etc. That is time that
| could be spent doing something fulfilling.
| cableshaft wrote:
| I wouldn't judge those people too harshly. That might be
| all they have the mental energy to do at the end of the
| day, they need to let their brain reset.
|
| As someone who tries to spend most of my days after work
| making games, there are days I just don't have the mental
| energy to do it. And there have been months where I
| haven't worked on it at all, as work and things in my
| personal life get more stressful.
| great_psy wrote:
| Maybe work became the central piece in people's lives because
| they don't have time to devote to other things.
|
| It's a 40 hour work week, but add in commuting and chores and
| decent sleep and you're left with a few hours left for other
| things.
|
| Hard to build an identity around a few hours of something else.
| Izkata wrote:
| Don't forget work social events that extend beyond those 40
| hours. Seems like there's more of them each year.
| srackey wrote:
| But we used to work more and this wasn't as much of an issue?
| kqr wrote:
| Depends on which people you talk about and during what
| period. In the grand scheme of things, renting out most of
| your waking hours to an employer who charges you for that
| service is an extremely uncommon thing to do.
| sanderjd wrote:
| It probably was, except that there weren't blog posts about
| it.
| sarkhan wrote:
| We don't just work more, we spend rest hours that we are
| not working think about the work. In short, we never stop
| working.
| hitsurume wrote:
| What do you mean by that? Like in the industrial /
| manufacturing age where people manually did the same thing
| over and over? Where people were physically exhausted but
| not mentally?
| gffrd wrote:
| I want to add: I 100% agree about the points on "unlimited
| amount of things that could be done" and "unstructured
| urgency."
|
| I'm not sure if this has been found to be an effective
| leadership/management tactic ... or if we sleepwalked our way
| in to this reality (a la ping pong tables), but it's not good.
| davesque wrote:
| I feel like there's nothing inherently wrong with having your
| work take up most of your mental space. With the way we have
| things set up, it seems natural to dedicate most of your
| attention to the place that your money comes from. What's wrong
| is that employers in the US don't reciprocate that attention.
| They're happy to have you committed to them without being
| committed to you. The power balance has gotten way out of
| whack. Time for unions to make a comeback I guess.
| golergka wrote:
| Work is where you provide value to the society, create
| something for other people and make world better, while
| simultaneously applying and improving your main set of skills.
|
| Why wouldn't you want tie your identity to something like that?
|
| Just to be clear: I have a few hobbies aside from work -- I
| make music, DJ, paint, cook, hike sometimes. I have friends,
| and I'm also not a productivity maniac (I actually work in a 4
| day workweek startup). But do I see my main job in the way I
| described above, and I wouldn't want to tie my identity to any
| other community or hobby. In all other aspects of my life I'm
| mostly just enjoying life, but at my work, I'm actively
| improving someone else's. When I worked in gamedev, I loved
| interacting with players and seeing how they enjoy my work. Now
| I make professional software and relish in the fact that I make
| other professional's work easier and more enjoyable.
|
| May be people don't need other identities, but just more
| fulfilling jobs.
| re-thc wrote:
| You imply that all companies add value to society and all
| jobs are meaningful. That's simply not true. Most people also
| don't and won't have the power to fix these issues even if
| they wanted to.
|
| Even if the company as a whole adds value there are lots of
| pockets of politically charged actions e.g. for promotions.
| Like are we doing anything meaningful to society by building
| 1 of those Google projects that gets killed in a few months?
| golergka wrote:
| > You imply that all companies add value to society and all
| jobs are meaningful. That's simply not true.
|
| Most are. Unfortunately, people often don't recognize the
| immense benefit for society that some industries offer.
|
| > Like are we doing anything meaningful to society by
| building 1 of those Google projects that gets killed in a
| few months?
|
| Yes. Hindsight is 20/20, and making bets is (often, not
| always) worth it even if some fail in the end.
| HellDunkel wrote:
| If you are lucky enough to work on one of those google
| projects chances are you have options working on more
| meaningful things or freedom to steer in that direction.
| gffrd wrote:
| > Why wouldn't you want tie your identity to something like
| that?
|
| Because conflating _need for purpose_ and _need to pay rent_
| can be tricky business: they don't always join neatly.
|
| Happy they do for you!
| golergka wrote:
| Need to pay for rent is quite literally need to pay back to
| other human beings for shelter, one of the most basic human
| needs. Why would it be a bad purpose in life?
| pnut wrote:
| Because it relegates your definition of a life purpose to
| society's value system.
|
| If your purpose in life is caring for the infirm or
| teaching, or doing dance performances, society will not
| compensate you meaningfully in response.
|
| What if your purpose doesn't align with society's
| definition of talent? Are you worthless as a human being?
|
| What then, abandon your true purpose because of
| economics? These are rules of scarcity, not of life
| fulfillment.
| kqr wrote:
| If rent was only about paying other humans for shelter!
| It takes what -- a month of work? to house a person for a
| year. (Based on the assumption that about 8 % of the
| working population works in construction, building
| maintenance, and related areas.)
|
| I'm happy to pay a month of my wages for a year of
| shelter. My rent is way, way higher than that.
| golergka wrote:
| Never judge value of something by how much it costs to
| produce, it's not fair. Judge it by how much people are
| willing to pay for it. And in most major metropolitan
| areas you're paying premium for your rent to outbid all
| other renters that would be ready to live in such a
| lucrative place.
|
| In essence, you're paying back not only to people who
| work in construction, but to ask the people who made this
| city so desired, over many generations. It takes much
| more than a month of work per renter to create all the
| value that you get from living in New York or San
| Francisco.
|
| If all you need is literally just shelter regardless of
| location, there's plenty of places around the globe where
| you could rent a perfectly good apartment for $300 per
| month.
| adestefan wrote:
| 28 years ago was the original Bowling Alone article. That was
| expanded into the book by the sane title rehearsed in 2000.
|
| It's probably time to give it a read again.
| datatrashfire wrote:
| I actually relate to this quite a bit. For years I was a
| workaholic. I was constantly stressed out over work, was
| generally pretty miserable person.
|
| A few years back got very intensely into a new hobby that
| blossomed and it totally changed my quality of life.
|
| At the same time, I wouldn't say I've drastically changed my
| hours. I work 40-50 hr weeks typically, I just stopped putting
| in the 60 hour ones that I felt I needed to. No one ever
| noticed or cared. It was always my own impulse to do that. Even
| though in my head, I felt like there was pressure to do it.
|
| I really think it was just my brain knowing I didn't have
| anything else lined up for life, so it just kept lining up more
| work for me.
|
| If all of a sudden that person was told four day work week had
| arrived, it wouldn't have made a difference. I'd just be there
| feeling I needed to work cause I didn't have anything else to
| do.
|
| Recently, my health has prevented me from participating in the
| hobby. And unsurprisingly I find myself obsessing over work
| again...
| angarg12 wrote:
| https://archive.vn/fEoP7
| deet wrote:
| Comments here so far seem to be missing Newport's key point (in
| the second half of the article)...
|
| For many modern (knowledge work) jobs, it's volume of tasks, not
| duration, that seems to induce burnout.
|
| For instance, if you have 1 central task for the week--say, write
| a report--but there are ten subtasks (hold 5 meetings to prepare,
| read 3 background papers, ...), and then each of those have a
| bunch of subtasks (Slack each 5 meeting attendees 10 times to
| coordinate and schedule, get interrupted when reading each paper
| so have to resume X times each) ... this 1 central task can
| easily be dozens or hundreds of subtasks.
|
| And then each coworker is doing the same thing, adding tasks to
| your load (you have to read their messages, respond to their
| emails, etc) in a multiplicative way. Newport calls it the "Hive
| Mind" in one of his books. The number of total tasks, from very
| small to very large, each individual has to accomplish in a week
| ends up far far greater than expected on the surface. And adding
| to that, they come in in an unpredictable way.
|
| All this adds up to burnout, not just the number of hours. It's
| the intensity, and the unpredictability.
|
| I've experienced this myself. I was at one of the FAANGs,
| constantly bombarded with new tasks, and felt burnt out. Now, I'm
| at a startup--very much inspired by Cal Newport, and using AI and
| context awareness to make teams operate together more effectively
| (see bio)--and I'm working far more hours per week than before,
| but with less interruptions and less distraction, I'm able to
| focus and feel far less burnout despite the increased hours.
|
| All this to say, we really need to rethink how we work, not just
| how much.
| nostrademons wrote:
| It's both. Burnout is when you invest too much emotionally in
| something or someone and don't get anything back from it. That
| can be because you have a steady stream of work items and none
| seem particularly important but you feel obligated to do each
| one. Or it can be because you labor on the same project for
| years and never complete it. Or it can be because you work hard
| _and deliver_ but events outside your control make that
| delivery pointless.
|
| I'm an eng manager at a FAANG. I view my _primary_ job to be
| saying "No, that doesn't matter." New bug comes in - if it's
| not a production outage or security bug, it can go in the bug
| queue and we can forget about it. Engineer says "But what about
| [edge case], now I have to worry about that too", I can say "No
| you don't. Ship it anyway." Request from another team comes in
| - "Sorry, we don't have engineering capacity for that." UX
| designer has a great new idea - "That's not feasible in the
| time and resource constraints we have."
|
| Probably doesn't make me very popular with other teams, users,
| or cross-functional partners, but my team (which had had
| recurrent problems with burnout and spinning their wheels
| before I joined) is being productive and delivering stuff and
| seems reasonably happy at work now.
| MrDresden wrote:
| On behalf of your team, thank you for taking good care of
| them.
|
| As someone who has been in a team situation without a good
| manager (where every little thing got highest priority) and
| subsequently got burned out (also my fault to get too
| emotionally invested in the work) along with most of the
| team, I know firsthand the damage that bad management can
| have on morale, throughput and quality.
| asdfman123 wrote:
| I'm an engineer at FAANG and it seems absurd, though, that we
| have so many resources but can't apply some craftsmanship
| every so often.
|
| Instead, we churn out features, and everyone cheers when
| someone adds a new button to the UI.
| nostrademons wrote:
| It's not rewarded by the performance review system (except
| at Apple).
|
| You _can_ apply craftsmanship, it 's just you won't get
| credit for it, your manager won't get credit for it, your
| VP won't get credit for it, and so on. That makes it a hard
| sell. A good manager's not going to penalize you for going
| above and beyond and fixing issues that you see, but it's
| hard to make a case for it when there's lots of other stuff
| to do and nobody important is going to notice the bugfix
| you just made. (And chances are, new bugs are just going to
| be introduced by some other team chasing the hot new
| feature.)
| Falkon1313 wrote:
| On a personal level, we also have to remember to say "No, I
| can't stay late tonight, I have things to do." or "I had to
| work a double shift yesterday, so no I am not going to be in
| first thing in the morning." and so on.
|
| When we're young and don't have any clout, it's really hard
| (and scary) to do that. Which is exactly why those of us who
| are older and have the experience and acceptance to do so
| really need to normalize it. To make it clear that that is ok.
|
| I'm extremely lucky because my company has a culture where
| people can, and routinely do, say things like "My brain's
| fried. I can't do anything else productive today so I'm leaving
| early." or "I didn't sleep well, so I'll be late today and I'll
| make it up later." And people ask for help almost every day.
| And we watch out for when someone's stressed and do not pile
| more things on them.
|
| Everyone agrees that none of us wants somebody just adding bugs
| because they're too overwhelmed, and then wasting time
| afterward reverting and fixing them. That's not productive.
|
| I know, that is rare. It requires everyone involved to create
| that culture of acceptance and assistance. Management alone
| can't do it, but also, if all the employees are doing it, they
| can't stop it.
|
| It's a duty of all of us senior employees to set the right
| example.
| wildrhythms wrote:
| +100 to this, any time I get an 'emergency request' coming in
| like that I flat out tell them this is not going to happen, I
| can't do it given the time constraint. I didn't used to do
| that, but I got burned too many times and it hurt my mental
| health scrambling to meet someone else's fabricated, and
| usually self-inflicted deadline. My well-being is so much
| more important than somebody else's lack of planning. My
| usual strategy for dealing with this is saying "Sorry, I
| can't help given the time constraint. Since it's an emergency
| maybe we should bring this to the attention of <relevant
| manager 2 levels up>?" and magically the 'emergency' goes
| away and I never hear about it again.
| [deleted]
| BogdanPetre wrote:
| I would encourage a focus on "right productivity," (doing the
| right things at the right time with the right pace, rather than
| merely doing more or less.). The key to "right productivity" is
| finding the right balance between quality and quantity, speed and
| deliberation, work and rest
| layer8 wrote:
| That doesn't say anything, because any mode of operation can
| fit that description, with a suitable definition of "right".
| tortoise_in wrote:
| This is true. Only one Sunday is off and the working hours for me
| are not fixed! The problem with sales jobs is you have to be
| always on the edge. Like edutech. You need to be always around
| students and their have continuous followups. For personal life
| you have to just manage things in between. I feel I am getting
| angry and I have to do course corrections. But it's hard to earn
| money at the of the day in certain domains. But yes skills
| matters
___________________________________________________________________
(page generated 2023-05-20 23:02 UTC)