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!
Actually, the report is wrong. They just don't read the resumes carefully. The other 68% actually know *Javanese* Java, not Sun Java.
"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."
We also would have accepted: Only 26% of submitters to Slashdot can create proper sentences.
Also "99% of researchers and statisticians have no idea what they are talking about and don't know what research means"
Joe Llywelyn Griffith Blakesley
[This post is in the public domain (copyright-free) unless otherwise stated]
It really is sad.. I've been dealing with Java for years, and I know that I couldn't bring myself to bother messing with a 'complex' project... Of course, I'm not going to be putting 'Java' on my resume anytime soon, either...
Java was the popular thing of it's time. If you didn't know it at the apogee of the internet bubble, you didn't get a job in the computer idustry; it's a lot easier to say that you know it, and hope that you never have to use it. I for one hope that I don't have to write Java code again...
.NET - buzzwords rule the market from the big business' point of view.
Now things are pointing similarly towards C# and
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.
I see that I'm not the only one!
"Send an Instant Karma to me" - Yes
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
My real world experience tells me it is much less than 32%. 15% at best (though another 15% THINK they know java - this is where the real danger lies).
If you require knowledge of complex topics like sensible J2EE architecture or multi-threading it falls into the single digits.
The second half of the article recommends Model Driven Architecture for the masses as the solution. This amounts to putting complex tools into the hands of idiots. Tools that go out of their way to keep people ignorant, while simultaneously giving them the power to commit their sins on a grand scale. Brilliant.
dhk
"Only 32% of Java developers really know Java."
An old Digital Equipment Company manual for technical writers said that only a small percentage of people really know English. And here is an example of not knowing English, in the Slashdot story:
"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."
Knowing Java is very different from knowing programming. If you can't do a complex project in Java you can't do a complex project in any language. If you can do it in any language, you can do it in Java. The first step might be learning Java, but any good programmer can handle that in a short time. Now granted I'd want someone who knows all the tricks on the team so I don't re-implement the wheel, but a complex project by definition requires many people so that isn't an issue.
HR is far too hung up on what you have already done, not realizing that the data structures and algorithms are what counts, and they are the same in any language.
On the other hand, most of us mortals don't store all the details of API's in our heads. Back in the Stone Age we used manuals and in the Information Age we use the SUN Web site. If your interview objective is to see how someone would get the information to solve the problem, that is fine, but if your objective is to see if that person already has some narrow set of information, you are going to exclude some capable people.
I am mainly a Delphi developer (I should say a Delphi component developer), and my Java experience is only 4 months old, and gee, my Java experience is limited to using JNI to allow a Delphi ActiveX component to invoke an extension module written in Java and using a class loader so that extension module can be reloaded while the ActiveX component is still running.
I don't know the answer to your question about Java collection objects without looking it up, although I have enough sense to know that you have to use Object wrappers for value types in collections and then have to cast those objects back to their original types when you pull Object references out of collections -- I know that from "wasting" time reading Slashdot.
I guess I would fail your interview.
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?
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.
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.
It doesn't work well for an applet in a browser, and it doesn't work well for stand alone apps.
Yes, and those are not the areas where Java has been very successful. However there are others, like server programming where Java is clearly the best choce.
I think most Java programmers are like me, they played with it enough to find out it's not worth the trouble.
I hope so. That will make it easier for those of us who actually understand Java and where it is appropriate to charge high hourly consulting rates.
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!
I list Java among my skills, even though I cannot write Java code worth a damn. And I'm not lying to the resume reader.
I know what Java is, I know how to use the Java commandline to turn on Debugging, manage memory usage, turn off GC, etc. I know more about idiosyncracies in Java VM versions on 6 different platforms then most programmers.
I never said I knew how to program Java.
I'm a C/C++ coder who's just been roped (against my wishes) into a J2EE project that's using OptimalJ to save time. It seems to me that J2EE is totally over engineered and that something like OptimalJ is needed to make J2EE development competitive (developer time wise) with ASP or PHP. OptimalJ is woefuly inefficient in the Java code it creates, but is very powerful - you can make an entity relationship diagram, click a few buttons and you've got a fully working website ready for deployment. I can see all web development going this way soon...
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.
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.
... 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."
78% of all statistics are made up. //smirk
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.
You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:
Don't Repeat Yourself: knowledge should be represented only once in the system.
Tell, don't ask.
Classify objects in your systems by the messages they respond to, and the responsibilities they hold.
An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")
Prefer short methods.
Apply design patterns according to the problems they are intended to solve.
When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).
Design your code to be tested, or better, write test code to help flush out the design.
Keep a nostril open for code smells, use refactorings and tests to fix the problem.
...
Always remember these are principles and not rules.
Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.
I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.
Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.
You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'
No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.
Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.
Thanks for the response, and the discussion.
Michael Murphree
As long as there are people putting "I know CHMOD and Upload/Download" on their resumes, I guess anything is possible....
At what point does a person *know* java? I graduated a few years ago, and I listed Java on my resume. I had taken two semesters (Introduction and Client/Server) and felt like I should list it. I would venture a guess that no project done for a class rivals the complexity of a real world project, but are college students supposed to leave their resumes blank? Naturally I didn't list Java under the experienced listings,but under languages known. Maybe there should be industry standardized tests for each language, not unlike A+ certifications or Redhat Linux Certifications.
#) 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.
This article is an advertorial, I am in the development industry in south africa and itweb.co.za is often used to dispense stuff like this. In fact some software products I have written myself were paid for and featured on itweb.
provide a development platform by which developers could do applications applications that would run either on the client or the server. The big problem is that Java never really delivered on the client end. Applets run, but they are so poorly engineered, in the words of Marc Andreeson "client side java is dead'--and Javascript has take much of the role it was anticipated that Java would take on the client.
I previous poster made legitimate points that Java brought garbage collection, reflection and runtime safety into the popular eye. However, there are other widely used, well-standardized languages with those same features, namely Javascript.
C# may be better in key respects than Java, but I have trouble conceiving of C# as a really open standard. The ECMA standard for Javascript is already supported by a variety of companies(i.e. IBM, Lotus, Microsoft, AOL/Time/Warner/Netscape) in a variety of products.
The folks at have shown that they can extend Javascript quite a bit-even in browser implementations.For all of the talk of C#, one thing that is interesting about
I'm a DBA and Perl/Python programmer. I've used Java for class projects at CMU. Java and C# both strike me as overly complicate for most of the work I do on a day by day basis. Javscript isn't there yet-but I can see that it might get there. There is a real niche for a well standardized, universally available scripting language that just hasn't been filled yet. If a small fraction of the engineering effort applied to Java were applied in this direction, I'd expect big benefits.