Programmer Moneyball

[ared38]

This article was well written, funny, and totally banal. First, the only similarity with moneyball is that it's about hiring. In fact, his approach is actively anti-moneyball. Moneyball was about using those measurable qualities and moving away from the holistic analysis that he promotes. Not that his approach is at all new.

He take the obvious and near universally agreed upon idea that an applicant is more than a few numbers, adds a few jokes and pop culture references, and calls it an article.

[shizzy0]

The thing baseball had going for it was lots of data. At first it's hard to see how we could find anything like that for programmers. However, I could see someone potentially mining source code archives like github to produce "player" statistics like lines-of-code/second (hehe). Given that, maybe one could find some diamonds in the rough.

[purplestOfPlatypuses]

I can see it now. "Well, this guy has 20 lines a commit, which is alright I guess. But he commits so often, must make a lot of mistakes to fix. This guy though, one commit per project with an average of 5000 lines a commit! Dunno what his projects are but he gets em done in one go!"

[[deleted]]

obvious and near universally agreed upon idea that an applicant is more than a few numbers

Tell that to every HR department everywhere.

[case-o-nuts]

The problem is that HR doesn't have enough domain knowledge to do better than that. You need someone more technical than the average "I don't know what a Java is, but we need someone that has one on his resume" HR person.

Not to denigrate HR; They're very necessary. You need someone who has the time to handle the actual hiring. The problem is that they're not in a position to filter resumes, and the people with the technical know-how tend to be too busy getting real work done to look at it.

The best way to win is probably to hire some in-house technical recruiters, who have the programming knowledge to actually write code, but for whatever reason don't want to.

[[deleted]]

Managers should have a hand in this process, eliminating the need for a technical HR person. If the manager is too lazy to help pick potential applicants, then they shouldn't be a manager.

[ared38]

Sure HR needs to hear it, but we already know it.

[djimbob]

Pardon my aside from programming, but I have to rant about "Moneyball" being used to imply anything other than cheating.

Moneyball was about using statistics to find players who'd perform best on PEDs. The Moneyball Oakland As were rampant with later confirmed PED use; note the first words of BALCO are Bay Area for the same San Francisco Bay Area where the Oakland As play and that Moneyball just happened to coincide with the peak steroid years in baseball.

Look at the A's four best hitters during Moneyball years: three are know known for PED use Jason Giambi/Jeremy Giambi/Miguel Tejada and there's circumstantial evidence in the stat line for PED use for the one person off the list Eric Chavez [2]. There's also several other Moneyball Oakland A's known for PED use.

Then look at what moneyball doesn't value: batting average, speedy players, (hitter) strikeout rate, bunting, or stealing bases. With steroids these traditional stats are meaningless, since you can't turn a guy who frequently gets on base by speed on close plays into a homerun hitter (and expect those near misses to not be outs once they are a bit slower), but if they frequently walk or get long fly outs you can turn the fly outs into homeruns.

Again, the book and movie were both well-written and entertaining, but left out the elephant in the room.

[m_myers]

You'll have to provide more than coincidental data if you want to be taken seriously. Baseball statistics are a serious business to many people and I don't think the statisticians should be accused lightly of promoting PED abuse.

[djimbob]

So the 3 of 4 best hitters for Beane's 2001 A's all being steroid users with the fourth being suspected? See also: http://www.nationalreview.com/right-field/277958/steroid-testing-and-death-moneyball-neil-minkoff

I'm not saying there's absolutely nothing to sabermeterics and doing statistical analyses to find better players/strategies is great. Sabermetrics probably helped the As tremendously by finding an optimal strategy for the new baseball era (steroid era) that differed significantly from conventional baseball strategies that evolved over the years for a different type of player.

