I found a question/thread on StackOverflow where someone else had already pondered the same thing and got a long list of possible answers to compare to each other, including using Apache Commons and the Google Collections Library. After testing all of them, the fastest way ended-up being implementing a "MutableInt" class and using it as the value data type in the map:

Pretty interesting stuff! Note that the above code snippet is not very cleanly formatted, but you'll get the idea.

1. Getting Started

Not sure if you were cut-out to be writing code for the rest of your days? Are you feeling different than your peers? Justin James wrote an interesting list-- 10 signs that you aren't cut-out to be a developer.
Now that you've decided you are genuinely interested in becoming a programmer, there are many, many ways to go about this. If you don't have any idea what direction to head to, a good starting point is Getting Started in Programming.

2. Get Your Resume In Shape

Resumes are yet another major thing to get right. A resume is what can get your foot into the door into the company of your dreams, or put you in an infinite job search loop with very little feedback. There are many opinions and guides to creating the perfect programming resume, and here a couple which I've found to be the most helpful are Writing a Resume That Will Land You a Programming Job and Resume Pitfalls Every Programmer Should Avoid. Most programmers are notoriously bad at presentation and should also think about giving their resume a face lift. It also might not hurt to take a look at the 100 most searched for resume keywords and add them to your resume if they match your skills and experience.

3. Starting your Job Search

One of the best ways to get jobs is to reach-out and network with people you know to see what jobs they know about. The most natural and unobtrusive way to do this is to sign-up for LinkedIn and import your address book.

A good way to see what sort of jobs are out there and what the market is like is to use a job aggregator and search engine like indeed.com. There are also some other sites to take a look at which it doesn't have permission to index such as craigslist. You may also find out about jobs through local mailing lists or user groups. You could also check into companies that you like and are interested in by going to their website and seeing if they have any open positions which fit your skills and experience.

There are of course many large and popular job sites which you might want to hit individually if you aren't finding what you're looking for via indeed.com-- sites like Monster, HotJobs, and Dice are all good places to start.

4. Prepare For The Big Interview

If you've been in the industry for awhile you know that what you can expect during the interview process is it being completely unexpected. There are a wide variety of interview techniques used by companies, and none of them seem to be the same. I think one really good overview on what to do is Preparing for a Software Engineering Interview. While that is a good overview, you have to prepare for a very wide variety of questions. Here are a lot of resources to prepare you for an intense Software Engineering interview process including some general interview tips as well:

• How To Pass a Silicon Valley Software Engineering Interview
• Google & Microsoft Algorithm Questions
• 50 Common Interview Questions & Answers
• Everything You Wanted to Know About Getting a Job in Silicon Valley But Didn't Know Who to Ask
• Programming Interview Questions
• Developer Job Interview Questions and Answers - This is probably the most exhaustive list of technical questions I have ever seen!
• How To Answer 23 Of The Most Common Interview Questions
• Answers To Technical Interview Questions
• Questions At A Google Job Interview
• IT Interview Open Questions Database
• "Why Should I Hire You?" and Other Favorite Interview Questions
• How To Answer The Toughest Interview Questions
• Five Essential Phone Screen Questions
• 25 Most Difficult Job Interview Questions (and their answers)
• The Top 10 Questions Every Programmer Should Ask on a Job Interview

Although you should be prepared for a wide variety of potential interview questions, you should also be prepared to ask plenty of questions of your own. Bruce Eckel provides a good list of questions which you should ask during an interview, and you should also be prepared to take some ownership during the process as well.

You should also make sure to dress appropriately for an interview-- it is not the time to break-out your DEFCON 1999 shirt, nor should you make an unnecessary trip to your local department store for a suit. Unlike most other white-collar professions, you are actually at a disadvantage if you wear a suit to an interview, but you should at least take the time to clean yourself-up and look like a well adjusted adult.

If you happen to be on a team trying to land a new developer and you experience great candidates turning you down over and over again. One thing to be conscious of is how poor interviewers drive away talent.

If you didn't get the job, it wouldn't hurt to read 25 Reasons You Didn't get the Gig to brush-up on your interviewing and presentation skills before you give it a try again. Or maybe it's just a sign that you're ready to start your own company or do freelance work from home, there are plenty of reasons you don't need a job.

5. Got The Job? Improve Your Situation

There are many things you should be doing to improve your career and general well being even while employed. For one, you should always continue learning-- whether this be new languages, frameworks, or even learning more of the classic Computer Science topics in depth, don't forget to prevent yourself from becoming stale. The one constant about technology is that it's always changing, and you will need to keep-up on your own time to stay competitive.

At the same time, being the master of a particular domain is not all it's cracked-up to be-- make sure you spend plenty of time outside of programming as well for a balanced life. I try to learn as much about as many topics as I can, and from time to time find some interesting lessons in life you can later apply to what you do. Travel to new places, try things you normally wouldn't do, try new cuisines, and in general find ways to grow your mind.

Programmers aren't known to be the most extroverted, gregarious people in the world (myself included), but you should make an active effort to meet new people in your field. Whether that be at user group meetings, conferences, chat rooms, mailing lists, message boards, etc, you'll find that having connections in the industry is a very good thing to have. I've mentioned it before, but LinkedIn (no affiliation other than a user of their service) is a really great place to keep in touch with your network.

A topic that many programmers overlook is budgeting and investing-- we've all been guilty of it at one time or another! It's easy to be wasteful when making a decent salary as many software developers do. Here are a few resources which will help you get a handle on your money and start making it work for you by doing more with less, and investing more:

