Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I have the 2 before that didn't use Agile. Agile is very clearly being misused to turn developers into factory line workers whose productivity can be measured by number of commits, reviews and docs they put out every two weeks. And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to.

And the burnout article linked in the OP makes a great point about inputs to development teams not being measured. At some places developers are left to spec out stories and others have Architects / Tech Leads do it - in either case that in itself is a large chunk of work that takes up huge amount of time that no one is rewarded for in any way!

Mostly though keeping the churn going is what gets really tiring - do most orgs have work that a) needs to be done every two weeks and b) can be done in two weeks perpetually? The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks - the real impact of that work is almost always never evaluated. Combine this pressure with time crunch that prevents people from spending quality time together to ponder bigger, high impact problems and collaborate on solving those within the meeting heavy Agile process and you are never going to get anything meaningful done.

This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. The trouble is software / IT is not at all like rolling cars out on a factory line so it all falls apart.

Edit: By Agile I meant Scrum really.

Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.

This.

I understand that some managers want graphs, points, velocity, etc. Those things makes it easy to point at something and tell the team to improve. A good (imo) manager on the other hand, would just ask the team how the sprint went and what problems needs solving.

Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do.

Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects.

The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.

> the other requires a more deliberate approach where doing things right preserves the ability to do things quickly

Yes. There is a surprising nonlinearity of benefits to doing something properly.

It’s not about over-engineering to “best practices” or being a “cowboy coder” tuned only to your own preferences. These two are the Scylla and Charybdis of pursuing quality in software.

Scrum does have a lot of processes and artifacts and things to measure. They all had a decent purpose: to give the product and project managers (Product Owner and Scrum Manager in Scrum parlance) information that allowed them to do their jobs more effectively. Story points and velocity estimates were supposed to drive decisions about what to build and when by giving the product manager some sort of signal they could use to decide things like, "Let's skip this feature; it's going to cost more than it's worth," or, "Let's push this bit a few weeks forward in the schedule, because it's looking like it's bigger and more likely to go quagmire on us than I had been hoping."

There was supposed to be an understanding that generating this signal would reduce the speed at which the development team could churn out features. (Of course it would; that time spent playing planning poker had to be taken from somewhere.) But this was understood to be worthwhile in the long run, in a, "Work smarter, not harder," sort of way.

On paper, it seems like a pretty good idea. The critical flaw, I think, is that, when you take a system that produces all those numbers, and even do something boneheaded like name one of them "velocity", and then drop that in the middle of a crowd of people who went to business school and have had heavily indoctrinated into Taylorist ways of thinking, well, it's like a will-o-the-wisp to them. They'll see something that looks bright and shiny, and follow it straight into deepest part of the swamp. And, since they're the manager, they'll be able to drag the whole team, or even the whole company, along with them when they do.

Years ago, I had an interesting "A Tale of Two Scrums" experience. I was on a product team that had been doing Scrum as their own internal thing for years. Quite successfully, too, everyone was happy, it was possibly the highest morale team I've ever been on. But then senior management decided they wanted the company to go Agile. So they brought in $FAMOUS_AGILE_CONSULTANT to deliver a week of workshops which was mandatory for all the developers and skipped by all the managers, including product managers. And then we had this very top-down, Taylorist, how-much-blood-can-we-squeeze-from-this-stone brand of Scrum rammed down our throats from above. Half the team left the company within 2 years. I found later that, not too long after I left, the company had subsequently divested of the product I worked on. While I was there, it was the market leader and cash cow.

Long story short, there's Scrum, and then there's Scrum. I can't tell you how much I loved doing Scrum, but I also can't tell you how much I hated doing Scrum.

Taylorism was known to only work on short interventions at the time it was created, and it's known to create all sorts of problems (one being absolutely demotivating everybody).

People are not cogs.

  > I guess the real question is why the fuck are management courses still founded in Taylorism?

That is why.

So, are the developers somehow responsible for the problem, since the managers were never exposed to the consultant?

The desire for metrics is also a major driver of surveillance capitalism and why every web site and app is now larded up with telemetry.

Some of surveillance capitalism is indeed about making the user the product, but a decent chunk of it is about people having metrics to show to people higher up the chain.

People who sell advertising need metrics to sell it. Managers need metrics to show the value of feature X or Y or the application in general. Companies need metrics to woo and placate investors. Investors need metrics to show to their investors/LPs. It goes all the way up the chain.

I'd say there is a general lust for metrics on the part of everyone who answers to anyone. Markets are not DAGs, but undirected graphs of power relationships, so everyone has a boss somewhere and thus everyone wants metrics.

That’s why it exists.

Our free speech society relies heavily on sticking to jobs, economics, and service to industrialists.

We were also writing code in C++ to run on an ARM 7TDMI core embedded in a custom ASIC. We used the Metaware C++ compiler and JTAG based debug hardware from a German company whose name I’ve forgotten.

Good times. The client company was successful and was sold to Fujifilm about 20 years later for $950M.

Edit: The JTAG ICE was Trace32 from Lauterbach.

