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 push 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.