Slashdot Mirror
Only 32% of Java developers really know Java
prostoalex writes "Research firm Gartner draws attention to the fact that less than a third of people who put Java on their resume actually know their stuff. The knowledge gap between someone who can successfully write a System.out.println() and someone capable of designing and implementing a complex Java system brings to companies being back-logged with pending projects."
How shocking this news is to me, because it confirmed a survey report I just read yesterday: that 68,015% people lie in their resumes!
For the record I do NOT ask those boring certification style questions that you'd only know the answer to by memorizing the spec. All the questions we ask start with "here's a problem, now solve it with real Java code, please." If I've learned one thing, it's if somebody groans and complains that writing code is so trivial you shouldn't even ask it, then sit there and force them to write code because chances are they can't.
www.HearMySoulSpeak.com
So true, that's why most people walk where they want to go, actually write letters, and live only off what the land provides for them.
stuff
And just because they may know the syntax, that does not mean they can write code worth a crap. I took over a project where a guy wrote his own xml parser while there were tons of free ones on the market. That was a disgusting mess the ended up being easier to convert to real parser rather than fix some parsing problems. He also used count to 1 billion loops when spawning external processes because he didn't know about waitFor(). At first we could not figure out why his code was so slow. Add on top this was all done in static void main, which no other methods or calls.
He has moved on to writing web application in RPG for another department, where every new group of pages gets deployed on a new port...they seem lost on the whole url concept
Knowing Java is like knowing English (or any language.) Just because you know the language does not mean you are any good at writing poetry.
Soccer Goal Plans
where "MDA" is Compuware's acronym for "buy our software and generate all your code". And since "highly skilled developers recognise the value", anyone who doesn't "recognise the value" and buy their product is an unskilled dolt.
The Army reading list
This brings up the point:
What do you have to know to put a computer language on your resume? Let's say that I put "Java" on my list. Am I expected to, say, know all of the built-in functions for a vector, or string, during my interview? If I put Python down on my resume, am I expected to know the names of built-in function overloaders for classes or the functions and parameters for the re module?
Basically what I'm asking is, if I put a computer language down on my resume, should I be expected to code something at an interview immediately without looking at any references? This doesn't seem unreasonable, if the program were simple, but I could imagine employers asking for more complex things. How complex is too complex and how much specific information should a computer programmer retain about a certain language, say, after not using it for 3 years (he was doing VBScript just until he could pay off his debt, I swear)?
I think it's more important to know "how to program" rather than "how to program in X" because the skills you learn in one language are usually easily transferrable to another, as long as you have lots of experience in different kinds of languages: functional, procedural, OO, assembly language, etc.
As a side-note, it looks in the article like by saying that 68% of employees don't understand Java, he really means that 68% of employees have never heard of MDA and have no idea what the hell it is, or don't quickly "recognise the value of MDA," since, of course, all highly-skilled Java programmers do.
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
I agree with your statements if a distinction is added between procedural and object oriented languages.
I have seen too many "old school" developers who havn't the foggiest idea about OO who think they can code in Java because they know the syntax.
All languages are not equal.
Soccer Goal Plans
This is exactly my experience. I've been developing in Java for about 8 years and I think I met just 10 other people who really know their Java. And of those 10 people just about 2 or 3 are able to design an enterprise class application.
:-(
It's not just Java developers, in the booming years a lot of people were hired by IT consulting firms here (NL) that shouldn't be near any computer at all. I've seen system engineers who studied politicology and got an MCSE who don't know the most basic thing about Windows and are not able to solve any problem at all. I've met tens of 'project managers' who don't know anything about IT and even less about software development and are too stubborn to listen to people who do know their shit.
The worst of all are VB 'programmers' who are just able to point and click a basic application, but don't have any feeling for what a programmer should be able to do.
The worst is title inflation. Every donkey is a 'software engineer' these days, and if you are able to actually design a piece of software you should call yourself 'architect', otherwise people won't take you seriously.
Because 'programmers' are seen as monkeys that type and are doing a trick that every other monkey can do.
I agree, I have stopped taking the Gartner group seriously because too many of their reports in the past are highly skewed, and wreak of funding from some party interested in the "findings" leaning in their favor.
And as for the sales pitch, you could almost tell it was coming from the moment they brought up Compuware.
those who really know their stuff
More than buzzword compliant resumes, I've been more interested in people who could show me nice looking code and explain it intelligently to an audience that includes people with varying levels of expertise.
I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.
That said, I can see the temptation to use stupid HR tactics to try to screen out smokeblowers. Problem is that it's difficult to devise a system that simple, where a non-expert in HR can turn a crank and cull the dolts from the field with perfect accuracy (it's like defending against spam). You're likely to let posers through the gates (false positives) and cull out an occassional gem that looks unpolished (false negative).
There's a good reason people resort to informal social networks for recruiting (that is, asking around if anyone knows anyone that's good and looking for a new position) - it's because the crank turning procedures are so unsatisfying.
"Provided by the management for your protection."
The studies I'm familiar with showed that it took 5 years to become competent in C++, and that was before they added STL. So I suspect the statistics for the number of alleged C++ programmers who actually know the language would be even worse.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I don't really know what it means to "know" java. The language's entire approach is to be an object zoo rather than using a few elegant commands to do most anything. Therefore, most of Java programming is looking things up in the docs. That my friend, is the most important skill.
There's a few main types of programming styles: Object Oriented (Java), Functionally Oriented (C), Procedurally Oriented (LISP), and hybrids (C++, Perl). Once you learn how to think in the way required by each of these styles, all that's left is memorizing syntax and commands. And that's what man pages are for.
-- Political fascism requires a Fuhrer.
Basically I set up a situation where I want to create a hashmap of numeric counters such that I am going to increment a million times, but only store 100k keys into the table, and ask people to write me the structure to do it.
I have [or have had] a fairly extensive knowledge of the J2EE Collections Framework, and I don't have a clue what that "sentence" is supposed to say. In fact, screw the "sentence"; let's concentrate on the clause create a hashmap of numeric counters such that I am going to increment a million times, but only store 100k keys into the table. What does this mean? "Numeric counters" of what? "Increment" what? "Keys" into whose "table" of what?
If I were the interviewee, and my prospective boss couldn't explain himself any better than that, then I'd give some serious thought to alternatives such as bagging groceries, hanging drywall, or pushing a mop.
PS: You can make upwards of $20/hr hanging drywall; of course, if you don't wear a mask, the dust might take its toll on your lungs, but hey, we're young and we're gonna live forever, right?
But it is mind-boggling what people can get away with on their resumes. Knew a guy who claimed to have graduate degrees from schools whose names he couldn't spell. You'd think employers would spot that, but no -- he actually held a couple of director-level jobs at the height of the bubble.
I really should get a little more creative with my resume. People who see it always ask why I don't mention where I got my 4-year degree. Answer: I don't have one. Which is a pain -- some companies won't even talk to me because of it. I could fudge up a degree from Whatsamatter U (double major, computer engineering and journalism). I'm sure nobody'd check. But I'm too much of a coward to pull off that kind of fib!
Oops. Just had a thought. I know Java. My credentials are impeccable: I wrote the JDK release notes for almost a year, and I once played a video game with James Gosling! But I've never worked as a Java programmer, being absolutely the worst coder on the planet. But if the shortage of Java programmers is that bad, maybe that's not such a problem!
buzzwords rule the market from the big business' point of view.
.NET implementations they don't control), it is an open standard, it has excellent facilities for interfacing efficiently with native code, and it addresses some serious limitations of the Java language. This is progress. However, even C# is still years behind the state of the art in programming language technologies.
Java did represent an important step for industry beyond C++: it was the first widely accepted language with runtime safety, garbage collection, and reflection. Those aren't just buzzwords, they make a real difference.
On the other hand, Java has failed to keep up: Sun's irrational insistence on insulating programmers from the underlying platform, their intellectual property claims and licensing strategy over Java, and their failure to evolve the language mean that Java has remained a poor choice for many applications.
C# improves over Java in several of these areas: it is "just" a language (Microsoft actually doesn't seem to want you to use third party
However, those who really know their stuff normally stick to the older languages... hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.
You mean, older languages like Lisp, Modula-3, CLU, Smalltalk-80, Algol-68, Prolog, and Scheme?
Or do you mean older languages like Visual Basic, C, and Fortran?
There are good, well-designed older languages, and there are poorly designed older languages. Many people seem to stick with poorly designed older languages out of habit and because they don't know any better.
If you are referring to C and C++, they are, in fact, relative newcomers as far as languages go, and they represent a significant step back over the languages that preceded them. And both C and C++ were enormously overhyped at their time.
OO design is all over the map. It is all based on opinions and different "gurus" have different opinions. I find very little consistency in OO designs. You might as well just slap classes and objects together until it works. Perhaps this is why Extremem Programming is becomming popular: it at least formalizes the trial-and-error incremental hacking process needed to get OO to work.
On the other hand procedural + a big database is a lot more consistent. You group code mostly by tasks or events, and a normalized relational database becomes the river that connects all the individual tasks/events. The size of a given task/event stays relatively the same regardless of "system size". However, OO just turns into a big sea of speghetti classes interlinked in a pointer-like mesh such that you have to grok the entire system to know how any one peice works. Relational is more logical and refined than pointers. (Past bad procedural code was often caused by limited languages and/or lack of a database.)
If there is a consistency to OO design, I have not seen it and/or OO fans don't agree on what it is. It just turns into an endless buzzword contest. OO has been the biggest boon for buzzword snakeoil salesmen in decades. Some say OO design is about modeling human interaction/resposibility, others say it models "little machines that interact" (Simula-style), and other say OO is something else altogether.
The problem is not Java, but OO design. It is bankrupt. It has no center, no solid rules, and no consistency from guru to guru. Mod me down if you must, but it is the ugly truth.
Table-ized A.I.
Java is a very strict OO language. You cannot get anything done in Java without a myrid of class extensions and "implementations." This has the great benefit of allowing lots of developers to work on very specific parts of a project and not run into eachother very often. This has the very negative effect of discouraging creativity in the individual programmers work since so much is set in stone.
...Yes, that was two rants in one. It's twofor day here on /.
Most Java programmers end up as class monkeys, taking very specific directions from a select few who determined the entire arcitecture of the system. This is not programming as an art. This is monkey work. Put them in a position where they need to use Java (or any language) to solve a real problem and they will fail.
Java has had the misfortune of a gigantic hype machine pushing it. Because it could not live up to the hype in some areas a lot of people have dismissed it. This is probably less Java's fault and more the fault of those who consider it "dead." For they should look at the language and realize where it's strengths are.
Java in the browser - DOA. It sucked. Still sucks. And nobody uses it anymore (or nobody SHOULD...)
Java as an App - So it turns out that the whole "corss-platform" thing was a joke. Multiple JVMs across multiple OSes made for far too many variables. Write-once, run-anywhere it most certainly is not. And these days you have multiple GUI implementations and their VM/OS-specific quirks.
Java on the Server - Ok, this has a future. Cross platform doesn't matter. Speed isn't an issue nearly as much. And there are a slew of components already available (J2EE) that do the hard part for you.
I don't consider myself a Java developer (I design/build UIs) but I would be pretty dismayed if I saw a self-proclaimed Java developer resort to looking up that "algorithm" on google. Granted, the parent post's wording is a little ambiguous but that shouldn't stop an interviewee from asking a few clarifying questions, then writing out half-decent code that avoids a few blatant obstacles, in this case the requirement for Collections to store primitives. The parent is really referring to candidates not being able to live up to their own talk, which I think is a valid statement. If someone groans about writing a snippet of code in an interview, wouldn't that make him look like a crappy potential co-worker who groans about writing code for production?
... or an advertisement for OptimalJ?
This has resulted in a tremendous backlog of projects," says Aad Van Schetsen, Compuware sales director for application development and integration solutions in the Europe, Middle East, Africa region.
Ben van Niekerk, Compuware SA product manager, says locally the backlog is mainly in projects to integrate new applications into Java legacy code.
Van Schetsen says the key to the success of tools such as Compuware's OptimalJ is their use of a model-driven architecture
Tools like OptimalJ ensure best practices and standards as well as enable companies to leverage the core capabilities of their developers by allowing them to focus on applications and not the underlying technologies.
"Although we are still in the education phase, particularly with less experienced Java developers and development companies, momentum is gradually growing with OptimalJ sales increasing threefold in the past financial year."
You seem to be a very much "old school" programmer whereby you don't adapt to new tech. This isn't a bad thing, especially if what you know works well but how long do you think you can afford to not learn new skills like Java? The OO programming paradigm is an evolution of programming languages designed to make it easier to replace parts of code that need changing (new GUI, database code etc) and aid ease of reading and understanding. OO should be used everywhere imho as its good programming practice. On a final note, you don't want ONE developer knowing a huge project. What happens if that developer dies? It will take a new dev ages to learn all of that code, not only that but what if that one developer is actually somebody who writes poor code? I'd rather fix a few objects than rewrite an entire system. P.S. Java is no longer slow, its evolved a lot since 1.1 days. After a few minutes on a server it can actually run faster than native code due to the VM containing a runtime optimizing compiler.
I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.
Close but not quite. You're as likely to find that they end up using whatever new language you throw at them as if it were some weird dialect of the only one they know well.
My rule of thumb if I'm looking for someone that needs to be able to pick up a new language is to find someone that knows at least three different ones (and I wouldn't count C++, Java and C# as three -- one and a half, maybe), or two if they're different enough.
My first two computer languages were Algol and APL, I've since been paid to write programs in about a dozen other languages and written toy programs in another ten or so. Heck, except for short term contract jobs, I've often ended up developing software in some language other than the one I was originally hired for.
It's tough being on the hiring end too -- if I've got project deadlines looming and I'm given a foot-high stack of resumes to look through to pick out a few candidates to interview, I'm sorry but my first pass through the stack is to going to be to find any reason at all to not look at a given resume any further, so I can shrink the pile that I actually have to read and think about. I may end up throwing out a gem but as long as there's still one left in the pile I look at, that doesn't matter. (Well, not to me, I know it matters to the one I threw out.)
Yeah, the whole resume/HR/interview process sucks, and it's one of the least efficient ways to find a job (or a good candidate), but alas most tech types are even worse at social networking, at least with the kind of people one needs to to get the job.
-- Alastair
"Java was the popular thing of it's time."
I'm unemployeed so I spend A LOT of time looking at job listings.
In Austin, Texas, at least, it is STILL Java's time. Maybe things are different in Iceland.
--Richard
#) Isn't this true for every langauage....
#) Building complex systems requires experience(on large projects and exp in a particular domain),no matter which language you are using....
#) One good way to identify someone's love for a langauge or platform is to check for his participation and contribution to FLOSS. that loves ensures his personal interest and can be a pointer to the fact S/he is inquizitive and likes exploring more (not just learning the basic sytax required to do the job).
Linux: Self-mutilation is a snap.Be a geek!!!
Remember the Matrix, when Keanu says "I know Kung Fu"? It's like that, only with Java. It doesn't mean you can puddle your way through a toy app, it means you make the language your bitch. It does what you want, when you want it, how you want it. Maybe you don't remember all the classes and their methods, but you know the common ones, and you can find the rest from the API in a flash.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
You probably wouldn't fail his interview. Even when a person gets a question wrong, you can tell if they know the language or now.
Interviewing should be an interactive process. If you try to store primitives in a Collection the interviewer should say that Collections only store Objects. A java programmer will respond, "oh yea, that's right" and throw in a few wrappers. Someone that just put java on their resume will still be lost.
At least that's been my experience. I look for comfort level with the material. Experienced programmers can miss easy questions, particularly because they have developed methods for avoiding those very questions. For instance, I may occasionally not be completely sure of order of operations, so I just slap on some extra parentheses or split a large equation up over more than one line.
t