At first I was annoyed by your comment, but then I realized how true it is and sulked instead.

The good consultants are leaving as soon as they hit the end of their first promotion cycle. The duds stick around and assume the upper-level manager roles. The group is in bad shape now and poised to get worse in the coming years.

Services Profit = Bid - Employee Cost + Upsales

Bids are only so flexible. Employee cost is much easier to minimize. So inevitably, all consultancies trend towards providing the cheapest employees that will satisfy the customer. And if the customer isn't constantly vigilant, the quality can get pretty dire indeed (BAs who just learned to "code" yesterday).

Depending who you get this could be an upgrade. I've met some damn good Indian programmers who work for contracting shops (and, sadly make way less than they would in the states). But, I've also met some who literally don't know how to code.

Fundamentally, the problem is that these firms are used for work that is not valued by either the customer or the implementor. The primary concern is cost. If you are a developer for a tech company working on core products, you drive revenue and are important. If a feature you implement is marginally better than the competition, your firm can win the market and, due to economies of scale, the revenue gain will be huge. Because revenue is sensitive to small differences in quality, you want the best possible developers that you can afford.

As a result, developers viewed as part of the firm's comparative advantage are paid well and treated well. But if you are a DBA working at walgreens, then you are not a part of the comparative advantage of the firm. If you are marginally better at your job, revenues will not go up. You are a cost that will be outsourced in a heartbeat if the firm could save a dollar. Or like doing landscaping at Google. Regardless of how awesome Google is, they are going to look at their landscaping expenditures purely as a cost. Revenues will not go up if you do a better job. Thus they don't care about getting the best possible landscaping, they want adequate landscaping, like water running out of a tap.

That's the type of work that is passed on to these outsourcers. It may be technical in nature, but there is little to no perceived marginal gain in the work being of a higher quality than the minimum amount necessary to be fit for use: maintenance of products that companies no longer want to invest in, but they have service contracts in place that require maintenance. The goal is to minimize cost while not breaching the contract. Or bespoke work in the B2B space where you don't get the type of economies of scale that result in a meaningful revenue bump when one particular piece of code exceeds expectations. In all these things, the driver is the cheapest talent such that the output is adequate.

That means that these jobs are not rewarding to the developers who do them, and so these firms have huge problems with turnover and keeping good developers motivated. Those developers who remain are the ones who don't mind working on code that no one cares about, being paid poorly to do it, and being treated as expendable. In other words, the least motivated, passionate developers are the ones who remain. It is no wonder that they will tend to be the least talented.

Truth. I've noticed many contractors take specs _very_ literally. While that might be good in that the result won't be _wrong_, the product usually becomes quite brittle and can't "scale" well.

BPO / offshoring is a whole other can of rotten worms.

This is sometimes referred to as the 'Dead Sea Effect'.[1]

The same way that water carries salts and other minerals to the Dead Sea, and then the water evaporates while the salts accumulate.

Similar effect with hiring a mix of good and bad people, and over the time the good ones leave because they have options while the bad ones stay and accumulate.

[1] http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

There's so much I could say about the crap I found (and if someone asks I'll be happy to!), but I can summarize it by saying that it was bad even compared to the what I've come to expect from WP sites that are plugin- and WYSIWYG-layout-builder-laden, to the point of being utterly unmanageable from the WP backend interface, even on a local setup, because just exploring the ridiculous custom interface pages take ages to load.

I truly cannot imagine this code being written by anyone but a lowly, unsupervised intern at this company. And yet, based on my experience, it was probably just some 'regular' employee, unnoticed by his manager, and his manager, and the client none the wiser because how should he be able to assess competence.

That being said, if they weren't trying to eke every microsecond of performance out of the system, then that's pretty poor design, maintainability wise.

She wasn't trying to eke every microsecond. There were some smart guys on our team, and we were all afraid of that code! The programmer who wrote it would fire back about her Mathematics PhD if you ever tried to bring up Object Oriented design. When I was there, she would sit in the cafe downstairs eating a sandwich, until something broke. She wrote herself fantastic job security!

After two full weeks of him quietly 'working' at his new MacBook, I got a bit suspicious about the fact that he'd not asked for help once. So decided to check up on him and ask him how he's settling in with the codebase and if he could use any help.

He opened up his editor to show me something he was struggling with. I gave some suggestions (look at this code here, do something similar).

After some back and forth it became clear that: 1. he was entirely unfamiliar with Ruby On Rails 2. he had no idea how to use a Mac 3. he had not bothered to learn how to use a mac while sitting at his desk for eight hours a day for two full weeks 4. his approach to copying some existing code and then changing it for the new use case involved mostly clicking through the Edit menu. He was less familiar with keyboard shortcuts than my mom and her mom. CMD-C was not in his vocabulary.

He was let go shortly after, but of course he did get a full month's pay, an amount that would comfortably support the frugal freelancer for at least another three months.

Honestly, I'm mostly thankful for this situation. It cured a decent amount of my 'impostor syndrome'. It also left me wondering how these kinds of things happen.