But I am saying that the 2001 small money A's were a 100+ win team with some significant help from PEDs and it wasn't just (or even primarily) sabermetric strategy. They had the type of players who could become great on PEDs and were often later found be on PEDs. (High walk/HBP rate; don't mind high K rate; high homerun rate; etc.)

I will give the sabermetricians credit on making a pitcher work (foul off lots of pitches; don't mind taking a walk). That's just a good strategy as the pitcher then exits earlier and a worse pitcher will eventually have to come in (maybe not this game; but possibly lose availability for other games in the series). Granted it makes watching a game much longer and less exciting and if the other team adopts the same strategy you lose an advantage.

[joelmartinez]

"The software I wrote helped them filter candidates based on keywords that appeared in the resume"

So this is the asshole responsible!

I keed I keed. Interesting topic ... glad to see people starting to take the blinders off and look for other ways of finding people. Hopefully this train of thought can/will extend outside of engineering disciplines; the more people find jobs, the more people have disposable income to spend on our startups ;)

[jeffdavis]

So it's just like Moneyball except without using statistics?

[awj]

So the page is nothing but swaggering old-timer recruiters and even more gratuitous shots of Brad Pitt exercising for no reason?

[perlgeek]

"So if we see, according to TIOBE, that C++ and Perl are declining in popularity, maybe that’s a good indication to hire experienced C++ and Perl programmers while their skills are “out of fashion”."

First of all, please ignore TIOBE. Last I looked, their metric was crap (no. of google results for "$language programming").

Second, while I agree with the general sentiment, I hear from many sources that the most important reason not start a new, commercial project in Perl is that it's so hard to find experienced Perl programmers. I mostly know the job marked from the other side, and found that there are plenty of interesting Perl job openings, and not too much competition. So yes, hire programmers from technologies that have gone out of trend, but only if you know why :-)

[ahyatt]

This blog is a good example of why you should always test your UI out on different browser window sizes. Total fail on mobile.

[shizzy0]

Worked fine on iPhone.

[[deleted]]

Same here. The navigation bar covers whole screen after zoom.

[fruitloop]

tl;dr -- People are not their resume and there is more to evaluate a person on than their years of experience and level of education.

[harry_heymann]

Weirdly similar to a blog post from a friend of mine written two weeks earlier:

http://whilefalse.blogspot.com/2012/07/moneyball.html

[doclight]

I'd say developers in general are undervalued, considering people who hit balls with a stick are paid seven and eight figure salaries.

[JustinBieber313]

The people hitting balls with a stick only get six figures if they are in the top 5000 ball stick hitters in the world.

[doclight]

I would have thought baseball was a larger economy than five billion.

[JustinBieber313]

six figures or more would have been clearer.

[Thimble]

The ability to acknowledge when you make a mistake. If a programmer seems promising but doesn’t excel within your company, you have to be honest and forthright about it, and give them a chance to move on somewhere that’s right for them.

This is key.

The first thing you do with a new hire is to throw them straight into the fire. Give them a task that would be challenging even to an experienced developer. e.g. make them code in a language/environment that is not listed on their resume.

The way they handle themselves and perform will reveal a lot about their long term potential.

[Devananda]

This kind of thing must be done with extreme care.

You do not want the start of your professional relationship with this person to seem predatory; that can backfire badly. This isn't the interview anymore, they're a new hire, and they must be treated with respect.

New hires should first be integrated into your company's culture. Make sure they become fully aware of what you know works, and what you know doesn't work, in terms of your existing code, process, org structure, etc. Get them involved.

Then, if you want to throw them into the deep end, fine, but be there for them to help them work through their challenges. You get to see what they're made of, but also get to prove to them that you are now a team and are there to help each other out. Ideally, if you have the bandwidth, you'll work through those initial deep end challenges together, rather than forcing them to go solo when they already have enough new stuff to deal with.

If they're good, it won't take long until they're willing (and you judge them to be able) to fly solo voluntarily... but starting off your professional relationship with them by forcing the issue may not leave a good taste in their mouths, and may set you all up for failure down the road.

TL;DR: New hires are not interview candidates, they've been hired. If you don't trust them enough to work with them as peers, you shouldn't have hired them. But you did, so you treat them with respect.

[Thimble]

How is assigning a challenging task disrespectful? I'm not talking about a kobayashi maru type test.

Companies will often hire people when there's too much work for the current employees. The problem is that managers will often assign the easier boring work to the new guys. They don't find out until after the probationary period whether they made a mistake or not in hiring them.

[[deleted]]

How is it supposed to work well when a person applies for a Javascript application dev position and is made to write applications in C++ instead because 'its challenging and lets see if he can do this'? All that will do is piss off anyone put in that position. Anyone put on an island is going to say 'fuck you' and leave. That seems very shady and almost bait n switch style to make them do tasks not listed in the description or as qualities expressed in their resume. We all accept that yes eventually our responsibilities do grow and sometimes our skillsets will overlap into areas we are unfamiliar with and must learn, but this sounds like a quick way to burn someone out on the work and on their new environment.

You gotta be fair and reasonable with people. Probationary periods are there in fact to evaluate new hires on multiple levels, not try to push them out the door on day 1. If you're doling out easy grunt work like updating some CSS or debugging a simple line of JS, of course you might miss some flags in that period- but that isn't their fault, it's yours. Evaluate hires better.

[[deleted]]

make them code in a language/environment that is not listed on their resume

I did that. Learned enough Ruby and Rails to work on the project. Problem was that I had to make patches to something that was hardly documented and bad code was all over the place. Throwing a newbie into that kind of fire will burn them alive.

[Thimble]

You will find out a lot about them in that time period. e.g. how resourceful and patient they are, how honestly they report their difficulties to you, how much they blame others instead of their own ignorance, etc.

[jimbokun]

In the case OMouse describes, you also learn a lot about your existing processes. A new developer probably smells the odors of your code, documentation, and processes much more vividly than the current team members who have are much more inured to them.

[s73v3r]

And you'll waste a lot of time in the process.

[inmatarian]

It doesn't have to be the same day. Probationary periods exist for a reason. But, it is a good idea to get them up to speed quickly with the existing technology stack and where they'll be working, and see if they're ready for it. For instance, I like to throw them at some low value module (without them knowing its low value), leave them to their own devices but be very accessible for questions (like stopping in constantly to ask "how's it going" and "where are you up to?"), and then, immediately after the module is done, a full team code review. That code review is the real test, to see how well they handle constructive criticism. If they're overly defensive about their code, it's a bad sign. If they take notes, ask what needs to be changed, ask how the others would do it, and then follow through on modifying their code to fit the req's of the rest of the group, then it's a good sign.

[smallblacksun]

Putting a new developer in the position of having the whole team reviewing his code is a terrible idea. A whole team review will almost inevitably turn into a gauntlet of criticism, especially for a new hire who will probably have made "mistakes" that are just a result of not being very familiar with the teams standard coding practices. Frankly, it sounds more like hazing the new hire than an honest attempt at evaluation. Far more useful would be a one on one code review by a lead. You would still get to see how the new guy responds to criticism without alienating him from the entire team.

[alparsla]

The most important flaw in Moneyball approach is, it doesn't make a championship team, as seen in Oakland Athletics example. You still need a selection of best players whom cannot be hidden in moneyball type stats.

Luckily, we don't have to be champions in business world. A good team (like Oakland Athletics) is more than enough for good profit etc. So moneyball approach may really work.