## HR Model

by Javantea
June 11, 2009

Human Resources is a tricky business. There are two goals involved:
1) Expansion of business capabilities (two coders produce more code than one)
2) Cheaper completion of goals (a cheaper coder who does the same work saves money)

Equation 1:

HR = (Work - Peer contribution) * Factor - Cost

Variables:
HR: HR is the amount of money that the worker has profited the company.
Work: Work is the total amount of hours that the project would normally have taken by an average employee (a peer who is available for work).
Peer contribution: Peer contribution is the number of hours that other workers have put into solving the problem. For higher paid workers, this must be multiplied by a wage ratio.
Factor: Factor is a simple unit changer that turns hours into units of money. It can usually simply be wage (for example \$20/hour).
Cost: Cost is the amount of money that the worker was paid to do the task.

So we can calculate this for an example day of work:

Person A did 5 hours of work in 5 hours, but asked for extensive help for 3 of 5 hours.

HR = (5 - 3) * 20 - 100 = -60.

Alas, this is negative profit for the company. But wait, there's more. A person in training needs a lot of supervision because every person is in a constant state of incapability until the very moment that they do something. So the training (the loss) creates a person who is better able to do the work needed of them and thus creating recurring profit over the long term.

The question of whether a person will work out depends on their performance not during training but during their work toward profit for the company. The less peer contribution and the more work, the more the business will profit.

How does HR decide whether a person will work out? There is a learning curve to every job. In fact, every creative non-repetitive task has a learning curve. That is why every very creative person has incredible issues with projects that require high learning curve. A project cannot be completed if a person doesn't have a way to overcome the learning curve. In a project that is so cutting edge that no peer exists (or where peers are too expensive for individuals to hire), the only way to overcome the learning curve is by personal problemsolving skills. Thus it is not specific knowledge that is required of a new recruit, but a general skill: problemsolving.

Problemsolving is what differentiates code monkeys from programmers. Code monkeys can write in a language that they are familiar with but are generally unbelievably bad at solving difficult problems. A programmer is able to take their vast knowledge of the way that computers can and should work and decide on a path of problemsolving that is extremely efficient. Over the years that the person has been writing bad code, they have noticed patterns in how things work and how they don't work. Thus a problem in language that they've never used before may be a shock, but once they do a simple web search for the error they are coming up against, the explanation is capable of solving a class of problems that they will come up against in the future. Often programmers are good enough at problemsolving that if they come up against a problem that no one has ever seen before (pretty rare in computing), they can use the same steps they use in any other language to figure out the issue.

The first step in problemsolving that has been handed down to me by other programmers and my experience is that reduction is often the fastest method to fix a problem. If a=1;b=2 doesn't work but a=1 does, there's something wrong with one of the 4 characters you've removed, isn't there?

The second step in problemsolving is verbose output. When in doubt, you need more output. Some people go way over the top sometimes, but you can always reduce verbosity. Verbose output solves difficult problems like race conditions, null pointers, and so forth. If you rely on your code to be what you think it should, you're going to be wrong once in a while. Why not check? Many people are dumbfounded when accustomed to a high quality breakpoint-based debugger and are thrust into an environment that totally lacks a debugger. Think of it the other way around: you are not lacking a debugger, a debugger is just doing the prints that you are too lazy to add. Seriously how difficult is it to add a few debug statements to your code? I have debugged everything from shellcode to javascript and python using prints. (Though I must say that shellcode is an exception to the whole print debugging thing though, much easier with a breakpoint-based debugger).

The obvious third step is to query the friendly documentation and do a web search for any bug or issue you find. Remember the whole thing about peer contribution? You get the same solution for free when you search for the bug before you ask a real person for help. That's because the internet is designed to incredibly increase everyone's HR benefit by providing answers to common questions. If you can't figure something out by using documentation or the web (happens all the time), it's up to you or your peers. If you solve it and you think that someone will benefit from your expertise, write a paragraph and post your data to your blog. Then when someone has the same problem as you, you'll save them time. Or not.

So here we have a model of HR that allows us to judge a person's contribution to a company at any given time. But to know whether a person is worth their cost, they must be evaluated during the time where they are certainly least capable. During training, a person's output is bound to be negative. However, a good employee will show promise in problemsolving skills. Problemsolving skills are what turns a difficult problem with high learning curve into a solution. That is why I decided to test my first employee with a project with the highest learning curve and the highest standards. Although she and I did not like it and it didn't really profit my business, that wasn't the intention. A failure just proves that the project was beyond my employee's ability. When given the solution (often to an obvious problem) the reaction of the employee is important because if there is understanding, there's room for improvement. If the employee is totally helpless, it's a lost cause. It is obviously true that an easier project with lower standards will be more manageable for the employee. The true test of whether the employee is worth hiring is whether when faced with a similar problem, s/he is able to overcome it without any help. If the employee shows inability to learn when given two similar problems, it is probably not worth your time to hire this person. How long does it take to figure out if a person is worth hiring? \$400 by Sunday if she works her tail off on this project.

Business is business; it is quite unpersonal; HR is a model designed to reap profit from human intelligence. A person with intelligence will profit a business given there is money to be made, a person who doesn't learn is doomed to never be a programmer or a good businessperson.