This company was one that lots of good developers would want to work for, in one of the most desirable cities in the world, and they were constantly in need of good developers. I was baffled by the mismatch between what the market offered (plenty of good developers, more than most cities) and their constant need for developers, to the point of hiring this guy and not realizing that he didn't know the basic copy and paste keyboard shortcuts until two weeks in.

When I got into the group, I was asked to do stuff I had never done. Okay, I start to learn it, but slowly.

Then I was reorged into a different group, doing stuff I had never done. Okay, I start to learn it, but slowly.

Then I was reorged into a different group, now I'm a Developer, when I've never programmed professionally before.

I am far far worse than my colleagues at even simple tasks. It's not that I'm not trying, I'm working tons to try and learn data structures, and programming to be able to complete my job.

But it would be entirely valid for my coworkers to feel the same way about me, as you describe about this guy.

It's likely going to take another 4-6 months before I'm competent at my job. Will my colleagues still care at that point? Will I be reorged into another position by then? Who knows?

And I'm an expert at many fields, just none of the ones I'm being asked to do.

I'd leave, except my colleagues are great, the topics are great, and if someone is going to pay me to learn how to be a proper developer, I'd be stupid not to do this.

But it's hard as fuck, and I'm certainly not pulling my weight.

I do think that he might've had a chance (perhaps downgraded to a junior position) if he'd shown willingness to learn though. The fact that he just sat there for two weeks pretending to be busy was the primary reason he got let go.

Hell, I spent time stuck on a problem because I had never used code folding before, and couldn't find the import statements I needed to edit.

Would you agree that not understanding code folding is a bit much?

I'm not defending the particular individual, or the situation, only giving some context to my comment.

Not knowing the copy and paste keyboard commands is a completely different realm of incompetence!

But you're right that lots of developers don't know many keyboard commands. I was being a bit too broad. Personally I can't imagine how any programmer would not bother learning keyboard shortcuts (or even better vim keybindings), but I've met plenty who didn't.

That being said, while using the 'edit' menu to copy/paste is clumsy, I don't see that it would actually have a significant effect on someone's productivity. So I would not go so far as to say that someone was incompetent just because they did that.

The ones that do stay in that environment either have golden handcuffs or are goddamned patriots and love the challenge. I like to think many are the latter as government is an amazing place to do impactful work that is too important to screw up.

Update: I’m not saying this is a good thing, just an industry observation.

It's somehow really counter-intuitive and uncomfortable to challenge someone's honesty openly, maybe?

For example, I can be relatively rude and direct (without meaning to be about half the time), but when someone tells me a story that strikes me as unlikely or heavily embellished, I feel really uncomfortable challenging the story, because it's tantamount to saying "you're lying".

In the situations where I was 'conned', in hindsight I could have probably found ways to test the person involved surreptitiously. It just didn't enter my mind to do so. But openly challenging them just felt wrong to me, and it still does, because if you're wrong you just accused someone of lying.

So these days I make a game out of finding ways to surreptitiously test the people around me. I often forget how useful that approach is (trust, but test), and I guess your comment reminded me to apply it more.

Whether its a good plan to challenge someone's honesty actually has nothing to do with whether or not that person is lying, even if I have certainty and evidence. The question is: what is the best thing I can do for my life? If my accountant lies to me, I will call the police. But if someone turns out to not be skilled as claimed? It depends on context.

It doesn't advance my life to tear down someone else; the best thing I can do is try to build my own understanding and take action. My approach is to be curious, actively listen, and ask clarifying questions. This can be as simple as saying "tell me more about that." Once I have enough information and context, I can judge claims and ideas directly.

It's not about tearing down someone else, it's about assessing the validity of someone's statements.

I might have presented it as more suspicious/antagonistic than I meant. My actual approach is pretty much as you describe in your last paragraph.

Basically, my approach to 'new humans' is the biblical adage: "be as shrewd as snakes and as innocent as doves", because I do believe, as in the biblical context, that good people are sheep among wolves. I try to be a good sheep, but I know for a fact that I can't handle wolves without being clever.

So far it works pretty well for me, but I've found it difficult sometimes to explain how I try to be both a sheep but shrewd, calculation but not shrewd or manipulative.

That said I’ve witnessed plenty of cringeworthy moments watching members of the MIT community deal with guest speakers during Q&A.

In corporate environments that I've experienced, the otherwise very argumentative developers would never actually challenge Employee No. 9610 in their basic skills. There's a formal distance in every interaction, pros and cons.

But in the few startup environments (<15 people) the culture was much closer, and there's no way that they would not have been 'caught' very early on, probably even in the first interview.

Even the nicest manager and teammates in the world don't have to proactively call someone out on being incompetent if every sprint their tickets are going unfinished, etc. And with the tooling, it's an automatic paper trail.

I think everyone is going to get a lot quieter, as you don't know who's listening.

You can’t realistically look at engineering culture and say wow here’s a sympathetic bunch who stay quiet when they see something wrong. Just read what industry leaders Richard Stallmen or Linus Torvalds write.

Exactly. Between my freelancing and full-time experience, I've been involved with dozens of teams. Very few of them react well when you question their abilities, no matter how fair and justified the question.