jeanne’s oca/ocajp java programmer I experiences

Posted on by
22

Today I passed the Java SE 7 Programmer I with a score of 98% which makes me a “Oracle Certified Associate, Java SE 7 Programmer“. (see other post for Java 8 exam)

Deciding to take the test

If you’ve been following this blog, you may know that I’ve been a Java developer.  (tech lead and architect count if you still code <smile>).  Last year I took the SCEA and Core Spring certs.  So why go back and take the “entry level cert.”  I’ve thought about taking the SCJP twice.   My thought process to finally getting here:

  1. Bert Bates mailed me a free copy of K&B version 5 so I could help spot plagiarism of questions on BlackBeltFactory years ago.  I read the book then.  I learned a lot.  I scored poorly on the sample questions because I didn’t take any time to memorize the  relevant information.  And I didn’t care to spend the time learning obscure details.
  2. In 2009, there were rumors of the Programmer Plus exam.  If that exam existed, I wanted to take the beta of it because it sounded *so cool.*  I re-read K&B version 5 and actually studied APIs.  The programmer plus never came to be and I wasn’t motivated to take the traditional SCJP.
  3. A year or two ago, I was one of the cadre of JavaRanch moderators providing technical review of the K&B SCJP 6 mock exam book.  Reviewing that book actually made me less likely to want to take the test because I read it questions about obscure details.  (It did make me interested in doing technical reviews of future books though.  I actually did one for a yet to be printed Manning book – The Well Grounded Java Developer.)
  4. When I noticed the Java 7 OCJPJP had JDBC and NIO sections, that got me interested again.  JDBC is one of my favorite topics and I moderated the CodeRanch JDBC forum for many years with Scott Selikoff.  The beta of part 2 was only $50 so I decided to take it.  I decided to take it on 4/19 and took the beta on 5/9.  I’ll be blogging about this separately in the next week or two.  While I don’t have the score yet, I think I either passed or came really close.  If I fail, I’ll pay full price to take it again.  I’m never going to be more prepared for it than I am right now and don’t want to learn obscure details again!  Once I realized this, I needed to take part 1 of the Java Programmer exam to actually get certified.

My study plan

In all fairness, most of the studying went on before I decided to take either exam.  Both by reading/reviewing the SCJP books and by just picking things up over the years.  I had a week and a day between part 2 of the exam and this part (part 1).  For two of those days, I didn’t do anything at all.    What I did the rest of the time:

  • re-read chapters 1-5 along with parts of chapters 6, 7 and 10 of K&B SCJP which Bert recommended
  • take all 6 mock exams from Enthuware JA +V7

How were the resources I tried

  1. K&B version 5 – Granted you’d buy version 6 at this point.  (or the OCA/OCP 7 version once it is out).  If you plan to take the OCP afterwards, I recommend going with this book to study.  If you just want to take the OCA, it is overkill as the information you need is mixed up with lots of harder information you don’t know.
  2. K&B SCJP 6 mock exam book – If you are planning to take the OCP afterwards and don’t mind the material being mixed together, this is a great resource.  If you want to get your OCA first without being exposed to the OCP information, it isn’t helpful though.  Also, some of the content is no longer on the exam so you have to ignore these parts.
  3. Enthuware JA +V7 – This was a great resource.  It was more difficult than the exam, but not overwhelmingly so.  The only topic that stood out as being on the mock and not needing to know was the ranges that primitive objects could hold.  A free 14 question trial is available so you can see what it is like before committing the $10.  Yes, you read that right.  You get 6 full length mock exams, analysis on your weak areas and the ability to retake questions by subject – all for ten bucks.  Even though there aren’t drag and drop questions, the mock exam still includes them because they are harder.  It also includes one or two fill in the blank questions.  (I found this to be practically impossible as a one character typo marks it wrong and then it is hard to compare to see why you were wrong.  But it isn’t frequent.)  The mock has been updated for Java 7 and the new objectives/difficulty.  I was highly satisfied with it. [My scores were 78%, 82%, 82%, 83%, 80% and 88%]
