Senior developers are leading the great resignation movement(tipsnguts.medium.com)
tipsnguts.medium.com
Senior developers are leading the great resignation movement
https://tipsnguts.medium.com/why-senior-developers-are-leading-the-great-resignation-movement-37b93ab9a634
356 comments
> 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.
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.
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.
Agree to this. Daily standups are the bane of many people's existence.
wasting time hearing about peoples work yesterday/today that I am not involved with nor has any impact on my work is a waste of every ones time.
Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
I despised daily stands in person, but love them on a remote team.
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'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.
I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV
My current employer's standup is now an hour long. There's only 6 developers on the team.
Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.
Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.
This is almost certainly due to poor facilitation. That is to say, whoever is facilitating this meeting is either afraid to push back or else thinks that this is how it should be.
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.
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.
The central evil is letting anyone control the standup that isn't directly participating in the work output of the team.
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.
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.
I knew one company where the standups were getting so bad, the managers solution was to have everybody in a plank position for the meeting. Meeting time got short real fast.
Next up: forming an actual rugby scrum, from where the scrum methodology gets its name.
https://en.wikipedia.org/wiki/Scrum_(rugby)
https://en.wikipedia.org/wiki/Scrum_(rugby)
> This is almost certainly due to poor facilitation
Yep. I've suffered 20 years of poor facilitation. I keep hoping for some facilitation.
Yep. I've suffered 20 years of poor facilitation. I keep hoping for some facilitation.
Facilitator is the PM, person who thinks it should be this long is the client. Client always wins.
Dont go. Seriously. When they ask why just say 'I do not contribute and am in the way there'. One place I worked it took them 4 months to realize I was not in the 1-2 hour meeting every other day. It took them another year to realize most of the people on that call should not be there. The managers are confusing their status meetings with yours and now they are one in the same. That is why they are long and disorganized.
I knew a particular self-important PM that had follow up point-poker meetings that easily went into the three hour range. She was very useless, but it was almost like going to her own little tea-party with her little dolls that she fed fake tea.
Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.
Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.
Oh man I feel for you. At the startup I'm currently at, it's all remote and we have daily stand-ups that are only 15 mins but usually they finish in 2. Not sure if it's useful or not since you could probably express the same info in a message but it's nice to see people I suppose.
Daily standups, weekly retros and weekly 1-on-1:s. Those are the ones that bother me the most, the micromanagement around planning, I can deal with. But the creepiness of these other vague "Hey, I'm your friend, we can just talk" type of meetings are too much for me. And this trap of "giving feedback" and whenever you do, you get punished and marked for no promotion, immediately, it's just loyalty checks masked as something else "this meeting is for you" uhmm, can I just go back to work please?
Stand-ups can be a drag. My last stand-ups were literally 3-5 minutes, which I attribute to everyone working on long-running project where we all either knew what "Today I'll be fooing the bar" meant or knew it wasn't important to know. And we were very good about mentioning but not discussing problems during that meeting; they'd be dealt with "off-line" (so to speak).
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.
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.
Spot on - In my mind I use Agile and Scrum interchangeably because Scrum is what I see being used everywhere and it sure has swallowed Agile up it up like you said! It's too easy to throw scrum in - who doesn't like ready made processes that take minimal effort to overlay instead of integrate? Agile without scrum would require a deeper level of effort as it would first and foremost involve people. Much harder to think from people first standpoint than process first standpoint.
> 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.
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.
I usually come back to my “products vs projects” division.
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.
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.
Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.
I used to lament “they’re doing it wrong” but I’ve come around to the fact that sometimes, that op model really is best for the size and way the company operates. If they don’t have technology product management as a skill in-house, it’s a seriously hard capability to build. In those cases, being able to work with an experienced vendor is great — but usually requires either time-boxed T&M or a deliverable-based contract (which is effectively timeboxed to protect the consultant’s margin). So you need to do handovers as your MSP / internal IT may not have the expertise to execute every project, and those (expensive, specialized) resources need to go away after the project is done.
I understand what you are saying, but this is all internally built stuff. The slopey shouldered mentally breeds a "don't give a fuck" mentality around code, testability, ease of new releases etc. I'm used to eat your own dog food.
This crystallizes for me that I’ve been a product developer mostly living in a project world (even when nominally building products).
> 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.
> 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.
> managers want graphs, points, velocity, etc.
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.
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.
To me, Scrum is a sad story about how the road to hell is paved with good intentions.
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.
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.
I guess the real question is why the fuck are management courses still founded in Taylorism?
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).
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).
You know that high you get when your software finally works, with all the little cogs churning away and producing something much bigger than any one of them as a system effect? That, but with people. Feeling powerful feels good.
Only if you have zero empathy for human beings and the consequences of your actions.
People are not cogs.
People are not cogs.
> I guess the real question is why the fuck are management courses still founded in Taylorism?
Are you familiar with the streetlight effect?
That is why.
That is why.
So did the consultants tell you that you were doing Scrum completely wrong or why did you have to change?
[deleted]
“ … mandatory for all the developers and skipped by all the managers, including product managers.”
So, are the developers somehow responsible for the problem, since the managers were never exposed to the consultant?
So, are the developers somehow responsible for the problem, since the managers were never exposed to the consultant?
> Scrum does have a lot of processes and artifacts and things to measure
Scrum, per se, has no defined measurable bits. If a process has lots of things to measure, that's due to decisions besides the one to use Scrum.
Scrum, per se, has no defined measurable bits. If a process has lots of things to measure, that's due to decisions besides the one to use Scrum.
Those things provide jobs and revenue streams for companies.
That’s why it exists.
Our free speech society relies heavily on sticking to jobs, economics, and service to industrialists.
That’s why it exists.
Our free speech society relies heavily on sticking to jobs, economics, and service to industrialists.
Scrum in of itself is not so much a deal, if it just provides a light framework/training wheels for companies transitioning to Agile. 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.
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.
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.
The reason people are hating scrum isn't because the simple scrum statement is simple, it's because a whole industry has been formed around advocating "true scrum" with consultants that fly in and give big meetings about how you can turn scrum into a tool for micromanagement.
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.
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.
Agree. Also tickets being units of work that you can assign "effort" points to and measure "velocity" with is the biggest load of shit I've ever come across. I'm surprised any developers buy it. I've been told "oh no effort is not time" me : "but you always says what's that in days?"
"No but we don't measure velocity like that"
Me internally "oh fuck right off"
Scrum doesn’t have velocity and burn-down charts. Those are add-on Agile extras. Scrum is simple, but it’s so annoying how people make everything so complicated. When I start working on something, we may have an idea of how much effort it is, but often you dig into the code and find gnarly tangles, or the model has more gotchas than people realize and the person doing the work is the one person who has the entire model loaded into their head at the moment. Yes, a manager might need to verify people are actually working, but if the manager is capable it shouldn’t require burn-down charts which can be full of inaccuracies. It often takes actual thinking to get real work done and micromanagers hovering about do not help with producing thoughtful work. Scrum just says to get some help from friends when you need it, communicate about what could make your job better in the next few weeks, and are we breaking things down into bite-size pieces or do people have unrealistic expectations?
Yeah that semantic debate about what exactly the story points mean, is my least favorite recurring stupid conversation, right after that angry debate of what exactly constitutes a "true" unit test, lol
We just had a talk from our master about how points are not days. Every developer ignored him and treated it as days because that was the signal. Management just made it official. Jira Align is rolled out and points are days. The master just threw up his hands and took his promotion under great duress.
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.
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.
Scrum is a tool. It even has a tool built in to take care of these things, the retro. If you have someone on the team who is counting every point and dogmatically sitting on every metric that should be brought up in the retro as 'something that is not going well'. These tools are a way for devs to say 'here is how I am going to break this up and you have a limited amount of time so pick what you want'. The metrics are to help you realize you are doing an anti pattern. But if you force everyone to be good at them they will hide what is wrong.
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
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
If everything is a number one priority, nothing is.
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.”
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.”
I get that. I have used that exact way of handling it. I was just tired of the 'everything is first' and got pissed off. To prove that they were being silly I picked something I knew for a fact would be a low priority and said 'this is going first. 'oh well not that' 'ahhhh you do know what order this is in compared to the others lets write that down'. I made it painful meeting wise for them to do that to me. Think in one meeting I walked in with a quarter and just started flipping for what went first. They did not like that either. Again 'ahhh you do know lets write that down'. The confusion comes from 'i want it done' to 'which one first'. Those are not the same thing. Something will go first. Either you pick it or I do. If I pick you may not like the answer.
Ah yes, that conversation. Here's the list of things on the road map. Which ones do you want to bump to next quarter/year in order to do this new priority? "None" is only an option if you can somehow retroactively hire another dev 90 days ago.
My favs are the ones who still despite all of that somehow think they can 'make it work out'.
> they can not work on 15 things at the same time 200% of the time.
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 ;)
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 ;)
in my team we don't micromanage, however I agree that some scrum events can be adjusted a bit. For example the sprint reviews don't make much sense if you can deliver any time you want, and we do. It's probably just a way to wrap a bunch of work we did and show it to keep everyone on the same page about what's happening.
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.
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.
Scrum stems from lean not agile
In the late 90’s, one of my clients was an ultrasound company in Seattle. I was on a small software team of five or six competent engineers. We gelled as a team, embraced Kent Beck’s Extreme Programming (XP) philosophy, and really kicked ass.
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.
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.
In my team, we have a fairly strict process, it's been refined over time by the team. We change little things every sprint.
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.
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.
Great idea on safe word!
Which is to say, a competent manager of developers doesn't need someone to hand him a textbook that denotes how to organize a development project, and people who do replace their own void in competence with meetings and reports?
If you witnessed the transition from mediocre, not to speak of incompetent, manager to a competent one, your comment doesn't need an more explanation.
Agile is A) vague and inspiring enough that everybody can project their desires, hopes and dreams on it and B) vague enough that it can be twisted by any authority to serve pretty much any purpose they like.
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.
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.
My opinion is that Agile is intended to be vague, as there can't be a silver bullet plan that fits every occasion. Of course, "no silver bullet" sells way worse than "I've got a silver bullet for you right here, Mr. CEO, just sign here".
Let's check some "principles" posted at https://agilemanifesto.org/principles.html
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.
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.
Wasn't the original manifesto written by consultants?
Some of the them were practitioners and very technical. Kent Beck, Alistair Cockburn, Ward Cunningham, Dave Thomas, Robert C. Martin, Martin Fowler. In general there was a movement about better ways to develop software (beyond waterfall) and people were trying to figure it out. In 2002 they just got together and put it in writing.
What do you mean by not using agile? No time boxing? Continuous delivery? 1yr waterfall?
He's not complaining about Agile itself.
He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.
He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.
He must've used some kind of work planning and scheduling though, even if it was 'as soon as possible but not sooner'
I have worked on a combination of Time boxed and CD. The timeboxed ones had a overarching timeframe defined but we had lot of leeway within that to go and do our thing - sometimes we would spend more time thinking about how to solve it more efficiently - do PoCs, brainstorms and that saved us implementation time. We would have weekly status update meetings and more if needed - it was mostly self organizing and so long as we had people that cared and knew what they were doing it really worked well.
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.
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.
In my case it was gitprime. This is a software to stack rank based on git commits. Since good developers supposedly make lots of small commits, if someone makes too few, they are bad. Also bug fixes are penalized as “code churn”.
This is downright hilarious. First order of business is to write a program that generates a commit + well-form commit message whenever a character is typed.
“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”
“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”
Spot on and well said!
Completely agree and I left my last job for exactly this reason. Endless meetings fuelled by direction coming from above of needing to cooperate more and Agile coaches popping up.
The CTO and some early developers in the company were basically meeting in secret, deciding what new cool thing they had to run in teams (whether mob programming for hours or some new way of organising the backlog) and then all the early developers (who didn't have a formal manager title - sure, just normal developers like everyone else! Flat structure! Everyone has power!) were going back to the teams and proposing this new cool thing. The majority didn't have the heart to put them down and soon the trial would become a standard practice.
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.
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.
I would love to work without these idiotic ceremonies. I get into fight with our agile coach because he insisted on making new features instead of fixing bugs because we didn't have anything new to present in demos. Stupid.
It's not stupid.
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.
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.
Apple's Snow Leopard was mainly an under-the-hood redesign and re-architecture with very few features. It's considered by many to be one of if not the best OS they've ever released.
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.
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.
I should give some context. We're developing an internal application for the staff at the branch. A customer comes into the branch and a company employee sets it up in the app. We have a release every two months and the demo is every two weeks. The problem is that not many people come to the demo because they are not interested. Our agile coach says it's because we're not delivering enough new features and we should be doing more. For us, it's not the app that sells, it's the people. An app is a tool to get somewhere, store data, but it has a lot of bugs in it. I'd rather have a functional product than useless metrics that in our case doesn't increase sales. That seems silly to me.
"This is not to say Agile itself is bad"
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.
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.
I completely agree - that's really what I meant by Agile as a philosophy isn't bad - its implementations? Sure.
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.
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.
I describe this as "agile manifesto" vs "agile methodology".
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.
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.
> 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.
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.
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.
We're on the 15 minute schedule since some of my team's work is billable hours.
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.
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.
The Toyota process says - you cannot manage a production line effectively if you don’t understand it.
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.
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.
> Agile has become a way for people with no development experience to “manage” developers and that will always be wrong
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.
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.
> True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge
What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.
What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.
In reality they turn into work assigners - individual A in team C has no stories to groom - let's give them some stories from Epic D which has more story points per developer. Think about how simplistic that sounds to the scrum master and how complicated it is in practice and who is filling in the gaps.
Most people have discarded his ideas and success as toxic waste but a lot of people are still drooling over Jack Welch. "A good manager can manage anything!" ...and similar pronouncements. People learned this years ago in the context of unquestioned success. And like the rapidly changing circumstances usually involved with things like communicable disease spread and business in general, these people have not updated their understanding in light of new information and so continue to act on the aforementioned "wisdom."
Who can blame them. They got an A for repeating what the professor repeated.
Who can blame them. They got an A for repeating what the professor repeated.
Virtually all aspects of western society is being eroded by the “management is a job-skill” type thinking. I expect that eventually we will stop doing this simply because it’s complete nonsense and clearly counter productive.
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.
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.
This is absolutely it. Since the managers are measured based on the productivity of their team, rather than the quality of their management, businesses have no mechanisms to identify whether managers are accelerating their developers or holding them back. This often leads to our products succeeding despite management, rather than because of it. Working under leadership that does not understand the work has been the single greatest source of burnout for me personally.
This is definitely a fundamental problem. It often becomes clear when a "scrum master" asks some technical sounding but non-sense question.
> when a "scrum master"
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.
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.
[deleted]
Small "a" agile is perfectly fine. I worked in an organization that did "Scrum of Scrums" (aka waterfall disguised as Scrum) and my job description could have easily been "attends meetings".
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.
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.
Agile is like Communism. Sounds good in theory, but it's never actually been used successfully. And every time someone tells a story about it failing the apologists inevitably reply with, "but that wasn't real agile."
I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all.
I would suggest that if something is so hard to get right, then maybe it's not such a great methodology after all.
> 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
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
I think Scrum has sometimes its place for web agencies or the like, with external clients with deadlines and budgets.
The mistake was applying it elsewhere.
The mistake was applying it elsewhere.
Yeah that was a huge transition to make when working for an agency. Realizing that the bullshit work to communicate with the client while technically slowing the whole project down was the most important task you had. Reason being, the "product" wasn't really the code you were developing for the client, it was delivering client happiness, and often they cared more about being in the loop than getting the maximal amount of functionality.
Yeah this is how I always felt about Scrum, that it's made for IT consulting firms to manage the relationship with the client, and that the "product owner" is in the clients organisation, and scrum master works in the consulting firm, so it's a tool to negotiate and manage expectations for delivery.
> The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks...
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).
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).
I've come to see a lot of these tools as sharp objects.
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.
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.
One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
Yeah same here, I quit my last job when they started the transformation to Scrum and I got a supervisory manager.
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.
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.
TBH every team/company I've seen that uses strict agile/scrum is surpassed by the non-agile teams eventually. There are exceptions to this for teams that have modified agile/scrum to the point they can sensibly do long-term project planning and account for short-term hickups.
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.
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.
Is Scrum the problem? Or is that tech, which has become high status in the last 6/7 years is starting to attract the kind people that went to make a management career into more prestigious areas and they are starting to manage us in the same way they manage these other areas?
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.
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.
> Supervisory managers brandishing Agile + endless meetings
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.
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.
I wish scrum had some support for decision making, where you'd attempt to evaluate suggested solutions based on the actual goals of the team/company, have healthy moderated debates, and in the end (by voting or manager) make a decision which is then documented, with a note on when it can be revisited the earliest.
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).
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).
> 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.
> 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.
> 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.
> 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.
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.
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 agree completely with everything in your comment.
I work at a company where "Agile evangelists" are charged with making technical decisions and prioritising work over actual software developers.
If I go job hunting again, I want to avoid that sort of company. How do I do detect that sort of culture before I join the company?
This reads to me as yet another screed by someone who has never worked outside the tech industry. Software Engineering is IMO the best, most privileged job available in the US, and I suspect in much of the world. Life-long tech workers have no idea how much worse conditions are even for “knowledge workers” in other fields.
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.
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.
> privileged...resort...great pay with benefits...privilege...entitlement....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.
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.
Jay Gould once bragged he could get one half of the working class to kill the other.
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.
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.
> 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.
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.
You can now add: mask vs maskless, pro vs anti-lockdown, vaxxed vs unvaxxed.
So when you sit in endless meaningless meetings and see how the management create insurmountable obstacles that make it impossible to actually do some meaningful work while whining about deadlines and changing the requirements on a whim, you should just be thankful that you have a nice paying job? Well you can be thankful and still cry inside since if the management were competent, you could get 3x done. If you feel this several decades you die inside little by little until you do what is described in the article.
I think the point is that these are not real problems.
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.
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.
I've worked roofing jobs, carrying heavy bags of shingles up ladders to the roof in >40C temperatures in the summer. I've cleaned filthy toilets. I've worked in a factory where the noise and hot stench of plastic injection molding machines would give you burning headaches for hours. These experiences don't invalidate the problems of tech workers, but they help me put them in perspective. Having the choice, I will choose sitting in an air conditioned office dealing with impossible deadlines and soul-sucking meetings any day of the week.
same. any meeting is just 'me time' chilling for an hour.
yeah, I've known people working in Law and Banking. Lawyers at big firms work grueling hours until they get promoted enough.
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.
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.
Remember we are talking about senior developers. People with 15, 20, 25 years of experience. By that point in law you are not grinding.
Yeah I’m a “sr architect” on an enterprise team where I work. I work from home in my home office and I get to see my wife all day or play with the dog. But at the same time I have dozens of people screaming at me over Teams it email or sometimes just calling me. Everything is always top priority. Everything is mission critical. Every project deadline is static and can’t be budged even a little bit. Don’t get me wrong. I’ve worked in factories before. And gas stations. And warehouses unloading trucks. I know what a hard day is like in a physical job earning a fraction of what I earn now. But at the end of the day it’s also about what it costs to earn that salary. And when sr leadership refuses to listen or understand something and when projects change wildly or have no direction…it might not be the same as unloading trucks of heavy boxes in the summer…but it really, really sucks to work so hard and build things that are genuinely cool only to have then be pulled into meetings the next day asking why you suck at your job.
Relatively smaller problems are still problems. Rather than diminishing the significance of certain perspectives by calling them "not real", we should be acknowledging issues like this at all strata.
There are people out there that make your wife's problems look paltry too.
You can safely dismiss almost every problem in the world with your approach.
You can safely dismiss almost every problem in the world with your approach.
Sure, but software engineers are at the top. There is no career where the reverse of your example is true.
"Our jobs aren't that bad – do you hear what they do to software engineers?"
"Our jobs aren't that bad – do you hear what they do to software engineers?"
Software engineers are not at the top. Billionaires are.
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.
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.
Plenty of poor people around the world make way less than your wife and work the same or more hours. So, I guess tough noogies to your wife. If she's not literally starving then she has no right to complain ever about anything since starving people exist.
The point I’m making is that software engineers have developed a habit of bemoaning about how their jobs don’t bring them to the peak of self-actualization.
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?
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?
"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.
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.
[deleted]
Working conditions can always get a little better. And if you don't ask for it, you won't get it.
Agreed. If you’re not working the literal one objectively worst job in the whole world you should never complain about anything
[deleted]
I think the problem here is motivation and keeping it up for so many years. Maybe there is a trick to it. Idk.
Book & YouTube talks:
Dan Pink - Drive: The surprising truth about what motivates us
Dan Pink - Drive: The surprising truth about what motivates us
There are people who would do anything to make a FAANG salary. Acting like sitting in meetings is hard shows exactly how much of a bubble you are in.
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"
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"
The criteria was that is was the best job available in the world's wealthiest country, not that it was palatable to a someone living in a very poor country plagued with issues much lower on Maslow's hierarchy
Lots of American developers would love for a FAANG salary too. Total comp at a FAANG is now, what like $500-800k for a mid-senior position? Outside of a handful of areas in the USA, that same person would be earning, maybe $100k, no stock, and passable benefits.
Ok? what is your point? Are they physically and mentally capable of achieving that? How much do they desire that goal? Are they willing to sacrifice other things in their life for that? Its not like FAANG employees are picked out of a hat
Mid-senior is more like $300-400k.
I really don't think that changes the point!
Working for FAANG simply isn't sustainable. First of all, it's very difficult to get a job there as an engineer. And even if you did, most people don't last very long: I think the average is like 2 years. And, even if you somehow manage to stay longer than 2 years, you're going to keep getting abused with high pressure work environment: I've heard several first hand accounts of this. and you can find evidence of the same, all over glass door if you read the reviews.
It's not that difficult, FAANG (literally just those 5 companies) employ probably at least 5% of the SWEs in the country; add in all the other companies that pay comparable money and you're probably at 8-10%. Something that 10% of engineers can do (and, realistically, much more than 10% - how many engineers have never even tried to get in? At least half?) is, by definition, not "very difficult", relatively to the baseline level of difficulty inherent in the job.
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!
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!
There's also plenty of people who refer to Google as a retirement home. It's a huge company, individual experiences will vary.
^^^ Burrito is right, levels.fyi is your friend.
what a straw man you are making. It is meaningless to diminish the wants/needs of one by comparing to some arbitrary level of poverty in the world.
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.
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.
You don't even have to invoke a dirt poor Haitian, you can just invoke younger me: I thought then that if I even made half of what I make now, I'd want for nothing. And the reality is, I'm doing pretty well. But that doesn't mean there aren't some things that could stand to improve.
Yeah and there are many blue collar jobs where workers have way more integrity and respect, and where the managers are actually (held) accountable. Being a software developer is pretty spineless in comparison, even though you make more money and get to sit on your ass. I think it's unhealthy and causes burnout.
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".
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'd say my desire for a physical job post-engineering comes from an innate desire to build physical objects. Building software doesn't really press all the buttons.
I mean, I love my job, but I still plan to FIRE and become a machinist or something.
I mean, I love my job, but I still plan to FIRE and become a machinist or something.
People make fire exits.. because they can. All jobs suck if you prize freedom. I’d probably do more gardening in fire but I could never fire on a similar load of work in a gardening job.
I wouldn’t do that, I’d change jobs. That’s the awesome thing about working in software - we’re so in-demand, and there are so many jobs where you don’t just sit in meetings all day.
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.
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.
It’s 12:15 pm and I’ve been working since 3:00 am trying to keep on top of deadlines but in my current role I’m an architect and I’m also the engineer that builds the things I design. And I’m also the only point of contact for testing. And I’m the only point of contact for troubleshooting. I don’t have an engineering or qa team..it’s just me by myself. And it crushed my soul every morning when I wake up. I’d quit right now if my wife didn’t require expensive and complicated medical treatment. I guess that’s more a problem with the medical system than anything. But even with savings we wouldn’t be able to last more than a year if we didn’t find similar income with similar insurance.
If you truly could get 3x as much done, why not just go out and do it on your own? (Because all the stuff you don’t like actually has value, and you need someone to do it!)
My way to deal with this is to pocket the money, while planning my exit by way of launching my own products. Once one of them get some traction, I am out.
Relative Privation fallacy[1]. Or just another case of: "But there's people starving in Africa".
[1] - https://www.logicallyfallacious.com/logicalfallacies/Relativ...
[1] - https://www.logicallyfallacious.com/logicalfallacies/Relativ...
I worked in the Marines and am now a software engineer at a large tech firm.
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.
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.
This is really eye opening. Thank you for sharing!
Though I feel the military & the Marines specifically might be an outlier and not a valid comparison
They may be, tangentially, my experience resonates with blue collar and union workers that I know.
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.
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.
I used to think like you, until I turned 40 and spent 3 years in a row, doing full SCRUM, babysitting developers while my "manager/PO/everything" does little regarding planning other than "I want this". Conclusion: I dropped to 24 hours/week and have a much better life quality now, working 3 days per week.
best most priveleged job? no social status, pay below marketing and sales execs, relearning tools every year, assumed to be replaceable, leetcode BS every year, doing incredibly hard work with little credit, the list goes on. engineering only pays off if you are a founder and manage to sell the company for a lot of money, which is a gamble. also, no protections such as unions as engineering is a white collar job. sure, there are worse jobs. but claiming that this sort of work is the best job ever is ridiculous.
That's good. Don't advocate against yourself. Other kinds of work don't have this because they take on that idealogy of working against themselves. Be privileged and demand more. The companies are perfectly capable of paying it.
>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).
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.
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.
more like 0.1%
Tech pays well and has benefits, beyond that it leaves a lot to be desired. Having worked “shit jobs” tech is great when it’s great but when it’s miserable it is worse than retail, construction, etc. Your self-worth and ego are closely entwined with your performance, and sometimes situations outside yourself can make it hard to perform. At least in retail you never dream about a problem or question if you are smart or good enough to do your job.
> Life-long tech workers have no idea how much worse conditions are even for “knowledge workers” in other fields.
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.
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.
> the best, most privileged job available in the US
Not quite. Actors and musicians have it better, once they've established themselves.
I'm not being facetious here - with people trying to "break in" to programming and endless auditions in the form of whiteboard interviews, I can't help but feel like we've ended up in a career with most of the downsides and few of the upsides of an entertainment career.
Not quite. Actors and musicians have it better, once they've established themselves.
I'm not being facetious here - with people trying to "break in" to programming and endless auditions in the form of whiteboard interviews, I can't help but feel like we've ended up in a career with most of the downsides and few of the upsides of an entertainment career.
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.
> Actors and musicians have it better
citation needed
> once they've established themselves.
BIG if; the ones you're thinking of represent the 1% or less. Survivorship bias.
citation needed
> once they've established themselves.
BIG if; the ones you're thinking of represent the 1% or less. Survivorship bias.
> once they've established themselves.
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.
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.
Maybe partially "strawman argument": when someone refutes an argument by proposing a counter point that refutes a related, but different, argument. It can even be stuff like: "Senator: I will vote to increase the public transportation budget. Public: Why don't you care about education?"
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.
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.
This comment must be satire.
I agree this is a phenomenon right now, but I feel that article is vastly overcomplicating it, and not necessarily accurately.
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
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
Also: more and more job interviews are happening via Zoom. It's far easier to find a new job when you can do it without booking a day off from your current job.
This isn't true for everyone. I'm on site every day and Zoom is a hassle compared to a phone call I can do from my car.
Sure, but how many companies were hiring Senior Engineers with just a phone call? Zoom is definitely less disruptive than having to sneakily drive across town, let alone fly across the country on a weekday or two for in-person interviews.
Replying to myself - the phrase "the war for talent", coined in 1997, has always been apt for the tech sector and it's just becoming more and more so.
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.
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 also suspect there's a personality aspect. Software engineers make good money, but that's not their primary, or only motivator. They're willing to trade a bit of that income for QoL.
And interesting problems.
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.
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.
Interesting work that I'm ethically OK with is pretty much the only thing I care about. I have taken positions that involved a reduction in pay because the work itself is something I'm particularly interested in, and would do so again in the future.
Businesses are focusing on "developer experience" and burying people in tech tools and abstractions instead of addressing leadership, product, or pay issues.
Pretty much. We can do so because the market is in our favor. Not because we have balls of steel unlike in other industries.
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 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.
Very true.
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.
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 can charge a month of minimum wage for a day of my labor. That's awesome for me, but that's not normal.
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.
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.
> This honestly is quite normal
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.
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.
It’s been normal since software and the internet started to become an important part of every area of society. But that’s how economies progress. There was a period in recent history when demand for manufacturing labor greatly outstripped supply. Our skills are simply in demand by the fastest growing areas of the economy right now.
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.
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.
Sure. Also, we were the industry with the most experience and tooling to work remotely, not to mention the best format for that. That couldn't have hurt.
How did you get started in contracting? Did you just start with a previous employer or do you use an outside firm?
I started out contracting through a firm. People complain about them clipping the ticket, but if they’re actually good at their job, then they can be pretty worthwhile to work with. The guy I worked with was great, and I was recruited by him to work a contract role the same way recruiters are constantly reaching out to people for other full-time roles.
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.
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.
I have 3 main sources:
- 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.
- 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.
With the flood of boot camp graduates etc on one hand, cs grads , not being able to find work after sending out hundreds of applications — what would you consider a “software engineer” in terms of merit for being sought after like you mention? Open source ? Have sent a large codebase to prod successfully? Or just have the basics of modern workflows with DevOps /cicd / web / basic leetcode
Do you have some numbers on this? This contradicts what I've been seeing/hearing - that companies are snapping up novices and fresh grads to fill more senior roles.
nah no numbers, just r/cscareers
Is it a bull market or a supply-constrained market? Bull market implies your work is heavily valued in a trendy way, whereas supply constraints mean it's simply very hard to find skilled engineers.
I'd say both, but the quote was not for accuracy, rather convey that we should stay humble about it.
I would throw in that some percentage of 'the great resignation' isn't a new movement at all, but a one-time backlog of people who stayed longer at their jobs in the middle of a pandemic for income security. Now that things have gotten better (YoY, relatively speaking,) 2021 is full of both 2020's and 2021's resignations.
This x 100. I’m surprised we don’t see this brought up more often. The same effect is happening with many obvious life changes - weddings are way up, and I wouldn’t be surprised if there’s a small baby boom in the next year or two as people who waited through 2020 finally felt safe/stable enough to make voluntary life change again in 2021.
I would throw in also real estate market that makes them cash in on their homes in the city to move to the rural areas (or back home). I think the are way more factors that just this.
I resigned yesterday, and with 20 years experience I guess I'm a senior dev. It was many factors, but management and the amount of process and the banality of the work finally did me in.
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.
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.
What kind of work you were doing? I'm working in bank and most of my work is finding a bug in tens of thousands lines of logs and then fixing it. It's really slow not because it's hard to solve but because literally everything there is slow. New features consist mostly of integrations on systems so rest call and them data process. It was similarly dumb?
I used to do a similar job a few years back. Reading logs upon logs and reading code I didn't write. I was so depressed I eventually got fired. Now I earn a third less, but I design and code my systems from start to finish. It really makes a difference if you have a feeling that you did something of value at the end of the day.
Instead of quitting I retired this year after 40 years as a programmer. I was much in demand since I could do with fewer people and deliver things no one else could do, yet my team was taken advantage of repeatedly and given no thanks for anything. In the end it simply wasn't worth the long hours any more. I didn't work in a FAANG company but a huge non tech company that used a lot of tech to support the business. Now I make art using my programming experience and life is much more pleasant. But my former team (younger than I was) still suffers and likely each will move on soon as well.
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.
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.
In my experience it's rare for a company whose core product is not technology to realize the ROI they're getting is completely worth is and to continue investing in tech and appreciate their tech staff.
I'm right with you. 20 years experience, I guess I'm a senior dev. I'm worried about ageism, being an imposter, having to leet code, endless rounds, etc.
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.
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.
> How was it out there? I haven't been getting the recruiters hitting me up on linkedin as much
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.
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.
Are you trying to only find remote work? What area do you live in?
Yeah only remote right now. Normally I’m open to relocate, but I recently had to renew a lease that’s not breakable.
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.
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.
how do you ensure that new company isn't the same or just slightly better than older company. Everyone seems to promise rainbows and ponies in the interview.
You don't really, that is why I consider the pay bump what I call 'grass is not greener' insurance. I'd rather get paid more for the same thing wouldn't you? And I can't imagine it much worse really. But you won't know without trying.
From the article:
> 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.
> 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.
This doesn't magically happen, a new developer can sit in their room all year and won't get a single lead unless they do something to get them.
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.
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.
"writing blogs and teaching courses is a whole different set of skills to programming"
True.
I'm a tech blogger and teacher and I sometimes get offered development and management jobs.
True.
I'm a tech blogger and teacher and I sometimes get offered development and management jobs.
I didn't have a blog until about 2015. Most of the work I've gotten happened before I had a site or created courses. Prior to that I had no background in writing or making videos. I decided to try those approaches on a whim. It literally started with "I wonder what would happen if...", and then I started working on it the next day but neither are necessary to find leads.
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.
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.
Sure, you're just swimming in consulting work by now.
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 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 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.
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.
15 hours a week is two full work days.
Other three days spent promoting the stuff he put in those two, lol.
People who imitate MLM marketing for self promotion are among the internet's most insidious grifters, imo.
People who imitate MLM marketing for self promotion are among the internet's most insidious grifters, imo.
> Other three days spent promoting the stuff he put in those two, lol. 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.
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.
Could be god tier leet-coder with that time.
He is talking about senior developers. A "new" one will have to build good credentials over the years with different companies before being able to pull a contract without doing a single formal interview. I can confirm that this is also possible without having any blog or whatever, there are enough companies who don't play the FAANG HR game.
I've only walked right into a job once. I had worked with one of the head guys at another job, weeks before they hired me. So they clearly knew I knew my stuff and was capable.
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.
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.
All companies (regardless of size and paycheck) make competent developers go through grueling 4–7 rounds of interviews.
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.
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.
I think that's mostly US corporation thing, all five jobs I've had in EU - including two in current fintech unicorns - had at most 2 rounds of technical interviews, then one with manager/director of department.
Unless you count 15 minute call with recruiter at the beginning as "interview round", there was nothing more.
Unless you count 15 minute call with recruiter at the beginning as "interview round", there was nothing more.
In my entire career in the US, including at multinational software companies, I have never had to go through more than 2 rounds of interviews. If I were faced with that prospect, I'd probably just pass on the position.
That's the new standard at least for companies in Canada and US. Everyone says the market is hot but with 6 rounds of interviews where the companies nitpick on every little thing is not a signal that they actually really need more developers.
Maybe you need to find a different class of folks to hang out with? I just started a new programming job in the Midwest. I had one Teams interview with a bunch of people and a "pre-interview" questionnaire before that.
That was sum total of my interaction with the company before being hired (other than telling the recruiter to send in my resume).
That was sum total of my interaction with the company before being hired (other than telling the recruiter to send in my resume).
Sure I think they do exists somewhere?
Should we start a list of companies that do sane interviews?
I mean no take home "4 hours" assignments or one weeks test work arrangement or 7 rounds of virtual on site....
Simpler to clearly tell them, no, I'm not doing that. Enough people refuse and the practice stops.
The market is hot, and because companies are hiring so much,they now have to rely on people (engineers) who in the past didn't have to conduct interviews; people who are not particular skilled in, or hired for their knowledge of conducting interviews. Hiring is one of those things that scales poorly.
Who is doing more than a couple rounds of interviews outside of (pardon the scare quotes) "tech companies"? Has anyone run into, say, a bank pulling 4+ rounds of interviews, or is this limited to FAANG(M), SV companies and startups that seek to emulate them?
Sorry, you are right. Non-tech companies totally slipped out of my radar. I never interviewed with one so I have no idea how it works there. I don't know what is more depressing an interview with a tech company or working on a legacy Java enterprise system at a bank.
Banks are so much more than legacy Java systems. Name a cutting edge research domain or a a 'cool' programming language and banks will be at the forefront of work with that.
the 4-7 rounds of interviews is just a time staller while they pick and choose alternative candidates. unethical.
I created AirTable spreadsheet to collect all the companies that have sane interview practices
https://airtable.com/invite/l?inviteId=invtzMOjpyMmmowAK&inv...
https://airtable.com/invite/l?inviteId=invtzMOjpyMmmowAK&inv...
> From the article:
>> All companies (regardless of size and paycheck) make competent developers go through grueling 4–7 rounds of interviews.
I don't see this in the article. Are you reading the same one as me?
I don't see this in the article. Are you reading the same one as me?
It was in a bullet point under the "The final destination" header. If you CTRL+f the page for "all companies" you'll find it unless Medium is doing some crazy A / B testing where chunks of the article have different content.
No results for that search. Here is the full text of the article I see:
The Great Resignation Movement is turning the US job market upside down.
Around 4 million employees left their jobs in July 2021, according to the U.S. Bureau of Labor Statistics.
This should be surprising, especially in an aftermath of the pandemic, where the economy of the entire world is in shambles.
The Great Resignation Movement is turning the US job market upside down.
Around 4 million employees left their jobs in July 2021, according to the U.S. Bureau of Labor Statistics.
This should be surprising, especially in an aftermath of the pandemic, where the economy of the entire world is in shambles.
It's in there. Go down to "The Final Destination."
It's one of the bullets.
It's one of the bullets.
Not every problem can be solved with contractors. Many products and systems need long term owners and maintainers and people involved need to be part of a team. That team culture is precious and the red flags can be hard to discern which is why teams come up with such lengthy processes. They're painful but I've yet to see a plausible alternative.
And yet the average tenure in a software engineer role is just under 3 years. That's not exactly long term.
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...
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...
I seriously doubt that the lengthy processes are achieving that.
I second this. Often, working as a freelancer is also a great way to get offers for full-time employment without any interviewing. Companies like to keep good people around, so if you're doing good work as a freelancer you'll often get an offer to join the company as an employee. Personally I used that strategy to get some really great deals, and I don't think I could've negotiated the terms I got if I had applied to these jobs as a regular candidate.
Good point and thanks for sharing. I've had some similar experiences (though my current long-term contract required the "standard" tech interview process).
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.
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.
Is there a specific freelance experience you want to know more about? Like, finding gigs or how I manage the business? There's a few dev / business'ish posts at https://nickjanetakis.com/blog/tag/dev-business-tips-tricks-.... I have posts on finding gigs, accepting payments, invoicing, protecting and licensing the code you write and things like that.
Do you have a site? Comparing notes is fun.
Do you have a site? Comparing notes is fun.
I feel as if the article is a bit of “tea leaf reading,” but it does make sense.
> A verifiable track record is overlooked, while CVs filled with adjectives top the stack.
This is not new, but I do believe it has reached a crisis point, in tech. I’ve often posted about my own travails with this.
The most annoying thing, to me, is, despite all the hoopla about “disruption,” companies hire for conformity. They always have, but the screeching about being “disruptive” is fairly recent.
Protip: you won’t “disrupt,” if you hire people that “won’t rock the boat.” Truly innovative workplaces aren’t necessarily comfortable (especially for management).
It’s like classic waterfall companies that claim to be “agile,” because they have daily meetings.
I thought this linked article was interesting: https://betterprogramming.pub/why-software-companies-often-r...
> A verifiable track record is overlooked, while CVs filled with adjectives top the stack.
This is not new, but I do believe it has reached a crisis point, in tech. I’ve often posted about my own travails with this.
The most annoying thing, to me, is, despite all the hoopla about “disruption,” companies hire for conformity. They always have, but the screeching about being “disruptive” is fairly recent.
Protip: you won’t “disrupt,” if you hire people that “won’t rock the boat.” Truly innovative workplaces aren’t necessarily comfortable (especially for management).
It’s like classic waterfall companies that claim to be “agile,” because they have daily meetings.
I thought this linked article was interesting: https://betterprogramming.pub/why-software-companies-often-r...
I left Amazon a couple of weeks ago after nearly a decade. And the answer to "why" is pretty straightforward.
1- I couldn't get that SDE3 promo. If my clone had interviewed, he'd have been given an sde3 offer easily. But being on the inside requires a long checklist of requirements that I could never quite hit all of. Two other companies offered me the equivalent role immediately. With a nice pay bump.
2- Amazon won't commit to remote. It's all "between you and your manager" and "with your VPs approval", which is to say: subjet to change any time the person in that role does. Want to change teams? Best make sure that other manager and his VP will support you first. So can I really move four hours away from the office? Not really. My new employment contract has "remote" in it.
3- a growing sense that this isn't the right company for me. Too many controversies that I can't really see "our" side of. The leadership principles that I used to teach to new hires sound more and more hollow.
And when I looked at all that, and realized how good the job market is, it became a question of why would I stay?
1- I couldn't get that SDE3 promo. If my clone had interviewed, he'd have been given an sde3 offer easily. But being on the inside requires a long checklist of requirements that I could never quite hit all of. Two other companies offered me the equivalent role immediately. With a nice pay bump.
2- Amazon won't commit to remote. It's all "between you and your manager" and "with your VPs approval", which is to say: subjet to change any time the person in that role does. Want to change teams? Best make sure that other manager and his VP will support you first. So can I really move four hours away from the office? Not really. My new employment contract has "remote" in it.
3- a growing sense that this isn't the right company for me. Too many controversies that I can't really see "our" side of. The leadership principles that I used to teach to new hires sound more and more hollow.
And when I looked at all that, and realized how good the job market is, it became a question of why would I stay?
I feel you, was in the same boat, although I spent way less time there. Too many LPs, too little time.
I think this article is overlooking the most important reason for this. Most senior developers have plenty of assets and are retiring or taking a long vacation with stock/crypto/real-estate gains from the past year.
Some are rolling out their own businesses sure, but it's a terrible time to start a business now. Wages are skyrocketing, supply chains are overbooked, inflation makes it impossible to secure long contracts on predictable terms, and the passive income mania fuelled by the banks makes working on fixed income unappealing.
Some are rolling out their own businesses sure, but it's a terrible time to start a business now. Wages are skyrocketing, supply chains are overbooked, inflation makes it impossible to secure long contracts on predictable terms, and the passive income mania fuelled by the banks makes working on fixed income unappealing.
> it's a terrible time to start a business now
Hard disagree. I think this is one of those moments it's an unusually good time to start a business. It has challenges to be sure, but they're manageable, and I see more opportunity around me than I've seen in decades.
Hard disagree. I think this is one of those moments it's an unusually good time to start a business. It has challenges to be sure, but they're manageable, and I see more opportunity around me than I've seen in decades.
If your business plan includes shipments from China at specific costs or times, or if your business plan needs reliable workers at $18/hour, you may run into trouble. Otherwise, yes
That's exactly what happened with me. When people ask why I retired "so early" (I'm 56) my first answer is always that I did it because I could. I was fortunate to have accrued enough that I didn't have to keep doing something that had become more burdensome than satisfying, so I stopped.
As to why it had become more burdensome, some of the OP's points ring pretty true. Software development is much more rushed than it used to be, which is not at all to say it's more efficient or productive. Everybody wants to rush into coding without having a real anchored discussion about approaches and pitfalls, then rush into coding the next thing before all the really "interesting" bugs that live in the interstices between unit-testable components are dealt with. Yeah, I know the excuses, and I'm sure they'll be repeated in replies here. Basically they all come down to "don't worry we'll rewrite it next year anyway" which is not entirely wrong but I got tired of being disparaged for wanting to be even a tiny bit further on the "get it right the first time" side.
And then there's the ageism. Like other -isms it's never as simple as "I hate X" but more about failing to consider X. Open-plan offices are more problematic for older people because of hearing and personal-comfort issues. Mandatory oncall shifts are more burdensome for people with kids than those without. A senior developer trying to apply an idea learned on other systems will often be blocked because those systems are assumed to be irrelevant, but a junior developer reinventing the exact same idea in the context of the current system will get a bonus or promotion. To some extent it's just good old NIH, but when it consistently gives one group an advantage over another it's discrimination. "Only people who grew up in this environment can add value to it" is ageism.
A lot of these issues are much more prevalent at certain companies, notably FAANG, so arguably they could be improved by going elsewhere. Which would have meant going through another one or more BS interview processes for what was likely to be a slight improvement because everybody imitates FAANG. "I prefer not to" as Bartleby the scrivener famously said, and I suspect that's the same conclusion many other senior developers reach. We've made it so that development usually becomes more and more of a chore as people become more senior (no it didn't used to be that way), so we shouldn't be surprised when they take the earliest exit.
As to why it had become more burdensome, some of the OP's points ring pretty true. Software development is much more rushed than it used to be, which is not at all to say it's more efficient or productive. Everybody wants to rush into coding without having a real anchored discussion about approaches and pitfalls, then rush into coding the next thing before all the really "interesting" bugs that live in the interstices between unit-testable components are dealt with. Yeah, I know the excuses, and I'm sure they'll be repeated in replies here. Basically they all come down to "don't worry we'll rewrite it next year anyway" which is not entirely wrong but I got tired of being disparaged for wanting to be even a tiny bit further on the "get it right the first time" side.
And then there's the ageism. Like other -isms it's never as simple as "I hate X" but more about failing to consider X. Open-plan offices are more problematic for older people because of hearing and personal-comfort issues. Mandatory oncall shifts are more burdensome for people with kids than those without. A senior developer trying to apply an idea learned on other systems will often be blocked because those systems are assumed to be irrelevant, but a junior developer reinventing the exact same idea in the context of the current system will get a bonus or promotion. To some extent it's just good old NIH, but when it consistently gives one group an advantage over another it's discrimination. "Only people who grew up in this environment can add value to it" is ageism.
A lot of these issues are much more prevalent at certain companies, notably FAANG, so arguably they could be improved by going elsewhere. Which would have meant going through another one or more BS interview processes for what was likely to be a slight improvement because everybody imitates FAANG. "I prefer not to" as Bartleby the scrivener famously said, and I suspect that's the same conclusion many other senior developers reach. We've made it so that development usually becomes more and more of a chore as people become more senior (no it didn't used to be that way), so we shouldn't be surprised when they take the earliest exit.
Raising money also seems a lot easier though. I’m astonished at what has raised 2-5 million.
For most of the time I was at startups, a $30M round or a $100M exit was great news. A goal to shoot for. Now the first would be considered a red flag and the second a failure, and it's not all because of inflation or growth of the industry. Everyone has unicorn fever, which favors certain kinds of startups over others. The result is a glut of some things and a shortage of others. It's a kind of imbalance we distributed-systems folks try to avoid, for good reason. The consequences of screwing it up at the level of the whole industry - let alone all of society - are even more severe.
I have been studying pizza. I became obsessed when trying to perfect the craft and found out how crazy technical it is to do it right. (On a side note the pizza industry lost it's top dough scientist to COVID, but he thankfully openly shared all his knowledge)
I have always had it in the back of my mind that I was going to start a pizzeria and now the writing is on the wall.
My sister has a small novelty shop (pipes, crystals, etc) and recently moved to a good location in her community. It blew up immediately from the foot traffic in that location. She went from welfare to six figures overnight. I'm eyeing the same mall for my pizzeria.
There is a constant string of anxiety inducing bullshit that occurs in corporate America, more so now for devs and especially senior devs like myself. Ladle on mounds of boring work and it becomes unbearable. I just want to move to farm country and start a takeout restaurant. (I used to manage restaurants and run kitchens in a past life, it's in my DNA)
I have always had it in the back of my mind that I was going to start a pizzeria and now the writing is on the wall.
My sister has a small novelty shop (pipes, crystals, etc) and recently moved to a good location in her community. It blew up immediately from the foot traffic in that location. She went from welfare to six figures overnight. I'm eyeing the same mall for my pizzeria.
There is a constant string of anxiety inducing bullshit that occurs in corporate America, more so now for devs and especially senior devs like myself. Ladle on mounds of boring work and it becomes unbearable. I just want to move to farm country and start a takeout restaurant. (I used to manage restaurants and run kitchens in a past life, it's in my DNA)
> Wages are skyrocketing, supply chains are overbooked, inflation makes it impossible to secure long contracts on predictable terms, and the passive income mania fuelled by the banks makes working on fixed income unappealing
Or, you could look for opportunities in all of those statements.
Or, you could look for opportunities in all of those statements.
I don't know honestly, but the reasons to me are just a subjective view of the writer.
Some people find it comfortable working at big tech firm or enterprise and move around their layers or so. Ageism could be a thing but so there are lots of companies that pay seniors dev very well.
I think the only reason why some of these folks are leaving is because after earning more than 250k a year for many years (plus stocks) they've realized that there's not much value on working
Some people find it comfortable working at big tech firm or enterprise and move around their layers or so. Ageism could be a thing but so there are lots of companies that pay seniors dev very well.
I think the only reason why some of these folks are leaving is because after earning more than 250k a year for many years (plus stocks) they've realized that there's not much value on working
Once I hit 4M net worth, I really lost the desire to continue to work at the stressful enterprise analytics startup I was at.
Congrats on the milestone. Did you aim for it, like with FI/RE, or did it just happen some day and you quit?
I didn't have a goal, I had a low cost of living and high income and a big interest in technology. So I invested a good bit of my income into GOOG, and then into TSLA. Over the years those have turned into a lot of money.
I quit when we hit a 2 year mark without any new customers.
I quit when we hit a 2 year mark without any new customers.
Exactly right. The numbers might vary, but the basic principle is that the reward for staying goes down[1] and the feasibility of getting out goes up and at some point the lines cross. For me it was just over one year ago, at 55. For someone else it might be at 40, or 70. And good for anyone who gets there.
[1] For most people. There are a few "plum" roles where it keeps going up, but I honestly don't think that's the norm.
[1] For most people. There are a few "plum" roles where it keeps going up, but I honestly don't think that's the norm.
Economic version:
Devs are the specialists least dependent on capital. If you're a surgeon, you need a hospital, if you're a windmill engineer, you need the windmill factory. Dev can work with all his own tools, it's so cheap you can have your own workbench (eg on Hetzner) for almost nothing. The range of firms with dev-relevant capital is very wide.
Capital is cheap, too, thanks to the times we live in (let's not go there).
Senior devs who don't need hand-holding are a rare form of labor. It's free to everyone to learn how to be a coder, it's all out there on the internet in a way that is unparalleled across subjects and in history. But we are not flooded with competent devs. It would appear the bottleneck isn't in educating people.
Finally, the WFH revelation means markets are a lot less local. It only makes sense to look for a new job when you know all this.
----
BTW, it really is a dev's market right now. It's white hot, it's been white hot for at least half a year, and nobody knows when it ends. I encourage anyone who feels even a tiny bit inclined to have a look around. Even if you don't, try to finagle a day at home each week, because the recruitment game has been turned on its head by the ability of people to chat during work hours.
Devs are the specialists least dependent on capital. If you're a surgeon, you need a hospital, if you're a windmill engineer, you need the windmill factory. Dev can work with all his own tools, it's so cheap you can have your own workbench (eg on Hetzner) for almost nothing. The range of firms with dev-relevant capital is very wide.
Capital is cheap, too, thanks to the times we live in (let's not go there).
Senior devs who don't need hand-holding are a rare form of labor. It's free to everyone to learn how to be a coder, it's all out there on the internet in a way that is unparalleled across subjects and in history. But we are not flooded with competent devs. It would appear the bottleneck isn't in educating people.
Finally, the WFH revelation means markets are a lot less local. It only makes sense to look for a new job when you know all this.
----
BTW, it really is a dev's market right now. It's white hot, it's been white hot for at least half a year, and nobody knows when it ends. I encourage anyone who feels even a tiny bit inclined to have a look around. Even if you don't, try to finagle a day at home each week, because the recruitment game has been turned on its head by the ability of people to chat during work hours.
Yeah, I could apply to a job listing but I haven't found one in a while that seemed like it would be a good use of my time.
I’m beginning to think of this era as the arrival of Fred Brooks formulation of the highly productive or surgeon like developer; someone who is highly trained and can be highly productive. And “senior” developer is a proxy for that; highly trained and experience with the myriad of tech and mountain of knowledge software development requires today. And as such, truly “senior” developers are highly desirable and relatively rare. Hence rising demand and salaries. Spurring many to job hop and maximize their salary.
Note I didn’t use the loaded “10x” or “rockstar” monicker intentionally, to avoid the incessant argument whether they actually exist or not. I submit the current trend as evidence they do, and are often “senior” developers.
Title inflation is in fact a thing and not all seniors are equal. And of course the typical HN reader is near the top of the curve, so maybe we don’t realize just how much truly arcane knowledge is required to do this job.
Note I didn’t use the loaded “10x” or “rockstar” monicker intentionally, to avoid the incessant argument whether they actually exist or not. I submit the current trend as evidence they do, and are often “senior” developers.
Title inflation is in fact a thing and not all seniors are equal. And of course the typical HN reader is near the top of the curve, so maybe we don’t realize just how much truly arcane knowledge is required to do this job.
> And of course the typical HN reader is near the top of the curve
I feel as if it is not necessarily "senior," as much as "on the bleeding edge." Lots of smart folks here, with a lot of "exploratory" energy, but as far as highly experienced, seasoned, folks; maybe it's not such a huge demographic. I know we're here, but we're not always welcome.
I feel as if it is not necessarily "senior," as much as "on the bleeding edge." Lots of smart folks here, with a lot of "exploratory" energy, but as far as highly experienced, seasoned, folks; maybe it's not such a huge demographic. I know we're here, but we're not always welcome.
This rings true to me.
> I know we're here, but we're not always welcome.
Us graybeards are working in an industry that generally doesn't value experience (mysteriously, it seems to equate "experienced" with "not capable with modern technologies"), so there's the baseline. And the HN demographic appears to be a particular subset of the young, which tends to amplify that.
> I know we're here, but we're not always welcome.
Us graybeards are working in an industry that generally doesn't value experience (mysteriously, it seems to equate "experienced" with "not capable with modern technologies"), so there's the baseline. And the HN demographic appears to be a particular subset of the young, which tends to amplify that.
> the typical HN reader is near the top of the curve
For seniority? Not a chance. The last time there was a poll (admittedly a long time ago), two thirds of HN's users were under 30.
For seniority? Not a chance. The last time there was a poll (admittedly a long time ago), two thirds of HN's users were under 30.
It's very worrying to me that (especially US-inspired developers) people only think of a job as doing something for someone else. I guess it's pretty different in Germany, but a company is also a community, you spent a lot of time with these people. Sure, there are some folks who like to stay at home at all times, but I feel like that's not a majority. Humans are social animals at core, so I don't understand this one-sided discussion at all. Of course the article shits on management. Management enables you to do the work you came in for. I don't know how someone doesn't understand this. It helps you focus more on the stuff you like. Sounds like your management/company culture is shit.
Are you sure this is a Germany vs US thing? I'm originally from Germany and now live in Switzerland. I also think I'm doing something for someone else, no matter that my current project has public utility. I've also never cared about my company for socialization purposes.
We'd need some data about this question to see whether it is a cultural or individual thing.
We'd need some data about this question to see whether it is a cultural or individual thing.
I agree. I enjoy socializing, but it never even crossed my mind that my job isn't doing something for someone else.
This hypothesis is quite easy to verify: the sets of activities that I perform at work and in the time I have full control over are strictly disjoint.
This hypothesis is quite easy to verify: the sets of activities that I perform at work and in the time I have full control over are strictly disjoint.
At least in the USA/Canada, the community element is heavily manufactured. Sure, you talk to your co-workers but you won’t speak to 90% of them again after you leave.
In the US, or at least the west coast, the developer community is tied to the broader ecosystem and not the particular company where you work. When I worked in Silicon Valley, there was a saying that you don't work for "the company", you work for "the Valley". And it very much felt that way. Companies were ad hoc gatherings of talent within a larger close-knit software community. The tech companies generally understood this.
This dynamic lead to rich cross-fertilization of ideas and talent between companies. Socialization happened at the ecosystem level, not the company level, and I think it is probably a healthier than tightly coupling professional socialization with a company.
This dynamic lead to rich cross-fertilization of ideas and talent between companies. Socialization happened at the ecosystem level, not the company level, and I think it is probably a healthier than tightly coupling professional socialization with a company.
That actually sounds so awesome! We don't have that here quite that much. Maybe in Berlin, but that's not representative of Germany in any way anyhow.
[deleted]
I am really surprised by all this "humans are social animals and like to be in the office community" bullshit. I had to be lectured about this from all of my managers allready. But if this would be really the case, then why is office community not part of the application process?? If that would be true, then interviews should be done in a very different way, giving the applicants the chance to get to know the people they will be working with.
In all my interviews the topics were 1. What is the company doing? 2. What have I done? 3. What can I do for the company?
Never was something like do I share some of the interests / hobbies of the people allready working there relevant.
Maybe it is a match for some people. But then it is a coincidence. You are employed to work and to produce something for the company. It was never about having fun. Stop twisting things.
In all my interviews the topics were 1. What is the company doing? 2. What have I done? 3. What can I do for the company?
Never was something like do I share some of the interests / hobbies of the people allready working there relevant.
Maybe it is a match for some people. But then it is a coincidence. You are employed to work and to produce something for the company. It was never about having fun. Stop twisting things.
> Never was something like do I share some of the interests / hobbies of the people allready working there relevant.
I always interview so that the team and the applicant meet and can chill a bit and I also ask them about their opinion. Especially for small teams it's way more important to have a personal match than ticking the boxes on the "hard requirements" like coding abilities.
> Maybe it is a match for some people. But then it is a coincidence. You are employed to work and to produce something for the company. It was never about having fun. Stop twisting things.
That's so sad. I'm sorry but you can't ignore the basic biological fact that we are meant to connect with each other.
I really wish that you experience a nice working environment somewhere down the line, but based on the vibes you give off you would block that anyways.
I always interview so that the team and the applicant meet and can chill a bit and I also ask them about their opinion. Especially for small teams it's way more important to have a personal match than ticking the boxes on the "hard requirements" like coding abilities.
> Maybe it is a match for some people. But then it is a coincidence. You are employed to work and to produce something for the company. It was never about having fun. Stop twisting things.
That's so sad. I'm sorry but you can't ignore the basic biological fact that we are meant to connect with each other.
I really wish that you experience a nice working environment somewhere down the line, but based on the vibes you give off you would block that anyways.
I quit last year because I was financially independent (actually way past the point of financial independence). There was no financial motive to keep working and the work itself felt like drudgery, no matter how much I was paid. I'll bet a lot of people quit for similar reasons.
> I'll bet a lot of people quit for similar reasons.
Most of us on HN are not multi-millionaires, or even millionaires.
Most of us on HN are not multi-millionaires, or even millionaires.
But to be fair, if you’re willing to live in cheap places, you don’t nearly need to be a millionaire to be financially independent.
I know the reasons for me (mid 30s).
I just don't have patience for artificial hoops and barriers to career growth set by management.
I don't want to "write more docs" or "be visible on slack" or "join some engineer guilds" or "give demos" or "mentor juniors" just for a promotion.
Just look at what I produce, is it valuable for the company? If yes, extra curriculars don't matter.
It is these bullshit hoops that make me wonder - why should I listen to anyone in management? I have only one life and I have to dance to this fools tunes? Leading me to switch jobs for a higher pay.
I know I will still have to report to a manager at the new job, but by switching, I get the promotion, I get more money and don't need to jump through artificial hoops set by a middle manager, who doesn't want me to rise as fast as I can.
I just don't have patience for artificial hoops and barriers to career growth set by management.
I don't want to "write more docs" or "be visible on slack" or "join some engineer guilds" or "give demos" or "mentor juniors" just for a promotion.
Just look at what I produce, is it valuable for the company? If yes, extra curriculars don't matter.
It is these bullshit hoops that make me wonder - why should I listen to anyone in management? I have only one life and I have to dance to this fools tunes? Leading me to switch jobs for a higher pay.
I know I will still have to report to a manager at the new job, but by switching, I get the promotion, I get more money and don't need to jump through artificial hoops set by a middle manager, who doesn't want me to rise as fast as I can.
Hold on. If you jump every few months you actually never have to do anything and can probably find an endless string of companies. Hell, you might even land at one where they never realize you aren't doing anything as long as you can complete tickets....I mean "stories."
> I don't want to "write more docs" or "be visible on slack" or "join some engineer guilds" or "give demos" or "mentor juniors" just for a promotion.
That hit close to home. Such a depressing reality.
That hit close to home. Such a depressing reality.
I can't fathom why this would be depressing.
Senior developers aren't paid to write code. They're paid to cause good outcomes. Sometimes writing code is helpful for that.
If the team needs more documentation, more demos, or more mentoring, and you don't want to do it, you don't sound like you're behaving like a senior dev to me.
Senior developers aren't paid to write code. They're paid to cause good outcomes. Sometimes writing code is helpful for that.
If the team needs more documentation, more demos, or more mentoring, and you don't want to do it, you don't sound like you're behaving like a senior dev to me.
> If the team needs more documentation, more demos, or more mentoring, and you don't want to do it, you don't sound like you're behaving like a senior dev to me.
That's a big "if". Sometimes those things are just not needed by the team. But management is imposing it on you because they want to make you jumpy through hoops.
You could invent a new kind of desalination plant, bringing in millions for the company but the manager still wants you to first spend a year through bullshit hoops.
That's a big "if". Sometimes those things are just not needed by the team. But management is imposing it on you because they want to make you jumpy through hoops.
You could invent a new kind of desalination plant, bringing in millions for the company but the manager still wants you to first spend a year through bullshit hoops.
No upward financial mobility for developers?
Developers are rushing to start new companies?
Seems bogus to me. Tech workers are doing quite well financially speaking, and anecdotally I know no one (I’m 37 in medium/big tech) who started a new business the past year. The data from VC funding of companies is hardly a good measure of devs in their 30s/40s leaving their jobs to start new companies.
Also angst against capitalism is being addressed by…checks notes…starting your own company?! Seems like such an endless spew of one false narrative after another
Developers are rushing to start new companies?
Seems bogus to me. Tech workers are doing quite well financially speaking, and anecdotally I know no one (I’m 37 in medium/big tech) who started a new business the past year. The data from VC funding of companies is hardly a good measure of devs in their 30s/40s leaving their jobs to start new companies.
Also angst against capitalism is being addressed by…checks notes…starting your own company?! Seems like such an endless spew of one false narrative after another
If this hypothesis (they’re starting companies of their own) is true, why not show any data on new incorporations or number of new startups? Very doubtful of this. Funding amounts could be increasing because of more capital; valuations could be increasing due to that capital chasing fewer opportunities.
100% with you on this. Where are all these new companies, who are investing in all these one-dev startups, how did all these devs suddenly discover product market fits, ...?
A lot of seniors also realize that once you build a large enough network of former bosses and colleagues you can actually just open a consultancy shop and contract for larger companies.
My point being that just because they are not founding "one-dev startups", senior devs are much more commonly transitioning to self-employed/contracting arragements where they are setting their rates.
My point being that just because they are not founding "one-dev startups", senior devs are much more commonly transitioning to self-employed/contracting arragements where they are setting their rates.
Most of the new companies that I'm personally familiar with are intentionally avoiding investment money and are bootstrapping up. And the devs starting them did not suddenly discover product market fits, they're finally pulling the trigger on things that have been percolating for a long time.
I appreciate the effort that goes into articles like this, but they always seem to be based on the unproven hypotheses of the author. I'd appreciate more it if authors would reach out to the community via, say, LinkedIn and survey developers on their seniority and reasons for resigning, then building an article around those results.
I know that resignations are up but is there the corresponding jump in startups or sole proprietorships that the author claims? In other words are people striking out on their own or are they just jumping to another company?
The tech industry is so effective at optimizing that they've managed to turn engineers into factory robots. Maybe it's just my experience but the tech industry in the late 2000s were so much more fun compared to the last 5 years.
I feel like the article talks about me. Early 30s dev, quit during the pandemic to start my own company (manylogs.com)
Not gonna lie, we have it pretty good. Great salary, flexible working hours, bonuses, job prospects etc... but it's kinda sad seeing your employer riding the internet wave while you're stuck on a leash.
If you're a senior dev, you probably can build something useful for people and make a great living out of it. The only thing you need is a laptop and some creativity.
Not gonna lie, we have it pretty good. Great salary, flexible working hours, bonuses, job prospects etc... but it's kinda sad seeing your employer riding the internet wave while you're stuck on a leash.
If you're a senior dev, you probably can build something useful for people and make a great living out of it. The only thing you need is a laptop and some creativity.
The rapid increases in compensation right now isn’t even the primary motivator. That’s the icing on the cake in case you weren’t sure.
In the big companies senior developers are tired of the failed institutionalism. Most large companies I have worked at are Java shops and do everything the same way. They move so astonishingly slowly and spend a lot of time convincing themselves otherwise with agile. It’s not hard to feel like a 100x developer when working on an open source project that does 10x your corporate equivalent in a fraction of the time.
What I have learned from interviewing:
* front end skills are dead. If you are a startup use react for everything, otherwise you can dick around with Angular or some custom jQuery looking mistake. It doesn’t matter. Its all unimportant MVP that just needs to look good and will get fixed after business exit or lawsuit.
* for backend don’t worry about inverting binary trees. That’s so last generation. Now the interview process is to build an entire tech stack in 3 hours or play in a software toy box of a trillion dependencies or service tools. Good systems automation skills or just services are too boring.
* Open source contributions are resume line items, like education. If you want people to take that serious be very explicit about the value of your open source contributions on your resume. Even then be prepared to treat open source as a new business pitch deck if asked.
* If you are a non-management developer don’t bother with things of social value. These are commonly viewed as a harmful distractions. This includes professional certifications, social organizations, accreditation’s, security clearances, and so forth.
In the big companies senior developers are tired of the failed institutionalism. Most large companies I have worked at are Java shops and do everything the same way. They move so astonishingly slowly and spend a lot of time convincing themselves otherwise with agile. It’s not hard to feel like a 100x developer when working on an open source project that does 10x your corporate equivalent in a fraction of the time.
What I have learned from interviewing:
* front end skills are dead. If you are a startup use react for everything, otherwise you can dick around with Angular or some custom jQuery looking mistake. It doesn’t matter. Its all unimportant MVP that just needs to look good and will get fixed after business exit or lawsuit.
* for backend don’t worry about inverting binary trees. That’s so last generation. Now the interview process is to build an entire tech stack in 3 hours or play in a software toy box of a trillion dependencies or service tools. Good systems automation skills or just services are too boring.
* Open source contributions are resume line items, like education. If you want people to take that serious be very explicit about the value of your open source contributions on your resume. Even then be prepared to treat open source as a new business pitch deck if asked.
* If you are a non-management developer don’t bother with things of social value. These are commonly viewed as a harmful distractions. This includes professional certifications, social organizations, accreditation’s, security clearances, and so forth.
You're the first person to tell me accreditation or clearances are a negative, but maybe we apply for different jobs. I'm going to continue to believe the opposite until you show some evidence.
They're very important in any company that has a partnership, like with AWS or Microsoft Azure. They have to maintain a certain number of people with certs to keep their partnership, so they push for their employees to get it. Seems very common in consulting, for example. Hiring someone that already has those certs makes things easier.
Also for the companies that need security clearances, I've seen plenty of job postings that have security clearances are required (or the job is contingent on your ability to get one). I'd be surprised if that wasn't still valued.
Also for the companies that need security clearances, I've seen plenty of job postings that have security clearances are required (or the job is contingent on your ability to get one). I'd be surprised if that wasn't still valued.
Not OP. It's anecdata, but our worst candidates all had AWS certified developer as a top bullet-point on their resumes.
Maybe the guidance then should be around how much emphasis is placed on the cert in the resume, rather than the mere presence of it.
I think we have all seen resumes where there is an alphabet soup of certifications and a lack of real projects or positions. But if they just have a cert casually listed near the bottom, it's usually a compliment to the work they were already doing in that area (and maybe their employer paid them to go and get it)
I think we have all seen resumes where there is an alphabet soup of certifications and a lack of real projects or positions. But if they just have a cert casually listed near the bottom, it's usually a compliment to the work they were already doing in that area (and maybe their employer paid them to go and get it)
"Bad" meaning all the worst candidates have these certificates while very very few of the best candidates had certs (presumably they were busy building things with the knowledge than passing tests).
"Good" in that certain roles require certificates to make nondev clients feel better. Government contracts, consulting, etc. Places where appearance/marketing is more important than skill.
First chapter in cracking the coding interview also agrees. Certifications may be seen as compensating for lack of experience.
Anecdotally, engineers that I have interviewed that had a litany of certifications were very weak candidates.
As were bootcampers, which is similar I guess.
As were bootcampers, which is similar I guess.
> Open source contributions are resume line items, like education. If you want people to take that serious be very explicit about the value of your open source contributions on your resume. Even then be prepared to treat open source as a new business pitch deck if asked.
Do you have any good articles/recommendations on this?
Do you have any good articles/recommendations on this?
Curious why certs would count against you? I know people who spend their free time learning and studying for those exams. Should they simply be spending more time working on open source projects or watching TV?
A good example might be an MBA. Given how much antagonism I've seen towards the degree here on HN, I've been tempted to remove mention of mine from my resume. If you ask some people here, it's as if it invalidates 20+ years of software development and project management experience.
So front end is dead and back end is dead? We're all just sysadmins now.
[deleted]
I don't know that I've ever been part of a "movement" until now. I joined the great resignation and went out into business for myself about four months ago. Just could not stand horrible management, HR, and weirdly empowered project managers at my megacorp any longer. Best decision I ever made.
Most of the pathologies that get associated with Agile or Scrum in particular are in fact the manifestations of Managed implementation of Agile/Scrum. In my view, a perfect litmus test is the primary qualifications of a Scrum Master - if it's a PM, then it's rather a Scrum Manager, a chimera of the corporate existential doom.
Ideally, in my opinion, it's a rotating role among the team members. This may simply be impossible read unallowable in many organisations due to hierarchies, chain of command and payscale restrictions.
Stale organizations have underlying reasons to be so wasteful yet to live on. I often wonder how some visibly and practically crappy restaurants or stores could stay in business for many decades without much change. Perhaps change has a different meaning and value for different organizations.
Ideally, in my opinion, it's a rotating role among the team members. This may simply be impossible read unallowable in many organisations due to hierarchies, chain of command and payscale restrictions.
Stale organizations have underlying reasons to be so wasteful yet to live on. I often wonder how some visibly and practically crappy restaurants or stores could stay in business for many decades without much change. Perhaps change has a different meaning and value for different organizations.
> Supervisory managers brandishing Agile + endless meetings
I've never understood why programmers in these kinds of environments don't shop around.
(Acknowledgement that in our industry we're immensely privileged to be able to do this, but emphasizing that it is very doable)
I've had four different tech jobs, and none of them have been like the one described here. At most of them we've done "casual agile" where we do standup and tickets and sometimes a retro or planning meeting, but we don't take any of it too seriously.
At my current job (and my previous two) my product manager acts as a filter from upper management, negotiating and processing requirements into a form that we can handle and work with. My engineering manager (and my previous one) checks in on my mental health and makes sure I'm neither under- nor over- utilized. At one point I tried to work late on something and they gently asked me not to. I've been asked at several junctures whether I'm happy with what I'm working on or would be more happy doing a different kind of task (happy == motivated == productive and not burning out). All of my engineering managers have also previously been engineers. Both my prod and engineering managers (and again, my previous ones) act as team members who have their own responsibilities; there is no hubris or lording around or micro-managing. The only time I've experienced that was at a past job when I temporarily didn't have any managers and reported directly to the CEO.
Now, none of these have been FAANGs. All but one were two digits of employees; the current one is by far the biggest at ~200. Despite that they've all paid quite well. Probably not on the same level as FAANG, but enough for a very good quality of living with plenty left over even in a skyrocketing tech hub.
I guess my point is: it can be so much better. As a developer today you're in a hyper-privileged position. Take advantage of it and find somewhere you can be happy. You probably don't have to burn it all down to do so.
I've never understood why programmers in these kinds of environments don't shop around.
(Acknowledgement that in our industry we're immensely privileged to be able to do this, but emphasizing that it is very doable)
I've had four different tech jobs, and none of them have been like the one described here. At most of them we've done "casual agile" where we do standup and tickets and sometimes a retro or planning meeting, but we don't take any of it too seriously.
At my current job (and my previous two) my product manager acts as a filter from upper management, negotiating and processing requirements into a form that we can handle and work with. My engineering manager (and my previous one) checks in on my mental health and makes sure I'm neither under- nor over- utilized. At one point I tried to work late on something and they gently asked me not to. I've been asked at several junctures whether I'm happy with what I'm working on or would be more happy doing a different kind of task (happy == motivated == productive and not burning out). All of my engineering managers have also previously been engineers. Both my prod and engineering managers (and again, my previous ones) act as team members who have their own responsibilities; there is no hubris or lording around or micro-managing. The only time I've experienced that was at a past job when I temporarily didn't have any managers and reported directly to the CEO.
Now, none of these have been FAANGs. All but one were two digits of employees; the current one is by far the biggest at ~200. Despite that they've all paid quite well. Probably not on the same level as FAANG, but enough for a very good quality of living with plenty left over even in a skyrocketing tech hub.
I guess my point is: it can be so much better. As a developer today you're in a hyper-privileged position. Take advantage of it and find somewhere you can be happy. You probably don't have to burn it all down to do so.
The author claims that one reason people are quitting is because of terrible interview processes. This doesn't make much sense to me because if they we working there they would necessarily have had to pass some kind of process in the first place. They also point to agism in tech -- which certainly exists and it's not great -- but suggest it applies to people as young as 30, and that's not particularly plausible. (We're not 1960s hippies anymore)
Stop using Medium. I am getting a HTTP 500 and page reload every 10 seconds on both desktop and mobile Safari. It could be due to ad blocking, I am not the only one.
Also office environments have degraded, open offices, yuck.
>The verbal interviews (+personality tests) are formulaic, and one can rarely get past them without lying about their careers.
At least in my experience, this is ridiculously overblown.
I'm far from a fluffy personality, but to me the "culture fit" interviews are by far the easiest of the pipeline. I was never tempted to lie, nor can I see how that could possibly benefit the application.
At least in my experience, this is ridiculously overblown.
I'm far from a fluffy personality, but to me the "culture fit" interviews are by far the easiest of the pipeline. I was never tempted to lie, nor can I see how that could possibly benefit the application.
Given the stunning financial asset price appreciation over the last decade and widespread confidence that traditional portfolio returns will continue, I'm surprised that the wave of retirement is not bigger than indicated by the numbers cited in this article.
I remember telling people in late 1999 that these stock prices can't be long-lived because we can't all retire rich.
I remember telling people in late 1999 that these stock prices can't be long-lived because we can't all retire rich.
The author did not mention another contributing factor that let people quit jobs - the Affordable Care Act. Before it was passed you could not buy health insurance at any price if you had a pre-existing condition. Even with good health, insurance was prohibitively expense if you were not in some kind of group.
[deleted]
[deleted]
OK a senior developer resigns. Often that creates opportunities for other less senior whose ideas have been repressed due to some senior developers' personalities or reputations. Don't always see such folk who quit as a negative.
[deleted]
How come there is no objection to the word master in the scrum master?
lettergram(3)
[deleted]
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.