Business Can Pay to Train Its Own Work Force
chronicle.com
chronicle.com
Industry processes are mostly fads that change with wind. CS fundamentals however, are much more stable. 20 years from now knowledge of automta, graph theory, and complexity analysis will still have immense value--a scrum master certification won't.
Industry fads aren't useful outside of industry, so learning them should be paid for by industry. As the article argues, 20 years ago they were. Now employers are trying to push the cost of vocational training onto workers and the public.
There hasn't been enough work serious research done on "Software Engineering" to call Engineering with a straight face. You can't point a whole stack of serious research to say the design pattern A is objectively better in situation X because Y and Z.
What you can say is that design pattern A is currently in vogue so you should probably use it, while design pattern B has fallen out of favor in industry, so you should avoid it.
That is something that belongs in a vocational training program or an internship/apprenticeship not in a university Computer Science education.
They also aren't based on any formal theory. They are based only on the experience of the people who create them. They are almost the definition of a craft (as opposed to engineering).
In an actual Engineering discipline you would need evidence to prove that your model fits reality as opposed to just trusting the experience of a few guys who wrote a book.
They keep people from re-inventing nearly identical solutions over and over, and allow for a vocabulary which can express rather complex ideas because fellow practitioners of software engineering generally know many of the same design patterns. This saves time and reduces the opportunity for miscommunication when expressing a more complex idea (assuming the person you are talking to doesn't lie and for instance say they are familiar with the facade pattern, when they are not).
To me this is using them to both get and express a better understanding of a complex system. I am also able to understand code for new projects I am to work on much quicker when I understand the underlying design of the elements. When the elements are designed with a structure that resembles things I am familiar with this process becomes fairly easy.
I see them as things like definitions of 'Suspension Bridge', 'Victorian House', 'Tunnel', or 'Dog House'. Sure we might see a book consisting of very rudimentary definitions of structures like these as being absurd, for the corresponding type of engineer, but that is because of our familiarity with the form these structures take. That familiarity with the form is the point of design patterns in my opinion. And I believe their utility is indispensable should we want to continue building more complex structures in code.
However, design patterns are craft, not engineering, and should be taught as vocational training--not as an academic subject.
Design patterns have no rigorous underpinnings. They have very little academic research to back up their efficacy. The only "proof" we have that the design patterns being taught are beneficial is the word of a few guys who wrote a book and the collective folk wisdom of industry.
There is nothing wrong with this, but it isn't firm foundation for an academic subject.
> "They keep people from re-inventing nearly identical solutions over and over"
No, they force users to rewrite the patterns over and over again, since a pattern is an idea that a given language is not powerful enough to abstract over. Cf. opinions on the C2 wiki.
Maybe that's why you think what we do is "too complex to fully describe" - you haven't used a language that allows you to abstract at will.
And in order to formulate that attack you pieced together quotes from two completely differently messages and people to make your 'point'.
I said they keep people from re-inventing solutions, however it was the comment you actually replied to which else claimed they were too complex.
I agree they are patterns which languages do not yet abstract over, but until languages do I think they are very useful patterns for programmers to be able to correctly recognize as they occur frequently enough that knowing the pattern saves a lot of time and work. When languages can successfully abstract over those patterns, then knowing them will be niche knowledge assuming new patterns cease to be detected by humans prior to their ability to be abstracted by a language.
Please.
Rhetoric = Ethos + Logos + Pathos
Unless you want to believe I chose my words while extremely angry at you personally, and unless you want everyone to never use pathos and talk like robots in perfect clauses and rebuttals connected in an acyclic directed graph, I suggested you get used to this very common rhetorical necessity.
If many people learnt over and over again that global state, for example, leads to more bugs, you'd be wrong in completely dismissing it just because it isn't objectively proven. Because then you'd be arguing that a program that uses only global variables is just as good as one that's properly encapsulated and abstracted. Do you think anyone would take you seriously if said that?
If there is no theory we have to fall back to empirical analysis, and unfortunately our industry hasn't done much of that. The only thing we have to go on is the general "consensus" of the industry, which is cyclical, transient and mostly fashion.
Some of the industry folk wisdom if beneficial and withstands the test of time. Most of us agree that encapsulation is nice. However, we don't agree on what form that encapsulation should take.
OO programmers argue that state should hidden away inside objects, functional programmers believe that state should be explicit and we should always try for pure functions and immutable data when possible. There's very little objective data to support either side (except that functional programming languages tend to have more formal underpinnings). Mostly it falls back to personal preference, which programmer sages you trust, and what the current industry fashion is.
Our industry reinvents the wheel time and again because we are slaves to the cyclical nature of the industry fashion.
Relational Algebra/calculus has been formalized for decades, yet people who don't understand relational theory cried out for something "simpler" and thus NoSQL was born. Fast forward 5 years and you'll find many of the people championing NoSQL had to reinvent most of the tough problems that CS had solved decades ago.
Again, there is nothing inherently wrong with craft and folk wisdom--just like there's nothing wrong with learning salary negotiation, but they don't belong in an academic CS environment. These things are best taught in an internship/apprenticeship after you've learned the underlying theory.
Math, on the other hand, has been around for thousands of years, is relatively stable, and unlikely to become obsolete in the way a scrum certification, or even a machine learning algorithm, will.
Of course, 'CS fundamentals' usually end up at a very close intersection with math. I'm just suggesting that mathematics has an even deeper level of the 'stability' you referenced.
I agree with you completely. The parts of CS that are stable are the parts that are based on rigorous mathematical foundations. I think that teaching things like Object Oriented Programming strays too far from a rigorous foundation--away from math and even engineering into craft (which belongs in vocational training).
When I look back, the classes that I learned the most from were, Discrete Math, Automata, Design and Analysis of Algorithms, and Programming Language Concepts (which went into the academic side of programming language research more than what was currently in use in industry).
Computer architecture is big E Engineering, done by Computer Engineers for example. The networks class I took was also one of the most math heavy, and most of the book was supported by proofs. In addition, we spent the first half of databases working with only relational algebra.
If you look through a textbook on any of the subjects you mentioned, and compare it to say a book on design patterns, the distinction between math/engineering and craft is pretty clear.
>I also learned a ton from studying the history of computing, which I wish would be more of a focus for those entering the industry.
We went over the history in depth in my program--from Turing to Konrad Zuse to Backus. I also found it immensely useful.
All in all, it was boring and tedious but it certainly wasn't the worst class I ever had in regards to preparing me for a career in technology. I use those lessons to some degree all the time, I rarely directly use all the work I had to do to create my own OS...
I think you probably would have learned those lessons after a few months on the job. You probably wouldn't have picked up the knowledge to build your own OS on the job, however.
>All in all, it was boring and tedious but it certainly wasn't the worst class I ever had in regards to preparing me for a career in technology.
Did you learn about billing clients, and effectively advertising your services in your CS degree? What about equity versus salary tradeoffs?
At least 50% of working in technology is soft skills, why doesn't a CS degree spend 50% of the time teaching you those? The answer is that a CS degree isn't supposed to be vocational training.
Vocational training, including learning to talk to clients, should be done on the job, during an internship/apprenticeship, or in a specialized vocational training program. By including it in a college degree, employers have successfully pushed employee training costs onto workers and society (as the article argues).
When companies hired people for 30 year careers, they could afford to invest a tremendous amount in training. When they hire people for 2-3 years, they have less time to amortize the costs. And it's up to the employee to convince the companies that they can learn quickly, and on their own if need be.
Any CS major with decent grades and a positive attitude can learn anything in most any job. (Certainly CS, consulting, finance, marketing, even some kinds of sales) I can't say the same for liberal arts majors. There are great ones out there, but also a lot of folks who goofed off for 4 years and didn't learn anything.
In college, I didn't learn version control, continuous integration (continuously submitting your work in small changelists or patches), unit testing, making sure you're building the right product before building it, delivering the simplest possible code and design that meets the requirements, code quality, working in teams, untangling dependencies and making as much progress as possible today without waiting for all your dependencies to be resolved, and so on.
I expect that all these skills will be very much relevant 20 years from now. So, don't confuse long-term value with "grounded in CS fundamentals". Programming isn't a hard science like physics.
I didn't say that. I said most industry processes are fads. I also didn't say that nothing that isn't grounded in CS fundamentals has long term value.
There are plenty of other skills that have long term value. Office politics, salary negotiation, self-promotion are much more valuable than knowing how to run a few git commands. But non of those things should be taught in a Computer Science program.
They are fundamentally vocational skills. Just like version control, unit testing, and continuous integration are vocational skills. Sure they're useful but they should be taught in an internship/apprenticeship or on the job.
>In college, I didn't learn version control...
I learned to use subversion, and other than the fact that they are are both version control systems, what I learned didn't really carry over to distributed version control like Git.
In a CS program you should be learning things like how to implement a version control system, not how to use Git. I would have been pissed paying thousands of dollars per semester for a professor to walk me through a Git tutorial.
I don't have a problem if a professor wants you to use github to submit your assignments or something like that. And sure some of the vocational skills you listed are going to be useful for years to come. But these skills should be ancillary. They should be just a happy side effect--like learning teamwork during a group project.
In fact, some of the academic stuff like compilers and automata have been useless in real life. That's a failing of academia from my point of view.
>In fact, some of the academic stuff like compilers and automata have been useless in real life. That's a failing of academia from my point of view.
Finite state machines and pushdown automata are an incredibly common pattern, and I can't see how you can work as a professional software developer without running into that pattern time and again. Have you never used regular expressions?
Automata (usually taught along with theory of computation) teaches you all kinds of useful real world knowledge, like why you can't parse HTML with regular expressions, and why you can't write a program to tell if another program will eventually halt.
As for art history and psychology, that's a different debate to be had about education — whether these should be part of education and how much time they should take.
As for your question, I've used regexes, but you don't need to understand the details of the regex engine in order to use them. Neither do I, in my day-to-day work, write programs that try to tell if other programs halt.
vocational - adj. 2. (of education or training) directed at a particular occupation and its skills.
Which is exactly your idea of education. The labels are descriptive, not arbitrary.
Yes, at some point you do. Without understanding how regular expressions actually work, you can't know when it is appropriate to use them. Many things aren't possible with regular expressions and many grammars aren't parsable with regular expressions. You can either waste time trying to write an impossible regex (or write one that works on your tests, but blows up in the wild) or you can study automata theory and understand what actually goes on underneath.
As for the halting problem, I'll leave you this stack overflow explanation for why it is beneficial to understand.
http://cs.stackexchange.com/a/32853
Many problems in CS have already been solved, some are impossible to solve. You can either waste time on trial and error trying to reinvent the wheel or you can study the theoretical underpinnings.
Do you want to spend a week trying to model a problem as a finite state machine, only to determine that finite state machine isn't powerful enough to solve your problem?
Do you want to spend a month banging your head against a wall trying to solve a problem that you could have solved in 5 minutes had you realized it was just a well known graph theory problem all along? A problem that was solved decades ago. The only way to know these things is to study the theory behind what you do.
Why do you think Civil Engineers are required to take physics? The difference between an Engineer and an artisan is a rigorous understanding of the formal system underpinning his work. Artisans build through trial and error and experiences, and they leave many failed projects in their wake while they gain this experience. Engineers use theory and modeling to limit the number of failed projects to the net benefit of everyone involved.
Becoming a software developer is just one of the possible career options after a CS degree.
It's not colleges fault, in my opinion.
First Semester we took Intro to Programming and Algorithms (CS1100 or something like that). We learnt everything from Binary notation, logic gates through to floating points, I went from not knowing any programming language to having a fair idea about how topics like recursion worked our last project was to write some code to walk a tree using recursion. I also learnt how to use Unix and recieved my lifelong love of Emacs (which we used in our tutorials) from this course.
Second Semester we had to take Software Engineering (CS 1110 I think). It covered waterfall model, version control, specifications, unit tests and more estoteric stuff like loop invariants and formal correctness. Our major project was to write an essay about the Arriane V rocket explosion. I really enjoyed CS 1100 class but CS 1110 effectively succeeded in boring me to tears. It was somehow supposed to give us a taste of real world software design. All it really did was encourage myself and many others not to take CS electives in later years.
My major was Materials Engineering I took mostly physics electives in the last year of my degree, which is kind of ironic now because I work pretty heavily with programs - my day job involves writing computer simulations. I learned most of the skills I need on the job (including the C programming language, databases/SQL etc.) I probably would have benefited from more formal training but my experience of university CS was so miserable I actively avoided it.
As a result, a business can't pay to train it's own work force - if a business invests $20k in training and $80k in salary, there is nothing stopping another employer from offering $90k in salary after training is complete.
If an investment can't be protected it's pointless to make it. Having employees pay for (and be compensated for) their own training is the most reasonable workaround.
This is overall a good thing, but there are side effects.
Is it any wonder then that my generation has absolutely no sense of loyalty to their employer and show a pathological willingness to jump at almost anything that pays more or has better growth potential?
What benefit is there to an employee that would encourage them to stay with one employer? (To be fair...I've been with my employer for about 10 years, so YMMV.)
http://www.thedailybeast.com/articles/2013/03/15/sorry-folks...
Of course, a lot of benefits choices are driven by laws/accounting rules/taxes. Ideally companies want to give benefits that cost them less (however they look at cost) than their value to the employee. Once that balance flips, that benefit makes a lot less sense.
That said, a benefit structure that assumes long-term employment with a single company doesn't make a lot of sense for most people or most companies today. (Though I'm probably unusual among this readership is that I actually will have a modest pension from a past employer.)
Pensions were always unfeasible. ERISA simply requires employers to properly account for that.
Doesn't this assume a lifestyle from several generations ago where you get "the training" then you're set for the rest of your working life? I don't think the real world has worked like that since at least the 70s.
If I took that $90K job I'd be OK while I'm there... thats what, on average just a couple years? Then I'd be dead in the water and have some explaining to do at the interview for the next $80K job that provides the entry level training I'd need. Why would any employer hire an untrained employee if there's a perfectly well trained employee from the $80K job? Meanwhile the guy who stayed at the $80K job likely got a promotion to $100K and here I am trying to get in at the ground floor yet again.
How this fits in with stereotypical OTJ training is a mystery. Most formal training is a way to shovel money to middlemen who provide it in an accelerated format for an extremely large fee. Most real world training is "here's a PC with a web browser and your bosses bosses boss declared the due date for the project is next month, now figure it out yourself".
Think of the last time you worked a project with a junk spec that has no relationship with reality. Those people who can't spec a fizzbuzz if their life depended on it are the ones specifying the required training. I wonder if that training spec will be worth the paper its printed on?
And there's a huge spectrum of on the job training, from pointless classroom exercises to tick company compliance boxes to highly expensive professional qualifications that might pay for themselves in two years if the firm can hang onto the employee and bill for their time, but also make it much easier for the employee to get a better offer. It's the latter type that costs firms the most money as well as benefits candidates the most.
In other news, the huge demand for people who could efficiently work a loom has slacked greatly since the industrial revolution.
(A snarky way of saying, training and the benefits and value it confers is a function over time. Especially in the current world of web-based software development, two years can be a very large amount of time.)
How would training followed by a bonding period be considered differently than other mechanisms inducing employees to stay? Could these other mechanisms also be legally questionable?
E.g. some San Francisco Bay Area technology companies offer large (~$20k) signing bonuses to new uni graduate hires that the employee must return if she leaves within her first year at the company. Similarly, companies offer five-year equity packages that deliver no equity until the twelfth month.
I got my masters degree and then stayed at the company for a year and a half before leaving. At which point I had to pay back the remaining loan balance.
Worked pretty well for the situation, but that would only work if the cost of training wasn't exorbitant and the worker pay was relatively high. I believe I was making $58k when I left and had to pay $8k or so to repay the loan. Doable for me, but not necessarily so for a lot of people.
That being said, this deal was to further your education for your job. So you couldn't get your masters in finance unless you worked in finance. A software developer couldn't get their finance degree paid for.
This was for a company my friend worked for.
First year - no company 401(k) contributions.
Second year - full 401(k) contributions but 25% vestment. That means you get the money in your account (and it compounds) but if you leave before you hit your third year you only get to ultimately keep 25% of the money they contributed.
Third year - 50% vested.
Fourth year - 75% vested.
fifth year - 100% vested. Money is all yours.
(I think vested is the right word, correct me if I'm wrong)
Also, I worked for a company (in a non-technical position) where they initially hired at a low rate. You learned your job as you went and each job milestone had a test (written and practical). Passing the test netted a large increase in salary. You could learn other jobs other than the one you were hired for and increase your salary even more. It was a great system.
Then that business will have to pay better.
You want me to stick around? Fuck you, pay me[1] (or give me some other reason that is compelling--to me, not to you--to stay).
And nothing stops the first business from raising the employee's pay to $91k. Why should they expect to keep paying the same salary to someone they've made more valuable? They already amortized the costs of training over the value added by the employee in the first year, right?
In contrast, if you simply pay $100k to trained employees, and employees can pay for training out of pocket, you preserve the cost structure (big caveat: I'm ignoring taxes) but without the risk of losing your investment.
Assuming 1) you can find trained employees, and 2) they are willing to work for $100k. If the value of the trained employee is $111k, then why would they work for $100k except for ignorance of their value?
This is my big problem with STEM shortage parrots and with labor as a market in general: ideal candidates are rare, and, in general, willingness to spend more or train up is pretty low. On the other hand, anecdotally businesses seem willing to wait months or years for that ideal candidate to come along and fail to balance the gigantic opportunity cost lost with the cost to train.
It's economically not as simple as what I'm describing, but that's sorta my point. I rarely see anyone in labor market discussions (especially around STEM or highly skilled workers) include the opportunity cost of an unfilled position.
Competitor does not pay $111k because competitor does not pay for training. Which was the entire point of the exchanges above
You could of course question why a company would train their employee at all if the market rate for an already trained member of staff was about $90k. Because retaining an existing member of staff at an $80k salary after paying $20k for their training happens to pay for itself after 2 years. Its quite sad I feel I have to post the calculation to avoid further downvotes, but its: (($80k * 2) + 20k)/2 = $90k
I honestly thought this was high school stuff....
Whatever a competitor is willing to pay, the company that provided the training can just pay that and not risk their employees being poached. Additionally, it isn't free to poach employees, they will have training costs no matter what. In other words, after training you raise their salary.
Yes they can, if they want to go out of business.
If I spend $20k to train a new employee, I can afford to pay them their value to me - $20k (less than that if I want to make a profit, but this is the maximum that allows me to stay in business). Meanwhile, my competitor waits 4 weeks for me to do the training and offers their full value. Now I can either let them go, or match the offer - but either way I'm down $20k, while my competitor comes out even.
So you can imagine why I might not want to spend money on training.
Given your other points, this is only a problem is the cost of the portion of the training that is transferable is more than the extra cost of poaching (over that of hiring a fresh employee). As the job market becomes more liquid (decreasing that poaching cost), this becomes the case more and more.
And hence, in the original example, the company providing the training ending up spending $111k on their member of staff over the course of the year to head off a competitor's $90k offer, even if the employee isn't worth $111k (Considering your original contribution to the thread was to argue the competitor wouldn't pay $111k, I think accusing me of missing the point is a bit rich...)
The (IMO very weak) counterargument here is "well, budgets are set to blah blah blah" - but in that case, you're allowing a difference of a few dozen thousand dollars dictate whether or not you get someone, which can be the difference between shipping, getting out a new version, or whatever and not doing so. If your budgeting is that inflexible, maybe your organization has other problems it should address first.
When it comes to software, cost-based pricing should not be anywhere near the discussion. Software developers and their output should judged on value. It's crazy that anyone is still in this mindset after nearly two decades of software eating the world. We may be getting paid a lot relative to the median, but it's still just a fraction of the value it creates - otherwise, why would anyone bother? Hire a dev for 135k for example (includes benefits), and have them only generate 150k worth of value? Come on.
Extremely common in the UK :(
How true this is depends on the field and subject matter, but surely any entity will tend to see their own specifics as basic things anyone should already know even though the field is actually much larger.
Taken to the extreme, sure. But every voluntary interaction necessarily "leaks value", being non-zero-sum.
This word "training" keeps getting used, and I think it's at the heart of this disagreement - viewing learning as a discrete top-down event as opposed to a continuous process.
GP's example is akin to an employer paying for a bachelor's degree. My comment is easiest thought of in terms of company-specific processes. For any specific 'skill', the truth lies somewhere in the middle.
Software is a bit of a rare case where most tools are highly complex, but are also freely (as-in-beer) accessible. Tool choice is heavily driven by fashion, yet fashion being foreign to our worldview we're blind to this. Is $software_package a fundamental that every college graduate should know, or basically equivalent to an in-house framework? Who knows...
Training from a company says that they have a vested interest in the person, but they don't. Companies don't care about you, they only care about the bottom line and do not have any interest in spending effort to teach you something you could use somewhere else.
As a result, a business can't pay to train it's own work force
Well, they could offer more pay after the training is completed, or focus on being a nice place to work such that employees would choose to stay put with a company that treated them well. Your argument rests on the implicit assumption that employees will leave the moment they receive a competitive offer and are only interested in maximizing the take-home pay aspect of their economic advantage. Employees are motivated by a combination of monetary compensation, benefits, and good will towards a firm in the same way that a firm is valued by both its book assets and its good will in the marketplace. You assume, without foundation, that employee loyalty towards an employer that provides training will be nil, and ignores the possibility that employees might look forward to receiving future training (and promotions) which would have significant economic value, whereas a firm that poaches employees and offers no training of its own presumably won't be offering any in future either.
If an investment can't be protected it's pointless to make it. Having employees pay for (and be compensated for) their own training is the most reasonable workaround.
You could equally argue that it's pointless for employees to run up debt buying expensive an education which an employer might then say doesn't quite meet their requirements and therefore shouldn't be rewarded by additional compensation. Considering the non-dischargability of student loans in bankruptcy and the financial weakness of employees relative to employers when it comes to negotiating prices for training/education, I would say it's rather irrational for employees to take on all the financial risk involved.
As for the costs to employees, that is indeed a potential concern. I encourage anyone considering investing money in education to consider the marketability of same.
I'm all in favor of using economic analysis to work out how much a firm should invest in its labor force, but what you are doing (and do in almost every conversation about economics) is arguing that we should consider only those which affect your preferred metric. As someone else pointed out, you ignored things like the probability of increased productivity to the training employer during the training period and so forth.
I've actually worked freelance most of my life, and so I'm responsible for my own skills, pay both the employer and employee portions of payroll tax and so on, so the ideas you're advancing are far from being foreign concepts to me.
I don't know why you think I'm disputing that transaction costs can cause markets to be inefficient - I agree completely. As a limiting case, if we punished quitting your job with death, shifting jobs would only make sense for the suicidal.
What, exactly, do you disagree with me about?
Your original analysis neglected transaction costs entirely.
You for some reason seem to hold the idea that after training, some other company can just come in and offer more money. Why?
"there is nothing stopping another employer from offering $90k in salary after training is complete"
Sure there is, and many people have pointed out the flaws in this comment. If $90k is the market rate, then there is nothing stopping the company that provided the training from paying that too, and there would be no more advantage to offering $90k. In addition, as others have pointed out, there will still be some ramp up time and training at any new company.
If your point is that the first company can't expect to under pay their employees after providing training, well, that's obvious and nobody suggested it.
Do you not see any reason why a company might prefer to be in the second category?
The 2nd company doesn't have to bear the costs for training.
>If you're in that category you'll be trying to hire employees for the same salary they're already being paid by an (intelligently run) company,
For the first company, it doesn't matter how much they (intelligently) increases the salary because they still have to add in the expense of the training.
>, in addition to having to retrain them for your company.
Not necessarily. A common example would be IT consultants. It is very common for Oracle and SAP have their consultants spend 4 to 8 weeks of training and then boutique firms would poach them with higher salaries. The boutique firms didn't have to pay the $20k to $40k for the 8 weeks of classes and they also don't have to retrain them. The Oracle DBAs' skills are ready to be put to use on day 1.
If one thinks Oracle/SAP can simply increase the salary to what the boutique firm was offering, the math doesn't always work out because the total higher compensation has to include the training they already paid.
If we use following placeholders:
s=salary, t=training, i=increase to market salary rate
Category 1 company total expense = s+t+i
Category 2 company total expense = s+i
Because "t" was a non-zero amount that can't be magically erased, it means that for all values of "i", "s+t+i > s+i"
In other words, for Category 1 company to "match" a higher Company 2 salary, they must always pay more than that salary because the "pay more" includes the training $$$ they paid.
Hopefully, for Company 1, they have other non-monetary advantages that outweighs the absolute mathematical disadvantage the above equation shows.
This is great if you're an employer but what are the consequences of shifting from a capitalist economy to a capitalist society? There is more to a successful society than increasingly desperate and ruthless competition for a shrinking pool of jobs. How many people want to spend their entire working life in a cage match for survival hoping that they are one of the lucky few who make to the billionaire's club? If government isn't going to represent the people what's the point of having one?
The standard retort from market fundamentalists (and it is a faith) is to reframe the debate as capitalism vs. socialism, or argue that the market is as natural as breathing and we have to let it do what it must. The first one is straw man argument; not many people are arguing in favor of a Marxist paradise. And the market as a system of nature is simply delusional. A market economy is fine, most people agree on that. The problem is when the market model invades every last aspect of society and opposition is neither mon-existant or rendered impotent. The end result is a dictatorship of market fundamentalism. Kind of a capitalist version of the Soviet Union where the Communist Party is replaced by oligarchs and the lowly worker is replaced by the lowly worker version 2.0. IOW, post-industrial feudalism. Is that what "the people" want? Something tells the answer is "no, they absolutely do not."
"What if we invest in training and our employees leave?"
"What if we don't, and they stay?"
I believe in Germany consortiums of businesses in the same industry subsidize training. Seems reasonable.
In any case, your observation would seem to be refuted by the fact that businesses in general used to do precisely that, and many businesses still do do precisely that.
"Having employees pay for (and be compensated for) their own training is the most reasonable workaround."
For the business, maybe.
Until a new programmer is making minimum wage, there's always a point at which companies can employ them for less, and hope their value (plus expected value from the ones who stay on at a higher wage) will be more than the costs of training.
Also, training is often domain specific. Employees are generally worth more to their employer than a competitor (though there are exceptions).
Except for the massive information asymmetries in the market.
Even ignoring the information asymmetry, hiring a new employee is expensive. You can easily end up paying 40-50k to hire a good developer (as a combination of the recruitment process and ramp up time).
So really company B is paying salary + $40-50k recruitment. This means company A can easily match company B as well as provide training.
If you can hire people who already have the specific skills you need, sure, let others pay for the cost of acquiring those skills. But, when you run out of those people, then the choice becomes paying to train them, or suffer the cost of leaving the work they'd do undone. If the value of the work they perform is more than the cost of training, it's logical to train them.
In this example, the market rate for someone already trained at a certain set of skills is $90k, and the cost of training is $20k. Nothing prevents a company from offering people who are smart and capable, but not trained at whatever the company happens to need today, $70k. But with a promise (in the employment agreement, not orally) to offer $90k one year from now.
Everyone benefits from this arrangement — the candidate, who now has a better job they otherwise would have (which is presumably why they're taking the offer in the first place). And the company, who's getting a capable employee without spending more on training.
So, the bottom line is that you can always structure your incentives in a way that makes the training worthwhile for all parties involved, without asking the employee to pay for it.
If the training has increased her market salary, then the simple solution is to raise her salary to meet the market.
It's hard to defend the code schools though. There are a high amount of horror stories we hear about them on HN, from both the students' and hiring managers' perspectives.
Can you link to them? I'm trying to do due diligence on some of them, but haven't been able to find much at all of substance. I'm specifically interested in Maker's Academy in London.
Ask HN threads I found interesting:
https://news.ycombinator.com/item?id=8844848
https://news.ycombinator.com/item?id=7147664
https://news.ycombinator.com/item?id=9616691
The one I really wanted to find, which accompanied an article about some students who felt scammed by their bootcamp, is eluding me right now. It was an interesting article about how the students were required to post misleading stories on social media that made the school look better than it was.
Edit: I found out why it was hard to find; it was taken down. Here's the link to the comments. https://news.ycombinator.com/item?id=9492381
Coding bootcamps exist to bridge that gap - in a sense, you can think of them as recruitment agencies and not as learning institutions. The goal isn't to replace a 4 year degree with 3 months of intense learning. That's simply not possible. The goal is to find smart, motivated people who can learn quickly, give them a skill which will let them hit the ground running, and present them to companies.
Companies benefit because they get a low cost hire who has the potential to grow tremendously if given the right environment. Employees benefit because they can typically enter the workforce at a higher salary than they could command from self-study alone. Win-win all around.
The key takeaway is that for-profit code schools are not schools. Code schools are primarily recruitment agencies designed to find high quality, non traditional talent. In that regard, I think the best ones are an absolute success.
"They took all the guys that were working on vehicle autonomy — basically whole groups, whole teams of developers, commercialization specialists, all the guys that find grants and who were bringing the intellectual property," recalls a person who was there during the departures" ... Uber snatched up about 50 people from Carnegie Mellon, including many from its highest ranks.
... the deal includes a "transition period" that keeps some of the departed staffers around ... "The work of these employees is very incestuous and loose," says the same NREC insider. "They are given free rein of the facilities as part-time CMU employees, but there are absolutely no checks on the work that they are doing or what [intellectual property] they are taking. Is it for CMU? Is it for Uber? None of us here know."
Edit: could CMU have gotten better IP licensing terms and ROI for the University, if they had spun out the entire team (with private financing) and had an open auction of RoboticsResearchCo to the many companies investing in this field?
CMU could probably have gotten better return if they hadn't made it a point to underpay them so much compared to their market value.
A signing bonus or normalized salary is in an entirely different (smaller) class of compensation, especially since there was already an international track record of investment into the commercialization of self-driving vehicles.
For reference, $160k can buy a nice house in a nice neighborhood or suburb in Pittsburgh.
[1] http://www.cmu.edu/homepage/environment/2014/fall/from-0-70-...
That said, Uber pretty much showed that they are unable to be trusted (if anybody trusts them at all still).
Well, I guess if already-educated workers are the norm in your industry, companies are going to change their hiring practices accordingly. It's okay not to like it, but arguing against it on the basis that 'it didn't used to be like this' just makes you look entitled and whiny.
> Bemoaning the unpreparedness of undergraduates isn’t new. Today, however, those complaints are getting a more sympathetic hearing from the policy makers who govern public higher education.
Yeah, well, when policy makers are responsible for all the cheap money flowing into the system (without which the system would probably collapse at this point), I guess that'll happen.
That's the point -- there's a difference between education and training. It is only an issue because so much of the education looks very similar to the desired training.
It is not the purpose of an education to produce new employees, but to provide a broad basis for experiencing and making sense of the world. It just so happens that you also learn transferrable skills like a basic familiarity with a particular field, along with some tools and techniques that help you organize and solve problems. A proper education is not an extended code bootcamp, nor should it be.
Excellent point. Two problems:
(1) Over the past ~2.5 generations, the narrative about education has been informed by the conventional wisdom of {grades -> university -> job -> pension}. Hence, education is now only nominally about producing 'citizens of the republic' (so to speak), and de facto about producing well-trained workers. Disambiguating these goals is important, but hampered by...
(2) The perverse incentives created by cheap government money encourage malinvestment (i.e. an English degree [I say this with love — my wife is an English major]), and the consequent propensity of industry to not only see it as a jobs program, but also as a government policy problem.
Untrue. The logic is if there is a disparate impact against a legally-protected class, such that the test would be a convenient cover for illegal discrimination, and you allow discrimination using the test without demonstration of relevance, it becomes an easy, obvious, and effective tool for those looking for cover for discrimination on an illegal basis; to avoid that, the logic goes, you simply require those who wish to use the test as a basis for discrimination in that case to actually be able demonstrate that the test is meaningful to the job and that it is applied as a discrimination factor in a manner consistent with the way that it is meaningful to the job.
If they've actually done the kind of analysis that would let them know that the test really is useful, this is trivial; it does, however, prevent adopting a test with discriminatory effect against a protected class merely based on intuition or conventional wisdom.
The type of analysis involved may be costly, but then, if it really is something that those wishing to apply have high confidence would be valuable for their business, that type of analysis would be worthwhile to pay for. The reason it is difficult is because none of the people who like to talk about how useful these things would be when talk is cheap wants to put their money where the mouth is on the issue.
If challenged in court, and if the work sample test is shown to have a disparate impact such that its use would be illegal discrimination if it were not tailored to the job, they do have to show this for work sample tests. Your premise is simply false.
(OTOH, the disparate impact of IQ tests is more readily established by a plaintiff since there are numerous, readily available studies. So the work of establishing the threshold issue which requires the employer to prove relevance has largely been done by the plaintiff for IQ tests.)
> given that the former are better predictors of job success
The legal standard addresses the specific job for which hiring is being done, not a generic job. Interestingly, your source indicates that the types of jobs where IQ test challenges have notably occurred are those where the test is least relevant per the source you cite (unskilled/semiskilled jobs).
If you can demonstrate this is the case for the specific jobs where you want to apply it, you will then have no problem, even if it has a disproportionate negative impact on a protected class.
Only in the same sense that an unjustly accused person will "have no problem" as long as they're actually innocent. In practice, they do have a problem. Firms are afraid of using IQ tests and being the first against the wall.
I.e., if my subjective human hiring technique is biased, you need to prove I discriminated on purpose. If my objective, IQ-based technique is biased, I need to prove I didn't. Why this disparity?
Untrue.
> I.e., few companies have ever done a study (sufficient to win in court) to prove that their subjective human opinion-based tests do not have a disparate impact.
When an employment practice -- including a subjective, human-based tests -- does have a disproportionate impact against a protected class, and actions under it are challenged under anti-discrimination law, companies do have to prove that the practices are sufficiently related to the specific job being hired for that the disproportionate impact is not unjustified. IQ tests are not different in this regard.
They are different in that:
(1) the evidence of disproportionate impact is well-established and ready to use, and
(2) unlike most companies' other hiring practices, there is very little on the surface to show a trier-of-fact that it is related to the specific job duties, so tying it to the specific job duties takes a lot of work -- and, in fact, the places where they have been used and challenged are largely the kinds of places where studies have shown them least relevant to job performance.
For the simple fact that we already have evidence that some protected classes perform worse on IQ tests. Therefore, simply by using an IQ test you are discriminating against a protected class. The burden is on you to prove that the discrimination is necessary. No one needs to prove that discrimination is happening because you are using a test that has already been show to be discriminatory.
Interview based hiring techniques are much more varied than IQ tests, and they have not been shown to be near universally discriminatory. Therefore the burden is first to prove that discrimination is happening in the particular situation.
They actually have...
I am not going to get fully into it at the moment (but there's a ton of research on the topic) but we know that resumes that say Lakisha are significantly less likely to get a callback than a resume that says Karen.
Another example is blinding in orchestras. When the practice became the applicant played behind a curtain (so they judge didn't know what the applicant looked like) the number of women in orchestras increased.
Subjective interview based hiring across all companies has been show to be discriminatory towards protected classes. But that's different than showing a specific company's hiring process is discriminative.
If company A uses IQ test X, and IQ test X has been shown to be discriminatory, then you can say definitively that the hiring process of company A is discriminatory.
If company B uses hiring process Y, and you can show that hiring process Y is discriminatory in 50% of the companies that use it, you can't make a definitive conclusion about company B in the same way you can company A.
There is a huge difference is explicit bias (give applicants an IQ test even though we'll weed out the blacks or even to weed out the blacks) and subconscious bias - which is an incredibly complex problem.
Most companies are trying to eliminate (unintended) bias in the hiring process.
Tests have been used as a tool to weed out the undesirables, this is a fact. Look at literacy requirements for voting, for example. If this wasn't the case we wouldn't be facing this issue.
That being said - its a huge can of worms that needs more clarifying. It has a spotty judicial history, to put it lightly.
It is also questionable that requiring a college degree for many jobs is actually legal anyway and it is consistent with precedent such a practice is actually illegal.
Griggs v. Duke Power was a big Supreme Court case in this area. The Duke Power Company had explicitly segregated its workforce when it was legal to do so reserving the low paying jobs for blacks and the high paying jobs for whites. When it became illegal to do so they changed "you have to be white" to "you have to have a high school diploma or pass an IQ test."
Duke lost the case.
See here: http://www.popecenter.org/commentaries/article.html?id=3118
>Furthermore, the company’s lawyers argued, the legislative history of the Civil Rights Act clearly showed that it was not intended to interfere with bona fide aptitude testing, widely used in business at that time. During Senate debate on the bill, opponents argued that it could be used to attack employment testing, which had in fact occurred in a case in Illinois involving Motorola. A state official had ruled the company’s testing illegal under state law because it was “unfair to disadvantaged groups.”
>Bill sponsors, including Senator Hubert Humphrey, replied that nothing in the language of the statute could be construed that way, but to head off objections, they included a new section, 703(h). That makes it legal for an employer to use a “professionally designed ability test” if it is not “designed, intended or used to discriminate….”
>You might think the Court would have ruled in Duke Power’s favor. Wrong—it ruled unanimously against it. The justices ignored the legislative history and gave deference to the federal agency charged with enforcing the law, the Equal Employment Opportunity Commission (EEOC).
>But there was also a delayed consequence. With actual intelligence testing now an invitation to costly litigation, “many employers made the college degree a de facto intelligence test and focused only on hiring applicants who possessed it.”
>O’Keefe and Vedder raise that question: “If challenged, could employers who have set the college degree as a requirement show that it has anything at all to do with ‘business necessity’ or are ‘job related’? That is very doubtful.”
>Suppose that someone who’d been turned away from a sales job for lack of college degree took the company to court, claiming that its educational requirement had a disparate impact, screening out people who could succeed in the job. That would appear to be a strong case.
>I have never heard of such a case, attacking an employer’s college degree requirement on disparate impact grounds. But nothing would more rapidly deflate the college bubble than if the Court were to hear such a case and rule consistently with Griggs.
Intention doesn't match with reality. Honestly, we need to revisit the issue and so something differently. However, political correctness has nothing to do with it.
(I am also not convinced such tests actually have much to do with intelligence anyways...)
That being said, if you're not in a leadership position that kind of decision making isn't what you're doing: you're most likely just optimizing on your own little anthill, so a "profit-centered" education like the article is against might make sense for the worker bees.
Another thing that I think is usually missing from the "train your workers" debate is how much variance there is in productivity, and how actual productivity is usually unknowable unless you have 2-3 months of project data for a given worker (these are assumptions). So hire unskilled contract workers, fire 80% of them, and then train the remaining 20%. They won't have the credentials to work elsewhere, and you've been able to identify the true all-stars using data on their actual work product.
Businesses that would like to but that operate in a sector where a competitor can successfully externalize that cost will be at a competitive disadvantage.
And businesses that subscribe to managerialism -- the idea that it's primarily management/leadership skills that differentiate a business, rather than domain knowledge -- may not know how to train employees at all, as it takes someone with domain knowledge to know how that can be done...
Pick some company at random, look around, and there will often be piles of people who have no official training or certifications to speak of, and no relevant degree, but who are perfectly competent at their jobs. Somehow, magic happened, and they were trained, despite no training money in the budget.
A lot of it is just done semi-officially. The boss points at some guy he trusts and tells him to fill them in, and lower productivity is accepted for some period.