If you only have one resource, I would pick the Enthuware mock exams.

My impressions of the exam

  • Just like on the SCEA, I had a ton of time.  I had an hour left after taking all the questions and carefully reviewing them.  (I found one wrong answer on review.)
  • Unlike the SCEA, the questions are designed to be tricky/subtle.
  • It was similar to the Enthuware mocks in terms of facts/skills you had to know and format.  The Enthuware questions used some of the same variable names, class names and structures.  Kind of like the SCJP talks about horses.
  • I really like how the exam uses incredibly similar looking questions to ask different concepts.  Even within the same exam.  This prevents you from remembering much of use or memorizing much in advance.
  • A few questions had you flipping between the “exhibit” class and the question.  This was annoying because if you are looking for subtle details, it is a lot to remember between flips or *a lot* of flips.
  • While taking the mock exams, I found a technique that helped me limit stupid errors.  My score jumped 8-10% of the last mock I took (the only one using that technique) and then again on the actual exam.  On the mocks, I went too fast because the questions appeared easy.  On the final mock and real exam, I subvocalized as I read the code for *all* code questions.  This prevented my brain from going too fast and missing anything.
  • When you get your score report, it tells you which objectives you missed questions in.  Mine was “flow control” which tells me I made a stupid error in that space.

And finally, why you should visit a testing center in advance

Note: the testing center fixed the problems I had – see comment below this post for updates

I took the SCEA and Java Programmer part 2 exams at my local testing center which I am happy with. They provide you with pen/paper and a detached room from the office to take the exam.  The only distraction is if there is another person in the room with you and he/she stops and starts at a different time.  They take care to be quiet.

Then there was the center I was at today.  They gave me a *one sided* erasable markerboard to write on.  But that’s within their rights.  If you want paper, you should call and ask.  The exam was held in what looked like a closet.  A small table with two computers and poor ventilation.  It was hot!  And no soundproofing.  I heard everyone who walked into the office while I was there.  Which included an irate customer who had computer troubles and was dissatisfied with the speed at which they were fixing it (this went on for 10 minutes) and another potential customer who was inquiring about training. It was loud enough that I had to hold my ears to think.  Which doesn’t go well with using a mouse to select answers or trace code on paper.

I wanted to take the exam today because I was off work today.  And I figured minimizing the time between part 2 and part 1 would give me less time to get out of the habit of looking for details in exam questions.  It was the right decision.  But I wouldn’t recommend “Horizon Technical Consultants of Flushing” as a testing center for anyone.

distributed retrospectives with a twist

Posted on by
Reply

In  the traditional agile retrospective, everyone gets in a room and puts post it notes on a board.  The group then sorts the post its by topic.  Then there is discussion about the points brought up.  I find there are a few limitations with this approach:

  1. It requires everyone to be in the room at the same time.  This isn’t always easy.  (Especially if the team is distributed or partially allocated to other teams.)
  2. Everyone has to watch the sorting exercise.  Throwing more people at this doesn’t make it faster on a big team.
  3. People get worn out by the long meeting.
I’ve done about a dozen retrospectives where people write on post-its in advance of the retrospective and leave them in a shoebox.  (We’ve extended this to having the shoebox available for the length of the project so team members can add thoughts as they occur.)  We then have myself and another team member group the post its by category.  Then we use the actual retrospective meeting for discussion/brainstorming.  For members located remote, we let them e-mail post-it notes.  This loses the anonymity, but people haven’t seemed to mind.
At he end of the season, the programmers of Stuypulse do a  lessons learned over e-mail.  We had more new programmers this year that stuck with the team than ever before.  I wanted to make sure we got their input and the brainstorming wasn’t “biased” by older team members.  I suggested we do a retrospective.  It was an experiment for me too as I’ve never done one completely remote (or without post-its or a shoebox.)  Remember that these are high school students and it is likely they’ve never done any type of agile retrospective before.  Here’s what went down.