Where it becomes a problem is where it's used to enforce underlying pathologies like micromanagement. But if your shop has a micromanagement problem, you'll be miserable, Scrum or no Scrum.

Corporate suits eat that shit up. The value add of scrum, to them, is everything devs hate. They love the burn down charts, the timelines for features, the resource allocation, the ability to fly in and say "You are working on polish? WTH value add does that bring to the company? Dump it and do feature 123 instead!"

And, unfortunately, corporate suits tend to pay the bills.

I'm sure there are companies out there that don't fall into micromanagement shit, but I'm convinced it's an inevitability that any successful company will eventually turn into a feature factory hell hole.

Before that the master really tried to have meaningful retros. Now we type some things in a doc, everyone is silent, and the master has dropped any mention of follow up or takeaways.

...and this is a company with a good culture! I have done this dance at places where the culture was not good. As a person renowned in my circle for technical ability and productivity this was the only place where I couldn't get anything done and was removed from the account by the manager. Relief.

One group I was in everything was a #1 priority. I had to sit the manager down in his office for a couple of hours and make him pick the priorities. It turns out he did not know what he really wanted, yet he wanted to micromanage everything. I had to show him that you have 4 devs and they can not work on 15 things at the same time 200% of the time. They have lives outside of work and you will get nothing done if they are jumping around at every whim you come up with. After that the team worked much better. I would at the start of each sprint make him pick what order he wants things in then the devs could come in and fix it up correctly.

Team management is totally on the table of 'things to work on' in scrum yet many PM's seem to forget that.

My new team has 3 15-30 min calls a day. I just joined this team so I am watching for now for a couple of sprints. But you can bet money on the fact I am bringing that up in a retro. You are distracting everyone at regular intervals and they can not get into anything because they are always prepping for your status meetings. You are leaving them basically 30% of their day to actually do anything related to the things you want status on.

A good PM who 'gets it' is great. One who strictly follows the metrics... yeah

I’ve literally told our internal users “if you can’t tell me which of these two things is more important to you, my team will work on them in whichever order is best for us.”

“If you could only have one and then the other, which would you pick to go first?” “But we have to have them both.” “Are they related/linked?” “No.” “Then which would you want first?” “I want them both.” “Thank you; I don’t need any more information from you.”

Haha this is funny because it's so true. And this is a person who is actually a supposed to be a professional at allocating resources ;)

Daily also don't make sense, because the team has several major tracks in parallel and I can't really contribute to what others are doing, unless I decide to put my work aside and/or overwork.

Why this? My guess is that it's more convenient for a manager to have a more consistent view of what's happening. On the other hands there are team members that like to hear what's happening besides their own work, and such meetings give them that opportunity.

The luck we have are the retrospective meetings: one of the most efficient ways to actually make actionable things. This meetung I would never cancel, because it has nothing to do with the sprint but with the teamwork, workload, etc.

The issue with all "things" is the ability of people to be able to adapt it to the own workflow. It takes balls and experience.

  > ...provides a light framework/training wheels... Start with 15 minute daily standups and 2 week sprints, for example, but if you work better with a twice-weekly standup and a 6 week sprint, fine.

Retrospectives can also be good when they're focused on how to improve processes (including Agile's). If it's just a venting session, that can become demoralizing, even caustic. There's also value in not having certain people in the room, so they can't get defensive or cause people to clam up.

Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.

Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave.

Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s.

I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories.

Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation.

Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.

Because then it's easy for that person to forget that stand-ups have no independent value -- their only value is in making the other work go faster. And should be calibrated to maximize that.

Which is why you get the "We standup because we have to standup" shops.

https://en.wikipedia.org/wiki/Scrum_(rugby)

Yep. I've suffered 20 years of poor facilitation. I keep hoping for some facilitation.

Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.

We've decide to drop the status updates from standups to focus solely on discussing things of interest to the team - blockers, processes, issues, announcements, icebreakers, etc.

We have checklists/agendas for what to discuss and we go through them fast. We update the agendas when we need to. We don't tolerate diversions from the meeting topic for more than a couple of exchanges and anyone can ask to move the meeting on/back on-topic at any time with a funny "safe word". Our stand-ups focus on "what needs to be organised, who needs to talk to whom, what work/bugs have come in from other teams?" not "what has everyone done". Our planning is split into two or three (so it's more meetings, but they're shorter - one focuses just on bugs and is only for a subset of the team). Our sprint review is open to the entire product and engineering teams and we go to theirs. They're actual demos; the last one we did was interactive.

In my opinion, Scrum can work. It takes time to find the combination of people, agenda items and venues to get the best work done in each "ritual". If you didn't have Scrum, you'd still have to create _some_ proces to follow; you'd do most if not all the meeting functions, but perhaps at a different rhythm. The scrum system is pretty minimal and under-describe exactly because you can mould its it to fit your team. If your Scrum implementation isn't working for your team, make your Scrum master change it or take on that role. Any other mindset will cause the process to fail.

It's probably not the right process for systems which include hardware or other long-lifecycle subsystems. It's best when the whole team can focus on specific goals, and a small number of goals.

