Most jobs want experience, even those jobs classified as “entry level.” This is especially true in the software development field, and it’s easy to take that as an insult, particularly if you just spent four years getting a bachelor’s degree, and thousands of hours tinkering.

Using professional experience does a few things for an employer. In the first place, it guarantees at least a modicum of human normalcy, which is important: we have to be able to communicate with our coworkers and treat them appropriately long enough not to get fired. That problem is hardly unique to software, but it’s exacerbated both by the need to communicate requirements clearly between varyingly technical stakeholders and by the tendency towards introversion. Some really smart people who are able to develop software very quickly might be unable or unwilling to understand the customer’s needs or treat them with respect, and that can make even the best engineer less effective.

Experience also allows a developer to dive in and begin work without substantial ramp-up on documentation. Regardless of whether you start with the model, the view, the controller or the database layer, knowing what those concepts are and how they interact allows you to begin by actually writing code instead of heading over to frameworkofthemonth.com and scratching your head and watching youtube tutorials just to get the ball rolling.

Finally, experience provides an understanding of the gotchas in a given language. I think this is the real reason why we see job posts asking for five and ten years’ experience in J2EE or .NET or whatever: it’s not that a less-experienced developer won’t be able to write code, or even that he won’t be able to establish a sensible architecture: it’s that he won’t understand the edge cases and sometimes non-intuitive behavior of certain features of the language or framework.

A funny quirk of the Java language bit me pretty hard earlier this week. The computer has a bunch of different ways to represent numbers, all of which have tradeoffs. In college, everything was an ‘int,’ an integer represented with 32 bits of binary. This lets us accurately present anything between -2,147,483,648 and 2,147,483,647, and that’s enough for most toy or academic purposes. In professional settings, we end up using a lot of ‘long’ numbers, which have 64 bits and can therefore represent numbers between –9,223,372,036,854,775,808 and 9,223,372,036,854,775,807, or as we doctors like to say, “enough.” Little-i ints and little-l longs are just the numbers themselves, but we also have big-I Integers and big-L Longs, which are bigger objects representing those numeric values with some verbs attached – we can ask a Long how many zeroes are at the end of it, but a long doesn’t even know what a question is, much less the answer.

Despite that, it makes sense to be able to ask the computer whether a Long and a long represent the same number, and you can do just that, by saying “if l == L.” This works just fine for values less than 127. Since my little fake test environment has fifty-ish users, I was able to check whether the users had the same ID using ==.

But when you get above 127, Java starts acting weird. It doesn’t automatically convert a Long to its long value when faced with the == question. Instead, it compares the memory addresses, a process akin to asking two people where they heard some information and deciding that the information must be different if it came from a different source. Why should it work for 126 and not 130? I don’t know. Some former Sun employee knows. I’d much rather have the == operator never work on Longs than have it work sometimes and then fail when I commit code to the world-facing web site of a multi-billion-dollar company.

The quirky, foibly, five-years-matters experience doesn’t only apply to developers, either.

My precision rifle is a Steyr SSG 69 PII. A friend of mine called and mentioned that there was one for sale and that the seller was having trouble moving it, so I bought the thing, and ran it without issue as it came from the box. But being the way I am, I had to take it apart, and when I put it back together it wouldn’t reliably strip the next round from the magazine.

I misdiagnosed the problem, and bought a ten-round factory magazine to replace the five-rounders it came with. Steyr’s factory mags are fragile and pretty terrible, but the ten-rounders were no better than the five. Then I swapped the plastic trigger guard and magwell for an aluminum CDI Precision replacement, which offered both better durability and the ability to accept AICS magazines (evidently I got one of 30 or so that were ever produced, which is cool). The rifle didn’t behave any better.

Having exhausted my nonexistent expertise and my patience (and done a terrible job at a match in the meantime) I took the rifle to a gunsmith in Missoula. He proceeded to sit on the thing for seven months, during which I moved. I got the rifle back from him, and the firing pin wouldn’t even stay cocked – it was missing a spring (which I replaced with a 69-cent part from Ace Hardware) and a set screw (which Steyrarms sent me for free).

A friend of mine started getting into handguns, and did a transfer through a kitchen table FFL who turned out to be a pretty competent gunsmith. Having spent some time messing with the rifle himself, my friend suggested that we could take it over and see whether the man’s expertise would be any use, and we did.

So we drove the several miles to the guy’s house, and he greeted us in his wonderful German accent and told us some brief stories and described his NFA business and corrected my out-of-date numbers on what a registered M16 costs. Then he looked at the rifle.

“Oh, yeah, I know what’s wrong,” he said. “Steyr, I don’t know why they do this, but the plastic stock is very flexible. You have to get a torque wrench when you install the action screws. Otherwise the stock flexes and it’s just terrible. You should get a McMillan stock. In the meantime, I can do it for you, but it’s just as easy if you do it yourself, and my shop rate is $60 an hour.”

Just like the Long != long issue I had, this is something that I could technically have known, something I might even have read at some point before. But because neither of these had caused me specific difficulties in the past, I didn’t remember them. In both cases, it took the oversight of more experienced people to diagnose the problem – not only that, it took a specific sort of experience, and in both cases the first expert I approached couldn’t solve the problem.

So general experience and education are great, and it’s important to have theoretical understanding of the factors at play. But vendor, environment and product-specific experience also matter. We can laugh at the HR guy who writes “10 years experience with Node.js” on a job posting, but the concept is sensible: ten years offers a great many opportunities to run into trouble, and that’s true even if you’re getting one year of experience ten times.