I recently met a gentleman who asked me for a bit of advice: he has a passion for programming and, after being in the workforce for several years as a technical writer wants to make the move into software development. He’s done some programming on a very part-time basis at work, but most of what he’s done has been for classes in his Masters program. The MS program he’s attending is an evening program and lies in the middle ground between a computer science curriculum and a software development program.
He’d like to know how to break into the field. It’s a good question – there are many people out there who’d like to get into the field who’d be able to hack it, but didn’t get an undergraduate degree in computer science (perhaps didn’t get a degree at all), don’t understand much about professional software development and don’t have any experience. While pondering his question and coming up with some answers, I’ve read questions from others asking about how to break into the field in similar but not identical situations.
Alas, I’m not the best person to be answering this person; I took what seems a traditional route these days – got a computer science degree, put out some resumes and applications and found a programming job as I graduated.
Even though my advice may not be accurate, therefore, I present it in two parts: part one discusses two particular obstacles I’ve seen in the industry (decries, perhaps, since I have little practical advice). Part two will feature specific advice.
The Obstacles:
Obstacle the First: “We Hire By Keyword”
Allow me to paint with a broad brush: there are two major schools to hiring for programming teams. One holds that it’s best to look for smart people who’ve a broad background and who can learn various tools and techniques. The other school holds that programmers are the sum of the languages and technologies listed on their resumes, and nothing more. I’ll not discuss the first school here; others have done a much better job than I’m able.
We Hire By Keyword is typical of consultancies and of companies where programming falls under the IT department and is secondary to the business at hand – in other words, any company that directly sells the time of its employees or that doesn’t “sell software” or do something closely related. Hiring in these companies is usually centralized through an HR department that’s responsible for hiring everybody in every department – and it’s impossible to know the requirements and attributes that signal brilliance for each and every single roll in these companies. A master salesperson is probably a very different person than a master accountant, but they all go through the same application filter.
How does this relate to you as a programmer? The way HR tries to sidestep this issue is to get a list of requirements from hiring managers in the form of various technologies, then run every programmer’s resume through a keyword filter and grade them by the number of matching keywords. Some hiring managers do the best they can to provide an open list – maybe just asking for a C# person – but then get rebuked for not being detailed enough. After all, just asking for a C# programmer will net a lot of resumes & these will be resumes that have to be further processed.
It’s much easier all around to look for a programmer with 12 years of C# 3.0 experience on Windows Server 2000 and who has 3 – 6 years of Microsoft SQL Server 6.5 experience in a clustered transactional database environment. Makes for vastly fewer people to follow-up with and interview.
Why’s this a bad thing?
- Those who make it through the filter are just as likely to be lucky or to have embellished their resumes than to be smart.
- These filters reward those who’ve had the same year of experience 10 times much more than those who’ve had 10 years of different experiences.
- The illusion of a skills shortage in IT is, IMHO, a manifestation of the over-filtering problem. That is, when overly specific job ads aren’t a cover-up to try and hire a specific H1B holder and indenture him/her to their employer. But that’s a separate discussion.
If I hire a contractor to remodel my kitchen, I don’t interview contractors and ask if they’ve used a #2 Phillips screwdriver but then send them on their way if they’ve not used a #3 Phillips screwdriver on maple cabinet doors. No – one looks for good references and experience, talks about previous projects and ultimately goes on some faith. Interviewing programmers is analogous – one should look for previous experience, talk about previous projects (professional, personal and school projects) and look for good references, among other things. Again, others have written about this at much length; the important thing is to, as Joel Spolsky says in the Joel On Software blog, look for someone who’s “smart and gets things done”.
It’s much easier for a smart person to learn a tool than it is for a tool to learn how to be smart.
Obstacle the Second: “Only People Who Are All-Consumed by Programming Are Worth Hiring”
There’s a… a belief that some hold out there. Or maybe it’s a grudge. Or maybe it’s an attitude based on misapplication of experience. I don’t know. But there are those who hold that only programmers who think about computers all the time, who work all day programming and then turn around and program as a hobby, who are easily excitable by the technology du jour and who spend all day decrying the faults of wetware – only those who’ve given their lives to the computer can be good programmers. All else need not apply, for none else are worthy.
I can understand some of the reasoning behind this, just as with hiring by keyword. Most all of us have worked with at least one person who makes no effort to stay current in any aspect of the programming craft or to learn anything new. Or worse, those who expect “the company” to tell them how to keep current and will learn what’s paid for and on company time. I’ve nothing against these attitudes – and I believe strongly that company-paid training is important (unless you’re an independent contractor, in which case it’s all your responsibility). Still, these people become the co-workers who are able to contribute less and less as time goes on. Then these people become ex-teammates. Then ex-colleagues who can’t find jobs and can’t get interviews. Trust me, I get the impact these people have on those who work with them. And we all know that one year of experience repeated twenty times does not make for twenty years of strong experience in the field. Keeping current in the field should be a joint effort between you and your employer but in the end is your responsibility. Right. Got it.
There’s a significant minority out there that takes this attitude out to absurdity, spending all their hours tooling around on the computer and basing one’s life and outlook entirely in world of the screen. While in the end this is one’s right and personal choice, I reject the attitude and reject the attitude that people who get out into the big blue room are somehow not dedicated enough to the “programming cause” and make for bad coworkers. This is the attitude that shows up for work at 11:00 in the morning and whiles away the hours IM’ing friends from work, surfing the web, &c., and staying until some off hour in the evening – and the attitude that derides those who show up earlier, do work at work and leave at a reasonable hour as “not dedicated” to the cause.
Nobody likes working with someone who doesn’t pull their weight. However, someone who’s at work 70 hours a week every week usually isn’t working very hard very many of those hours. Usually they’d do well to come in a little earlier, leave a little timlier and focus with the time they do spend at work. Some sunlight, hobbies that doesn’t involve a screen and a little exercise make for, in my experience, much better developers than those who while away all their hours in front of the screen.
In short: depth and passion are great but are compliments to, not substitutes for, breadth and versatility – the broader your mind, the more inspiration you have for the next great discovery. Work to live, don’t live to work – you get more work done that way.
