Hi there..
I eventually also an undergrad student which has passion on Java. From
my research joining Java bandwagon really need you to study more,
especially towards industrial grade. My suggestion is, strengthen your
J2SE skill set, which is the fundamental. Don't be to eager learning
much larger and advanced API, stick to the basics and it helps. When
you are ready and confident you may choose either J2EE or J2ME clouds.
Both used J2SE as the basis or subset of their own libraries. Plus you
also need to learn about popular commercial or open source libraries
and tools for example, JasperReport, POI and etc.

Hi Ryan,

I graduated from college in 2003, and in many ways am still bridging
that gap between school and professional work. I don't know what has
worked for others, but I can at least tell you what worked for me:

(1) Read as many books, Web sites, blogs, etc. as you can.
(2) Get a pet project - a hobby application to develop in your spare time.
(3) Get involved in an open source project.

You can try to do an internship in a local company. Or an actual job in
your holiday period, if you're "good" enough.

I did a Computer Science degree and I felt that I learned so much more  
about the practical craft of software development in the first 6 months of  
work after graduating than I did in the years at university.  At  
university you don't get to do software development all day every day.  At  
work you do, and you quickly get better at it, especially if you are lucky  
enough that one or two members of your team really are top notch at what  
they do and you can learn from them.

The number one way to get better is to practice.  You can do this by  
writing programs that interest you.  By making mistakes, causing yourself  
problems and using books, websites and newsgroups for solutions, you will  
develop better approaches to programming that will help you to avoid the  
same problems in future.  Steve McConnell's book "Code Complete", while  
not Java-specific, will get you thinking about a lot of these practices.

Possibly the big difference between coding for university assignments and  
coding in the real world is that, in the real world, you will usually be  
working in a team.  This means communication and coordination are so much  
more important.  Your code has to play nicely with other people's.  You'll  
be using things like version control, issue tracking and continuous  
integration that probably weren't even discussed on your course.  The book  
"The Pragmatic Programmer" by Andy Hunt and Dave Thomas covers these real  
world concerns and contains a lot of common sense.

If you're already a competent Java programmer, then read Joshua Bloch's  
"Effective Java".  Yes it's out-of-date, but it's still the best book  
there is to make yourself a better Java programmer.  It was a revelation  
to me when I first read it.  You may also consider studying for the Sun  
Certified Java Programmer qualification.  It's by no means essential, but  
you'll learn something doing it and, for a vendor certification, it is  
reasonably well respected by employers.

People will tell you things like "you must learn JSF" or "you need to know  
EJB to get a job".  I say the Java universe is huge and you've got no  
chance of learning everything or even close to half of it.  Pick the  
technologies and frameworks that look interesting to you.  There's no  
point learning something just to get a job if you're not going to enjoy  
that job.

Dan.

Pick an technology (database, GUI, concurrency, web, etc) and build
something.

Matt Humphrey http://www.iviz.com/

Programming tends to be the easy bit, understanding the business you're
working in is the tricky thing.

On Tue, 11 Dec 2007 18:55:18 -0800 (PST), "ryanthames@gmail.com"
<ryanthames@gmail.com> wrote, quoted or indirectly quoted someone who
said :

The big difference between school and work is that in school the
problems are extremely tidy. The inputs and outputs are precisely
specified, the problem to be solved is defined with rigour.  In the
real world this is not so.   Often it is your job to tease out of the
users what they need.  Usually this require iteration. Most users will
not give you any useful data until you show them something they can
critique.  Humans are much better at pointing out what is wrong with
something than telling you what they want.

Even on a team where you did not write the specs, the specs will be
nowhere near and detailed an unambiguous as you are used to.

So you need some practice refining and clarifying the specifications.

You can do this by writing code FOR somebody, or by tackling a vague
student project see http://mindprod.com/project/projects.html
where you get to fill in the details yourself of what the program is
supposed to do.  (You act as your own user.).

You also need some experience in team programming. It is a TOTALLY
different skill from coding on your own. It requires great diplomacy,
and holding your ego in check. You can gain experience by joining any
of the team source code projects such as you might find at
SourceForge.

I have been doing this for about 45 years now.  It is a extremely fun
job.  It is like getting paid to play.  The other fun thing, is
computer programmers get to interview people in every profession
imaginable and get to ask any questions they please.  It is sort of
like a licence to play George Plimpton, trying out every possible
mini-career.  For example, for a time, I knew more about high voltage
power line design than any engineer. I knew more about how a bank
worked that the bank manager or any employee. I knew more about how
the lights and fans worked in a large shopping mall than anyone who
worked there.  I got to be present at the first experiments in
ultrasonic communication with dolphins.   I got to have my own solar
energy lab with pipes and pumps, solar collectors, silicon collectors.
I got to evaluate every brand of microfiche equipment.
I got to program a computer used to control nuclear submarines without
having to sell my soul by joining the navy or creating products to
kill. I got prepare most of the evidence in a multimillion dollar
lawsuit where the coding, testing and production had to be completed
within 30 minutes of a lawyer's request.  At one point my office was
in an earthquake simulator while I worked on differential equations of
how pollutants move in soils and rivers.

It opens the door to all manner of variety. I hope you have as much
fun as I do.