[OmarShehata]

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

[bstpierre]

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.

[Pepe1vo]

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.

[turdprincess]

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.

[adolph]

> 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

[jghn]

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]

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

[nevon]

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]

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]

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]

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

[closeparen]

Given how short tenures are across the board, those of us who are even around to notice long term outcomes are sort of wierdos to begin with. Many senior and staff engineers, architects, directors, etc. have never seen their own work 2 years down the line. Even if they stay at the company they switch teams, etc.

[kaidon]

> deteriorate productivity in ways that will be difficult to understand

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.

[twawaaay]

That's why my personal favourite tool to manage this is pair programming with people. I do pair programming for interviews and I do longer (at least a week) pair programming projects with all my devs at some point.

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

[bratbag]

I've had one. I put them on a pip and they found a more senior role at another company.

Good luck to their new manager.

[vervez]

So you `pip install`ed them at a new company? I'll see myself out.

[coredog64]

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

[ckdarby]

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]

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__]

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.

[solardev]

Maybe I've just been lucky, but I've never actually seen one of these in the wild (a supposed programmer who can't code even mediocrely). Even the interns at my current job are pretty proficient (and better at some things I am!). And in the right cultural atmosphere, people support each other and help them learn and grow... they don't stay a beginner for long.

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.

[tharkun__]

One reason could be that our "bars" are different. I say that because you said:

    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

I sense that your bar might be quite a bit lower than the bar I would apply, solely based on that comment. If you think doing the bare minimum is OK, your bar very likely is below the bar that I set. While it's hard to actually define and talk about the standards we think are to be met or not, here is one thing I value and that thus goes into the bar.

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

[solardev]

Points taken, but I also wonder how much of this is due to our dysfunctional work culture (as a society) where people are so detached from their jobs it feels like they're just an invisible cog in some big machine.

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.

[SamuelAdams]

Do you not have internal coding standards / guidelines? Ideally this is what a PR process is for - reviewing new code and making sure it adheres to the team’s expectations.

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.

[tharkun__]

I don't know why you mention this in reply to my comment. I don't see how this is related.

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.

[closeparen]

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.

[hasmolo]

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]

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]

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

[twawaaay]

FWIW: I don't do tests because of how I learned programming writing large swaths of code for weeks that had then to work perfectly the first time (embedded C on a machine with very poor development process and external company that had to sign the binary before I could run my code). I taught myself rigorous thinking about code and various techniques that make it less likely that there is something wrong with it, otherwise I would be loosing a week before I got another chance to run it. I also then worked in a lot of projects with poor code quality and no test coverage that I had to run extensive refactors of and keep hammering on until it looked decently. With this in mind, unit tests have never been useful to me in any way and would be just a waste of time because they would not bring any benefit to anybody else I worked with.

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.

[adolph]

> otherwise I would be loosing a week before I got another chance to run it

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.

[solardev]

In my experience, new teams just tend to rewrite everything anyway. We have this cultural delusion that we write code for posterity when in reality it rarely lasts more than a couple years no matter what. Technology changes too quickly.

[infinitezest]

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.