Layoff spree in Silicon Valley spells end of an era for Big Tech(washingtonpost.com) |
Layoff spree in Silicon Valley spells end of an era for Big Tech(washingtonpost.com) |
It's always sad to see the "who could have forseen this" argument passed around whenever things like this happen.
In fact if you treated companies like any financial advisor would tell you to treat something like a 401k or a savings account they would have considered what these companies have been doing for the last two years outright gambling with them and in turn also gambling employees futures.
With a lack of accountability for these reckless financial decisions though there is little chance that things will improve in the short or long term. This will continue to happen until legislation provides some kind of guardrail to simply firing at will anyone who disrupts a profit margin with their well paid talent and years of service.
Companies still desperately need developers to make their business goals reality. This is not changing anytime soon. There has been no advancement that makes developers less relevant.
What changed is how companies react to perceived bumps on the road and productivity. Companies learned that global recession can affect them and it pays to prepare. Companies also learned that fast hiring causes low productivity down the line. The easiest way to fix this is to fire a bunch of people at a time rather than individually and then blame it on perceived recession (even if it barely affects the company).
My experience is also that large proportion of hires can barely program at all and got into business because every other job they could get pales when compared to software development. There are multiple reasons why these people got successfully hired (broken hiring, enormous pressures, etc.) I can't blame people for trying to do their best but from our point of view it has a huge effect on entire IT business.
Also companies started playing a kind of chicken game, it seems. Everybody waits for one company to lay some people off so that they can use it as an excuse to do the same.
"Hence it is to be remarked that, in seizing a state, the usurper ought to examine closely into all those injuries which it is necessary for him to inflict, and to do them all at one stroke so as not to have to repeat them daily ... For injuries ought to be done all at one time, so that, being tasted less, they offend less; benefits ought to be given little by little, so that the flavour of them may last longer."
-- Nicolo Machiavelli
Also, when you fire one person, you have to explain in detail why this person. You open yourself to risk of being called for discrimination whether you intended it or not. All this scrutiny disappears when you do the same in bulk.
This seems like an oft repeated myth, but you say it's your personal experience, so I'm really curious what you mean by this. These are folks you've seen in SWE who just like, not opening any PRs? Just pretending to do busy work while some nice coworkers do their assigned tasks? How does this work?
Sometimes they can code, but slowly and their output is unacceptable. This creates a burden on the rest of the team to either try to review it into something good (this doesn’t actually work) or to fix/rewrite it after it’s committed (typical in shops that don’t have a review/PR culture or process). IMO this is the worst of the three types. In it’s worst form it’s also the most obvious and these bad hires tend to get managed out fairly quickly.
Sometimes they can’t seem to get anything done on their own. Questions from new hires are expected, yes, but the questions are supposed to wane over time. This group doesn’t have that curve. Having talked to coworkers after these people have left, I’ve later realized that these people have bothered a lot of people on the team with a lot of questions, to the point where most of their work has been done by other people. This is only slightly better than the group above, but it’s still a waste of a lot of productivity.
Sometimes they just hide out. I guess they dodge questions about output from managers? Or are otherwise very poorly managed? I’ve only observed this in environments with a very weak management system. Honestly if I had to choose a bad hire situation, this would be my preference. They’re leeching from payroll but they mostly don’t get in the way of work that I have to get done.
I'd say that 90% of the new graduates we hire straight up cannot program beyond what you'd need for your typical uni assignment (a few months ago one asked me what 'git' was). If they're motivated and eager to learn, I can usually get them to productivity in a month or two. The ones who are not take months to get up to speed and become a real drain on the team's productivity.
The more senior colleagues I interact with are kind of a mixed bag, some are really good and a pleasure to work with others have learned just enough to get by in their current role and become useless as soon as they have to do something slightly different.
That being said I do think that the level at my company is above average in relation to "the industry". If you want to see truly large amounts of non-contributing employees, have a look the IT-department of a large bank, pension fund, government agency or some other technology adjacent big organization. They can't hire the most talented engineers to start with and then most of them are actively kept from doing productive work by layers of middle-managers and bureaucratic procedures.
And much more often than not, the underlying issue for those crappy devs was less their lack of coding skills and more general lack of critical thinking skills. Making bad decisions when faced with a choice, that sort of thing
(For the record, I also copy SO code into my projects, but I at least leave a note on what specific problem I’m solving and a pointer back to the question.)
There are a large number of SWEs that are not worth keeping but the incentive structure is misaligned to deal with it. If tomorrow you realize more than half of your staff should be cut and replaced, how much effort would it be to do it, what do you gain and how much risk do you put on yourself if it back fires?
I recently watched a fellow leader try to go down this path to get stonewalled by HR about respect, moral and cultural values.
Disclaimer: Own personal opinions.
1. pair programing where they "want to watch you", but never modify your code and submit it
1. talks a lot about progress, but it takes days to get a commit out of them
1. will build "solutions" to perceived problems that really only serve to make them the single failure point and are not usable
1. says shit like "i don't write tests" or "it works for me, can you show me what you mean?" and clearly has no idea what you're doing
1. you repeat the same comments in loops, because they aren't taking your feedback, they're trying to hit a KPI
these people fall into two major groups, the people doing it on purpose, and the folks that don't realize that this is them. a lot of people lie to themselves about their ability, and this is the end result of them being incapable of acknowledging that they've got work to do!
whenever i read statements like that I am reminded of this : Illusory superiority
" Illusory superiority is a condition of cognitive bias wherein a person overestimates their own qualities and abilities, in relation to the same qualities and abilities of other people. "
It comes across as you stating you are so much better vs everynoe else. Sort of like how 88% of the population think they are better-than-average at driving
Also stating that there exists something like "illusory superiority" does not mean there does not exist "superiority". Yeah, I also studied theoretical math.
Even though most drivers think of themselves as above average it absolutely does not mean that there do not exist superior drivers. An F1 driver can absolutely say he is a superior driver and it is completely true, factual and not driven by feelings of "illusory superiority".
The 'low code' / 'no code' phenomenon is rising fast where the business folks are being asked to build out a good part of programs based on their knowledge of business systems.
Theoretically, if this all pans out, The developer is now forced to learn the business or is managed out of this particular job.
It does not pan out. Syntax is the easiest part of being a software engineer.
The reason is that they are solving easy, junior level problems. They are solving the problem of how to do this specific task that requires coding.
What they do not solve is how to develop complex systems. As a developer, you not only learn how to program things and solve technical problems, you also learn the big picture of how to develop large and reliable systems.
Agreed.
> What changed is how companies react ... Companies learned that ... Companies also learned ...
Also all wrong, though.
Nothing has changed.
> My experience is also that large proportion of hires can barely program at all ...
And that won't change either. Hiring anyone with a pulse started in the late 90s and 2008 didn't interrupt that. Those will be the people who are likely to lose their jobs in the coming recession, but hiring will expand again afterwards.
This is just another layoff cycle. People are projecting weird myths about how they think things should change onto companies when there's zero evidence that they've fundamentally changed or learned anything.
Sociologically it is weird how we haven't had a recession since 2008 and all the kids who either don't remember or barely remember that one are projecting all kinds of fundamental shifts onto the next one.
But tech job interviews are infamous for how crazy the interviews can get. Is this mainly for non-entry level positions that you're referring?
>Everybody waits for one company
The same can be said in reverse so that people are hiring just to prevent someone else from getting to hire them. If you have a milkshake and I have a milkshake, but I have all the employees that can reach your milkshake, then I have all the milkshake
I’m in the process of hiring a few hundred people - we’d never be this far down the funnel in 2019 because we’d be out of desks.
There's no doubt that for the next few years we're not gonna see the levels of compensation raise we've seen in the last 24 months, but it's not "end of an era" rather than a correction imho.
Will variable rates mortgages and wealthy tech workers end up paying for the covid lockdowns and government excesses?
[edit] We're talking like 2-4% of originations have been ARMs from 2009 onward, vs. a peak of 35% in 2004-2007.
I went thru the previous crashes. It feels like the start, but not the eye of the storm. Companies are cutting jobs, not going going out of business. The casualty rate of startups in dotcom felt like 90%+. In 2008 major banks had to get bailed out. Today, companies are making cuts to get back to 2019 levels. There is still a long way to go before it's a hard reset.
“Slicing to the bone”: you
I don’t think a two year hiring spree with a pullback spells the end of anything other than an aberration caused by a global natural disaster.
Back in 2000, many tech companies were buying products services from, and selling products services to, one another. When the flow of fresh capital from VCs and IPOs dried up in mid-2000, money-losing tech companies cut spending to conserve cash, reducing revenues at other tech companies, which in turn did the same, and this dynamic became self-reinforcing process affecting the entire tech ecosystem, first gradually and then "suddenly." Tech companies that had been growing at double-digit annual rates in 1999 found themselves with sudden, "unexpected," double-digit revenue declines a couple of years later. Many tech companies that couldn't make cash last for three years failed during this unpleasant period, including many which had good products and capable teams.
If the current wave of layoffs and revenue slowdowns gradually becomes a self-reinforcing process affecting the entire tech ecosystem, it could take a long while for the layoffs and revenue declines to end. These things can take a life of their own, and individual companies can't stop it, because they must cut spending to survive.
Now, within the Crypto market, yes, that is a lot like the dot com bust. I'm just wondering what the FAANG of crypto will be!
There was a lot of VC funded advertising $$$ that went straight to Yahoo. The canonical examples being WebVan and pets.com
At the other side tech companies enjoyed lot of growth during Covid as the world digitalized, and are now, well not yet in a crunch, but flatlining toward where their natural growth would have been if Covid didn't happen.
Pair lack of growth with over hiring and you get a readjustment.
I don't see reason to call this a jobpocalypse yet.
In my opinion, these are corrections to the excessive hiring done in 2020. If you take each of the companies, the layoffs cane from bets which didn't make money. I don't think this marks as an end of an era.
It's still incredibly expensive and hard to hire and retain engineers. If that remains true then this is really a blip. It won't really be the "end of an era" unless there is a glut of engineers in the market. This happened in 2000. In the UK, the unemployment rate for engineers was huge (>35% IIRC) and that excluded those who had left the industry.
Another interesting question is what will the collapse in share prices to do hiring and retention since equity is a massive (typically >50%) part of total compensation. Those who got hired last year in particular have seen a huge amount of paper value disappear.
Yes. At least at the large firms, the best case scenario is probably that effective overall comp has and will continue to take a huge haircut. And corresponding cost of living will not. In fact, pretty much the opposite. Even housing in high cost of living areas will probably be pretty sticky with respect to prices.
That said, there's little indication so far that things are in "would you like fries with that?" territory as they were in the tech sector (well beyond just engineering) as they were in ~2000 to 2003 when many people left the industry for good. I was laid off and was very lucky to land a (less well-paying) new job in short order. There weren't much in the way of nibbles.
There will probably be reasonably plentiful jobs. But comp will come down to earth commensurate with other branches of engineering for example.
Any good write-ups about this? Sounds like a very interesting time.
The “Video game crash of 1983” was a similar event that happened 30 years earlier, https://en.wikipedia.org/wiki/Video_game_crash_of_1983. Apple and Nintendo were the phoenix that rose from those ashes.
I'm surprised that Google and Amazon aren't jumping in and poaching all of these talented engineers from Meta, Stripe and Twitter.
Part of what you’re seeing is just that the tech giants are integral to modern society and get covered the way e.g. railroads were a century ago. I think it’s especially strong for companies like Facebook, however, because they’ve not only taken the lion’s share of the profits and lowered standards in a way which has had real-world impact, and things like Facebook’s infamous pivot to video or Google’s AMP were bad-faith attempts to give tech companies more control over journalism. Angry bees are to be expected after kicking the hive.
They may be angry, but newspaper coverage isn't supposed to be about settling scores and getting revenge on the companies that threatened your profits. It's supposed to be about reporting facts and making reasonable inferences.
I know that ideal isn't always adhered to, but let's not excuse the media too quickly when they behave badly.
If economic conditions continued going well then they had the staff to meet their needs.
If they didn't then they'd cut the worst performing employees and anyone else they didn't want. Since every other company would also be doing layoffs they'd get no bad PR for it and low risk of employees leaving for greener pastures (since all other pastures would likely be closed).
Layoffs aren't some massive horrible thing for a company. They're just another part of doing business.
Then growth slows and suddenly there's a need to tighten the belt a bit and a lot of waste is found
Remember that much of the tech foundations for 2010s success were laid in mid to late 2000s. I saw it from within Amazon as AWS was building the core infrastructure components that went on to become independent services in 2010s. So I expect 2020s to go through similar phase. Maybe AI? Robotics? VR/AR? I don’t know.
Big tech happened because of open source and remote work (international collaboration on the internet). C, gcc, Linux, BSD, and publicly funded protocols like email and HTTP unlocked the last 20 years of growth. The next wave of open source is happening in robotics and manufacturing. We’re around 2005 right now in software terms. The iRobot, Nest, Oculus generation of companies was the first .com wave. Robotics and manufacturing teams are figuring out how to work remotely (accelerated by the pandemic).
That's why you'll see insane hiring phases (and hear stories of so many new people with nothing to do and no onboarding systems yet in place), and a couple of years later you'll see huge layoffs when there are big public economic fears.
Second best is a GitHub repo but often those I have seen simply included test apps resulting from a CS course or perhaps worse, code copied from somewhere else.
Regardless, app or code (or both) give the interviewer something else to talk about with the candidate about (and you would expect a good deal of enthusiasm from the candidate in this kind of discussion).
* Nobody asked culture-fit questions
* Nobody was interested in portfolio, side projects, or GitHub.
* I was not asked questions related to the role.
* Only presented with a leetcode screen
If you move away from the FAANG/unicorn scene, the interview process becomes more personable, and I was actually asked questions related to the role.
The only reason I have any open source work on GitHub now - I stopped programming as a hobby the minute I graduated from college in 1996 - is because my company has a very straightforward open source process where I can open source reusable project work I do for customers (consulting).
Tech might be changing, and it may be the end of an era, but it's not the end of tech.
People tends to believe that the current situation will last forever, the bad and the good ones.
How does Twitter, Google, Meta etc make money? With ads.
Ads.
What I am avoiding like the plague are companies that have no profits, no dividends and no real innovation. Any company that is still aiming for growth before profits is just scary.
I wonder if part of the broad labor shortage of the last year or two was from so many people pivoting into remote roles for tech companies (not all engineering roles either). It was unsustainable. Now things are going back.
For example, Facebook has some great people working on VR. If they get spooked about profitability, someone with a neuroscience Ph.D probably isn’t going to pivot to ad sales.
My hunch is they might be doing exactly that, even if they don't want to grow a lot at the moment since their profits and share price are lower than they have been. Poaching top experienced people can be done almost quietly, as it doesn't result in significant headcount expansion by itself.
Myself I took the opportunity to just improve my degree with an internship at CERN.
Later in 2008 while not being fired, I enjoyed the merge that Nokia went through with Siemens, and a few side effects from that, as they tried to keep going in a market with uncertainties.
Almost all companies cut IT spending to the bone for about 24 months. The rebound in hiring was pretty quick, but wages where suppressed until the later 2000s.
This does make me wonder if we’ll see some quiet reform in large companies as they hire people who have worked at major tech companies and can better make the case for areas to modernize.
Big layoffs never are. Projects and groups get cut and, while there may be some nominal effort to hold onto people who are particularly valued on the basis of perceived ability, connections, or or something else, there is a whole lot of randomness built into the process.
Google itself in that case afaik. Times are different now.
-- Not Stalin
Same, in 25+ years I've never met these developers who can't code.
There are many who make problematic decisions in other aspects of the engineering lifecycle. But actual lack of being able to write working code, no.
On my new team, there is an incompetent senior engineer. Damn... how I miss my incompetent junior, who aside from wasting some time, never really affected the team. The incompetent senior produces impressive amounts of badly architected, untested code which breaks subtly and is impossible to maintain. They are also totally unreceptive to mentorship because they are so senior and know everything.
That seems very logical. The outcome is in line with the optimization. For a different outcome choose a different optimization.
CS !== Programming
The premise of emphasizing leetcode is to get developers who can solve problems fast.
But if the only thing someone knows is competitive programming, and not operating systems, distributed systems, network protocols, serialization formats, libraries and frameworks and pretty much everything that's required to implement actual software, that person won't be able to solve problems fast. In fact, that person may reinvent the square wheel and waste resources.
Apple makes a decent penny on ads themselves.
Don’t forget all the technology these companies sell to empower the ad ecosystem.
None of these companies are ad-driven, or have cultures based upon them. Losing the ads division would not irreparably harm the business.
Youtube had 2021 revenues of $28.8b. Google ad revenue for 2021 was $209b. That's what an ad-driven business looks like.
It takes a week to learn Python syntax, it takes 10 years to be a good software engineer. Engineering software without code is what the most senior software engineers do all the time because the less experienced folks need (want!) direction from them and they have the knowledge and wisdom to provide it instead of coding.
This is probably the best quip I've heard all week.
I'm developing a language with "no syntax", every token is executed immediately, making it trivial to create arbitrary syntax at any point in the file (literally you could define a function that implements SQL syntax and then call it - you are now using SQL syntax).
I don't necessarily recommend it for every language but it's really interesting how little it actually affects the hard problems of software engineering.
I agree on pair programming, as a tech lead, pair programming is my single best tool to get some understanding of my team member capabilities.
"Talks a lot about progress"... this is a mixed bag. In most cases you are right. But in some cases.. I have worked with people who obsess about quality of what they produce (and I am the same) who will spend a lot of time polishing things after they are nominally done. It is not that they don't deliver, they need some help defining what done is.
"Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion. When somebody says shit like "I don't write tests" I want to hear a follow up explanation on why is it. Because if you do not write tests you have to be doing other things.
"You repeat same comments in loops because thy aren't taking feedback". Guess what, a lot of good programmers are bad in some other respects. Just because they aren't taking feedback doesn't mean they are bad. I stress to people it is not enough to be good at programming, development is about building things and programming is just one skill. Development is a team sport that requires multiple people to work together to build something.
if you're producing code, it is not just talk. i'm talking about a scenario where you've heard about the great struggles they've faced, and after a week you get a commit with 4 files cahnged, and it's on a "sample" of the full work. overdone is fine and not what i meant.
- "Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion.
This mindest is the same to me as saying "we only need a single point of failure for all things". "I can just read the source" is the same thing as saying "i can just take a course on it later that will take hours without the help of the original context". I firmly believe that anytime you build a big suite of software without tests, you're just unloading tech debt on an org with no guidance on how to handle it. comments, tips, and tricks can drift from the code overtime, a test can't and is the only provable way to validate your code. if you don't have time for testing at work it's an organizational failure that will only come due in the worst of times. Remember when Jira deleted a bunch of shit and couldn't get it back without one engineer fixing it manually? boy, i bet it would've paid to have _any_ testing in there!
- "You repeat same comments in loops because thy aren't taking feedback".
When you tell someone "commiting secrets to the repo means they are no longer secret" and they go oh yeah, makes sense, and then proceed to dump credentials into the next four commits, that's what i'm talking about. not this "i dropped a whole new concept on you. learn it in one" concept that i may have implied. i'm talking about poeple who just aren't even trying to listen, they just want an approval or w/e from you to move on.
fwiw: i'm a bit of a stickler for testing, and will acknowledge that my stance comes from my experience, and is therefore a known bias, just one i have a hard time letting go of
It is not that I believe tests do not work. Tests is a viable solution to a problem. The issue with tests is that you have to do a lot of things right and you have to structure your development in certain way for tests to be productive. And if you don't do a lot of things right then tests will just cost a lot of development time without much benefits.
Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.
Very few organisations I worked in would be at maturity level when investing in unit testing would be the highest return on investment thing you could do at the moment. There is usually many other problems that cause less disruption to development practices and bring much more benefits than unit testing.
On the other hand I am a huge fan of functional testing where you create a test harness that ensures that public interface of your product (application) functions as expected. The effort is much smaller (you only evaluate public interface which already is integrated with other things and which isn't expected to be changing a lot anyway), the benefits are clearly demonstrable and understood by stakeholders.
Now they're getting the kind of coverage companies in industries without that soft glow get, and I think they're missing the time when e.g. stories used Facebook as shorthand for where you share pictures with your friends rather than where your grandparents are misinformed.
>The official dating of recessions in the United States is the responsibility of the National Bureau of Economic Research (NBER), an independent research organization. The NBER has identified the shaded areas in the graph in Figure 1 as recessions and the unshaded areas as expansions. Recessions are periods between cyclical peaks and the troughs that follow them. Expansions are periods between cyclical troughs and the peaks that follow them.
>The NBER defines a recession as “a period of significant decline in total output, income, employment, and trade, usually lasting from six months to a year, and marked by widespread contractions in many sectors of the economy.” People sometimes say that a recession is defined by two consecutive quarters of declining real GDP. This informal idea of what constitutes a recession seems to be consistent with the past recessions experienced by the United States, as every recession through the 1990s has had at least two quarters of falling real GDP. However, this is not the official definition of a recession. The business cycle dating committee of the NBER generally focuses on monthly data. Close attention is paid to the following monthly data series: employment, real personal income less transfer payments, the volume of sales of the manufacturing and wholesale– retail sectors adjusted for price changes, and industrial production. The focus is not on real GDP, because it is measured only quarterly and does not permit the identification of the month in which business-cycle turning points occur.
This makes zero sense and shows you lack understandings of the issue being brought up.
Obviously like anything else, driving fits on the bell curve and there are really bad drivers and some exceptional ones.
But the point of the effect is that when asked, most(>80%) THINK they are above average. If they were actually tested they would be shown this is mathematically impossible and they would not rank where they think they do.
You may very well be that superstar dev because as stated, when there is an average there exists the possibility that some are below and above the average.
> Can't say how I am stacking up against developers with same level of experience
This is very telling.. you come across as condescending to others but are unable to rank yourself vs others with your level of experience?
One, 25+ years ago tech got the best and brightest. Early ‘00s because of high demand and good salaries, schools cranked out a lot of mediocre developers, plus offshore poor quality firms had companies snapping up nearly anyone good or bad just to have warm bodies to do what they need. The average developer quality dropped drastically.
Two, they have likely worked in many many different platforms and tech and bring a more holistic knowledge that folks that have been working for 3 years in (name whatever language/platform/framework du jour).
My career started in the mid eighties, I’m not a developer, but have worked with many over a long career and I can say without a doubt in my experience the average software dev in 2022 pales in capability to the average dev in 1984. Im often in awe at how bad they are…
I attended a very reputable CS department (top 5 in the US) and there was very little instruction on actual development skills. Most of us were not skilled developers upon graduation and had to learn these skills in industry.
Now, there were a few, rare, lower tier schools that “cranked out” developers with say C++ skills or Java, but I found most of them to be mediocre within industry and quickly surpassed by the CS kids out of better programs.
One thing I've really had to get over is "illusory inferiority" - I am objectively an extremely good programmer, as demonstrated by my accomplishments and career path, but I constantly underestimate the value I provide to my employer because the contributions I make don't always feel important.
As an analogy, I can imagine a slightly bored senior sushi chef who is a master at preparing fugu (poisonous blowfish). The value they provide is huge, but they've done it for so long that it does not provide a challenge.
Okay, enough analogies. Here is the thing: your 30 years of experience maybe means squat if you are a COBOL god and we are a React shop.
To stay relevant in this business you need to study. A lot. If you don't, you might end up in this situation where you contribute barely to the team but consider yourself the top dog because you don't understand what the other are doing.
Why is it a problem that some people do the bare minimum? By and large they still contribute in some small way to the project, hopefully. I'd much rather work with people who are less competent but easy to get along with than someone who is above average but also cocky and inapproachable and won't take feedback well.
Most software and business problems aren't that hard. You don't need the best people to work on them. Superstar devs are sometimes just a pain in the ass and not worth the small improvements to code they can bring if they are a thorn in everyone's sides. Coding is just routine groupwork, not an Olympic sport.
My 2c as someone who's slightly below or slightly above average, can't really tell and don't really care lol.
I want to be able to set a certain bar of quality and work ethics and I want the average developer to meet that bar, not for them to be so far below it that I have to hire way above average people just to reach the bar.
I agree with you that you want people that you can work with. The star developers with the attitude you describe is not someone I want to hire. However doing the bare minimum is so way below the bar that this better not be what the average developer does. I want those people to be the exceptions - way below average.
These people with terrible work quality and work ethics... how do you end up with them to begin with? There can't be THAT many of them. Are you working for a huge company that hires by the hundreds and just don't have time to properly vet/interview individual hires? I don't even mean LeetCode, just casual questioning, code samples, etc.
I believe you, I just have a hard time understanding how somebody so terrible gets onto your teams to begin with. None of the coworkers I've ever worked with have ever been like that, and though all we all start at different skill levels for different things when we start, that tends to equalize itself after a few months of working together.
If code is not where you want it to be, reject the PR, leave specific comments about what was done well and what was done poorly, then repeat the cycle until code is where you need it to be.
One was doing absolutely nothing at all for months on end.
One was doing negative work - every line of code made things worse, every document was unintelligible, and they would approve every PR from other devs the second it was opened.
Suffice it to say, the dev that did nothing at all was the most productive of the two.
And these people frequently last surprisingly long at companies because it is pretty hard for managers to understand how individual team members contribute to overall productivity. Managers tend to focus on short term goals (like getting a feature delivered or a bug solved) but have hard time understanding long term implications of bad decisions their people make.
It is pretty easy to fix a bug or write a feature but a bad developer will cause large amount of debt along with it that will slowly deteriorate productivity in ways that will be difficult to understand. The people who understand what is happening -- senior devs -- will frequently not speak up about it or their voice will be downplayed ("Hey, this guy can't be that bad, he is delivering after all?")
- You close a feature ticket by cutting all corners possible
- Every corner cut will later become a bug ticket, that you can solve quickly as you are more familiar with the feature
Exactly! This can be very difficult to quantify; as this kind of debt is undetectable by standard gates (linter, static analysis, etc.). Instead, it is more nefarious... introducing coupling, where none was needed, or long-winded tests; that test very little, and make the code hard to refactor. I don't have a measure for this beyond my intuition of working with code for decades.
What makes it all worse, is when the features are 'delivered' and marked as 'complete' by these folks, they are difficult to take back! Especially if their delivery was identified as a key objective to a quarter.
Now with that said, of course we have standards. That's the bar ;)
The point I was making is that it seems that the average developer is so far below the bar, that I don't want to hire average developers.
Of course there are some juniors (and even some seniors) that will take to code review comments, pairing with them, mentoring them, giving feedback etc. and will improve. Many many don't. Like mentioned elsewhere in the threads here, I think at least some of that has to do with the fact that so many developers have entered the market but they actually aren't good at it. They're in it for the money. They pull the average so far down that hiring average developers is excruciatingly frustrating.
Sounds like there are existing problems more severe than lack of tests.
Recall that tests, like comments, are not for you in the here and now.
Particularly needed a lack docs and tests, and a surfeit of cash.
It not only lets me know how the person works, how they solve problems. It lets me remediate some of the problems. And just get to know the person on personal level.
The only issue with this is it takes time and does not scale. You can honestly manage up to a dozen devs this way and when I have larger teams I have to skip it (for example I no longer pair with juniors -- I pair with seniors and then teach them to pair with juniors more productively).
To me this is the skillset that seems to be the biggest difference between 2022 and 25+ years ago. I see developers today that if the requirements are not spelled out down to the crossed t or dotted i—-or an engineering plan is not drawn out in incredible detail, they are simply not productive. It’s almost robotic.
Perhaps this is due to resources like Google and stackoverflow, which provide solutions on tap. This avoids the educational and sometimes frustrating process of doing a deep dive into an area / “rabbit hole” in order to figure it out by oneself. It also can result in developers that give up more easily when solutions are not easily available on the internet.
I spent 8 years learning German at school and I don't remember anything. I never attended a single English lesson (not my native language!) and yet I am using it every day.
That's why I do not give any credit to people who finished CS courses. In my opinion -- monumental waste of time. You spent 5 years not really pushing yourself learning one, not even very important subset of skills needed for development. And are completely unprepared to handle the real work.
At least when you study engineering courses those kinda help you prepare for the work ahead (so you know how to design a building safely and can theoretically start doing it on day 1 in your new job -- with supervision). That is not what is happening with people leaving CS courses and joining development teams.
Why is it a problem that some people do the bare minimum? By and large they still contribute in some small way to the project
You should put 100% of your effort into your work, when you work. I'm against the overwork culture that exists in a lot of Corporate America. Don't do 150%. Don't work 60 hour weeks. That doesn't impress me. What I expect from an employee is that they work however many hours their contract says they should ("nominal hours" if you will in places where this isn't well defined by contracts) and that they give 100% of what they can do during that time. After that time is done, stop working. Do other things. Be with family. Be with friends. Go on a date and start a family or whatever floats your boat but stay away from work. But if I see you on your phone, looking through Facebook or Reddit or HN every time I enter the room (and you quickly put it away) we're not going to be friends. I love WFH btw. Never want to go back into the office. But you better not "do the bare minimum", i.e. be on HN 80% of your time that you "work".
EDIT: And of course that doesn't mean you can't ever check stuff on your phone or whatever during the workday. But there is a strong correlation between people with sub-par output and those behaviors, especially if they tend to quickly put their phones away as if you "caught them".
I don't think people can give 100% to anything 8 hours a day, 5 days a week. That's just a recipe for burnout. Our productivity ebbs and flows like moods. I mean, we're really not that more evolved than apes, and to expect us to behave like finely tuned robots is kinda unrealistic to begin with.
My quality bar is basically "does it work, is it readable, can it be modified and maintained without too much frustration". It's not going to win any awards but it's also never caused any major complaints that I know of or any major catastrophes. And to deliver that, I give 80 to 90% pretty consistently, between 30 and 50 hours a week depending on circumstances. My peers too. Sometimes my coworkers have kids who are sick, sometimes they have some personal errand to run, sometimes they're moving or having a bad breakup or just needing a mental health day. And sometimes they work late because they have nothing else to do and really want to wrap up that new feature for the next version. My managers follow similar balances too. I don't expect them to behave like machines, because they're not. And it goes both ways.
I never once thought, "I'm going to try to get away with being lazy today because the boss is away". I value my contributions at work, and even if it's just mediocre code, it's stuff I still pour a lot of energy and sometimes emotion into. It's just paced so as to not cause burnout. I also don't think of my employers as temporary steps on some treadmill to riches. I work with them as much as I work for them, because I believe in the company's projects and values.
Shrug. Different cultures, maybe? I don't work for assembly line code mills. They don't think of me commodity labor. With a bit of mutual respect and empathy, it seems to work out pretty well in the end. That's just my anecdotal experience though.
Regardless of the initial reasons, if you are continuously detached from your work you are extremely unlikely to get very good at it.
Our brains are actually wired to filter out information that you don't find interesting and even if somehow get aware of the information -- to quickly forget it.
Our RAS (reticular activation system) is part of brain that wakes your attention to facts that your subconscious is programmed to recognise as interesting. Have you ever noticed that when you get interested in some topic (for example cycling) you immediately start noticing a lot more about the topic in your life (like when somebody rides a particularly interesting bike) even though nothing about the world changed in the meantime (no more interesting bikes today than a month ago)?
Now that I think it might be enough explanation for why devs these days seem to be so weak compared to what I remember from decades ago. Because if the same problem of detachment from work applies to large portion of population then this large portion of population will be doing very poorly at getting better at what they are doing.
In software development the additional problem is that the number of developers has been growing exponentially for quite a long time and so there is only very small proportion of devs who remember world from before "big tech" boom.
"does it work, is it readable, can it be modified and maintained without too much frustration"
You mention between 30 and 50 hours. I don't think this is incompatible w/ what I wrote and how I see things. I just didn't spell them out in more detail (long enough post already but this time I'll try to just write it all out). Let's say your nominal hours are 40. I think it's fine and should be normal to sometimes do 30 hours and sometimes 50 hours. It should just even out. Like you say, sometimes you have an errand to run in the middle of the day but you have kids and can't just do a couple hours longer in the afternoon that day. But you can get up earlier one of the next days and add the two hours of your time that you promised your employer there. Sometimes you'll have hours of nothing but brain farts but other times you'll have a stroke of genius while you're in the shower and you code it up in 10 minutes the next morning. There are your mood and productivity ebbs and flows. I'm not saying you have to deliver that task that nominally takes 8 hours to do in exactly 1 wall clock work day. An 8 hour task is probably going to be spread across 2 actual wall clock work days. Not that anyone could actually make such an accurate task estimate.
And yes, it should be OK to work late sometimes because you just want to finish something off. In fact, I expect this kind of flexibility from my employers. I must be able to start at 6a.m. one day because I couldn't sleep as well as working till 10p.m. another day because the S.O. and kids are gone that evening and I want to do that refactoring I never have time to do otherwise. If my employer forces me into a 9-5 instead (i.e. hours outside of that don't "count") then I will be looking for a different employer. I also expect the employer not to expect me to work 60+ hour weeks. I don't want to have to pretend to work 60+ hours while actually goofing off. So of course those extra hours I did that evening have to even out as well. I'll maybe take the Friday after that off or do a half day or something. The last bit is important I think, because otherwise it leads to peer pressure and the aforementioned overwork culture. I don't want to have lots of people on the team that "have nothing else to do" than to code for the company till 10pm every day. Even if they're all about code and that's the only thing they love doing (been there earlier in my life), do it for a side project, open source work, you name it.
Like I said in the edit, when I say 100% it doesn't mean there's not time to talk at the water cooler or answer a personal message here or there and sitting around discussing soccer results w/ someone after lunch while having a coffee. But it does mean not taking 1 1/2 hour lunches every day of the week and counting them as work time. Or walking around w/ a cup of coffee all day, chatting and distracting everyone else. Someone that feels "caught" and quickly stashes the phone away when you enter the room wasn't just answering the S.O. about who's gonna drive little Joe to soccer practice later. They've been on HN since you left the room 3 hours ago.
I guess you can see how we're not really that far off. Empathy and respect, for sure. But I have to actually be able to respect the other person. Some people I really can't bring myself to respect. I rather wonder how they got where they are and I want to be as far away from them as possible. I want to work with like minded people with similar work ethics. I don't want to work with people that spend 7 hours of their "work" time on HN and then invent reasons for why they got stuck on the task and when you take a look yourself (to help them get unstuck) it takes you all of 5 minutes to do the entire task. OK 5 minutes is a bit exaggerated but I guess you get the point. Unfortunately there have been people that I had to work with (that were at similar "experience levels" with me) that took entire weeks to not finish a task that when I took it over was able to complete within 2 hours while doing it from scratch. I'm really sorry, but I just can't respect someone like that (professionally).