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.
> ...they said that no contract can bind an employee to a company.
Seems to work fine for athletes, actors, medical residents, certain kinds of scholarships, etc.
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.
> ...they said that no contract can bind an employee to a company. Seems to work fine for athletes, actors, medical residents, certain kinds of scholarships, etc.
I dunno the exact law, but those segments seem like specially-regulated segments of the economy.
> > The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. This may be true if your definition of programming is the literal act of writing code / recalling syntax, and learning new tools. Of course, that's not really what programming is. That's the easy part. Programming is about problem solving, code is simply the tool. Critical thinking/problem solving ability,…
> We wouldn't judge a carpenter on e.g. his/her ability to use a saw
I don't want to be mean but it looks like programming is both: Talent: 1. natural aptitude or skill. Passion: 2. strong and barely controllable emotion. ... * an intense desire or enthusiasm for something. ...
Couldn't passion be innate as well? If you hate cilantro, you certainly won't have a talent for eating cilantro. (Also, passion in this context doesn't imply any sort of lack of control. You don't program in the "throes of passion".)
I've skipped meals programming, when things are interesting at least.
> > The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. This may be true if your definition of programming is the literal act of writing code / recalling syntax, and learning new tools. Of course, that's not really what programming is. That's the easy part. Programming is about problem solving, code is simply the tool. Critical thinking/problem solving ability,…
> We wouldn't judge a carpenter on e.g. his/her ability to use a saw What? Yes we absolutely would.
I think the point is that we don't judge on the tools, but the results. If he/she did a good job, why would you care? you wouldn't. Which is the parent's point. I think.
> ...they said that no contract can bind an employee to a company. Seems to work fine for athletes, actors, medical residents, certain kinds of scholarships, etc.
I dunno the exact law, but those segments seem like specially-regulated segments of the economy.
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.
Lately, I've started thinking of programming as an art form. If you substitute programming with music, how would you make all of these evaluations about the craft and of its practicioners? You may be hiring for guitarist and require at least 3 years experience playing the guitar. J.S. Bach applies, but has never played the guitar. As an industry, we typically wouldn't hire him due to lack of experience. Instead we mi…
> Yet as an industry, we focus the ability to be productive on day 10 instead of day 100 or 1000. For long term positions. Why?
With what level of accuracy can one tell which of the 100 applicants are going to be virtuosos three months/years down the road?
With what level of accuracy can one tell which of the 100 applicants are going to be solid _enough_, _tomorrow_?
I used to be a "rock star" programmer. I could run rings around my coworkers. I wrote an embedded OS for running machine tools (I had help.) Back then, you read books and memorized everything. I knew x86 assembly and could use a logic analyzer to debug my code. This was in the 80's. Now the amount of knowledge required to do even mundane tasks is an order of magnitude more. No one can memorize all the APIs and framew…
Just a side note: I did some debugging of STMicroelectronics ST10 assembler with an oscilloscope the other week and it was quite a refreshing experience making me appreciate all the debug loveliness that is normally provided for us on a plate with even C. The one thing that the loveliness cannot really help with, that the oscilloscope shines with, is proper timing of signals though. Its great.
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…
> You could also choose to mitigate the risk of them leaving if you thought you could be successful at it. Yeah good luck with that.
There are many things you can do:
1. Pay them more money.
2. Give them interesting things to work on.
3. Invest in their career development.
...
It isn't "luck". Many companies just suck at that (either because they have bad leadership or their industries don't support it).
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 y…
You don't see what's wrong with this? Unreal. 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 tra…
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.