5 ms·

The author is leaving unstated what we all know to be true: most of these jobs aren't really that hard. You don't really need the people with pedigreed CS backg

The author is leaving unstated what we all know to be true: most of these jobs aren't really that hard. You don't really need the people with pedigreed CS backgrounds, but it's easier than actually figuring out how to screen candidates. The "pipeline problem" is the pipeline itself. So you have to go around the pipeline by avoiding the formal education system, which is where the bias is observed.

ajross 7y ago
That's not quite right either, because if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds. In fact engineering jobs are hard, and there is a big spread in candidate quality. The issue is that heretofore the best proxy for candidate quality is educational background, hence the pipeline problem. And you definitely fix that by going around the pipeline. But we shouldn't be blind to the fact that this has costs. You need to see a lot more bootcamp grads than Stanford alums to fill the same position. It's a cost worth bearing, but still a cost.
- TeMPOraL 7y ago
  > if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds Note that the same argument works as evidence against recruiting bias and pay disparity. Discriminating against people or paying them less due to factors unrelated to job performance is leaving money on the table. Such discrimination persisting would imply that the market is very inefficient in this aspect.
  - someguydave 7y ago
    The fact that many of the web companies want to crowd everyone in a few hundred square kilometers of the Bay area demonstrates that they don't know what they are doing and are leaving money on the table. That doesn't disprove the fact that women are somewhat more uninterested in pursuing those jobs than men are.
- stale2002 7y ago
  > because if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds. This is literally what is happening at many companies, quite often. I know so many female developers who have, in the past, said things like "Oh, I'd never work at Uber". And because of this, Uber has to pay their engineers a lot more money, because they can't attract any female employees. Skiping on diversity initiatives is not just immoral, it is dumb. And you will lose money because of it.
hinkley 7y ago
The problem is that if you give a rocket engineer the job of opening a pickle jar, you are forever in danger of them doing something titanically ornate, instead of just opening the goddamn jar or installing one of those toothy wedges under a cabinet near the fridge, where people can still function normally if they forget it's even there. The one time I worked on a team of all highly senior people you couldn't get any of us to do anything. We were always writing code to do the thing for us. Which sounds okay at first, until you started trying to trace through all that code and then holy shit, we have made a terrible mistake. On any project there is a mix of tasks that are perfectly suited for mid-level developers, and a set of tasks that are interesting enough but relatively low risk that you can use to train up low- and mid-level people for something meatier. Many of those tasks are also perfect for introducing new team members too. If you aren't constantly trying to make 90% of the tasks simple enough for a boring team member to do then I don't know how you prevent the overall complexity of the system from eventually swamping you all. There are systems that look like they avoid this but if you look hard enough there is almost always one or two people who are holding the system hostage, and if they don't want something done to the system, it's not getting done, no matter how many customers leave. Eventually power overshadows merit and you get an oligarchy instead of a democracy.
- TeMPOraL 7y ago
  > If you aren't constantly trying to make 90% of the tasks simple enough for a boring team member to do then I don't know how you prevent the overall complexity of the system from eventually swamping you all. One has to keep in mind that the things should be as simple as possible, but no simpler. Otherwise, you risk ending up with the stereotypical low-skill Java Enterprise shop, where inexperienced and not particularly skilled developers end up writing (or autogenerating) code by kilolines, where if someone better trained were to stop and think for an hour, it could all be done in 100-1000x less code, and with similar improvement in maintainability.
  - hinkley 7y ago
    Yes, and for me the happy ratio is around a 90:10 split. There is a time and place for really sophisticated code, and people will just have to expend some effort to understand its behavior at least, if not in fact how it accomplishes it. If that's leaking throughout the system then it's likely a code smell. I'd like to reiterate that the statement you quoted was made in the active voice. It's a process. As you add things to the system you should be looking at all of the pain points around it and amortizing the cost of addressing those issues. If you don't arrive there around the time the system begins to gel, but before calcification, you will never arrive. But if you try to get there from day one, you'll pick the wrong priorities and you'll certainly end up in that Enterprise hell you mention. What I see happen is that people grow with the project, memorizing one thing after another without ever appreciating the weight of it all, and then one day they have to hire more people because someone left, and all of a sudden they're terrified of letting that person do any real work. Because how could they know? Absolutely no effort has been expended setting new people up for success, and the token efforts feel more like sabotage than help. Then it takes years of their lives to memorize all the same stuff and really, I believe you should be investing that time in something more worthwhile. I'm living through that again and it's every bit as bad as I remembered.
commandlinefan 7y ago
> most of these jobs aren't really that hard This is a popular trope among non-programmers, and I can see why they’d like it to be true (it would make hiring a lot easier!) but actually yes, these jobs _are_ that hard. They’re hard because they’re constantly changing. Environments change, languages change, tooling changes, team structuring changes… and the programmers have to keep up. What may have been easier for, say, a self-taught PHP developer who doesn’t really know how databases work, or how networks work, or how operating systems work, or how HTTP works, ten years ago is much harder for that same developer without a decent grasp on the fundamentals trying to get their head around, say, React. There are easier jobs in “tech” like project management or testing, but developing software isn’t one of them.

