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.

Re:Too narrow a definition

[rnturn]

``because a lot of research code is throwaway stuff''

Another recent /. post (about scientific data loss) makes me think that little, if any, research code is really `throwaway'. That code -- along with the data it processed -- represents part of the work effort leading to the published results. Data without that code is almost useless because the next researcher who wants to built upon his predecessor's work will likely want to know how you went from the data to your result. Without the code all they can assume is that some magic was involved. Or, if they go through the process of re-processing the raw data and get different results draw the conclusion may be that the original results were faked.

Re:Too narrow a definition

[rnturn]

I can recall an incident where a number of Ph.D. dissertations were called into question because of a bug that had been discovered in a mainframe statistical package they had used. If memory serves, the University was contacting graduates and asking them to revisit their results to ensure that the bug didn't adversely affect the content of their work. Perhaps, nowadays, the University wouldn't care so much though I'd hope they would if for no other reason than to maintain the school's reputation.

I wouldn't call pseudo-code a reliable indication of what actually processed the data. It's pretty much the same thing as writing a specification and getting a faulty interpretation of that spec. We've all had an idea of what we wanted a piece of code do only to find that it didn't quite live up to our expectation due to some subtle bug (round-off error, etc.). I've spotted weird coding in other colleagues' code that introduced problems in the results. Perhaps that experience is why I'd still like to see the code. YMMV

Re:Huh?

[i kan reed]

Not me, coding for fun and 10 hours a month is way better than 40 hours a week on stuff you don't really care about.

Re:1%

[i kan reed]

95% of everything is crap. I don't know if you've tried to interview people for serious programmer positions lately, but about half of applicants seem to outright fabricate their credentials.

What about me?

[Max Threshold]

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

Re:1%

[clickclickdrone]

Which is why you give a programming test onsite.

Any number of which I'd probably fail as pulling random function names/jargon out the air isn't my forte. OTOH, I've been coding for 35 years, know where to find the answers to anything I need to know and can crank out pretty much bug free code until the cows come home. As an e.g., last task I was given was to monitor an IBM MQ for SWIFT payments, parse them, pull out the good stuff, validate it and put it in an oracle DB. Wrote it in ProC. Never used ProC (had used C though), Oracle or MQ before yet amazingly it went through testing with only one minor bug and that was a problem with the spec rather than the code. I even threw in diagnostic modes you could select with switches at run time to give verbose logging. Last count I've used 20+ languages from Assembler to 4GLs, across various Unix, DOS, Windows and VMS. As I said though, I'd be amazed if I could answer more than a handful of questions on the spot even though I was (so long ago..) a MCSD or whatever the MS dev training used to be called.

Re:Huh?

[mrchaotica]

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

Re:Huh?

[i kan reed]

You are mistaken, I'm a 40 hour a week programmer, and I enjoy the code, just not the resulting application. I achieve more in 10 hours a month when I'm making something interesting than I ever could with 40 hours a week on the job.

Re:1%

[TheRaven64]

Someone I was talking to a few months ago claimed that around half of the applicants they get fail to be able to write fizzbuzz in their interview. This is just a function that has to take an input number, print fizz if it's divisible by 3, buzz if it's divisible by 5 (fizzbuzz if it's divisible by both), or the number otherwise. It's a trivial use of simple flow control and if you can't remember the name of a print function in your language of choice (no marks deducted for using printf instead of puts) then there's really no hope for you.

Re:I find the term "hobbyist" to be offensive

[clickclickdrone]

Anyone agree with me here?

Not really, hobbyist isn't a synonym for bad.

You left out hobbyist coders

[Ukab the Great]

who do it for the groupies.

I never liked this title:Hobbyist

[GoodNewsJimDotCom]

Look, a lot of people are trying to start a business, it should be treated the same as work experience.

The funny designation people say when talking with HR is,"Oh, you actually made money with this home business, then I guess it counts as work."

It doesn't matter you busted your tail for 10 years in projects that failed, suddenly the less ambitious one you did that made a couple bucks actually counts as work.

So lets drop the hobbyist title. If someone is working a home business that isn't yet profitable because there is an awful lot of overhead to code first, they've been working that time.

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%

[Anonymous Coward]

100% of chan pedos would pass that test in 20 languages.

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.

Re:1%

[Buzer]

You don't need to use mod for fizzbuzz. It's likely the most effective (besides precomputed tables), but there are several alternatives. To name some:

1. Create your own mod function (you can most likely leave out dealing with negatives and overflows as long as you just point that out). Given dividend X and divisor Y, while X>=Y: X=X-Y and finally return X.

2. Take human approach and convert the number to string. Skip 0/print it depending on definition. If last number is 0 or 5, it's dividable by 5. For dividable by 3, you loop thru the string and sum the numbers. Repeat until the length of string is 1. Now compare it to 3, 6 and 9 (you can convert it back to number or just compare the string of those). If it's true, it's dividable by 3.

Surely you could create at least one of those in some language you know?