Read everything you can about Haskell (an advanced, purely functional programming language; http://www.haskell.org); there are many good books and papers on Haskell.

Bo Sanden, “Systems Programming with JSP”, Studentlitteratur AB, Chartwell-Bratt Ltd. (Here, JSP abbreviates “Jackson Structured Programming”)

Rabhi and Lapalme, “Algorithms: A Functional Programming Approach”, Addison-Wesley

Michael Jackson, “Software Requirements & Specifications”, Addison-Wesley

Michael Jackson, “Problem Frames”, Addison-Wesley

Daniael I. A. Cohen, “Introduction to Computer Theory”, Wiley

John Cameron, “JSP & JSD: The Jackson Approach to Software Development”, 2nd Ed., IEEE Computer Society Press

Various books on discrete mathematics

- Paddy.

XML — I’m not a big fan but it’s hear to stay. Know how to serialize and deserialize objects to and from XML, and how to query an in-memory representation of XML.

The comment about The Pragmatic Programmer is spot-on. This book, (the success of which launched a publishing company) is twelve years old (!) yet still provides the best advice (in my opinion) for a young programmer.

The reason why it remains current is that it doesn’t focus on technologies, but instead on the craft of software development. This is the important stuff they don’t teach you in school, which I can attest to, having interviewed many fresh-out-of-college candidates.

Some of my favorite pearls of wisdom from the book (the book elaborates more on each topic):

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Program Close to the Problem Domain
Design and code in your user’s language.

Always Use Source Code Control
Source code control is a time machine for your work—you can go back.

Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.

Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

Test Your Software, or Your Users Will
Test ruthlessly. Don’t make your users find bugs for you.

Don’t Gather Requirements—Dig for Them
Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”

Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.

Design Using Services
Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.

Test Early. Test Often. Test Automatically.
Tests that run with every build are much more effective than test plans that sit on a shelf.

Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.