The Degradation of Java Developers

On multiple occasions I was blogging about these legions of enterprise Java developers trained to use certain frameworks without understanding how things work under the hood. This morning I had chance to see it one more time after interviewing three job applicants in a row.

Our consulting company got a request for a well rounded Java developer with the knowledge of SQL. We have good reputation with this client, so I started screening the candidates, which I got from a recruiting agency.

First, about the resumes – each has several pages with detailed description of their work for various employers. Each resume had a list of technologies that the candidate supposedly know. Here’s the list of technical skills from a real resume:

Core Java, J2EE, JSP, JDBC, Servlets, AJAX, XML, HTML, XSLT, Web Services, CSS, JavaScript, SQL, Oracle 10g, MySQL 5.0., JMS,Eclipse, Adobe Flex Builder 3.x,UML, JDBC, SVN, JUnit, VSS, Jira, HTML, DHTML, CSS, AJAX, JavaScript, XML, MXML, Action Script, Servlet, JSP, JSTL, Hibernate 3.x, Spring 2.x, IBatis, SOAP, UDDI, WSDL, Apache Axis, Web logic Server 8.x, Apache Tomcat 5.0, Struts Framework, MVC, ANT, Maven.

Looks impressive… for those who haven’t been interviewing Java developers. I don’t want to say that this candidate is lying, but he wasn’t able to maintain a conversation about 80% of these technologies for more than 3 minutes. They’ve heard or even tried working with these technologies or tools, which is all that’s needed for adding them to the resume. What are the remaining 20% they can talk about? The frameworks. Most likely they will explain how to configure Struts or Spring, and even how to make Spring talk to Hibernate. BTW, they all love Hibernate cause it spares them from writing SQL, speaking of which, they know very little about this query language.

When I see all these Struts, Springs, and Hibernates on the resume I start with this, “Imagine, that you’re not allowed to use any frameworks. Explain in details the entire process of bringing the data from DB tables Customers and Orders to the Web page”. For most people it’s a killer proposition let alone writing some SQL queries…

One person had JQuery on the resume. I asked her, “Why did you use jQuery”…20 sec pause…”I like it, it’s nice!” That all I could pull out from her on the subject.

Two weeks ago I’ve attended a technical keynote at JavaOne in San Francisco. Brian Goetz was showing code samples of Lambda Expressions (a.k.a. closures) that will be introduced to Java 8 next year. This is a pretty advanced feature and proposed Java syntax is not for the faint of heart. I was thinking to myself, “Who’s going to use these closures in the enterprise Java world? 10% of the developers? 5%?”. Are these expressions being introduced just for fun cause it’s cool and other functional languages have them?

Software development industry is changing. It doesn’t need hackers anymore. It needs craftsmen who can configure and replace blocks of code when something stops working. Ideally, you should have in your team one Java expert who can actually understand the code of your application and can fix it not on the block level, but can drill down to a single line of the Java code. Somehow such people also know how to write a SQL outer joins, how to fix the broken build, and whatever else may come up.

A typical enterprise manager wants to increase the population of his software developers. Managing more people is the shortest way for moving up the career ladder. It is what it is. But if you are smart enterprise manager, make sure that for each dozen of framework programmers you have at least one real.

I already received a new resume for tomorrow’s 10AM interview. The resume looks the same. The only lines I read are the names of the former employers and projects. Any other written information is useless – the real picture will start developing tomorrow at 10AM.

Tomorrow’s Update. It’s 10:15AM. Yet another interview is over. The fourth wrong answer was that to send the data to the browser a servlet has to add it as an attribute to the HTTPSession object. Do you think it would be rude to stop the interview after listening to such answers for 10 minutes?

Yakov Fain

8 thoughts on “The Degradation of Java Developers

  1. Agreed with Hibernate and frameworks in general (not just Java). I’ve seen Hibernate being used in improper scenarios, with Derby being used as a simple key-value store, with horrible performance, no scalability and heaven forbid you want to aggregate some data.

    Javascript is becoming a lost art. Kids use JQuery and a million jQuery plugins even for the most trivial tasks, like getting the query string.

  2. I think you’re spot on. The bottom line is core basics. Understanding Java’s HttpServletRequest, HttpServletResponse classes and then diving deeper into session management, concurrency, and all of the basics of the Servlet architecture is essential before diving into a higher level framework. You have to get the fundamentals down before you start using a framework which does everything for you. Otherwise the features which do expose the servlet architecture aren’t going to make any sense.

    I admit I love using hibernate and think it’s awesome, but just using that will not make you a strong developer in SQL. Sometimes like doing GIS or geo coordinate mapping is near impossible to make efficient in hibernate without doing some SQL enhancements. And what about optimizations. Its important for a candidate to get the basics down, set up a stored procedure that inserts a gazillion bogus records and then see how their bloated hibernate queries operate then.

    Good post.

  3. Hi,
    while I am not objecting in the large, I kinda feel compelled (see the obvious XKCD) to argue about several fine points, coming myself from a rather enterprisey context. 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. Anyway, JPA does not magically lift the requirement to know SQL, since the data is still stored in a SQL database and accessed in a very SQL-like way (And, actually, most of frameworks try to reduce boilerplate — the question is if it is possible in a better fashion than now, since most JEE frameworks rely on runtime coupling, which makes the test cycles rather annoying)
    Another point is the whole lambda deal. Current Java developers seem to like Groovy, which is a good approximation of Java 8, albeit dynamic. Even without that, most architects will use the capabilities of Java 8 in new projects, so the “normal developer” will have to adapt to the given contracts. Since anyway, having support for anonymous functions reduces lots of scary code.

    Having said that, the main problem IMO is that enterprise development is getting more and more decoupled from the underlying technologies, which results in framework-oriented instead of problem-oriented thinking; partially this is the case since several frameworks are larger, and more complex than the core API. Which results in bad knowledge about what the code is actually doing.

  4. I’ve seen the same problem on another side of computer science. Dealing with a whole IT Infrastructure for a company (network, storage, database, then server and VDI) a single problem cause by a single configuration item can take up to months to be solved because nobody is getting the big picture anymore.

    And what would you think of the NodeJS way of having framework sprouting all the time. I have that feeling that we are just loosing focus all the time about value in software and how to build it.

  5. @DS Framework are created to spare the programmer from writing tons of mandane code. Hibernate might help you here, but it’s hard to imagine that if you have a 100 tables in the database the queries created by Hibernate don’t have to be fine-tuned and optimized. If a person who uses Hibernate doesn’t know SQL – it’s bad.

    Creating a comfy environment for software developers is great, but don’t forget that we are writing code to ensure that the users get the best possible product.

    For more detailed answer see this:

  6. I think every java developer should know the basics of how software works, this usually is tought at any computer sciences course. I also see this framework zoo on nearly every CV and I expect that all of those have been used to some extend, if not the candidate is lying and not worth a second round, period.

    Good luck with your search

  7. @Yakov, are you saying that java developers need to be good at java? That’s a groundbreaking thought :) On a more serious note, there’s no substitute for solid fundamentals such as Data Structures, Algorithms and OO Analysis/Design…or even more fundamental skills such as analytical thinking and a knack for problem-solving. Based on my interviewing experiences, the latter skills are not as common as one may think…

Comments are closed.