
Learning Java alone doesn’t make you Java developer - foppr
http://veerasundar.com/blog/2009/05/12/learning-java-alone-doesnt-make-you-java-developer/
======
snorkel
> I was thrown at huge list of Java jargon, which I’ve never heard before.
> log4j, DI, IoC, RMI, JNDI, to name a few.

...and therein lies the problem. J2EE is the umbrella word that covers up a
rat's nest of API's that are constantly changing and being replaced in favor
of other other API's.

What is so complicated about web development that Java developers feel that it
requires 18 different layers of code and special servlet containers to
accomplish? Take a peek at a plain Tomcat server process running absolutely
nothing: it uses 430MB of RAM for one process, and that without any extra
servlets installed. I'm convinced J2EE only exists only to keep mediocre
developers employed at big companies that don't know any better.

~~~
umjames
Yes, you didn't know that? Wherever you see the word "enterprise" just replace
it with "CYA".

As someone whose day job entails writing servlets (and all Java web
development boils down to servlets), I find that I really can no longer get
excited about a Java web project because the first thing I think about is how
much of a pain it's going to be to make it. Not pain as in difficult, but pain
as in tedious.

------
jcapote
You become that as soon as you implement a FactoryFactory complete with your
own xml driven configuration.

~~~
evilneanderthal
I didn't think much of the article (common knowledge statements).

But the combination of the title and the parent post is quite amusing.

Learning pl alone doesn't make you a pl developer. You become that as soon as
you implement a virtual database to make up for deficiencies in the existing
customer database which cannot be changed.

------
Zak
It's not clear from the article what sort of classes the author took to learn
Java. If the title was something resembling "enterprise software engineering
in Java" then he has a valid complaint; not covering the many libraries and
tools commonly used for that purpose is a serious omission.

If the subject was something like "computer science" then failing to include
any of several tools popular in industry is entirely appropriate if those
tools aren't optimal for teaching about how computers or computation works.
From what I know of Java and associated tools, it seems entirely appropriate
to omit the whole language from a computer science curriculum.

------
mildweed
College alone will never prepare you for real-world anything, programming or
otherwise.

------
dkarl
The article is quite wrong. Learning Java does make you a Java developer. You
don't have to know any particular framework to be a Java developer, because
there are dozens of popular frameworks in use, and different projects use
different frameworks.

There's no point in learning J2EE if you don't want to work on J2EE
applications.

There's no point in learning Swing if you don't want to work on Swing
applications.

I think what this he meant was, "Learning Java alone doesn't qualify you to
apply for most Java jobs," or maybe, "You will not be immediately productive
at your new job if all you know is Java."

~~~
gaius
Back when I did Java professionally (1997) it was expected and considered
normal for a Java programmer to know the entire thing and be able to do GUIs
or network servers or whatever else needed doing. The hyper-specialization
came later.

------
cruise02
I think that "Java" is being used as a variable name here, which can stand for
any programming language ever compiled/interpreted.

~~~
chaosmachine
"learning x doesn't make you an expert in x"

------
azanar
Learning the language and the du jour APIs will also not make you a skilled
Java developer, which is what I think the author means; doing that in any
language X will not make you an X developer of any reasonably high skill.

The problem I have with posts like this is that they seem to be focusing
entirely on the wrong way of learning to develop software. They work from the
assumption that becoming a developer is a matter of memorization, and the
reason they aren’t there yet is because they haven’t memorized enough API
definitions or acronyms.

Approaching anything from this level of abstraction results in needing to
learn most everything as if it were a completely new area of knowledge. And it
is an _incredible_ timesink, as the author has already confessed

Instead of realizing the need for a hash table to solve a problem, and
researching what options are available in this language, they either perform a
scan of all of the options and pick the one available that looks best, or they
rely on some mnemonic to decide what data structure to use without really
understanding why it should be used. Both arrive at approximately the same
place -- hopefully -- but they approached it from entirely different
directions.

The former developer already knows the metaphor he is looking for, and thus
his search will be very limited in size and when he finds class/library/etc.
he needs the API will already make some intuitive sense provided it implements
what it claims to.

The latter developer has no metaphorical basis for what they are doing, and
thus even when they find something that works, they’ll have to rote memorize
the API, because to them it’s just a formless black box.

To answer the author's question about what APIs one ought to know, my response
is that the author is asking the wrong question. I’d like to ask what has
convinced them that APIs and acronyms are the thing most worth knowing. It
seems to me the author's time could be far better spent learning the metaphors
and theory behind those acronyms and APIs, and then realizing that finding and
learning new APIs and class libraries aren’t all that tricky once the
fundamentals are understood.

------
TallGuyShort
You see the same mindset in any programming student regardless of the
language. Nothing can ever replace real-world experience, especially not with
just one language.

