It’s time to embrace slow productivity (2022)
newyorker.com
newyorker.com
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.
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.
Easier said than done though
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.
https://www.youtube.com/watch?v=PUWg905fGTA
Both funny and insightful for anyone starting a project.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
Do you know what planning poker is, and are you aware it's not a game for fun?
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.
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.
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?
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).
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.
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.
(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.)
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.
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.
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.
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.
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.
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!
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.
> Be first, but first be right.
"Agile" coaches scammed you
When I am under time pressure I slow down a notch. Over the years my slow speed has gotten faster as well.
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!
The waterfall:bad, agile:good trope is really tiring. Like listening to a teenager that knows jack shit explain how the world works.
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.
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.
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.
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.
Instead, we churn out features, and everyone cheers when someone adds a new button to the UI.
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.)
Still, I do try to make quality software, so I can actually be proud of what I’m doing.
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.
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.
This industry has completely alienated me to it. I loathe the grueling hours and the job search.
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 didn’t read the whole article because it had too many words.
> Maybe I’m just a long winded old fart but honestly attention spans have gone to shit.
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.
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.
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.
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).
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.
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.
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 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.
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.
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.
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.
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!
I'm happy to pay a month of my wages for a year of shelter. My rent is way, way higher than that.
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.
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.
From the perspective of the nebulous and not clearly defined 'society', it certainly seems like it's trending in that direction.
The real question is why do you believe its judgements are what's most important?
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?
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.
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...
It’s probably time to give it a read again.
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.
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.
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.
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.
In the meantime, AI automation is more likely to increase people's struggle by eliminating a whole lot of jobs.
What does that mean?
Cut my meetings in half and give me Friday, Saturday and Sunday off and I will show you a 5x developer.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The choice is made for us.
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.
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.
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.
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.
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.
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.
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..)
Embrace slow productivity - https://news.ycombinator.com/item?id=29893695 - Jan 2022 (203 comments)
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 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...
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.