My previous post “The Degradation of Java Developers” sparked several interesting discussions. One of the major topics was if today’s developer has to know what’s going on under the hood of a particular framework. To be more specific, if Hibernate, a popular object-relational framework, can hide from your how the database objects are being created or manipulated, why learn SQL? One reader stated, “First of all, Hibernate (JPA, actually) is a step forward since it reduces most of the boilerplate SQL of the obvious kind. In applications with around 100 tables in the SQL database it is not challenging to explicitly write data access objects by hand.”
I can agree with this to some extent, especially when we talk about such mature and stable framework as Hibernate. But this framework was created to spare the programmer from writing tons of mandane SQL and JDBC code. Hibernate might help you here, but it’s hard to imagine that if the storage consists of 100 database tables no queries created by Hibernate have to be fine-tuned and optimized. In such cases if a person who uses Hibernate doesn’t know SQL – it turns him into a useless team member.
About two months ago I was making my usual morning promenade along the beach. Every morning a couple of tractors are moving back and force leveling the beach surface destroying the sand castles and burying butts and seaweed. All of a sudden, one of the tractor’s wheels got stuck in the sand.
The driver started angrily pushing the pedal or whatever else there is to push, making the tractor move back and forth slowly but surely getting deeper and deeper into the sand. When the tractor’s belly was literally laying on the sand, the driver realized that he won’t be able to get the vehicle out of the sand himself.
I was observing the entire show from the beginning of submerging till the moment he started to call for help using his cell phone. This is when I took the picture. What struck me the most was that during all this time the driver didn’t even bother to step down from the tractor to do anything manually to prevent the submerging. He didn’t bother and he was not trained for these kinds of situations. I assume he was told to call the office in case of any extraordinary situations. Houston, we got a problem!
Do you see the analogy with a framework coder who doesn’t know how things work under the hood? I clearly do. I also know that among the tractor drivers that are working on that beach there are people who know how to fix these situations without calling for a tow truck.
On the same note, each team of programmers includes a person who knows how to fix everything starting from fine tuning SQL all the way to fixing broken builds or writing manual piece of code that performs better than a framework.
Some developers who use open source frameworks know that if there is a bug in the framework or some feature doesn’t exist they file the bug or request for improvement with the vendor and then happily report to their managers that we have to wait till the vendor will fix it. But there are people who understand the words “open source” literally. Yep, they open the sources, read the code, subclass the problematic classes and make the fixes on their own.
The question is if IT managers understand and promote those people who are not afraid to roll out the sleeves. It helps if the software developers know how to manage the manager. But this is a topic for another blog.
P.S. Replacing SQL with a 500-page long JPA spec “to make my life easier” is not a good idea unless you really need various types of data storage. In 99% of the today’s enterprise applications it’s not needed. But my kudos to the Sun/Oracle tandem for brainwashing millions of Java developers into believing that learning JPA is better than learning SQL.
yakovfain.com 
Excellent analogy!
Since last year I been using JPA (Eclipselink BTW) in the projects I been involved in the company I work for. I FORCED my coworkers to use it and, after a while they realize that the effort invested in learning it pays in the middle ans the long run. I even have to convince management of the productivity gain introducing JPA without their approval!
But…
They (coworkers) only learn the very basic stuff!
Sometimes they come and ask me why they get an error related to detached entity, optimistic lock and so!
It is so frustrating that having the WHOLE Internet to get answers they don’t look for their self!
I think that “java developers” (if we can call them that way) are getting lazy…
There is a special site for such people. It’s called Google it for me: http://googleitfor.me/
Although I am a Flex/AS3 guy, and not a Java developer, I have been in your shoes. The solution is simple: hire programmers with experience contributing to an open source project, and whom have experience teaching others what they know in their field. From experience, you do not really know something until you have to to teach it to others, and you do not really understand an open source framework until you are in a position to contribute a patch or a fix to it.
As for the resume bit, I look for developers who show that they know their stuff without playing the lying game. If they have teaching (or tech writing) and open-source contribution experience, that’s usually good enough for me, but I also look for a little honesty — not so many skills listed, but demonstrates a firm knowledge of them. Which is why I personally list “primary” and “secondary” skillsets: recruiters love all the acronyms (if I cared about recruiters, that is) and it lets me be honest: “No, I don’t do backend. No, I don’t do server side code at all. But I’ve written books on ActionScript, and can edit Flex framework down to the nth code line.” That kind of honesty wins me a lot of points. And has won points with me when I’m doing the hiring.
And by the way, speed coding tests are not going to show you whom the good developers are. Just like certifications don’t tell you. Speed tests are great for people who like tests. Most of the good developers I personally know such at ’em. Certifications are great for people who memorize stuff. Neither alone makes a good programmer. What makes a good programmer in my books is innovative thinking. Do you know how to get a tractor out of the mud _before_ it gets stuck, by yourself, without calling in the national guard?
Don’t know the answer off the top of your head, or able to recite of the top of your head the API which caused the mess? No problem. As long as you know what the problem is, know some of it off the top of your head, and the rest where to go find the information, and then how to go about putting together a solution to fix it. That may take prototyping and looking stuff up. I don’t mind, I’ll wait… can you do it?
This is the guy that gets things done. This is the guy that would get the job.
Most good developers are what I call Edisons (after Thomas Edison). They don’t bother memorizing a lot of stuff, but they have done a lot of stuff, and bridge the gap between what they have done and what they don’t know by trial-and-error, by prototyping in other words. The problem is, to an inexperienced developer, this looks a lot like “winging it,” but it is the furthest thing from that. Everybody expects good developers to be what I call “Teslas” (after Nicola Tesla): geniuses without parallel able to memorize anything and build it all in their heads before they write a single line of code. But if you go looking for Teslas, you’re going to wait a loooong time. Look for the Edisons.