Skip to main content

Why The New Guy Can’t Code - Really?!?!

Thank heavens Jon Evans posted Why The New Guy Can’t Code, an explanation for all software development shops to read before hiring someone. This article explains that the evils of all poor hirings are:
a) Microsoft's fault
b) old systems
c) hungarian notation
d) not female

It's not the fault of poor HR, a bad interview, or even the lack of the supervisor's ability to explain a problem - no, the above are the reasons that the new developer "can't seem to get up to speed", "shows basic ignorance", and produces work that "is so kludgey that it...must be rewritten"

OK, I'll agree with a few points:
1. The brain-teaser questions.

Sure, they're fun - HR loves them because they can remember them - but ultimately, they were designed to show how people think about problems and how people arrive at solutions. They aren't actually a bellweather, especially as most of them are posted online.

Can you imagine a MacGyver interview? "You're on a plane plunging to the ground, you have a paperclip and a coat-hanger and 10 people to save, how do you do it?"

How do you test knowledge? Yes, you ask them to solve a basic problem. Really though? The best interviews I've ever had or even given involved giving a real world scenario. "We're building such and such a system, how would you do it?" If you're what the company wants, you'll likely be describing the same system they are building. If you're good, you'll give some ideas that they may not have thought of (not that they would let on). If you're great, they'll simply walk out going " I have to hire this person".

2. Old Systems.
Yes, we all get that the new systems provide features that no one had when growing up and learning systems. That doesn't mean those skills are not valuable. Maybe it's just me but I wonder how I would get along if everything changed and we lived in a world where electricity was banned or forgotten.

I'm not saying that you have to know how to forge an steel but I remember years ago someone arguing for procedural programming over OOP and guess what? Today there are people who will argue for MVC or MVVM patterns or writing 1s and 0s over 0s. The fact is, learning programming is the same - the tools make it easier, but they are still just tools. Learning good programming techniques is the same, whether it be C+ or Python and Ruby.

3. Hungarian notation.
OK, I know Jon didn't go after hungarian notation as a concept - he merely used it as an example of someone making tons of money from an idea implemented by Microsoft but still, is hungarian "the dumbest widely-promulated idea in the history of the field"? While I'm sure a**hole programmers like to think that code should be unreadable except by themselves, MOST developers recognize that code should be read-able. While a variable named CustomerPhoneNumber is obviously a string even though it's named Number; if your newest hire is from a foreign country, they may not know that SocialSecurityID should be a string but EmployeeID is a numeric field because of the way a system was designed.

Hungarian notation does solve a particular problem for any language. Is it perfect? No. Is it overused? Yes ; but then so is any naming convention that results in a variable named TableWasRetrievedByInvalidNumber (while a fabrication, naming variables descriptively have been taken way too far).

In retrospect, it's crazy to think that some people still have horses to travel, when there are cars or Segways. Despite the fact that roads were only built the size they are to accommodate them.

4. Not Female
Not even going there. I'm sure there are female programmers that suck, even if Jon's never met one.

I don't know Jon Evans, a fellow Canadian, but he calls himself a software engineer yet his history shows very little software engineering. He graduated from Waterloo and spent most of his time writing novels. While I'm sure he's done some software development, most of it appears to be in order to scrape by while writing. I'm sure the post was written with the best of intentions..actually, I think it was written more to incite than to explain.

Maybe the real message got lost in the wording: "Don't interview anyone who hasn't accomplished anything." As he accurately states: there is no excuse for software developers who don't have "something" that they can point to and say "I did this, all by myself!"

That isn't something new, though. If you hired someone without seeing what they could do, for ANY field, except maybe theoretical physics, you likely shouldn't be hiring. I wouldn't hire a writer without asking them to write something. I wouldn't hire a tester without either a) seeing them test or b) know their testing work.

And this isn't just about the new guy - there are lots of "old" guys who have gotten to the point where they rest on their laurels and don't improve.

The comments on this post are what make this article:
a) Pair program a recruit with your top engineer for 30 minutes. (hell, I'd say any engineer)

b) train before you hire

c) hire them to produce

If the purpose of the article was to generate conversation (and is there any other reason?), then it succeeded.


Popular posts from this blog

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator)

So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinctions I…

Security in Windows 10

 discusses some Windows 10 privacy settings and their implications.

"Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary." "In other words, Microsoft won't treat your local data with any more privacy than it treats your data on its servers and may upload your local data to its servers arbitrarily"
I did a quick install on a VM choosing the Express settings. When I fully deploy this on a real workstation, I will likely choose to wade through all of the individual pages, as David recommends.

Of course, losing one's privacy is nothing new - it's happening all over the place (despite Santa Ana's police force's lawsu…


I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis.

Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it.

Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners"

Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message.

Guess that means the iPhone 8 will be back to boxy.

And honestly, Apple Watch is not worth "one more thing" --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thing" wor…