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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
- 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 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.
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.
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 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 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’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.
> 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 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.
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.
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.
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.
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.
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)
"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.
> 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?
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.
> 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.
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.
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'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.
> 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.
After reading your parent comment I was going to reply and ask if you had considered writing a blog post about your experiences. Thanks for writing about this kind of stuff and sharing it so openly.
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.
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 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.
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.
HN is very silicon valley-focused but i've never experienced in europe anything remotely like these horror stories about hiring you see every week here.
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.
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.
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).
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....
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.
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.
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.
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.
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 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?
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.
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.
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.
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)
> 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.
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.
> 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.
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'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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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).
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.
> I guess the real question is why the fuck are management courses still founded in Taylorism?
im not sure if its just management courses, ive been under technical managers that think the same way... they like numbers and measurables... maybe to them its like code coverage and performance metrics... but with people...
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.
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.
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.
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?
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.
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
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
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.
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 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.
> ...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.
training wheels are the perfect word for it, because people and management get used to it, and now cant ride without them, so now you have entire orgs running in training wheels smh
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.
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.
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?
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.
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".
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.
To me it looks like all of the above is screaming at you "quit your great perfect plan and look at the real world instead". If something's wrong, adapt and adjust - this is what agility is about. You can't calcify agility.
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.
Agile may have started with good intentions,but was repurposed by nontechnical managers looking for a chunk of money which really belongs to the developers. Agile theory and practice does not address any concrete technical issues, but it is a hand-waving about meetings, demos, hierarchy, convoluted bureaucracy related to the tickets (cf. the Law of Triviality). I do hope that the advent of remote work and networking as opposed to corporatocracy will wipe the Agile grifters out of existence.
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.
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.
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”
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.
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.
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.
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.
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.
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.
Thanks for using the terms 'formal' and 'informal'. Smart people/groups always refine their process so that it works optimally. I'm sure that long before this Agile nonsense there were team that implemented aspects of it informally.
Something similar goes for what is considered the 'scientific' method. It probably existed in various forms before the term was coined. Notice how the word 'science' is used ( or misused if you will) and the 'scientific' method used to justify a claim. Teaching low IQ people a 'process' that involves refining it later, never really works.
> 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.
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.
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
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.
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.
That sounds pretty awful and definitely beyond the competence of a scrum master. I would expect such things agreed between product and engineering managers
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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).
> 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.
> 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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
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
356 comments
[ 6.7 ms ] story [ 298 ms ] threadSome 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.
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.
> 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...
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.
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.
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?
> 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.
Most of us on HN are not multi-millionaires, or even millionaires.
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.
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.
https://en.wikipedia.org/wiki/Scrum_(rugby)
Yep. I've suffered 20 years of poor facilitation. I keep hoping for some facilitation.
Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.
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.
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.”
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
To me it looks like all of the above is screaming at you "quit your great perfect plan and look at the real world instead". If something's wrong, adapt and adjust - this is what agility is about. You can't calcify agility.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.
Something similar goes for what is considered the 'scientific' method. It probably existed in various forms before the term was coined. Notice how the word 'science' is used ( or misused if you will) and the 'scientific' method used to justify a claim. Teaching low IQ people a 'process' that involves refining it later, never really works.
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.
[1]: https://en.wikipedia.org/wiki/The_Market_for_Lemons
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.
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.
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.
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.
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.
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