How to Become a Better Java Developer
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Jennifer Bortel, an editorial director for InformIT, asked me to write about becoming a better Java developer, figuring I might know a thing or two about that since I just published Core Java for the Impatient. I agreed. Nothing could be easier—I'd just tell you to buy a copy of the book! But then she let it slip that I would have to write 1,500 words. So far, it's just about 77.
I recently received an email message from a developer who had been asked in a job interview why the following code isn't threadsafe:
class ThreadSafeClass extends Thread
{
private static int count = 0;
public synchronized static void increment()
{
count++;
}
public synchronized void decrement()
{
count--;
}
}
My friend thought this example was threadsafe, and I agreed, pointing out that, after inserting the missing static in the second method, access was controlled by the intrinsic lock of the class object. I also said that this wasn't a very good interview question, since surely everyone who needed a threadsafe counter would just use an AtomicInteger.
But in the middle of the night, I woke up and wondered: Maybe the static wasn't accidentally missing; maybe some fiendish interviewer had purposefully constructed this example to trip up candidates. So I wrote again to say that I was wrong, and in the parallel universe of interview questions, the correct answer was that the second method holds a lock on an object.
The developer then asked whether I had a YouTube channel from which he could learn how to deal with interview questions like this one. Unfortunately, I don't. I teach computer science and write books, but my goal has always been for my students and readers to become better programmers, not better interview candidates.
Peter Norvig wrote a great blog article in which he argued that books promising to teach you Java in 24 hours, or 21 days, are ludicrous. It takes 10 years, or maybe 10,000 hours, to become an expert at anything. And it is well known that experts have a very different way of processing information than novices do. In a classic experiment, expert and novice chess players are shown a chessboard for a few seconds, and then are asked to reconstruct it. The novices don't do very well, but the experts have no problem remembering where all the pieces were. Under one condition, that is: The board had to be from an actual game. If the pieces were positioned randomly, the experts remembered their locations no better than the novices did.
That's what happened to me with the interview question. My expertise is programming, not passing interviews, so I instinctively filled in the missing keyword and went to the "wrong" conclusion. I would like to think that I still would have been hired once I explained what happened, and why I would never code like the example in the first place. If I wasn't hired, I probably wouldn't have wanted to work for that outfit anyway.
I don't think that studying for certification exams or preparing for interview questions will turn you into a better programmer. What also doesn't work—though, as a book author, it pains me to tell you this—is buying more programming books and reading them cover to cover. On the other hand, a really good way of becoming a better programmer is to do more programming.
Every so often, I teach an introductory course in computer science at my university. It is by far the hardest course I teach—much harder than a graduate course. When I first started work as a young professor, I dutifully lectured students on programming concepts, such as the difference between while loops, for loops, and do loops, and I gave students four three-week projects to complete. That's how the subject had been taught since the beginning of time. The instructor of the second-semester course complained bitterly that most of the students, after an entire first semester of programming, still couldn't complete a simple loop. That too has been the case since the beginning of time. Remember FizzBuzz?
These days, I give beginning students lots and lots of automatically graded practice problems. By the end of the first semester, they have written so many loops that they can regard loops as experts do—as constructs with a purpose, and not random statements.
That's hardly revolutionary. When you learn a foreign language, the majority of instruction is drill and practice, not theory. It is crucial to push knowledge into the subconscious brain. Once you no longer need to actively think about each loop, or (in the case of French), about each irregular verb, you can go on to the next level.
The key is instant feedback. The autograder tells students right away when they did something wrong, and when they got it right. Some psychologists believe that we could do much more with computerized training and instant feedback. For example, in another classic experiment, novice pilot trainees took a training session in which they were required, over and over, to look at an instrument panel and describe the motion of the plane. They got instant feedback indicating whether they were right, and after two hours of training they outperformed seasoned pilots. Of course, that didn't mean they could start flying, but they no longer were nervous about all those dials on the instrument panel.
So, if you are just starting out learning Java, it is a great idea to do lots of drill-and-practice assignments. There are a good number of websites and online courses with automatically graded coding practice. Pick one that offers realistic problems, not gibberish code. After all, you want your subconscious to do well with the kind of code that you will actually write in practice. That's why I am not so keen on programming examples that use contrived situations, such as animal classes with methods that meow and bark.
After a while, you will have mastered the basics of programming. To go to the next level, you will want to complete projects. A couple of years ago, InformIT asked many experienced programmers this question: "What's the Best Way for a Programmer to Learn a New Language?" By far the most common answer: Put it to work in an actual project. Find something that you've always wanted to implement, and get going.
Twenty years ago, when Java had just got started, my friend and sometimes co-author Gary Cornell called me and said, "Cay, we are going to write a Java book." I pointed out that neither of us knew a thing about Java, but he said, "So what? We have a book contract." We had to hurry, because someone else had already announced "Teach Yourself to be a Java Dummy in 24 Hours," or some such title. And so I wrote a program that put up a user interface for retirement planning, a program that connected to a weather site and displayed a weather report, and a program that simulated cars moving along a freeway. (Those were exciting programs at the time.) In the process, I had no choice but to learn java.awt, java.net, and threading. And I had to learn how to actually get it to work, not just what the documentation said. At the time, those were entirely different things. That's why Core Java [1] was a hit when it came out—it was not for dummies.
Learning Java was much harder back then, because we had no sites like Stack Overflow. That relates to my next bit of advice: When you work on your pet project, you will get stuck, and then it is a really good idea to go to such a forum and try to find answers. At first, you'll have the same questions that everyone else already asks. But soon you will have become enough of an expert that your questions are more unique. That's a tremendous way to learn. Of course, you don't just want to dump some code and ask, "Now what?" You want to distill the code down to its essence and explain what research you already did before you got stuck. Most of the time, I say "duh" before I am done submitting the query, because the answer became clear in the process. And if it didn't, well, thoughtful questions tend to attract thoughtful answers. Be sure to pay back your social debt by answering other people's thoughtful questions. In both processes, you are becoming a better programmer.
But what about books? Are they obsolete, thanks to Google and Stack Overflow? Whenever I start out wrestling with a new technology, I figure that I am a manly man, and I can go it alone. After an hour of wasting my time, sanity sets in, and I buy a book. Nowadays, technical books are an unbelievable bargain. If I pay $40 for an e-book and get a quick answer for just one question, I got my money's worth already. It pains me to tell my fellow book authors this, but I never read the books from the beginning to the end. I dive right in where I think my problem and its solution are described, and I read just enough to pick out what I need. For that reason, nowadays I try to write books that can be read that way—hence the Impatient series.
Now I really need to stop—I have exceeded 1,500 words. In a nutshell, to become a better programmer, start by recognizing that there are many layers of expertise. At the beginning, push the basic language constructs into your subconscious mind through lots of drill and practice. As soon as possible, get to work on real projects that interest you. And then join a community where you can ask and answer questions. When you've done all that, you'll be able to speak with passion and experience in a job interview, and it won't matter whether you get tripped up by a contrived puzzle question.
Reference
[1] Gary Cornell and Cay S. Horstmann, Core Java. Prentice Hall PTR, 1996.