Since folks ask the "why certify" question from time to time, here's another benefit I've personally seen (got my SCJP, studying for SCWCD).
I find that studying for the certification helps me determine the scope and boundaries of a certain technology. A topic as big as J2EE web development is a little intimidating, and it seems like the possibilities are endless when you first start. So there is something very comforting to know you understand the topics that Sun considers most important about these APIs. That doesn't mean you're a world class J2EE developer yet, but you understand the "lay of the land" (good cowpoke sounding term) and know what topics you will need to master in order to get there.
Well, that is a nice sentiment, but the truth is a little more complicated. When I was with Sun, I was the lead on selecting the objectives for SCWCD (and for SCJP for Java v1.5 and SCJA). The way I did this was to (a) review the technology, (b) ask specification leads, and (c) ask SMEs. In the end, there were many political choices made. One SME really felt that "JSP Documents (XML-based JSPs) were the next big thing and everyone must know about them" While others felt that web developers must know all tag library mechanisms. This type of politicing leads to a bigger and muddier exam. I would let my group of SMEs vote on these issues, but in the end I often allowed more objectives in than I should have.
The alternative is to have one person dictate what will be on the exam objectives, but this strategy is only as strong as the dictator and I never felt that confident. So, I opted for the community (or the much-maligned "committee") approached.
Now that I am no longer with Sun, I am not in that position anymore.
Joined: Apr 03, 2006
Thanks for replying Bryan, that's good insight about what makes it in the exam.
I guess I'm thinking somewhat of the HFSJSP book where you guys do a good job of saying "don't forget this, even though it's not on the test". Do you still think it's fair to say that when you prepare for the certification you're "getting your arms around the topic" such as JSP/Servlet development? Not master but at least feel like when you run into challenges in real development you'll know where they fit in the overall picture, and how to map them to what you learned.
Joined: Apr 30, 2001
Originally posted by Ryan Day: Do you still think it's fair to say that when you prepare for the certification you're "getting your arms around the topic" such as JSP/Servlet development?
Yes, I agree. That was a theme for SCWCD: getting the big picture of the fundamentals of webapp development. There were some SMEs in the last revision of SCWCD that asked for objectives on frameworks, in particular JSF. I flatly reject this idea because JSF is not fundamental; it is built above servlets/JSPs.
Originally posted by Bryan Basham: I flatly reject this idea because JSF is not fundamental; it is built above servlets/JSPs.
Yes, good call. Although JSF will probably be in the next version of the exam since it is part of the Java 5 EE spec.
Here's why I think the foundational knowledge is more important than framework knowledge.
Java EE has multiple layers of abstraction to cover HTTP-ness and HTML-ness of web applications. Frameworks simply add another level of abstraction on top of what is already there. While this might make programmers more efficient for most tasks, the inexperienced people are at a loss when there is a leak in the abstraction. The knowledge from SCWCD has been terrific for me in plugging the leaks and knowing how to troubleshoot when a framework (like Struts) doesn't do what I'm expecting.
Humans, especially software developers, use models to store information. We rarely remember a series of facts. Rather, we remember a model that describes the more regular facts then memorize the exceptions.
For example, given a series of numbers 1, 3, 5, 7, 9, ... we remember "odd numbers". If the series becomes 1, 3, 5, 6, 7, 9, 11, ... we remember "odd numbers with the addition of 6".
For me, HSJP (and I suspect all the HS books) helped me solidify a core model of web-component development that will serve as a place to hang all the exceptions. This, even after several years of developing web components with J2EE.
BTW, this entire idea of how humans use models is expounded in Alistair Cockburn's classic book, "Agile Software Development". I strongly recommend it.