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.
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.
>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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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!
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
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.
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…
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.
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.
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.
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.
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)
> 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.
>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.
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.)
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.
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.
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.
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"
>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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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?
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.
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).
> 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.
>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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.)
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.
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.
+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.
I wish I was fortunate enough to work at such a place. When I'm given the ability to make those kinds of decisions for myself, I can get some serious work done. However, not many of my jobs have allowed for that. I've even been let go from a job that demanded so much of my time that I did nothing but work and doordash food supposedly because I wasn't putting in the amount of time they wanted.
This industry has completely alienated me to it. I loathe the grueling hours and the job search.
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.
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.
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.
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?
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.
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...
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.
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?
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.
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?
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.
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.
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.
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.
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).
I understand that. I am in a very similar position. I make time for my hobbies and it is often very difficult, especially as an active parent who makes a strong effort to be present regularly in my kids' lives. Sometimes, I don't get any time into my hobby projects for over a week at a time. Sometimes I get time in and it's unsatisfying because they're creative and intellectual hobbies and I'm already mentally drained, so I can't even appreciate them fully.
I wasn't making a judgment (though I wasn't explicitly not making one either), just saying that many people could use them. Hobbies are good identities, and many people feel a need to define themselves but struggle to do so.
That said, I do know people who complain about having very little time, but I know they spend 4 or 5 hours every day on television, video games, and social media. They don't own a home, they don't have kids, they get on the TV as soon as they get off their 40-hour-a-week job, and complain about how they can't afford the time to have hobbies. Excuses exist on a spectrum of reasonableness, and some excuses are more understandable than others.
The majority of people I know who really want to have fulfilling hobbies do have fulfilling hobbies. Many of them work long hours, also have kids, have to take care of their home, and the like. They'll still scrounge together a few hours a week to paint some Warhammer figurines and decompress.
Most people would also benefit from occasional therapy or a personal accountant. It's not accessible for everybody, but the fact remains.
> 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.
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.
Oh, I'm not judging at all -- I have my own preferred time-burners as well. I'm just pointing out that a lot of the time when I hear people say they don't have time for something, they also spend a lot of time every day doing things like that. For many people, "not having time" is the result of decisions about how their time is allocated. Those people can allocate differently if they so choose.
I think you missed some nuance there. If I only realistically have between 9 and 11pm, I am pretty limited on what hobbies I can take up. It's not just that I'm literally time constrained, but also that the time I have available is not conducive to certain activities, so I'm left with video games, TV, etc.
Its the same story as "I can't go to the bank if they're only open when I have to be at work", but for mental health rather than finances.
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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..)
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
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.
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.
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
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.