8 ms·

Nothing further from truth. Companies still desperately need developers to make their business goals reality. This is not changing anytime soon. There has been

Nothing further from truth. 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.

OmarShehata 4y ago
> My experience is also that large proportion of hires can barely program at all 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?
- nevon 4y ago
  Have you never had a coworker that needs so much help that they end up "costing" so much of other people's time and focus that you would have been better off if they weren't there at all? While I thankfully haven't encountered a lot of people that far out on the competency spectrum, I have met a few, or more than a few that are not too far off. Not a large proportion of hires, as OP said, but still.
  - kaidon 4y ago
    Absolutely. On a small team, we had 2 underperforming devs. 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.
    - twawaaay 4y ago
      I would add to it that there are a lot of devs that can't build stuff but they try (frequently successfully) to sell that they are doing a lot of volume of work (like closed tickets, lines of code, hours clocked). 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?")
      - leghifla 4y ago
        If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity: - 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 Total: you have closed more tickets than a dev that did the feature right the first time... sad
        deleted 4y ago
        [deleted]
      - 4y ago
- hasmolo 4y ago
  normally a developer that can't program shows in a few major ways: 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!
  - twawaaay 4y ago
    Some I do agree with and some don't. 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.
    - hasmolo 4y ago
      - "Talks a lot about progress"... this is a mixed bag. 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
- Pepe1vo 4y ago
  Maybe only tangentially related, but I can share some of my personal experiences with hires at my current job. I work for a mid-size IT consultancy agency in the Netherlands which prides itself on almost exclusively hiring people with a masters in comp sci, or occasionally some other STEM field. 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.
  - adolph 4y ago
    > new graduates we hire straight up cannot program beyond what you'd need for your typical uni assignment That seems very logical. The outcome is in line with the optimization. For a different outcome choose a different optimization. CS !== Programming
  - turdprincess 4y ago
    On my last team, I had an incompetent junior engineer. It was a time suck to do hold countless pairing sessions with them, answering the same questions again and again without having them learn anything. 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.
- jghn 4y ago
  Yeah I struggle with this meme. Have been in the industry for nearly 25 years at this point. Never once have I had a colleague who straight up couldn't code. I've seen a number of crappy devs, but they could at least do soething. 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
  - jjav 4y ago
    > Yeah I struggle with this meme. 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.
  - deleted 4y ago
    [deleted]
- bstpierre 4y ago
  I wouldn’t say it’s a large proportion, but I’ve seen this at multiple companies over the course of 25 years. It manifests in 2-3 different ways that I’ve seen. 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.
- ckdarby 4y ago
  This is my experience as well. A large portion of hires can barely program. There is also a portion of hires that are 20-40% more than market, but yield more than double the outcome. 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.
  - solardev 4y ago
    I wonder how much of this is just commonplace in any industry. Isn't mediocrity to be expected if people are, on average, well... average? When I walk into a bank I don't expect them all to be the best bankers in the world. Most of the restaurants I go to are fine, not earth shattering. Houses are built by crews of various competence. Government is run by the inept. Militaries are staffed with cannon fodder. Etc. 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.
    - tharkun__ 4y ago
      I don't think anyone is saying that being average is bad. At least I'm not. My problem with these people is that the average is such a low quality of work and work ethics. 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.
- closeparen 4y ago
  If you’re good at LeetCode, you can just get a new job every 1-2 years before your actual job performance catches up with you.
- coredog64 4y ago
  Not OP, but I can share my experience. Worked with two other people on a data lake project and their Python code was full of weird stuff, like if you just copy/paste SO snippets into the project. They eventually got outputs but the code was all-but-unmaintainable. (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.)
- infinitezest 4y ago
  I hope this remains a "myth" for you. I can assure you that it can be quite painful to deal with and take a long time to remedy.
foolinaround 4y ago
> 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. 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.
- flaviut 4y ago
  I've worked with several of these low code/no code things. It does not pan out. Syntax is the easiest part of being a software engineer.
  - baq 4y ago
    So very much this. 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.
  - vitiral 4y ago
    "Syntax is the easiest part of being a software engineer." 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.
    - twawaaay 4y ago
      Oh, so you discovered Lisp. Congrats:)