• 15 Ways To Keep More Of Your Money
• The Spending Plan: Budgeting for Non-Budgeters
• 9-Step Beginner's Budget
• Healthy Food on an Unhealthy Budget
• 2006 Makeover, Step #2: Budgeting and Saving
• How to Create a Zero-based Budget
• Budgeting For Non-Budgeters
• 50 Smartest Things To Do With Your Money
• Where to Put $5,000 Now
• How To Save $1 Million For Retirement
• How To Invest $20, $100 and $1,000+
• 20 Investments: Introduction
• MoneyChimp: learn Stock Market Investing, Index Funds, Valuation Models, and more.

6. All Things Must Come To An End

Once you've been in a job for awhile, it's pretty much inevitable that you will leave for greener pastures for a variety of reasons, or be forced to move for various reasons. You might even find yourself alone after many of your co-workers leave via a mass exodus in which management has no control over. If you feel that you're in a salvageable position, some links which might help you analyze what the problems are in hopes of fixing them include:

• Why Top Employees Quit
• 50 Ways a Manager Can get Employees to Quit
• How To Lose Half of Your new Hires Within A Year
• Managers fail to find out why employees leave
• 1/5 Employees Quit Within The First Two Years
• Why Great Employees Quit, And What You Can Do To Keep Them
• Top 10 Reasons People Quit Their Jobs

Perhaps you're tired of your job for various reasons and are weighing whether or not you should stay? A couple of articles which might help you make the decision on what to do include What To Do When the Thrill is Gone and Do I Stay or Do I Go.

Although this is quite an exhaustive list which took me quite a long time to write about and assemble, I'm sure I've missed plenty of tips or resources to pass-on. If you have any to add, be sure to leave them in the comments!

Thanks to Flickr user McBeth for the perfect photo.

And it reminded me of my days during the early 1990s working as a software engineer on the Space Shuttle operating system (FCOS). Many people don’t know that the Space Shuttle OS implements self-modifying code for the purpose of “fault-tolerance”. The Shuttle computer systems consist of four primary computers running the same software, and a fifth backup computer running different software that is equal in functionality. The goal is to be Fail Operational if one or more computers fail, and Fail Safe if all primary computers fail; this is called a Fail Operational/Fail Safe system.

An interesting read, especially if you're a software developer who doesn't work in embedded systems but likes to read about them.

I've been working on a sizable project at work that uses NIO under the hood, but luckily I'm using a 3rd party library which provides the network connectivity for me. It seems that NIO is very hard to implement correctly, but if you can, the performance advantages are definitely worth the effort. I'm only a few days away from starting to do some load testing on my work, so I'll be interested in seeing the performance improvement over the section of code I'm replacing which uses standard IO (not to mention the various synchronization and thread consumption problems I'll be fixing).

Being able to quickly handle a large number of concurrent connections is definitely a requirement for today's AJAX applications, and it's good to see an NIO based connector from someone other than Jetty.

Anyhow, here is the comment that Peter made which inspired this blog entry (which in context, is a quip):

I also have to question why you'd even consider using CF for a performance critical app - even Java is a little sluggish. If you want bare metal performance and think your time is worth less than the cost of a server, go for it and write the darn app in C++!

I wanted to point out and correct a common fallacy that I see repeated over and over again are statements rooted in comments like "If you need speed, you could convert your Java application to C or C++". I don't claim to be a Java expert by any means, but I do think I have a good enough understanding of the Java platform as well as basic operating systems & compiler theory and the like to explain why this is a false argument. The answer is actually more along the lines of "it depends on what you are doing", and I'll explain why.

It's very easy to see where this misconception started-- pretty much every software developer or system administrator has encountered a slow Swing/AWT based Java application which took forever to start, and generally seemed pretty sluggish. Not to mention it probably looked terrible. One of the best Java based desktop applications, Eclipse, even takes awhile to start. On the contrary, C++ desktop applications typically start very quickly, and are very responsive to user input. Generally speaking the symptoms of running a Java desktop application match the reality-- C++ is almost always faster for short running programs such as desktop applications.

Another common assumption is that it would seem that the JVM itself is an abstraction above machine level code because it acts as an interpreter, and that C/C++ will always be faster because the resulting compiled code is "closer to the hardware" which is also false. In the early days of Java, the JVM did in fact interpret code, but eventually it started using a Just In Time compiler in Java 1.2 to compile the code down to the machine level. Different implementations of the JVM use various JIT compilers, but the Sun JVM uses the HotSpot JIT. Not only are Java programs compiled down to machine specific code, but the longer a program runs, the better it gets optimized.

The HotSpot compiler monitors and analyzes an applications performance over time, and uses adaptive optimization to eliminate bottlenecks in the machine code, known as "hotspots". It essentially looks for pieces of code that are ran time and time again, and marks them for optimization. Those pieces of code are then recompiled again into machine specific code for performance. This allows for ongoing performance enhancements that you would never get from machine code produced by a C or C++ compiler such as branch prediction hints.

All of these things are not just unfounded theory, there have been several independent studies about this including this one by the University of Southern California.

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

This study is several years old now and doesn't include testing against the many performance enhancements which were made available in the 1.5 JVM, so I'd be interested in seeing an updated study.

That said, Java is probably much faster than you think. One way I've seen the Hotspot compiler in action (and you can try at home) is when working on a simple "Hello World" JSP and keeping track of it's execution time. Typically on the initial run or two, the JSP page is pretty quick, but then after a few calls of the page the Hotspot compiler kicks in and makes it wicked fast so that it's execution time is effectively nil.

Now that we've spoke to the "Java Is Slow" audience, we should cover the answer to the earlier question of "Is Java slower than C/C++?". This is more of an "it depends" answer. Generally speaking C++ has the advantage in short running applications, and Java is as fast if not faster than C/C++ in long running applications such as servers, web applications, etc. It also might surprise you to know that Java is also very good in real time systems, but that is another blog post of its own.