ajross 7y ago

That's not quite right either, because if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds. In fact engineering jobs are hard, and there is a big spread in candidate quality. The issue is that heretofore the best proxy for candidate quality is educational background, hence the pipeline problem. And you definitely fix that by going around the pipeline. But we shouldn't be blind to the fact that this has costs. You need to see a lot more bootcamp grads than Stanford alums to fill the same position. It's a cost worth bearing, but still a cost.

TeMPOraL 7y ago
> if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds Note that the same argument works as evidence against recruiting bias and pay disparity. Discriminating against people or paying them less due to factors unrelated to job performance is leaving money on the table. Such discrimination persisting would imply that the market is very inefficient in this aspect.
- someguydave 7y ago
  The fact that many of the web companies want to crowd everyone in a few hundred square kilometers of the Bay area demonstrates that they don't know what they are doing and are leaving money on the table. That doesn't disprove the fact that women are somewhat more uninterested in pursuing those jobs than men are.
stale2002 7y ago
> because if these were truly easy jobs someone would have figured that out and won by hiring cheap developers with non-traditional backgrounds. This is literally what is happening at many companies, quite often. I know so many female developers who have, in the past, said things like "Oh, I'd never work at Uber". And because of this, Uber has to pay their engineers a lot more money, because they can't attract any female employees. Skiping on diversity initiatives is not just immoral, it is dumb. And you will lose money because of it.

hinkley 7y ago

The problem is that if you give a rocket engineer the job of opening a pickle jar, you are forever in danger of them doing something titanically ornate, instead of just opening the goddamn jar or installing one of those toothy wedges under a cabinet near the fridge, where people can still function normally if they forget it's even there. The one time I worked on a team of all highly senior people you couldn't get any of us to do anything. We were always writing code to do the thing for us. Which sounds okay at first, until you started trying to trace through all that code and then holy shit, we have made a terrible mistake. On any project there is a mix of tasks that are perfectly suited for mid-level developers, and a set of tasks that are interesting enough but relatively low risk that you can use to train up low- and mid-level people for something meatier. Many of those tasks are also perfect for introducing new team members too. If you aren't constantly trying to make 90% of the tasks simple enough for a boring team member to do then I don't know how you prevent the overall complexity of the system from eventually swamping you all. There are systems that look like they avoid this but if you look hard enough there is almost always one or two people who are holding the system hostage, and if they don't want something done to the system, it's not getting done, no matter how many customers leave. Eventually power overshadows merit and you get an oligarchy instead of a democracy.

TeMPOraL 7y ago
> If you aren't constantly trying to make 90% of the tasks simple enough for a boring team member to do then I don't know how you prevent the overall complexity of the system from eventually swamping you all. One has to keep in mind that the things should be as simple as possible, but no simpler. Otherwise, you risk ending up with the stereotypical low-skill Java Enterprise shop, where inexperienced and not particularly skilled developers end up writing (or autogenerating) code by kilolines, where if someone better trained were to stop and think for an hour, it could all be done in 100-1000x less code, and with similar improvement in maintainability.
- hinkley 7y ago
  Yes, and for me the happy ratio is around a 90:10 split. There is a time and place for really sophisticated code, and people will just have to expend some effort to understand its behavior at least, if not in fact how it accomplishes it. If that's leaking throughout the system then it's likely a code smell. I'd like to reiterate that the statement you quoted was made in the active voice. It's a process. As you add things to the system you should be looking at all of the pain points around it and amortizing the cost of addressing those issues. If you don't arrive there around the time the system begins to gel, but before calcification, you will never arrive. But if you try to get there from day one, you'll pick the wrong priorities and you'll certainly end up in that Enterprise hell you mention. What I see happen is that people grow with the project, memorizing one thing after another without ever appreciating the weight of it all, and then one day they have to hire more people because someone left, and all of a sudden they're terrified of letting that person do any real work. Because how could they know? Absolutely no effort has been expended setting new people up for success, and the token efforts feel more like sabotage than help. Then it takes years of their lives to memorize all the same stuff and really, I believe you should be investing that time in something more worthwhile. I'm living through that again and it's every bit as bad as I remembered.

commandlinefan 7y ago

> most of these jobs aren't really that hard This is a popular trope among non-programmers, and I can see why they’d like it to be true (it would make hiring a lot easier!) but actually yes, these jobs _are_ that hard. They’re hard because they’re constantly changing. Environments change, languages change, tooling changes, team structuring changes… and the programmers have to keep up. What may have been easier for, say, a self-taught PHP developer who doesn’t really know how databases work, or how networks work, or how operating systems work, or how HTTP works, ten years ago is much harder for that same developer without a decent grasp on the fundamentals trying to get their head around, say, React. There are easier jobs in “tech” like project management or testing, but developing software isn’t one of them.