Last month, discussing the habits that developers should cultivate that will keep them employed, I emphasized aspects that were visible outside your current employment. But the easiest way to stay employable is to be highly valued at your current job; believe me when I tell you that searching for a job is vastly more productive when you are not in financial peril.

Before I turn to those aspects, though, I’d like to talk about a fascinating data point from Aline Lerner’s “Lessons from a year’s worth of hiring data”: spelling and grammar mistakes in your resume and initial communication matter more than anything else in predicting whether or not you’ll receive an offer. Proper English is more important than your GPA, the prestige of your college, or even previous employment at a top company such as Google, Apple or Microsoft! Perhaps more precisely, improper English is more damaging than other weaknesses. And although I have not seen Lerner’s data, I am confident that the grammatical errors are not esoteric ones, but mistakes of tense agreement, inconsistency in pluralizing, and homonym swaps such as its/it’s and their/there.

One costly mistake I see in lots of resumes and CVs is inconsistency in formatting lists and sections. You would never submit sample code that was inconsistently indented, had improper line endings, and used inconsistent bracketing and whitespace rules. Yes, it’s time-consuming and frustrating to manually tweak the beginnings and endings of every section and bullet item so that they are consistent. But what does it say about your programming discipline if you do not take that time?

Unfortunately, I can’t offer you the assistance of SD Times’ editorial staff, who save me from embarrassment every third sentence, but you can hire a well-reviewed copy-editor on Upwork for around US$60 an hour. That’s a trivial price to pay for the single-biggest determinant of a job offer.

Bottom line: There is no more shame in making a grammatical mistake than in making a coding mistake. The shame comes if you don’t care enough about quality to have a system in place to catch it.

Most analyses of hiring show another strong factor, which is the ability of the candidate to make money. The relationship between an individual developer and revenue is usually pretty tenuous, but the equivalent attribute is when a developer is associated with shipping projects. In a real sense, no software is ever finished, but gaining experience in delivering value to end users and focusing on customers—not code—is the software development equivalent of being a “closer.” Coffee is for shippers.

Bottom line: In your resume and during interviews, don’t dwell on your unfinished work, no matter how interesting or cutting-edge it is. The game framework in alpha is the 21st-century equivalent of the novel in the top-drawer. Instead, emphasize how your code has delivered value to real people.

Especially in high-tech hotspots such as the Bay Area, hiring managers have been scorched by turnover. Time-to-first-check-in is often weeks with new developers, and it can be months before someone fully understands the project and its context and starts to contribute at their full potential. But with salaries continuing to rise and career-growth expectations distorted by a combination of an industry boom, the youthful age distribution of programmers, and competition for talent, there’s no gap between the thought “This person has great talent!” and “Will this person leave us after a year?”

This question of whether you’ll stay at a company is coupled with the question of whether they’ll want you to stay there. I think this distrust of commitment is the dynamic that’s led to today’s absurdly long and byzantine hiring process: interminable rounds of interviews, programming tests, whiteboard coding, code reviews, lunch with the team(s), etc.

As far as habits go, I think the one to emphasize when it comes to “cultural fit” (a.k.a. likability) is being a team player. Here’s a secret: All those ads looking for “ninjas” and “wizards”? That’s just puffing by, at best, companies that overestimate their own elite capabilities and, at worst, blame their employees for their own managerial incompetence. What it most certainly is not is a casting call for prima donnas.

Bottom-line: I have enough of the stereotypical nerd characteristics to be the wrong person to give much advice on fitting in socially. About the only concrete thing I can suggest is that you avoid saying “Well, actually…” during the interview process.

Finally, we have the last (and most important) habit of being a highly employable programmer: Have an exit strategy. I hate this one because I love programming. I wish it were reasonable to expect to be paid as a professional programmer until the day you retire. It isn’t. Our industry has long had an ageism issue, and the increase in startups, with their high-risk, high-intensity models, has shifted the age distribution even lower. And even though offshoring is currently unpopular, one of the themes of these columns has been that the current good times cannot last forever. In addition to inevitable cyclical downturns in the technology sector, it simply defies logic to expect software development to forever stay immune to salary pressure from those in developing economies.

For many developers, the most attractive exit strategy is to become a development manager. With the seemingly reasonable expectation that the software sector will continue to grow, it is not unreasonable to believe that more and more managerial positions will open. Managing software developers has been famously compared to herding cats. It combines all of the uncertainties and frustrations of programming with the utterly inconsistent and nondeterministic thing that is “human nature.” Once you become a development manager, you’ll dream of having a problem as debugging a memory leak or race condition.

But at least you’ll still be developing products and delivering value to customers. On the other hand, you’re going to have to interview a lot of candidates, including some who will “Well, actually…” you during the interview process. Don’t hire them.