Senior developers are leading the great resignation movement
tipsnguts.medium.com
tipsnguts.medium.com
Personally for me - this led to burnout and I have quit last two jobs that used Agile faster than I have the 2 before that didn't use Agile. Agile is very clearly being misused to turn developers into factory line workers whose productivity can be measured by number of commits, reviews and docs they put out every two weeks. And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to.
And the burnout article linked in the OP makes a great point about inputs to development teams not being measured. At some places developers are left to spec out stories and others have Architects / Tech Leads do it - in either case that in itself is a large chunk of work that takes up huge amount of time that no one is rewarded for in any way!
Mostly though keeping the churn going is what gets really tiring - do most orgs have work that a) needs to be done every two weeks and b) can be done in two weeks perpetually? The pressure leads to manufacturing bite sized requirements that can be demoed in two weeks - the real impact of that work is almost always never evaluated. Combine this pressure with time crunch that prevents people from spending quality time together to ponder bigger, high impact problems and collaborate on solving those within the meeting heavy Agile process and you are never going to get anything meaningful done.
This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. The trouble is software / IT is not at all like rolling cars out on a factory line so it all falls apart.
Edit: By Agile I meant Scrum really.
Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.
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.
Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.
Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave.
Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s.
I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories.
Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation.
Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.
Because then it's easy for that person to forget that stand-ups have no independent value -- their only value is in making the other work go faster. And should be calibrated to maximize that.
Which is why you get the "We standup because we have to standup" shops.
Yep. I've suffered 20 years of poor facilitation. I keep hoping for some facilitation.
Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.
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.
This.
I understand that some managers want graphs, points, velocity, etc. Those things makes it easy to point at something and tell the team to improve. A good (imo) manager on the other hand, would just ask the team how the sprint went and what problems needs solving.
Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do.
Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects.
The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.
> the other requires a more deliberate approach where doing things right preserves the ability to do things quickly
Yes. There is a surprising nonlinearity of benefits to doing something properly.
It’s not about over-engineering to “best practices” or being a “cowboy coder” tuned only to your own preferences. These two are the Scylla and Charybdis of pursuing quality in software.
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.
Scrum does have a lot of processes and artifacts and things to measure. They all had a decent purpose: to give the product and project managers (Product Owner and Scrum Manager in Scrum parlance) information that allowed them to do their jobs more effectively. Story points and velocity estimates were supposed to drive decisions about what to build and when by giving the product manager some sort of signal they could use to decide things like, "Let's skip this feature; it's going to cost more than it's worth," or, "Let's push this bit a few weeks forward in the schedule, because it's looking like it's bigger and more likely to go quagmire on us than I had been hoping."
There was supposed to be an understanding that generating this signal would reduce the speed at which the development team could churn out features. (Of course it would; that time spent playing planning poker had to be taken from somewhere.) But this was understood to be worthwhile in the long run, in a, "Work smarter, not harder," sort of way.
On paper, it seems like a pretty good idea. The critical flaw, I think, is that, when you take a system that produces all those numbers, and even do something boneheaded like name one of them "velocity", and then drop that in the middle of a crowd of people who went to business school and have had heavily indoctrinated into Taylorist ways of thinking, well, it's like a will-o-the-wisp to them. They'll see something that looks bright and shiny, and follow it straight into deepest part of the swamp. And, since they're the manager, they'll be able to drag the whole team, or even the whole company, along with them when they do.
Years ago, I had an interesting "A Tale of Two Scrums" experience. I was on a product team that had been doing Scrum as their own internal thing for years. Quite successfully, too, everyone was happy, it was possibly the highest morale team I've ever been on. But then senior management decided they wanted the company to go Agile. So they brought in $FAMOUS_AGILE_CONSULTANT to deliver a week of workshops which was mandatory for all the developers and skipped by all the managers, including product managers. And then we had this very top-down, Taylorist, how-much-blood-can-we-squeeze-from-this-stone brand of Scrum rammed down our throats from above. Half the team left the company within 2 years. I found later that, not too long after I left, the company had subsequently divested of the product I worked on. While I was there, it was the market leader and cash cow.
Long story short, there's Scrum, and then there's Scrum. I can't tell you how much I loved doing Scrum, but I also can't tell you how much I hated doing Scrum.
Taylorism was known to only work on short interventions at the time it was created, and it's known to create all sorts of problems (one being absolutely demotivating everybody).
People are not cogs.
That is why.
> I guess the real question is why the fuck are management courses still founded in Taylorism?
So, are the developers somehow responsible for the problem, since the managers were never exposed to the consultant?
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.
That’s why it exists.
Our free speech society relies heavily on sticking to jobs, economics, and service to industrialists.
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.
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.
Corporate suits eat that shit up. The value add of scrum, to them, is everything devs hate. They love the burn down charts, the timelines for features, the resource allocation, the ability to fly in and say "You are working on polish? WTH value add does that bring to the company? Dump it and do feature 123 instead!"
And, unfortunately, corporate suits tend to pay the bills.
I'm sure there are companies out there that don't fall into micromanagement shit, but I'm convinced it's an inevitability that any successful company will eventually turn into a feature factory hell hole.
Before that the master really tried to have meaningful retros. Now we type some things in a doc, everyone is silent, and the master has dropped any mention of follow up or takeaways.
...and this is a company with a good culture! I have done this dance at places where the culture was not good. As a person renowned in my circle for technical ability and productivity this was the only place where I couldn't get anything done and was removed from the account by the manager. Relief.
One group I was in everything was a #1 priority. I had to sit the manager down in his office for a couple of hours and make him pick the priorities. It turns out he did not know what he really wanted, yet he wanted to micromanage everything. I had to show him that you have 4 devs and they can not work on 15 things at the same time 200% of the time. They have lives outside of work and you will get nothing done if they are jumping around at every whim you come up with. After that the team worked much better. I would at the start of each sprint make him pick what order he wants things in then the devs could come in and fix it up correctly.
Team management is totally on the table of 'things to work on' in scrum yet many PM's seem to forget that.
My new team has 3 15-30 min calls a day. I just joined this team so I am watching for now for a couple of sprints. But you can bet money on the fact I am bringing that up in a retro. You are distracting everyone at regular intervals and they can not get into anything because they are always prepping for your status meetings. You are leaving them basically 30% of their day to actually do anything related to the things you want status on.
A good PM who 'gets it' is great. One who strictly follows the metrics... yeah
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 ;)
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.”
> ...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.
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 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.
This is intrinsic to the entire movement and was from the very beginning as far as I can see.
There were some good ideas that emerged from the auspices of the movement but the movement itself never really committed itself too hard to any of them.
Let's check some "principles" posted at https://agilemanifesto.org/principles.html
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
P.S. not really in any particular argument with you, just that your comment prompted me to write some thoughts that have coagulated in my mind while going through the comments here.
He's complaining of the non-Agile practices that became synonymous with Agile, eg. Scrum, thanks to Agile coaches that feared losing power.
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.
“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”
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.
If you have normal stakeholders, they want to see features. You, as a developer or maybe an existing user, want to fix bugs. But new features bring new customers.
Too many demos without new features and the engineering political capital will plummet like a rock. That's when things get dicey and people get moved around or fired.
So I understand your point and it's valid, but it's stakeholders are really a force to be managed properly, not capitulated to.
The capitulation, I suspect, comes from the imposter syndrome many managers have, who are just happy to be in that position. They haven't yet grown the spine to do what's best for the project. I don't care how many features an OS has (Windows 8). If it's buggy and unusable, it will be perceived as a bomb.
But it is bad, no-good, horrible and sucky. If you do have the skill and diligence which are necessary to implement it (in a way that doesn't horribly suck), then you don't need to formally implement Agile.
The most productive teams I worked in invariably converged on something like this:
some kind of a backlog + a way to know who is working on what + informal but frequent and active communication
I think that if you look at the formal and semi-formal methods it's Kanban that is the closest to this model. If you need to placate people who insist on using "A Method", then at least try to convince them to use Kanban.
You hire competent developers that want to do cool things and you give them the basic necessary tools to self organize. You give them sound direction and a reasonable timeframe and they will self organize - maybe have infrequent checkups to ensure nothing is derailing or needs escalation and most projects can be successful with minimum overheads.
The agile manifesto attempted to describe a culture where devs could get things done.
All the methodologies are a bundle of useful ideas that came out of people attempting to find a process that fit the agile manifesto (and still delivered what the business cared about), but have been taken by consultancies, stripped of context, and sold as a panacea for what ails a company.
It's attempting to treat the symptoms, not the cause; the cause of what ails a company is bad culture, not bad process.
This is because the Scrum "masters" are not masters of the domain. In most cases, they went to a two-week class to get "certified". They have no understanding of the development process and they are not accountable to developers at all, only to upper management to whom they sell the word "agile" as a project management approach. What they are doing with all the planning/prep all the time, of course, is playing mini-waterfall in 3-6 month horizons.
> the real impact of that work is almost always never evaluated.
Because that might actually lead to reflecting on the performance of mid-managers and the scrum "masters". These groups tend to view developers as assembly line workers, they still think the "size" of a PR is indicative of its importance (think the KLOC counters of yore), and they think "key person risk" can be mitigated by eliminating said key person instead of fostering an environment that open to knowledge/experience sharing.
Those who can't do the tech get threatened by those who can and instead of focusing on their own comparative advantage and ensuring a productive environment, they focus on subjugating those who can do the tech to their every wish (fixating on things like label colors, prefixing every ticket with TAT, insisting that every ticket must be comprehensible to any random person in the company etc).
When 30 hours in a week are taken up by mandatory meetings, they then penalize people for not spending 40 hours on development. I've seen places which required keeping timesheets with 15 minute resolution.
I know there are places that are not like this, but I also know enough places that are.
At this point I've automated most of the time tracking into Excel. (CTRL-SHIFT-semicolon injects the current time into the current cell)
Timecard still takes an hour of work a week because I have to fill out both Jira time and HR time separately, because they want it at different granularities... Ah well.
Agile has become a way for people with no development experience to “manage” developers and that will always be wrong. The West’s obsession with “managerial” experience being a thing you can learn start to manage “anything” from is the origin of much of our malcontent. Management is just something you add on top of knowing how things work. It’s not valuable as an isolated skill.
True of course but also now the Developers and Architects are compensating for the scrum master's/manager's lack of knowledge in tangible and intangible ways - they bear the brunt of everything and that can become the many straws that broke the camel's back thing easily.
What do you mean? Scrum master's role is nothing more than facilitating the process, they don't need any technical knowledge at all.
Who can blame them. They got an A for repeating what the professor repeated.
Look at the difference between Elon Musk’s two companies and their ability to execute vs their rivals. The amount of value that was created because of an engineer led is so vast - it’s hard to even quantify.
When my son was about 10 or so, my wife mentioned that they were forcing her to perform as "scrum master" on her team and he laughed and said, "'scrum master'? That sounds like something a third-grader would say to insult another third-grader - 'you're such a... scrum master!'". I think he had the best take on it I've ever heard.
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.
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.
The mistake was applying it elsewhere.
Yes, the whole 2 week 'sprint' thing really wears me down. I can see the value of deadlines and splitting work up, but between all the release/demo/planning overhead and the constant rush to fit things in it leaves me with a constant low-level anxiety.
3 weeks seems like a more reasonable figure to me. Or with a senior team, just having a prioritised backlog of tasks and doing them in order (sounds crazy, I know).
Used well, sprints can help figure out how to put tracks of work in parallel, and keep anyone from overloading themselves.
Used badly, they're perpetual deadlines that fault individuals for inefficiencies in planning and create all kinds of fun toxic incentives.
To add insult to injury, everyone that complains about agile just gets told they're "doing it wrong," which 1. no shit, that's the substance of that complaint, and 2. blames individuals for what's essentially a management failure.
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.
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.
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.
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.
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).
> 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.
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.
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.
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.
[1] - https://www.logicallyfallacious.com/logicalfallacies/Relativ...
Imagine explaining this to a dirt poor Hatian:
"You will have unimaginable wealth, but sometimes you have to sit in a meeting and do nothing. It's really hard"
I don't know why you think the average tenure across FAANGs is 2 years but it no doubt varies heavily by company. As another comment mentioned, Google has notoriously good WLB, and any individual team will be more predictive than the company as a whole. You'll hear plenty of "first-hand accounts" of high-pressure work environments because hundreds of thousands of engineers work at those companies!
Everyone desires self actualization, and that is different for each person. If you are highly creative and technically competent, then yes, endless meetings are a detriment to that goal. A starving Hatian doesn't negate that.
Edit: that's why people make FIRE exists and start physical jobs instead, become farmers etc, it's not as simple as a job being hard or easy, but stressful, irrational, alienating and in other ways unhealthy that doesn't necessarily make it obviously "hard".
I mean, I love my job, but I still plan to FIRE and become a machinist or something.
My wife works in healthcare, and agree that our "problems" are paltry relative to what they deal with.
"Instead of 6-3 your hours are now 6-to-6 3 days a week because we lost coverage in the evening. Tough noogies"
She gets paid 1/2 what those with 4 years of experience in our field get, and works on brains and spines.
One of my friend works at a major consulting firm, he knows they just grind new accounting grads until they burn out every. year. They just hire new ones the next year.
Banking analysts, actually pretty much everyone in banking is in what sounds like an unending grind. The exception I've heard is if you can somehow push through as an IB and make it into being a VP you can calm down.
So, yeah. Meetings are boring, the work is sometimes uninspired but things are pretty cushy for us right now.
Dan Pink - Drive: The surprising truth about what motivates us
You can safely dismiss almost every problem in the world with your approach.
"Our jobs aren't that bad – do you hear what they do to software engineers?"
I earn a decent chunk but I'd still have to earn my current wage for about a million years and pay 0% taxes to have as much as Jeff Bezos does.
But we have, by far, the most intellectually stimulating and flexible careers in the world. And nowadays, get paid ridiculous to boot.
So why is everyone complaining? What is everyone aspiring for?
I can only speak for myself here, but I know it's a valid point for many that followed the same path I did. The work I come about to do requires constant and intense mental activity on non-repetitive tasks. That takes a lot of energy. Twenty years ago, the computer engineering university faculty I've been through saw constantly the highest rate of dropout in its freshman and sophomore years, compared to any other kind of school out there. The touted reasons were mostly that there was simply too much work, that it was too grueling, too hard. The ones that prevailed weren't necessarily the smartest or the most diligent of all. They were, however, the most passioned about the computer engineering field. One had to have it to fuel the energy demand of the work necessary both in school years and after. The money is good, but that alone didn't seem to cut it. The work conditions in office are nice, but those weren't nor aren't what kept me in the game. (There were times when the space I worked in had no heating in the winter and was often smoked in, with me as non-smoker.) What I see in my peers' complaints nowadays is something that hits on the root of what made me wake up and continue every day. And the worst part is that the decision makers don't seem to be aware or caring. The mood is more like "I pay them, therefore I saddle them with whatever I see fit". So to answer you, what I aspire for? I aspire for a better fit, for both myself as someone good at something, which (from a self-development investment prospective) it makes sense to strive to do as much of it every day, as well as for the client benefiting my work/skills. I also think it's just ethical to rise awareness (even by complaints, if it has to be) when I see (my) resources misused and degrading of performance/potential in general.
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.
I worked as a supermarket janitor in high school and college. Most of my work in tech has been for government contractors. Most days I feel like I'm still a janitor, only I'm coping with other people's tech debt instead of scrubbing toilets. The thing is, if scrubbing floors and toilets paid as well as coding I'd go back to pushing a mop in a heartbeat because at least janitorial work has a better-defined scope of work and definition of done than most of the development projects with which I've been involved.
Not quite. Actors and musicians have it better, once they've established themselves.
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.
citation needed
> once they've established themselves.
BIG if; the ones you're thinking of represent the 1% or less. Survivorship bias.
I only recently learned about the term "strawman argument", and I think this is one. (Correct me if I'm wrong.) Parents post was not about SW devs who established themselves, but about SW devs in general. That you don't need to establish yourself to still live a good life is exactly one of the advantages of being a SW dev.
Besides that: Establishing yourself as actor often involves attending partys of Harvey Weinstein kind of people.
So here maybe more "survivorship bias": the bias of looking only at the top performers / the most visible ones, or here "those who made it". Ex: "Interviewer: How did you get to your position? Politician: I worked hard! I spend countless hours doing XXX etc...". Many other persons might have worked just as hard or even harder, but lacked the connection or simply the luck to make it.
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.
The post was written by someone who works about the management and shareholders of corporations. If privilege and entitlement are qualities of the people working on death marches at companies the DOJ said were illegally colluding to keep wages down, then what are the qualities of the heirs collecting dividends from these companies - expropriating the wealth of the surplus labor time of those creating the wealth. The system is the creation of heirs who never worked a day in your life, but you make the case of the parasites - that those actually working and creating wealth are the ones who are entitles, privileged etc.
It does seem to be a feature of the American working classes that they are led to be persistently, easily and even violently divided over wedge issues. Abortion, gender, race, "coastal elites" vs. "flyover country", millenial vs boomer, heck, or even, as in this case, "1 paycheck away from bankruptcy vs. financially stable".
You'd think illegal collusion over wage suppression would unite people who... earn wages but it doesnt seem to. Not in the same way belonging to, say, an arbitrarily advertiser defined age cohort does.
Which is really weird if you step out of American culture and look at it from the outside for a bit.
Maybe this is what Marx was referring to when he talked about a lack of class consciousness.
All these ideological movements such as communism, inquisition or social justice warriors subserve the individual to the collective struggle, usually by force. Who loves to be spoon fed propaganda or cancelled "for the success of the greater cause"? They attack their own people even more viciously than the others for crimes such as original thinking which is nothing else than heresy to them. They reject the very basis of debate and logic-based reasoning, preferring to spread stories with emotional appeal and moral judgements instead. They cause a chilling effect on society, people live in fear of being persecuted for any reason, learn to be docile and lack the courage to change anything.
The biggest joke in the military was danger pay, which was $7.50. $7.50 if I was working in an active warzone that day. I still stood in formations, pointlessly, for hours. I still watched people who shouldn't have been promoted get promoted over people who should. I still watched people fuck each other over. I still sat though pointless and grueling training videos. I still had 8-12 hour workdays. I still lived with the idea that my life would end early through mental or physical health issues. I could go on.
The biggest difference I have is pay and the security to try and improve the system myself. I know if I get fired for trying to do the right thing that I'll find another job, whereas in the Marines as a four year corporal with one year total combat experience I made $20k and had no career prospects should the military see that I am a problem.
Those were the negative examples. More positively, engineers are motivated by many of the same things Marines are and I use these aspects in my day-to-day leadership as well. I exercise transparency, when I know the team is shouldering a burden I acknowledge it and steps were taking to minimize it over time. Marines and engineers like knowing their purpose and place in the world. They both desire a framework that establishes a domain for their autonomy. They both desire leaders who are scrappy enough to fight in the trenches but with the tactical persuasion to have vision from above while leading from the front. They're both willing to put in whatever it takes to accomplish the mission but they want to be recognized for doing so, and not necessarily monetarily. Again, I could go on.
I'd suggest simply:
- software engineers are hugely in demand
- software engineers have worked out they can work well remotely, and often prefer it for a combination of productivity and work/life balance reasons
- software engineers are voting with their feet and finding work that suits their needs - and many firms are losing talent accordingly due to not meeting the needs of those staff
Employers are going to have to compete really really hard for acquisition and retention of talent.
And wishy washy corporate platitudes won't cut it, firms will need to offer both aggressively competitive financial packages and attractive workplace setups - remote, flexible, whatever it takes.
I'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 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.
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’ve been working mostly as a contractor for quite a long time now. This honestly is quite normal. I’ve done contract work through 2 financial crises now, and the longest I’ve been unintentionally out of work was two months, and otherwise I’ve managed to charge high hourly/daily rates the whole time.
I have seen a lot of my contractor friends go full-time during this pandemic though. When it first hit, the place that I was working at converted about 1200 contractors to full-time. The allure of job stability was too good to pass up.
But the risks were an illusion the whole time. There was a shortage of software engineers during the GFC, a shortage of software engineers for the 10 years after it, and there’s been a shortage of software engineers during the pandemic. It’s just gotten so bad recently that people who were previously more risk averse have started to notice it.
For our industry, during the last 20 years.
Not normal for most industries. Or in IT before 2000.
> I have seen a lot of my contractor friends go full-time during this pandemic though
Yeah, that's why I think it's important to have an elastic life style if you are a freelancer. So that you can suddenly cut 80% of your expenses. If you have big loans, an expensive car, 2 children in private school and live in a pricey area, if you revenue get shots, you are in trouble.
> But the risks were an illusion the whole time.
It was surprising though, wasn't it? I mean I expected calls to stop, but I got more of them. Now I have people calling me for things that are very far from my specialty.
Software is, indeed, eating the world.
Personally, I wasn’t surprised by this outcome. Temporary instability is what I was predicting. For demand for software engineers to actually tank, demand for software and software services would have to tank. I figured this was possible, but would require the entire global economy to collapse. So I figured it was unlikely, and in either case declining the offer I had to go full-time last year (when my employer at the time said they were terminating all their contractors) was most likely to be the correct decision (because full-time employment wasn’t going to protect me from global economic collapse).
The thing that I didn’t predict at all, is how long travel restrictions would be in place. Which has turned out very well for software engineers in developed economies, because all developed economies import software engineering labor from developing economies.
- 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.
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.
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.
How was it out there? I haven't been getting the recruiters hitting me up on linkedin as much, I wasn't sure how hot or cool the market is.
Not nearly as much experience, but I had the same issue. I was expecting once I opened up, I’d have a flood of messages in my inbox, given how everyone is saying how hot the market is. However, I feel like I’ve seen less than previous job searches, and filtering out irrelevant, low paying, shit jobs from those the number is even more disappointing.
I’m in central FL and I’ve been generally disappointed in this state from a job market perspective. Most of the recruiters I’ve spoken to are recruiting for roles within the state, regardless if they’re fully remote or not.
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.
> All companies (regardless of size and paycheck) make competent developers go through grueling 4–7 rounds of interviews.
It's possible to get hired with zero interviews, you need to put yourself into a position where this is the norm.
Every single contract / freelance job I've ever taken happened without a formal interview. I never had to do a whiteboard test or explain an algorithm to someone. I never had to write 1 line of code or even talk about lower level programming things specifically for the sake of getting a job for a specific company.
All I did was talk to them over email or Zoom while we discussed what they wanted me to do for the job. Then it went straight to a statement of work / contract and that's it.
Most of these happened where the person hiring reached out to me directly. I don't use any freelance platforms or marketplaces.
Now, the debatable part here is "competent developer". I won't make any claims that I'm competent but I have done a ton of assorted gigs over the years and lots of them lasted for multiple years (and still do). For context I sent out 47 invoices in 2020.
If you hate the idea of parading around interviews and working in an office please understand you have options. Besides part time high school jobs I never worked in a non-remote position in my life.
You haven't said how, but given you've got an extensive blog and several courses, is that how you're getting your leads? And publically demonstrating your competence?
And you shouldn't forget that writing blogs and teaching courses is a whole different set of skills to programming, that have to be learnt and worked on.
True.
I'm a tech blogger and teacher and I sometimes get offered development and management jobs.
I've outlined how I started freelancing (pre-blog / courses) here: https://nickjanetakis.com/blog/how-to-start-a-successful-fre...
Everything there still applies today except for going to physical meetups because of Covid. You are right tho, you won't be able to sit in a locked room because no one will find you. You need to do something to make businesses aware of you and there's lots of options based on what you're comfortable doing. Eventually you can get to a "in Soviet Russia, job finds you" world where you sit back while picking and choosing the contracts you want to take on but it will take a good amount of effort to get there, but you can still be successful doing freelance work waaaay before that happens.
You just maintain video courses, ebooks, mailing lists, multiple social media profiles for marketing all of the above, and an endless supply of blog posts because you enjoy doing all this in your spare time.
You're not wrong but it's probably not as many hours as you think to do all of the above (and more). I average around 15 hours a week on that stuff and a few things you've listed are close to no time at all. For example I only send one email out a year and I haven't written an ebook in like 3-4 years.
I still stand by my claim that you can make a living as a freelancer without doing any of the above. That's not based on theory either, it's what I did for over a decade. I only started a blog and doing courses because I thought it would be fun and it felt like a good combination of things to do with contract work because both things feed each other in a nice way.
People who imitate MLM marketing for self promotion are among the internet's most insidious grifters, imo.
Those 15 hours account for everything because releasing free blog posts, podcast episodes, youtube videos and open source tools is the marketing. Almost everything I release is for free with no strings attached and if anyone wants to watch or read that stuff they can, if they don't then they don't. I don't even monetize my YouTube channel because I don't like watching ads myself.
I never purchased a single paid ad and also don't cold email or spam anyone to "market" my courses. I had to Google what MLM even stood for.
The rest of the time I'm doing contract / freelance work and by "rest" it doesn't translate to an outrageous amount of hours per week.
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 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.
Unless you count 15 minute call with recruiter at the beginning as "interview round", there was nothing more.
That was sum total of my interaction with the company before being hired (other than telling the recruiter to send in my resume).
https://airtable.com/invite/l?inviteId=invtzMOjpyMmmowAK&inv...
I don't see this in the article. Are you reading the same one as me?
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 one of the bullets.
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...
Tangent: I followed your profile's link to your blog. I like what I saw (wrt Docker practices). Have you written about your freelance / contract gig experiences per se? I've been mostly remote for the last 20y, strictly remote since starting my tiny S-Corp / committing to consulting FT 4-5y ago, and I'd be interested to compare notes.
Do you have a site? Comparing notes is fun.
> 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...
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?
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.
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.
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.
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)
Or, you could look for opportunities in all of those statements.
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
I quit when we hit a 2 year mark without any new customers.
[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.
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.
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.
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 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.
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.
We'd need some data about this question to see whether it is a cultural or individual thing.
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 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.
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.
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.
Most of us on HN are not multi-millionaires, or even millionaires.
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.
That hit close to home. Such a depressing reality.
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.
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.
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
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.
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.
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.
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.
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)
As were bootcampers, which is similar I guess.
Do you have any good articles/recommendations on this?
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.
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.
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.
I remember telling people in late 1999 that these stock prices can't be long-lived because we can't all retire rich.