Tips for Creating Prototype “Study” Code

The good news about the kind of coding we’re suggesting is that it’s very similar to the kinds of coding that lots of agile-ish software development methodologies use at certain stages of on-the-job software development. We’ll try to stay methodology-agnostic, but what we will say is that we’re recommending that you write code that’s very similar to code you might write if you were doing rapid prototyping or if you were in the early stages of an iterative development process. We understand that our readers have a wide range of experience, so please don’t be offended if you know everything in the following list.

Your Goal Write down your goal for the prototype code you want to create. As you develop and test the code, you might discover that you should have had a different intermediate goal… That’s great. Go with the flow.

Focusing Find the “sweet spot” for your goals. In general, you want your goals to be as focused as possible. At the same time, you want your goal to test something interesting. For instance, your goal might be “Create a separate thread in an inner class.” It might turn out that once you’ve done that you wonder whether you can create a thread in a constructor, or in an init block. Cool! Try it. In the list of coding projects that follows, we tried to create tasks that were in the “sweet spot”—not too easy, but also not too broad.

Reference Materials Unlike prototyping on the job, try to start each project without using the API or any other reference material. There’s another kind of “sweet spot” here. Ideally, you want to spend some time trying different approaches, but you don’t want to get stuck either. So, go easy on yourself—if your first iteration of code doesn’t work, but you have a couple of ideas, go ahead and try them, too. As long as you’re feeling positive and creative, keep experimenting. When you think you’ve hit a brick wall, don’t punish yourself—go ahead and look something up. When you find you need to look something up, that’s okay, but make a note of it. Perhaps make a new flashcard about the thing you needed to look up. The idea is to not get hung up trying to remember some little factoid.

Misunderstandings A couple of closely related “meta-goals” should be part of all the prototype code you create: you want to discover misunderstandings, and you want to discover lacks of understanding. Sometimes, when you start prototyping, you’ll discover that you mostly know what’s going on, but that you got a few details wrong—in other words, a misunderstanding. Other times, you’ll quickly discover that you’ve got no idea how to proceed—in other words, a lack of understanding. As you might guess, our advice is to keep a log of these topics so you’ll know which topics need the most attention. Again, don’t get hung up on any given topic.

Code Formatting Unlike prototyping on the job, sometimes you should use the horrible “exam style” code formatting that you’ll encounter in the real exam and (as you’ve discovered) in practice exams. Again, use moderation. You want to emulate “exam style” code enough so that you’re comfortable reading it, but not enough so it seeps into your real-life code. Here are a couple of examples:

Chain methods and/or constructors:

      new TestCode().go("2");

Eliminate curly braces:

      for(String s: names) s += s;

“Scrunch” your code. Here’s an example of some Java-style code transmogrifying into “exam style”:

Standard Java (a.k.a., “1TBS” [“The One True Brace Style”]):

      class MyStuff {
          int doStuff() {
              return 7;
          }
      }

Becomes “exam style”:

      class MyStuff { int doStuff() { return 7; } }

Put several related statements on a single line:

     s.add("a"); s.add("c"); s.add("b");

Creating Errors As you iterate through your prototypes, one of your sub-goals should be to break stuff. You want to understand what causes compiler errors, what throws exceptions, and so on.

Keeping Errors When you do break something, keep track of it! Instead of deleting the code that breaks, keep it inline and comment it out. For example, you’ll see examples of questions in this book in which you’re meant to determine which of several “code fragments” compile, or work a certain way. It’s a good bet that those fragments exist in comments, somewhere in our prototype code. And, of course, erroneous code can be a great topic for a flashcard.

S.O.P.s Yet another sweet spot here… System.out.println() statements (S.O.P.s) are a great way for you to debug your prototypes. But, unlike on the job, you also want to test your knowledge and learn stuff. In general, we’d recommend that in your first code iteration you don’t add debugging-oriented println()s. When the code does something unexpected, study it for a bit before rushing in and adding a bunch of println()s. On the other hand, don’t get too stuck. Usually when you’re studying, you should avoid getting bogged down on any particular point.

Debugging 101 If you’re really new to debugging, or to Java, common places you should consider adding S.O.P.s are:

In your methods and constructors (“I got to method X”).

Inside any loops.

To check the state of your data: What’s the value of x? How many entries are in my collection?

Typing It You’ll remember stuff better if you’ve typed it in rather than cutting and pasting it. It’s kind of like muscle memory for your brain.

Don’t Use an IDE We’ve said it a million times. The exam was created and tested using simple text editors and the command line. During the course of writing this book, we discovered a discrepancy between the compiler and a very common IDE. Also, even if you knew that your IDE would always agree with the compiler, IDEs are supposed to “help” by doing stuff for you behind the scenes. Once you’ve got your certification, go ahead and crank up your IDE; you’ll be more efficient. But don’t do it while you’re studying. (Okay, if you get really really stuck, you could use it once in a while as a last resort.)

Memorizing APIs We get a lot of grief about having the APIs on the exam. Candidates rightfully claim that they would never trust their memory of an API in production code, so why should they have to memorize API stuff for the exam? The exam creation team had a couple of very specific goals in mind for the API portions of the exam:

Demonstrate your basic understanding of how common classes work.

Demonstrate your ability to use the API.

For example, let’s say that a year from now you have to use the Date and Calendar classes. The exam creation team will be happy if you say to yourself: “I don’t remember exactly how to do this stuff, but I do remember that some of these classes use factory methods, and that there’s something tricky about Locales being immutable.”

Mangling Practice Questions At the end of this chapter we’re going to list some possible prototyping projects for you. But never forget that almost every practice exam question you encounter is probably a great place to start a prototyping project. So in a way, in addition to the projects listed in this chapter, this book contains about 260 more prototyping projects, at no extra charge.