Great post – I was just thinking about this very subject this morning, planning on writing about it, and then you beat me to the punch! Quit being so damn prolific and timely, dude. I’m starting to feel like Scott Hanselman over here!
Couldn’t agree more, though. Obviously, coders need to be able to code – a few folks here apparently missed that one. But at a certain point, it’s true – you either get it or you don’t. For me, the aha moment (having come up in the world of managed code) was understanding how memory and processors worked. Once I got tha stuff, and how my languages were shielding it from me, the world got a whole lot clearer, and learning new stuff a good deal easier.
I agree to a point. Clearly a good developer should be able to learn new skills fairly quickly, so qualities like talent and aptitude are usually more important than experience, especially when you are dealing with experience in some specific technology (like low level TCP/IP coding).
However, with a more general skill like Java programming (or programming in general) there is a big difference between 6 months of experience and 6 years of experience. I have been a professional Java developer for 3 years now and I can tell you I know a lot more today than I did two and a half years ago. And I expect to know even more three years from now. Problems that used to take me a week to debug I can now fix in a few hours. I attribute most of that to my experience.
Yes, a good developer should be able to learn a lot in 6 months, but they should be able to learn much more if they are given more time. The idea that after working with something for a few months they will know everything about it is just plain false. And several links to blog entries dwelling on anecdotal evidence and misused statistics certainly does not make it any less false.
I agree. In march of last year I landed my first job as a software engineer for a small company. Before that I was self-employed for about 1 year, and prior to that I pretty much taught myself how to program and did it for the sport of it for about 5 years. I stretched the truth a little bit on my resume to get my foot in the door, but the bottom-line was I could back up this projection of myself because I was confident I had the skills required to hold down the job, and be successful in this career move.
It did take me about 5-6 interviews before I got a job but my current boss seemed to grasp the idea, and he was wise enough to recognize that although my experience seemed to lack on paper that I was still the man for the position. And I’m grateful for that.
So now I’m involved in helping this small company grow which is quite challenging and good experience. The company has been around for a long time and it seems like they have kind of hit a brick wall for awhile and I can see why. I don’t agree with many of there practices. My boss tends to go off on tangents and doesn’t have the knowledge for efficient decision making at times, which does lead to some bad software design. Upper management overwhelms the under-sized under-trained staff with ridiculous deadlines because they don’t understand the means to reach the end. And it really does take time for me to make my mark. Make them feel confident in my judgment and understand better ways of doing things. But it’s almost been a year now and I’m beginning to make some important changes in the development cycle, software design and deployment which are crucial if this company is every going to ‘grow up’.
Another binary post by Jeff where two different concepts are placed in two very distinct piles: oranges here, apples there.
That you “get it” is not sufficient for employment, nor to value what you are worth. I want to hire people who “get it” but don’t have to look at the refs and specs every time they need to do something; I’d rather have someone who “gets it”, but has enough experience for what he gets to reach the keyboard effortlessly. You won’t get a new hire who “gets it” after 6 months in the AS/400 world; nor in assembler; nor in security, nor in a myriad of places where just being at ease with the structure of a language is not sufficient, experience must be gained.
Oversimplification challenges truth, and binary thinking does it to an caricatural degree.
I have a theory that where this happens, there is also a political structure within the company too. If a person is so adamant on getting so specific in thier requirements like stated in your post, then they really don’t have a clue what it means to be a programmer.
I worked for years with Mom and Pop outfits doing basic graphic design and a little web programming before I got my first real programming job. Most places I went into an interview with looked at what I was currently doing and turned their nose up at me because I didn’t do “REAL WORLD” programming. Never mind that I could pass their phone screens and employment tests. The years of experience killed me every time. But being a glutton for punishment after my 60th interview I found someone to take a chance on me and I’ve never looked back.
I agree with Louis. There is no magic formula to hiring someone. It’s a risk every time. I’ve had a few work out very well, and others limp along for years. Experience is only one small part of many things to consider. One guys resume’ listing for the jobs held in the last five years ran two pages. This might work if you are looking for someone to jump from one task to another, but the job I was hiring for took six months to a year to get up to speed. One guy I did hire stayed quit at lunch on the third day. He was qualified, seemed to be a quick study, but didn’t stay (never did find out exactly why). Or the guy who worried incessantly about the cost of a method call, and therefore wrote methods that stretched 10 pages at the minimum. Or the person who thought I was sabotaging him because I only needed a few minutes to find the error in his code.
Like I said, some have worked out well. The last person I hired before leaving my last job found a brilliant solution to a problem I had been struggling with for months. And he kept them coming.
I have wondered if the same criteria of X number of years goes into jobs ads for CEOs, company presidents, and the like.
In the software world, many (not all, but many) of the jobs are still roughly ‘state-of-the-art’ kind of positions. Like the companies asking for “x years of experience” in a technology that is only “x-1 years old”, to ask for specific skills sets when building a new, bleeding edge product is small-minded thinking that is doomed to yield sub par results. Yet it happens all the time.
I have worked in high tech for + 20 years. As soon as I “figure out” a product, I am bored and want a new challenge. And I know lots of people like me – we work for the intellectual challenge. (And the cash, of course, but also for the intellectual challenge…:-). Calls from recruiters asking me about my experience with “x” or “y” product (because they saw it on my resume from years ago) don’t get returned.
Proven ability to learn and interest in working on new product are critical skills for working on “new” software.
I’ve had the dubious experience of having to explain to a recruiter that the stated skill requirements indicate the composition of the TEAM that would be required to build the desired system, and I helped him break the ‘laundry list’ up into pools of expertise that go together - not that I got any of the jobs that we created descriptions for!
Peter Norvig disagrees with you, Jeff. See a href="http://norvig.com/21-days.html"Teach Yourself Programming In Ten Years/a. Smart, fast learning people are no substitute for real experience.
Also, attempting to comment on your weblog regularly results in errors revealing the crappy implementation beneath:
sometimes the year of experience matrix is skeewed to hire a specifc person they want. They have to do that as they are required to let people bid on teh positiona nnd realy they already have a person working in that area and want to renew that project. They than come a a trix that would like reward their preferred candiate the highest point!
Definitely appitude to learn and wilingness to work hard and with due cre is most important as programmer. willinges to stick to spec is critical as programmer. END user interface Design is vastly diffferenet from system or embedded programming.
I have a linkedin endorsement from the author of an OReilly book about a prominent web framework. I contracted for him in 2006 in our metro area where he is also a CTO for a small/medium sized company, and he recommends me for any project.
Last year however some company turned me down because I didn’t have enough recent experience (it had been a year) with the web framework in question. Their loss.
I’d go further - having many years’ experience in a single technology often means that the developer has reached that point where they nolonger want to learn anything new.
“10 years MFC” really means “can’t or won’t learn .NET”
I’ve noticed that many developers, after a few years reach a certain technology, and then stop learning - they become expert in it, and any new languages/frameworks/environments are “too slow”, “unsupported”, “no benefits”.
Do you know anyone who still uses Visual Studio 6 because they say VS2005-2008 are too slow? They’ve got stuck at that stage. Know someone who learnt .NET/WinForms but not .NET 3.5? Stuck again. Those people may be smart, they may have many years’ development experience, but if you need them to re-train, you have a struggle on your hands.
Sometimes of course, it’s not the developer’s fault: many companies hire someone new for any new projects, and the developers on their old MFC application are “too valuable” to move on to another project.
I think companies should state, “must NOT have 3-5 years experience with X”. Anybody who’s worked with some technology for 3-5 years is probably bored of it and will not be motivated to do their best. They won’t be learning anything new, they’ll just be doing what they were already doing for that 3-5 years that’s listed on their resume.
I agree, in a job posting I was interested in last year, I pointed out to a hiring manager that the job they had open required someone with four years experience in WPF. I also pointed out that they were limiting themselves to only people that worked for Microsoft and had access to WPF long before it was publicly released. Needless to say they corrected this error. The hiring person probably didn’t know the technology but only knew the acronym and that it was for developing “cool windows UIs like on the Mac”.
Jeff, you may have a point since after 10+ years of coding my code still looks like crap…however, it doesn’t account for how my 10 year old code looks even worse. /Mats