Phase 1 – post it generation

I searched if there was an online retrospective website and didn’t find anything.  [If anyone reading this knows of one, please post a comment.]  Instead of post-its, I created a google docs spreadsheet with the following columns:

  • green background – What did we do well?
  • red background – What should we do differently?
  • blue background – What did we learn?
  • purple background – What still puzzles us?
  • Division – I wanted to record whether the comments were coming from a programmer or someone in a different part of the team as perceptions were likely to be different.  This turned out to be a non-issue as only one non-programmer contributed content.  (Which is interesting because when we did lessons learned on the mailing list, we had lots of comments from engineers.  This may still happen in phase 3, but at least programmers got to frame the discussion about programming in the brainstorm phase.)
  • Optional name – In case there we wanted to clarify something.  Only one person choose to be anonymous.  This column turned out to help me because a week after I sent out the request to participate, only the more senior members of the team had contributed content.  This allowed me to “re-invite” the newer members by name.  If everyone was anonymous, I would have just known that turnout was poor but not why.

Phase 2 – post it sorting

Ina corporate environment, I just sort/group the post its.  With the high school team, I also edited a little.  Just to avoid “I agree with so and so” because the sorted post its don’t have names on them.  This took me about an hour.  I did not edit the items for length even though some contributes were sentences (which is really long for a post it note.)  I also added a couple post its to round out groups and get at missing subtext.  I’ve added post-its while grouping in a corporate environment too when the contributed post-its dance around an issue.  This is actually the first time I’ve grouped post-its without having an “other” kitchen sink category!

Now that we are ready for phase 3, the spreadsheet has three tabs:

  1. raw data – what people contributed
  2. grouped – data from tab 1 grouped by category
  3. a summary of the categories, # posts its in each category and a summary with some questions for discussion (in a corporate setting, I order the categories by # posts but don’t come up with questions.  I did here because phase 3 will be over e-mail)

Phase 3 – discussion

This hasn’t happened yet.  I’m sending the spreadsheet out today.  I expect it to be like the lessons learned e-mail threads of the past though.  Which is fine now that we’ve gotten the topics to talk about out there.

“i want a career in java”; “java is the next cobol”

Posted on by
3

Over the past week, I’ve heard the following quotes “I want a career in Java” and “Java is the next Cobol.”  While these two statements don’t conflict with each other when taken literally, the connotations are quite clearly opposites.  Let’s take a look at themS

“I want a career in Java”

This is often asked in the context of a college student who doesn’t have any programming job yet.  So why Java specifically?  When I was in college, I wanted to be a developer.  Any language would have been fine.  It was where my path happened to take me that made me (currently) a Java developer.

Further, you don’t have a career in one programming language.  Things change too fast in technology for that to be the case.  So despite the fact that I’ve been a Java developer for the last ten years, it doesn’t imply that will be the language for my whole career.  Or maybe a career is a shorter term concept than that which I think of?

I think the context behind this statement is that Java jobs appear to be plentiful and pay well making them attractive to someone without any language experience.

“Java is the next Cobol”

A quick internet search says Java has been compare to Cobol since at least 2007.   Let’s see.  Cobol is a widespread language used in countless production applications.  It lasted decades.  It wasn’t cool, but it worked.  Not a bad place to be.

I think the context behind this statement is that Java isn’t cool anymore.  Or a “default” choice of language.  Which is fine.

Where we are

 These quotes show that we have people eager to learn Java and people predicting it’s demise at the same time.  Clearly the reality is somewhere in the middle.

Java is good for certain types of apps.  JVM languages are good for certain types of apps (especially when there is a desire to integrate with “legacy” Java code.)  As is .NET and Python and Ruby and …

Inovation is good.  That’s why we became techies!