While on the surface of it, sure, programming is a skill and not an innate talent, it would be foolish to compare it to other career fields in that way. You can go to school to learn how to be an architect, then go and get a job as an architect and be immediately productive. You can go to school to learn how to lay bricks, then go to a job site and immediately start building something.
You cannot go to school to learn how to be a programmer, and then expect immediately to be productive at any arbitrary programming job, unless you're a talented coder. The education gap is too great. It's like medicine in which you need a few years of residency before the medical field considers you fully competent.
If you go to code school and learn Rails and React, then you can expect to be somewhat immediately productive on a Rails / React project. You can't expect anything out of them if it's not a Rails / React project. They may be able to ramp up quickly, if they're talented. If they're not talented, then they won't be able to, and the employer has to take the hit.
We will need a revolution in software development pedagogy before individual aptitude stops mattering to employers. The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals. Try that with medicine!
> You can go to school to learn how to be an architect, then go and get a job as an architect and be immediately productive. You can go to school to learn how to lay bricks, then go to a job site and immediately start building something.
Do you actually know anyone who's worked in these fields? Because that's not true. Wanna be an architect? Go to school + get 2 years of experience + take a professional certification THEN you can be employed as an architect. Wanna lay bricks? Get a job and you'll be taught there.
I've never laid brick, but I've been an electrician. Tradesmen are almost never working independently, and certainly not when they are working in a junior position. There's a lot of mentorship that goes on, and a lot of tribal knowledge that's shared - things that are simply not written about.
When I started as an electrician, I knew a lot about electricity already. I've always been a bit of a nerd and knew more about how electricity actually works than many journeymen I met. I knew almost nothing about how to actually put that into practice, though.
For example - when wiring an electrical outlet, you have to wrap the end of the wire around a small screw. It's obvious enough that if you do it clockwise tightening the screw holds the wire in place; if you do it counterclockwise, tightening the screw moves the wire and makes life difficult. What wasn't obvious was that instead of taking a pair of needle-nosed pliers and bending the wire to the right shape, there was a small hole in each side of a pair of wire strippers that was exactly the right size to do it: http://www.kleintools.com/sites/all/product_assets/catalog_i...
Had the person I was working for not shown me that, I would have probably never figured it out.
I think the role of a junior developer is very similar to that of an apprentice electrician, in that the dev knows at least enough to implement something on their own so long as they are given concrete tasks. A mid-level dev is similar to the journeyman; they take a partially-defined task, break it into well-defined chunks, and either implement or delegate. A senior dev is the master electrician - they decide what tools to use, make the larger-scope decisions on a project, etc.
This analogy breaks down once we start talking about software "engineers" or "architects". I can't really think of anything I saw in the trades that maps to it; it's more about identifying and anticipating important changes over time and mitigating their costs.
While I totally agree with the things you said and that talent does play a factor, but I feel like playing devil's advocate here a little bit and point how that you can replace every instance of "talented" with "dedicated" and what you said still works.
That's outside of an employee's ability to decide to be. The business has deadlines and needs, and writes the checks, so it's up to them to decide how long it takes for an employee to become a net asset for the company.
Right, but I meant more along the lines of dedication in that the employee spends their free time outside of work, studying, experimenting, and learning. This can drastically reduce the ramp up time and has nothing to do with natural ability.
A talented employee might be able to spend less time outside of work, but a dedicated one can be just as competent in the same amount of time. If you have a developer who has both, then obviously that would reduce the ramp up time even more.
I dunno, I've seen people try to do this, and they either really really struggle, or don't and never get to that point. People who aren't talented really do need their hands held, self study just won't ever get them there.
Being able to switch from a table saw to a miter saw isn't talent.
It's learning how to separate alike from different, using what you know to use something different. It's also realizing that languages vary, but you can learn the underlying concepts and apply them.
Being able to take general programming knowledge and apply it to multiple languages and projects is something you learn.
Talent may help you to learn the concepts and be more versatile, but that doesn't take away from the article's message of the typical distribution curve. This focus on "general programming skills" is fine, but lets not pretend it's "talent", because that's the whole myth!
> The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals.
I'll try that in medicine. Talented midwifes were delivering babies in the 1900s. Since midwifery is still a thing, maybe medicine is not as far advanced as you imply.
Seems like talent still plays a big role in any field.
The midwives who worked with my wife are full nurses with an additional two years of med school. They are very quick to point out that their main job is to recognize the 10% of the time when there is going to be trouble and get a better trained doctor involved.
Note that you can find "midwives" with less skill than the 1900s midwife. There are a lot of quakes out there doing awful things and getting by with it because ~80% of the time you don't need any medical intervention.
Did you ever consider that the employee might be a smidge less likely to walk out the door if the employer invested in him or her, recognized his or her achievements in a timely manner with responsibility and authority (promotion) and compensated him or her fairly?
Seems to me employees "are likely to walk out the door" mainly because employers view them as expendible expenses and not humans trading labor for something of value
Sure, but that still doesn't make it an investment, it just makes it a less risky bet. And betting on people being high-minded over being selfish has always been a bad one.
Well, yeah, that's what it means, right? If you pay me $50k per year and invest $20k of company resources to train me, and the second my training's up, I jump ship to a company promising to pay me $60k, wouldn't you feel ripped off?
Nobody these days would turn down a $10k raise out of company loyalty. They might for other reasons, but loyalty is absolutely not one of them anymore.
The right thing to do is to start transitioning the $20k you were spending training the new guy into salary as he acquires the skills.
Its stupid to spend the $20k, figure its "done" and then think you can just go on paying the $50k after the fact even though the employee is clearly now worth $70k.
You want a $70k talent, you can either find one straight up or make one with some mix of lower salary + training until you have one.
If you hire someone for $50k, then train them with $20k, then give them a raise after the training is over for the $20k it takes to bring their comp up to market, you're out $90k. Accounting-wise, you just gifted the employee $20k on top of his comp.
Or you can just go out and hire for $70k and just be out $70k. This is what's already being done, shifting the cost of training and education onto the ones receiving the benefits of that training.
I'm trying hard to not post a diatribe about what's wrong with this kind of thinking and just point out the errors in reasoning that come from it, but this game of whack-a-mole is frustrating. You can't demand your employer to shoulder all the risks and grant unto you all the rewards. It's unethical and leads to underhanded dealing. We want a more professional labor marketplace, not one governed by promises and half-truths.
The employer's reward in this scenario is more than $20k in value provided by the newly trained employee. The risk,10 of course, is through employee leaving before the employer can realize the reward fully. It's interesting that you don't see it that way, and that you think it's an error in reasoning.
I don't know why I let myself get sidetracked into this worthless ideological discussion.
Final answer, then I'm getting back to work. Because when you take risks, you should expect a reward. If your reward isn't worth the risk, but you still take it anyway, then you're the dumb one. When you're the one offering liquid compensation, you get to decide on the risk profile of the bought solution.
e.g. if a company invests in a building for their office, there's always a risk that building will incur excessive maintenance expenses, become unusable because of some calamity, or that the location around the building will become a bad neighborhood and make that building a lot less useful.
i think a company can invest in, say, teaching their employees a valuable skill and then make money off that investment, even if the employee leaves eventually.
You can insure against risks. You can't against bets. Good luck getting an insurance company to sell you a policy covering training cost recovery in the event of employee-initiated turnover.
i feel like we're playing word games. "risk" vs. "bet."
the distinction you raise is that there (apparently) is no such thing as an insurance policy that protects a company against a valuable employee's departure.
but that doesn't mean "invest" is the wrong word to use when a company spends money to educate an employee.
also, there are strategies aside from a literal insurance policy which companies can and do use to increase employee retention rates. (just like there are strategies other than insurance policies that companies can use to protect a building against damage or loss of value.)
Self-insurance against the risk of employee defections costing them time and money is exactly what employers are already doing, by not taking on the risk of educating and training employees.
You can hedge your bets in many different ways with different assumptions for likely outcomes. For example, if you think it likely that your employee won’t hang around for very long, then you can act by treating them as disposable. You could also choose to mitigate the risk of them leaving if you thought you could be successful at it. Both approaches are forms of self insurance, none of them are full proof, and they can also lead to self fulfilling prophecy problems.
Yes, but the difference between an investment and a bet involves the amount and type of risk. Investments generally don't disappear. Bets do.
Also the expected rewards are higher too. If a company bets $20k in an employee, the best they can hope for is that the employee does a good job. Not that that bet doubles in value.
> If a company bets $20k in an employee, the best they can hope for is that the employee does a good job. Not that that bet doubles in value.
What do you think it means from the company's perspective to "do a good job"? A developer who does a good job will most likely double that $20k in a few months.
Apprenticeship has been a thing as long as professions have existed. A common way to justify training an apprentice is to indenture them - they agree to work for you for a set number of years at a given wage, in exchange for training. Then you get professional organizations who negotiate on behalf of trainees/apprentices to make sure that the training wages are fair and the conditions aren't too onerous. Membership in the professional organization is contingent on keeping your indentureship agreements. Programming is such a young profession that we don't have any of that, and I think we need to evolve it.
Pro athletes are a terrible example. There has been decades of litigation, lockouts, negotiations, etc. across almost all leagues to get to where we are now and there are many that continue to think the system is too restrictive for the players and too much in a league's favor.
I'm surprised that no employers even offer this as an option when hiring.
There might be some legal barriers to this problem like recovering the investments when the employee breaks the contract? Seems like some kind of insurance would help there, though.
I asked my last employer about this and they said that no contract can bind an employee to a company. Any contract would be one-sided in favor of the employee. Seems obvious when you think about it. Indentured servitude is wrong.
Maybe knowledge work is also special. Arguably medicine is a form of knowledge work. And it's not exactly a small or especially niche sector of the economy.
How good is the documentation and process on your team?
Any place I work, it’s easier to train my replacement than it was to train me. It allows me to pick up new projects or leave for a more interesting opportunity without guilt.
Work yourself out of a job.
It definitely means I’m easier to lay off. But I’ve survived 2 rounds of layoffs before and buddy, if you can figure out how to pay your mortgage without a front row seat to watch a company crumble around you then I highly recommend it. (Also only the 1st round offers a decent severance package, and survivor guilt is no fun).
Personal finances help with that. As do maintaining relationships with people.
You cannot go to school to learn how to be a programmer, and then expect immediately to be productive at any arbitrary programming job, unless you're a talented coder. The education gap is too great. It's like medicine in which you need a few years of residency before the medical field considers you fully competent.
If you go to code school and learn Rails and React, then you can expect to be somewhat immediately productive on a Rails / React project. You can't expect anything out of them if it's not a Rails / React project. They may be able to ramp up quickly, if they're talented. If they're not talented, then they won't be able to, and the employer has to take the hit.
We will need a revolution in software development pedagogy before individual aptitude stops mattering to employers. The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals. Try that with medicine!