If you have multiple concurrent work streams (e.g. "epics", and you try to give chunks of work from each epic to individual developers, you'll fall into the trap of "feature farming". It's much more effective and interesting when the team is focused on a single feature and works together on it.

The backlog needs to be about the _product_ not "work to be done by the team". If you have multiple work streams/epics consider making specific, short-lived, smaller teams and splitting their stand-ups and retros out.

Keep changing it to suit your product needs and fit the teams around that.

But it is bad, no-good, horrible and sucky. If you do have the skill and diligence which are necessary to implement it (in a way that doesn't horribly suck), then you don't need to formally implement Agile.

The most productive teams I worked in invariably converged on something like this:

some kind of a backlog + a way to know who is working on what + informal but frequent and active communication

I think that if you look at the formal and semi-formal methods it's Kanban that is the closest to this model. If you need to placate people who insist on using "A Method", then at least try to convince them to use Kanban.

You hire competent developers that want to do cool things and you give them the basic necessary tools to self organize. You give them sound direction and a reasonable timeframe and they will self organize - maybe have infrequent checkups to ensure nothing is derailing or needs escalation and most projects can be successful with minimum overheads.

The agile manifesto attempted to describe a culture where devs could get things done.

All the methodologies are a bundle of useful ideas that came out of people attempting to find a process that fit the agile manifesto (and still delivered what the business cared about), but have been taken by consultancies, stripped of context, and sold as a panacea for what ails a company.

It's attempting to treat the symptoms, not the cause; the cause of what ails a company is bad culture, not bad process.

Agile has become a way for people with no development experience to “manage” developers and that will always be wrong. The West’s obsession with “managerial” experience being a thing you can learn start to manage “anything” from is the origin of much of our malcontent. Management is just something you add on top of knowing how things work. It’s not valuable as an isolated skill.

True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge in tangible and intangible ways - they bear the brunt of everything and that can become the many straws that broke the camel's back thing easily.

What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.

Who can blame them. They got an A for repeating what the professor repeated.

Look at the difference between Elon Musk’s two companies and their ability to execute vs their rivals. The amount of value that was created because of an engineer led is so vast - it’s hard to even quantify.

When my son was about 10 or so, my wife mentioned that they were forcing her to perform as "scrum master" on her team and he laughed and said, "'scrum master'? That sounds like something a third-grader would say to insult another third-grader - 'you're such a... scrum master!'". I think he had the best take on it I've ever heard.

Not only does it turn developers into factory workers, but also which is my biggest source of burnout, it turns developers into some kind of dysfunctional and immature people who need help with every kind of basic communication and decision, and forces you to undergo a quasi pop psychology group therapy. That's where I get the most burnout, I'm a grown-up and a normal well rounded person. I'm healthy, I can communicate, I can work in teams. Why do I not even get the benefit of the doubt that I can function normally in a team and do my job, and immediately get thrown into this awkward depressing self-help group therapy bs.

This is intrinsic to the entire movement and was from the very beginning as far as I can see.

There were some good ideas that emerged from the auspices of the movement but the movement itself never really committed itself too hard to any of them.

Let's check some "principles" posted at https://agilemanifesto.org/principles.html

    Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.
    
    Welcome changing requirements, even late in
    development. Agile processes harness change for
    the customer's competitive advantage.
    
    Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter timescale.
    
    Business people and developers must work
    together daily throughout the project.

P.S. not really in any particular argument with you, just that your comment prompted me to write some thoughts that have coagulated in my mind while going through the comments here.

This is because the Scrum "masters" are not masters of the domain. In most cases, they went to a two-week class to get "certified". They have no understanding of the development process and they are not accountable to developers at all, only to upper management to whom they sell the word "agile" as a project management approach. What they are doing with all the planning/prep all the time, of course, is playing mini-waterfall in 3-6 month horizons.

> the real impact of that work is almost always never evaluated.

Because that might actually lead to reflecting on the performance of mid-managers and the scrum "masters". These groups tend to view developers as assembly line workers, they still think the "size" of a PR is indicative of its importance (think the KLOC counters of yore), and they think "key person risk" can be mitigated by eliminating said key person instead of fostering an environment that open to knowledge/experience sharing.

Those who can't do the tech get threatened by those who can and instead of focusing on their own comparative advantage and ensuring a productive environment, they focus on subjugating those who can do the tech to their every wish (fixating on things like label colors, prefixing every ticket with TAT, insisting that every ticket must be comprehensible to any random person in the company etc).

When 30 hours in a week are taken up by mandatory meetings, they then penalize people for not spending 40 hours on development. I've seen places which required keeping timesheets with 15 minute resolution.

I know there are places that are not like this, but I also know enough places that are.

At this point I've automated most of the time tracking into Excel. (CTRL-SHIFT-semicolon injects the current time into the current cell)

Timecard still takes an hour of work a week because I have to fill out both Jira time and HR time separately, because they want it at different granularities... Ah well.

Kanban paired with CI/CD is the best workflow, in my opinion. Break work down into known chunks, no estimation games, work it through a kanban board and put it in production when its done. A known side effect of doing this process is you may have people work on things that get de-prioritized and they sit there for a while and/or turn into waste. I'd rather have that known side effect than side effects like burnout, endless meetings and death march waterfall projects. Devs can still learn and hone their skills developing things that may end up as waste. Devs get nothing out of endless meetings and trying to meet arbitrary metrics.

Yes, the whole 2 week 'sprint' thing really wears me down. I can see the value of deadlines and splitting work up, but between all the release/demo/planning overhead and the constant rush to fit things in it leaves me with a constant low-level anxiety.

3 weeks seems like a more reasonable figure to me. Or with a senior team, just having a prioritised backlog of tasks and doing them in order (sounds crazy, I know).

Used well, sprints can help figure out how to put tracks of work in parallel, and keep anyone from overloading themselves.

Used badly, they're perpetual deadlines that fault individuals for inefficiencies in planning and create all kinds of fun toxic incentives.

To add insult to injury, everyone that complains about agile just gets told they're "doing it wrong," which 1. no shit, that's the substance of that complaint, and 2. blames individuals for what's essentially a management failure.

20 years ago, friends which worked in non-management positions in hr, accounting, finance, etc envied the freedom I had being low-level worker. Nowadays I just follow orders and work on tickets as they do.

Scrum just pretends that there are no decisions to be made, or if there is, that they are obviously simple and that everyone spontaneously just get along. In reality there are a lot of pretty damn important decisions to be made in developing and evolving software, and people have widely different ideas, and smart people are usually very stubborn as well.

I had a guy insist that a build script for a React app should absolutely be written in Ant. And nothing else. I argued with him that it's highly unusual, and that shell script or Makefile would be a better choice, pleaded with the rest of the team etc. It was massively exhausting for me and the whole team, this went on almost a whole week, and when I finally got my way on this issue, he just rage quit the team and transferred to another.

I just wish there was a manager who would be "the bad guy" and make decisions like this like the old fashioned way, it's not without benefits.

And similar incidents happen to me all the time, whenever I use SQL to solve something, use the command line, or when I simplify some code, I always get attacked by (mostly) juniors.

I just don't understand how to contribute as a senior when you have no decision power and no impact, and every decision is made in an undefined way (in reality by exhausting arguing).

“Ah, benttoothpaste, I see you made 70000 commits last week! Fantastic progress, we’re very proud to have you on the team! Can you tell us a little bit about how you achieved this incredible breakthrough performance? Your bonus check is already in the mail”

If you have normal stakeholders, they want to see features. You, as a developer or maybe an existing user, want to fix bugs. But new features bring new customers.

Too many demos without new features and the engineering political capital will plummet like a rock. That's when things get dicey and people get moved around or fired.

So I understand your point and it's valid, but it's stakeholders are really a force to be managed properly, not capitulated to.

The capitulation, I suspect, comes from the imposter syndrome many managers have, who are just happy to be in that position. They haven't yet grown the spine to do what's best for the project. I don't care how many features an OS has (Windows 8). If it's buggy and unusable, it will be perceived as a bomb.

Scrum works if the manager is unclear on what the team does and when. Sometimes software teams are low productivity because people straight up aren't working, sometimes it's because there are a hundred operational tasks eating up all the bandwidth, and sometimes the team members aren't prioritizing the right work. In such a world scrum gives day to day status of the work everyone is doing and they can provide feedback to the team to get the team moving faster.

It's a short-term fix that sometimes gets pushed as a panacea for all software team management problems.

> Edit: By Agile I meant Scrum really.

The same thing would happen with any form of Agile, if it became widespread enough.

In most companies that use Scrum, managers change at least half of the rules of Scrum. In a parallel reality, you would see them change half of the rules of Kanban or Extreme Programming or whatever... and then developers would complain that (the actually practiced) Kanban or XP or whatever is not true Agile but more like the opposite of it.

The problem is that managers exist and want to keep their jobs. (Even worse, the power of a manager depends on how many managers are in the hierarchy below him or her, so even managers in the higher positions, who could in theory make the company more agile by firing the managers below them while keeping their own jobs, do not have an incentive to do so.) So whenever someone proposes Agile, managers modify it into Agile+micromanagement, to justify their jobs.

If you want to have actual Agile, you need to start without managers. If you have a hierarchy of managers who decide to implement Agile, you have already lost.

This is not Agile, this goes against the Agile philosophy of putting people first in front of process.

Agile doesn't need coaches, just make your staff read the manifesto. If you have an Agile coach scheduling meetings nobody cares about, you're putting process in front of people.

From my experience, people are generally nice (not including myself in this group) and they won't say to your face that your job is useless. Heck, they'll even praise how good of a coach you are and ask for more meetings - while complaining in private about long meetings and leaving in record numbers.

So much this. The continuous mental stress that agile imposes is so harmful. Having to re-justify your job every morning in daily status meetings, then having to spend all day worrying about having enough to say tomorrow. Counterproductively, it prevents me from getting in the zone and getting more done, so now I have less to status report tomorrow.

Apparently it's not just me either. I know someone who is a mental health professional (Silicon Valley area) and they've mentioned seeing an increasing trend of patients who bring up agile at the workplace as a cause for the stress that leads them to go see a mental health professional.

I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all.

Here is the thing, though: Agile is not a methodology. That's why, whenever people get sold a methodology and complain about it, they get the answer:

> "but that wasn't real agile."

As for why it's so common for people to buy "agile" from consultancies and end up with bad results, I would argue that "agile transformation" is a market for lemons [1]. It has been so for a decade now. For the interested people, I would suggest to learn about it by yourself from non-commercial sources, and to learn what you're talking about before contracting consultants.

[1]: https://en.wikipedia.org/wiki/The_Market_for_Lemons

The mistake was applying it elsewhere.

The CD ones were ones that actually needed continuous work - lots of new code needing routine bug fixes, Security fixes, artifact updates, incremental devops/automation for legacy projects etc.

He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.

Yes, that is the line that resonated with me as well. Twenty-five years now as a "corporate programmer" and I have watched the job go from cowboy-coder to "i"-dotter-"t" crosser.

There is way too much process now and it's not fun. Perhaps it's a sign of the industry maturing, the stakes are higher. Perhaps it's a sign that management no longer trust their devs. Perhaps one follows the other.

Regardless, I am soon to be exiting corporate and the new way is not something I will miss.

Case in point, when we get a tired of the office grind we can publish a manifesto that slams tons of people we’ve worked with in the past (with no fear of consequences from those burned bridges), move to a resort wherever we want, and still expect to either make great pay with benefits while fully remote, or realistically start our own business with a great chance of success (and can easily raise funding to defray the risk if we want to).

I’m grateful to work in software. It’s a wonderful thing that we have so much privilege. And so of course, at a time when the world has been quite stirred up and most of our lives affected, it’s great to see many engineers have the freedom to change jobs to fit their lives better, and that they’re exercising that freedom.

But could we observe and write about all that without the anger and entitlement? For anyone who has worked in other fields, or even less in-demand jobs in tech, it just comes across as whiny and out of touch.

The post was written by someone who works about the management and shareholders of corporations. If privilege and entitlement are qualities of the people working on death marches at companies the DOJ said were illegally colluding to keep wages down, then what are the qualities of the heirs collecting dividends from these companies - expropriating the wealth of the surplus labor time of those creating the wealth. The system is the creation of heirs who never worked a day in your life, but you make the case of the parasites - that those actually working and creating wealth are the ones who are entitles, privileged etc.

It does seem to be a feature of the American working classes that they are led to be persistently, easily and even violently divided over wedge issues. Abortion, gender, race, "coastal elites" vs. "flyover country", millenial vs boomer, heck, or even, as in this case, "1 paycheck away from bankruptcy vs. financially stable".

You'd think illegal collusion over wage suppression would unite people who... earn wages but it doesnt seem to. Not in the same way belonging to, say, an arbitrarily advertiser defined age cohort does.

Which is really weird if you step out of American culture and look at it from the outside for a bit.

Maybe this is what Marx was referring to when he talked about a lack of class consciousness.

All these ideological movements such as communism, inquisition or social justice warriors subserve the individual to the collective struggle, usually by force. Who loves to be spoon fed propaganda or cancelled "for the success of the greater cause"? They attack their own people even more viciously than the others for crimes such as original thinking which is nothing else than heresy to them. They reject the very basis of debate and logic-based reasoning, preferring to spread stories with emotional appeal and moral judgements instead. They cause a chilling effect on society, people live in fear of being persecuted for any reason, learn to be docile and lack the courage to change anything.

My wife works in healthcare, and agree that our "problems" are paltry relative to what they deal with.

"Instead of 6-3 your hours are now 6-to-6 3 days a week because we lost coverage in the evening. Tough noogies"

She gets paid 1/2 what those with 4 years of experience in our field get, and works on brains and spines.

One of my friend works at a major consulting firm, he knows they just grind new accounting grads until they burn out every. year. They just hire new ones the next year.

Banking analysts, actually pretty much everyone in banking is in what sounds like an unending grind. The exception I've heard is if you can somehow push through as an IB and make it into being a VP you can calm down.

So, yeah. Meetings are boring, the work is sometimes uninspired but things are pretty cushy for us right now.

You can safely dismiss almost every problem in the world with your approach.

"Our jobs aren't that bad – do you hear what they do to software engineers?"

I earn a decent chunk but I'd still have to earn my current wage for about a million years and pay 0% taxes to have as much as Jeff Bezos does.

But we have, by far, the most intellectually stimulating and flexible careers in the world. And nowadays, get paid ridiculous to boot.

So why is everyone complaining? What is everyone aspiring for?

I can only speak for myself here, but I know it's a valid point for many that followed the same path I did. The work I come about to do requires constant and intense mental activity on non-repetitive tasks. That takes a lot of energy. Twenty years ago, the computer engineering university faculty I've been through saw constantly the highest rate of dropout in its freshman and sophomore years, compared to any other kind of school out there. The touted reasons were mostly that there was simply too much work, that it was too grueling, too hard. The ones that prevailed weren't necessarily the smartest or the most diligent of all. They were, however, the most passioned about the computer engineering field. One had to have it to fuel the energy demand of the work necessary both in school years and after. The money is good, but that alone didn't seem to cut it. The work conditions in office are nice, but those weren't nor aren't what kept me in the game. (There were times when the space I worked in had no heating in the winter and was often smoked in, with me as non-smoker.) What I see in my peers' complaints nowadays is something that hits on the root of what made me wake up and continue every day. And the worst part is that the decision makers don't seem to be aware or caring. The mood is more like "I pay them, therefore I saddle them with whatever I see fit". So to answer you, what I aspire for? I aspire for a better fit, for both myself as someone good at something, which (from a self-development investment prospective) it makes sense to strive to do as much of it every day, as well as for the client benefiting my work/skills. I also think it's just ethical to rise awareness (even by complaints, if it has to be) when I see (my) resources misused and degrading of performance/potential in general.

Dan Pink - Drive: The surprising truth about what motivates us

Imagine explaining this to a dirt poor Hatian:

"You will have unimaginable wealth, but sometimes you have to sit in a meeting and do nothing. It's really hard"

I don't know why you think the average tenure across FAANGs is 2 years but it no doubt varies heavily by company. As another comment mentioned, Google has notoriously good WLB, and any individual team will be more predictive than the company as a whole. You'll hear plenty of "first-hand accounts" of high-pressure work environments because hundreds of thousands of engineers work at those companies!

Everyone desires self actualization, and that is different for each person. If you are highly creative and technically competent, then yes, endless meetings are a detriment to that goal. A starving Hatian doesn't negate that.

Edit: that's why people make FIRE exists and start physical jobs instead, become farmers etc, it's not as simple as a job being hard or easy, but stressful, irrational, alienating and in other ways unhealthy that doesn't necessarily make it obviously "hard".

I mean, I love my job, but I still plan to FIRE and become a machinist or something.

Alternatively I might try to get into management and see if I could make it more competent. I did that for a stretch at a Big Co, and I think I was able to really help my team to deep work and get a lot done. But then I was personally in meetings for roughly 40 hours a week and I got sick of that, so I changed jobs.

[1] - https://www.logicallyfallacious.com/logicalfallacies/Relativ...

The biggest joke in the military was danger pay, which was $7.50. $7.50 if I was working in an active warzone that day. I still stood in formations, pointlessly, for hours. I still watched people who shouldn't have been promoted get promoted over people who should. I still watched people fuck each other over. I still sat though pointless and grueling training videos. I still had 8-12 hour workdays. I still lived with the idea that my life would end early through mental or physical health issues. I could go on.

The biggest difference I have is pay and the security to try and improve the system myself. I know if I get fired for trying to do the right thing that I'll find another job, whereas in the Marines as a four year corporal with one year total combat experience I made $20k and had no career prospects should the military see that I am a problem.

Those were the negative examples. More positively, engineers are motivated by many of the same things Marines are and I use these aspects in my day-to-day leadership as well. I exercise transparency, when I know the team is shouldering a burden I acknowledge it and steps were taking to minimize it over time. Marines and engineers like knowing their purpose and place in the world. They both desire a framework that establishes a domain for their autonomy. They both desire leaders who are scrappy enough to fight in the trenches but with the tactical persuasion to have vision from above while leading from the front. They're both willing to put in whatever it takes to accomplish the mission but they want to be recognized for doing so, and not necessarily monetarily. Again, I could go on.

It's not that I disagree in principle with what you're saying, but I think you're describing the top 10% range of programmers.

Edit: and herein lies the danger in dismissing the complaints of entire swaths of people with concepts lile "privilege". It's just a socially acceptable form of prejudice that never applies to all people from the group.

I worked as a supermarket janitor in high school and college. Most of my work in tech has been for government contractors. Most days I feel like I'm still a janitor, only I'm coping with other people's tech debt instead of scrubbing toilets. The thing is, if scrubbing floors and toilets paid as well as coding I'd go back to pushing a mop in a heartbeat because at least janitorial work has a better-defined scope of work and definition of done than most of the development projects with which I've been involved.

    Not quite. Actors and musicians have it better, 
    once they've established themselves.

It's more like a freak statistical accident -- like "being born into a royal family", getting hit by a meteor, or winning millions in the lottery.

citation needed

> once they've established themselves.

BIG if; the ones you're thinking of represent the 1% or less. Survivorship bias.

I only recently learned about the term "strawman argument", and I think this is one. (Correct me if I'm wrong.) Parents post was not about SW devs who established themselves, but about SW devs in general. That you don't need to establish yourself to still live a good life is exactly one of the advantages of being a SW dev.

Besides that: Establishing yourself as actor often involves attending partys of Harvey Weinstein kind of people.

So here maybe more "survivorship bias": the bias of looking only at the top performers / the most visible ones, or here "those who made it". Ex: "Interviewer: How did you get to your position? Politician: I worked hard! I spend countless hours doing XXX etc...". Many other persons might have worked just as hard or even harder, but lacked the connection or simply the luck to make it.

I'd suggest simply:

- software engineers are hugely in demand

- software engineers have worked out they can work well remotely, and often prefer it for a combination of productivity and work/life balance reasons

- software engineers are voting with their feet and finding work that suits their needs - and many firms are losing talent accordingly due to not meeting the needs of those staff

Employers are going to have to compete really really hard for acquisition and retention of talent.

And wishy washy corporate platitudes won't cut it, firms will need to offer both aggressively competitive financial packages and attractive workplace setups - remote, flexible, whatever it takes.

I have terrible marketing skills and yet, as a freelancer, I have to refuse work because there is so much demand. This also means I can charge a month of minimum wage for a day of my labor. That's awesome for me, but that's not normal.

Everyone is a genius in a bull market.

I’ve been working mostly as a contractor for quite a long time now. This honestly is quite normal. I’ve done contract work through 2 financial crises now, and the longest I’ve been unintentionally out of work was two months, and otherwise I’ve managed to charge high hourly/daily rates the whole time.

I have seen a lot of my contractor friends go full-time during this pandemic though. When it first hit, the place that I was working at converted about 1200 contractors to full-time. The allure of job stability was too good to pass up.

But the risks were an illusion the whole time. There was a shortage of software engineers during the GFC, a shortage of software engineers for the 10 years after it, and there’s been a shortage of software engineers during the pandemic. It’s just gotten so bad recently that people who were previously more risk averse have started to notice it.

For our industry, during the last 20 years.

Not normal for most industries. Or in IT before 2000.

> I have seen a lot of my contractor friends go full-time during this pandemic though

Yeah, that's why I think it's important to have an elastic life style if you are a freelancer. So that you can suddenly cut 80% of your expenses. If you have big loans, an expensive car, 2 children in private school and live in a pricey area, if you revenue get shots, you are in trouble.

> But the risks were an illusion the whole time.

It was surprising though, wasn't it? I mean I expected calls to stop, but I got more of them. Now I have people calling me for things that are very far from my specialty.

Software is, indeed, eating the world.

Personally, I wasn’t surprised by this outcome. Temporary instability is what I was predicting. For demand for software engineers to actually tank, demand for software and software services would have to tank. I figured this was possible, but would require the entire global economy to collapse. So I figured it was unlikely, and in either case declining the offer I had to go full-time last year (when my employer at the time said they were terminating all their contractors) was most likely to be the correct decision (because full-time employment wasn’t going to protect me from global economic collapse).

The thing that I didn’t predict at all, is how long travel restrictions would be in place. Which has turned out very well for software engineers in developed economies, because all developed economies import software engineering labor from developing economies.

I worked with him for a few years, and since then I’ve done most of my work independently, which I mostly find through the network I’ve built up. I have old clients getting in touch with me, people I’ve previously worked with (who may or may not have moved companies), and contractors I’ve previously worked with who know about opportunities at wherever they currently are.

The biggest barrier to working as an individual is the MSA, getting through the corporate procurement process as an individual who’s trying to get put on some large companies list of approved suppliers is very tedious. It can be tedious for both you and whoever is trying to hire you internally, and avoiding this is a fundamental part of the value proposition offered by the contracting firms. It’s the main reason that I still very occasionally do a contract through the firm that I used to work with. I don’t often find myself without a new contract to move to, but I do occasionally find myself roadblocked by due diligence processes (which take months to get through).

In any case, one of the reasons that I feel very comfortable with this working arrangement, even in bad economies, is that I have a long list of people who are happy with the work I’ve done for them in the past.

- my first charity work in africa gave me a lot of contacts that knew what I could do, and that I could take a plane to anywhere to do it

- IT training companies that I spammed to work as a subcontractors. It was easy because they don't check reference and really need a lot of people.

- People that I trained. I can't be hired for training by them because I want to keep a good relationship with IT training companies. But people I trained sometimes contact be for dev work.

At the same time, software seems to be able to generate significantly more revenue for clients than other jobs. It makes sense that anyone wants a piece of the automation cake and therefore need software developers.

If you think about the value you're providing, you'll see you're probably creating much more value for the company than for yourself.

Sure, you charged 10k£ to build a dashboard serving 50 millions customers which took you a few days to build. That dashboard may avoid the company 25 millions calls, saving way more money than the 10k they spent on you.

I'm taking two years to work on a moonshot startup because the problem is interesting and I'm one of the dumber people in the zoom. I took a pay cut of 50% on paper and closer 80% when you price the stock realistically.

Maybe management is dysfunctional everywhere, I don't know, about to find out but mine literally just copied the email (headers and all!) from the client into the ticketing system and assigned it. Most of management has been there for decades and it has been their only job ever.

I spent more time tracking my time spent in the various systems and monthly reports than actual dev work. And the work was so mind numbingly boring.

I took the plunge and applied to half a dozen interesting job posts and that was it. I was worried about ageism, being an imposter, having to leet code, endless rounds, etc. But it wasn't that bad at all, a small take-home and a few rounds of talking about experience and now a nice pay bump and new problems to solve.

Programming as a profession has always been a blend of amazing and fun, and stupid and sucky for 4 decades. Still better than lots of things you could have to do instead. I never got rich or anything, but still have enough for a decent life.

How was it out there? I haven't been getting the recruiters hitting me up on linkedin as much, I wasn't sure how hot or cool the market is.

Not nearly as much experience, but I had the same issue. I was expecting once I opened up, I’d have a flood of messages in my inbox, given how everyone is saying how hot the market is. However, I feel like I’ve seen less than previous job searches, and filtering out irrelevant, low paying, shit jobs from those the number is even more disappointing.

I’m in central FL and I’ve been generally disappointed in this state from a job market perspective. Most of the recruiters I’ve spoken to are recruiting for roles within the state, regardless if they’re fully remote or not.

> All companies (regardless of size and paycheck) make competent developers go through grueling 4–7 rounds of interviews.

It's possible to get hired with zero interviews, you need to put yourself into a position where this is the norm.

Every single contract / freelance job I've ever taken happened without a formal interview. I never had to do a whiteboard test or explain an algorithm to someone. I never had to write 1 line of code or even talk about lower level programming things specifically for the sake of getting a job for a specific company.

All I did was talk to them over email or Zoom while we discussed what they wanted me to do for the job. Then it went straight to a statement of work / contract and that's it.

Most of these happened where the person hiring reached out to me directly. I don't use any freelance platforms or marketplaces.

Now, the debatable part here is "competent developer". I won't make any claims that I'm competent but I have done a ton of assorted gigs over the years and lots of them lasted for multiple years (and still do). For context I sent out 47 invoices in 2020.

If you hate the idea of parading around interviews and working in an office please understand you have options. Besides part time high school jobs I never worked in a non-remote position in my life.

You haven't said how, but given you've got an extensive blog and several courses, is that how you're getting your leads? And publically demonstrating your competence?

And you shouldn't forget that writing blogs and teaching courses is a whole different set of skills to programming, that have to be learnt and worked on.

I've outlined how I started freelancing (pre-blog / courses) here: https://nickjanetakis.com/blog/how-to-start-a-successful-fre...

Everything there still applies today except for going to physical meetups because of Covid. You are right tho, you won't be able to sit in a locked room because no one will find you. You need to do something to make businesses aware of you and there's lots of options based on what you're comfortable doing. Eventually you can get to a "in Soviet Russia, job finds you" world where you sit back while picking and choosing the contracts you want to take on but it will take a good amount of effort to get there, but you can still be successful doing freelance work waaaay before that happens.

You just maintain video courses, ebooks, mailing lists, multiple social media profiles for marketing all of the above, and an endless supply of blog posts because you enjoy doing all this in your spare time.

You're not wrong but it's probably not as many hours as you think to do all of the above (and more). I average around 15 hours a week on that stuff and a few things you've listed are close to no time at all. For example I only send one email out a year and I haven't written an ebook in like 3-4 years.

I still stand by my claim that you can make a living as a freelancer without doing any of the above. That's not based on theory either, it's what I did for over a decade. I only started a blog and doing courses because I thought it would be fun and it felt like a good combination of things to do with contract work because both things feed each other in a nice way.

People who imitate MLM marketing for self promotion are among the internet's most insidious grifters, imo.

Those 15 hours account for everything because releasing free blog posts, podcast episodes, youtube videos and open source tools is the marketing. Almost everything I release is for free with no strings attached and if anyone wants to watch or read that stuff they can, if they don't then they don't. I don't even monetize my YouTube channel because I don't like watching ads myself.

I never purchased a single paid ad and also don't cold email or spam anyone to "market" my courses. I had to Google what MLM even stood for.

The rest of the time I'm doing contract / freelance work and by "rest" it doesn't translate to an outrageous amount of hours per week.

True.

I'm a tech blogger and teacher and I sometimes get offered development and management jobs.

I've interviewed at many companies of all sizes in several countries in Europe and never faced anything closed to that. My current job I was invited by a former colleague to apply and the interview was mostly them convincing me to quit my job and work for them.

That was sum total of my interaction with the company before being hired (other than telling the recruiter to send in my resume).

Unless you count 15 minute call with recruiter at the beginning as "interview round", there was nothing more.

https://airtable.com/invite/l?inviteId=invtzMOjpyMmmowAK&inv...

I've found it's very rare to do this nowadays. Even if you know someone at the company, you'll likely get grilled in a technical interview.

Unless it's a very tiny company / startup.

Tangent: I followed your profile's link to your blog. I like what I saw (wrt Docker practices). Have you written about your freelance / contract gig experiences per se? I've been mostly remote for the last 20y, strictly remote since starting my tiny S-Corp / committing to consulting FT 4-5y ago, and I'd be interested to compare notes.

Do you have a site? Comparing notes is fun.

The real reason why hiring freelancers and contractors is easier than employees is that the cost of firing an employee is non-zero.

https://www.facilitiesnet.com/commercialofficefacilities/art...

It's one of the bullets.

> A verifiable track record is overlooked, while CVs filled with adjectives top the stack.