odyssey7 4y ago
> 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 "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
- twawaaay 4y ago
  Oh, yes, this quote I lacked. 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.
  - tome 4y ago
    "One person losing their job is a tragedy; a million is a statistic" -- Not Stalin
thenerdhead 4y ago
Totally agreed. Companies were over leveraged when we started seeing the excessive hiring during a prosperous time. The fact that most layoffs ranged in the 10-20% range and the similar company growth during that time speaks very loudly. This was less of a end of an era, and more of a temporary correction.
b20000 4y ago
barely program at all? looks like leetcode is bot getting the right people hired after all?
- twawaaay 4y ago
  Programming a short example that you trained to do for a long time when exercising for interviews is one thing and figuring out how to modify a large application in a desired way is completely different.
  - b20000 4y ago
    exactly
- b20000 4y ago
  bot => not
- therealdrag0 4y ago
  Do You think that problem didn’t exist or wasn’t worse before leetcode?
kennend3 4y ago
> My experience is also that large proportion of hires can barely program at all 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
- twawaaay 4y ago
  I have quarter century of experience in software development and have been programming most days for the past 30 years. Can't say how I am stacking up against developers with same level of experience but I can say with no exaggeration that I do, in fact, have more experience and more valuable skills (as I am routinely called to help with failing projects) than most developers I am working with. Saying otherwise would be just false modesty. 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".
  - kennend3 4y ago
    > Also stating that there exists something like "illusory superiority" does not mean there does not exist "superiority". Yeah, I also studied theoretical math. 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?
dylan604 4y ago
>There are multiple reasons why these people got successfully hired (broken hiring, enormous pressures, etc.) 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
- solardev 4y ago
  Isn't a lot of milkshake going to spill and melt while you keep going back and forth with it?
jjeaff 4y ago
Earnings reports are out and FAANG companies are showing drops in revenue. So I don't think their layoffs are entirely due to over hiring or simply using a looming recession as an excuse.
lamontcg 4y ago
> Nothing further from truth. 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.

OmarShehata 4y ago

> My experience is also that large proportion of hires can barely program at all 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?

nevon 4y ago
Have you never had a coworker that needs so much help that they end up "costing" so much of other people's time and focus that you would have been better off if they weren't there at all? While I thankfully haven't encountered a lot of people that far out on the competency spectrum, I have met a few, or more than a few that are not too far off. Not a large proportion of hires, as OP said, but still.
- kaidon 4y ago
  Absolutely. On a small team, we had 2 underperforming devs. 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.
  - twawaaay 4y ago
    I would add to it that there are a lot of devs that can't build stuff but they try (frequently successfully) to sell that they are doing a lot of volume of work (like closed tickets, lines of code, hours clocked). 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?")
    - leghifla 4y ago
      If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity: - 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 Total: you have closed more tickets than a dev that did the feature right the first time... sad
      - deleted 4y ago
        [deleted]
    - 4y ago
hasmolo 4y ago
normally a developer that can't program shows in a few major ways: 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!
- twawaaay 4y ago
  Some I do agree with and some don't. 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.
  - hasmolo 4y ago
    - "Talks a lot about progress"... this is a mixed bag. 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
Pepe1vo 4y ago
Maybe only tangentially related, but I can share some of my personal experiences with hires at my current job. I work for a mid-size IT consultancy agency in the Netherlands which prides itself on almost exclusively hiring people with a masters in comp sci, or occasionally some other STEM field. 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.
- adolph 4y ago
  > new graduates we hire straight up cannot program beyond what you'd need for your typical uni assignment That seems very logical. The outcome is in line with the optimization. For a different outcome choose a different optimization. CS !== Programming
- turdprincess 4y ago
  On my last team, I had an incompetent junior engineer. It was a time suck to do hold countless pairing sessions with them, answering the same questions again and again without having them learn anything. 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.
