IDC: 40 Percent of Developers Are 'Hobbyists'

itwbennett writes "A new IDC study has found that 'of the 18.5 million software developers in the world, about 7.5 million — roughly 40 percent — are so-called hobbyist developers,' which by IDC's definition is 'someone who spends 10 hours a month or more writing computer or mobile device programs, even though they are not paid primarily to be a programmer.' Lumped into this group are students, people hoping to strike it rich with mobile apps, and people who code on the job but aren't counted among the developer ranks."

Comments

Too narrow a definition

[barlevg]

people who code on the job but aren't counted among the developer ranks

This part makes this whole result pretty absurd, imo. My job title is research scientist, though I'm more of a data scientist. In any case, you can't do my job without a fair amount of coding. I would certainly not classify myself as a hobbyist.

Re:Too narrow a definition

[Anonymous Coward]

There isn't an engineer, statistician, physicist, etc. out there who hasn't written or doesn't write a significant amount of code in the course of their using a computer as a tool. They're hardly hobbyists. One has to wonder if IDC doesn't think that the code these people write should really be written by 'professionals'. (I'm thinking of the early mainframe days when only members of the Priesthood were allowed to approach the Sacred Iron and perform the Holy Incantations.)

It's likely a fairly useless little article, intended to be read only by anyone stupid enough to believe that the information contained therein is really worth $5,800 (~$193/page!). It must must be good because it costs so much, right? It does appear to be targeted to 'investors' and the 15 charts and figures contained in its 30 pages likely give the investor without a clue -- but with plenty of money -- much to point at and drool while dreaming of places to invest or for the CEO/BoD who's looking for a way to, somehow, justify moving software development. ("Oh look. There's aren't as many 'hobbyists' in Dirtcheapistan. Begin making plans to only hire coders from that country.") By pricing the article at such an exorbitant cost, it guarantees that it will never really be peer reviewed and its almost certain flaws pointed out for the world to see. My fear is that the folks that purchase this report will pick up on the word `hobbyist' and then drive a bunch of HR lackeys to starting asking job candidates about the amount of time they code and begin filtering out perfectly good candidates because they weren't, somehow, 'professional'.

Take this paper with a grain of salt of at least the size you would with anything that Gartner puts out.

What about me?

[Max Threshold]

I'm paid primarily to write software. Then I go home and write more software.

Re:Huh?

[mrchaotica]

The pharmacy billing software company I work for hires people like you to be product owners.

Re:1%

[Anonymous Coward]

In many cases, it's pointless to actually give the programming test.

Just tell the candidate that you're giving them a programming test. Have a system set up with developer tools. Have them sit there with a problem description for while you leave the room. Then come back in a couple minutes later and say, "Nevermind, we don't need you to do this." Make sure it's in a "this is silly, you obviously have skills and this problem is beneath you" way, not in a "we've already filled the position and you're wasting our time" way. (Remember, flattery, even if it's false, is a good way to get people to open up and show you how they really feel.) If they're relieved, show them the door and never call them back. If they're disappointed, give them an offer on the spot. Everyone else is a possible candidate.

You want someone eager to get the job done that isn't afraid of the task they're assigned.

Now, if you have a situation that requires more skill than just code-monkeying as part of a dev team, give them the full treatment before hiring them. (At a minimum, let them finish the test exercise.)

Re:1%

[gbjbaanb]

I agree here - but only to a point. At an interview you have to demonstrate some ability, and as there are so many idiots with bullshit CVs, you have to give some sort of test. Fortunately the tests don't (and should not) be very hard.

However, one test I had given to me a while ago was a code review. They gave me a visual studio project and said "review that, tell us what you think", and of course it had a couple of glaring bugs, a bit of very lazy coding, duplicated code that could be refactored into a common function, and similar. It wasn't about what variable names to call things (except the file called MyClass1.cs). It didn't require me to remember all the stuff I've consigned to Google's stewardship over the years and gave me the opportunity to explain my thinking.

I think such tests are vastly improved over coding tests that you end up writing differently to what the interviewer expected (and therefore he considers "wrong"). When you did tests at school, the teacher never really cared about the right answer - they cared about the working. An interview test that asks you to review code is pretty much the same principle.