jghn 4y ago
Yeah I struggle with this meme. Have been in the industry for nearly 25 years at this point. Never once have I had a colleague who straight up couldn't code. I've seen a number of crappy devs, but they could at least do soething. 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
- jjav 4y ago
  > Yeah I struggle with this meme. 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.
- deleted 4y ago
  [deleted]
bstpierre 4y ago
I wouldn’t say it’s a large proportion, but I’ve seen this at multiple companies over the course of 25 years. It manifests in 2-3 different ways that I’ve seen. 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.
ckdarby 4y ago
This is my experience as well. A large portion of hires can barely program. There is also a portion of hires that are 20-40% more than market, but yield more than double the outcome. 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.
- solardev 4y ago
  I wonder how much of this is just commonplace in any industry. Isn't mediocrity to be expected if people are, on average, well... average? When I walk into a bank I don't expect them all to be the best bankers in the world. Most of the restaurants I go to are fine, not earth shattering. Houses are built by crews of various competence. Government is run by the inept. Militaries are staffed with cannon fodder. Etc. 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.
  - tharkun__ 4y ago
    I don't think anyone is saying that being average is bad. At least I'm not. My problem with these people is that the average is such a low quality of work and work ethics. 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.
closeparen 4y ago
If you’re good at LeetCode, you can just get a new job every 1-2 years before your actual job performance catches up with you.
coredog64 4y ago
Not OP, but I can share my experience. Worked with two other people on a data lake project and their Python code was full of weird stuff, like if you just copy/paste SO snippets into the project. They eventually got outputs but the code was all-but-unmaintainable. (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.)
infinitezest 4y ago
I hope this remains a "myth" for you. I can assure you that it can be quite painful to deal with and take a long time to remedy.

foolinaround 4y ago

> 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. 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.

flaviut 4y ago
I've worked with several of these low code/no code things. It does not pan out. Syntax is the easiest part of being a software engineer.
- baq 4y ago
  So very much this. 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.
- vitiral 4y ago
  "Syntax is the easiest part of being a software engineer." 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.
  - twawaaay 4y ago
    Oh, so you discovered Lisp. Congrats:)

odyssey7 4y ago

> 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 "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

twawaaay 4y ago
Oh, yes, this quote I lacked. 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.
- tome 4y ago
  "One person losing their job is a tragedy; a million is a statistic" -- Not Stalin

thenerdhead 4y ago

Totally agreed. Companies were over leveraged when we started seeing the excessive hiring during a prosperous time. The fact that most layoffs ranged in the 10-20% range and the similar company growth during that time speaks very loudly. This was less of a end of an era, and more of a temporary correction.

b20000 4y ago

barely program at all? looks like leetcode is bot getting the right people hired after all?

twawaaay 4y ago
Programming a short example that you trained to do for a long time when exercising for interviews is one thing and figuring out how to modify a large application in a desired way is completely different.
- b20000 4y ago
  exactly
b20000 4y ago
bot => not
therealdrag0 4y ago
Do You think that problem didn’t exist or wasn’t worse before leetcode?

kennend3 4y ago

> My experience is also that large proportion of hires can barely program at all 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

twawaaay 4y ago
I have quarter century of experience in software development and have been programming most days for the past 30 years. Can't say how I am stacking up against developers with same level of experience but I can say with no exaggeration that I do, in fact, have more experience and more valuable skills (as I am routinely called to help with failing projects) than most developers I am working with. Saying otherwise would be just false modesty. 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".
- kennend3 4y ago
  > Also stating that there exists something like "illusory superiority" does not mean there does not exist "superiority". Yeah, I also studied theoretical math. 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?

dylan604 4y ago

>There are multiple reasons why these people got successfully hired (broken hiring, enormous pressures, etc.) 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

solardev 4y ago
Isn't a lot of milkshake going to spill and melt while you keep going back and forth with it?

jjeaff 4y ago

Earnings reports are out and FAANG companies are showing drops in revenue. So I don't think their layoffs are entirely due to over hiring or simply using a looming recession as an excuse.

lamontcg 4y ago

> Nothing further from truth. 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.