As a software developer, I have to always try to keep up-to-date as the software industry is growing at an alarming, and (doubly) exponential rate. This is the reason I'm always on StackOverflow: the question asked by other developers worldwide shows how software are evolving. If a developer misses the train of evolution, they will get frozen in the ice-age period of "This is how we used to..." mindset.
Now that I got the pleasantries out the way, I've decided to write this post on an observation seen from the many years spent as a software developer.
Being an "old school" developer, I have programmed with legendary API's, from WinAPI (Windows API) in Delphi, C and C++, to JDBC API in Java. Each language I've used, in my years of as a developer, shipped with API bundled in the Software Development Kit (aka. SDK). These API's gave developers the freedom to develop absolutely ANYTHING, based on their requirement/imagination. There was virtually no dependencies as the API existed in the SDK.
Times have changed. API's exists in a new model called Frameworks. This, unfortunately, results in fast-brewing a new generation of developers that I call the "component assemblers/integrators". They are very fluent in downloading frameworks, libraries, software modules and integrates them together to form an application that they can deliver to business. If there are issues during the assembling (and in assembling, I mean assemble through code) and/or integration, they are quick to Google for solution/answers or ask question through StackOverflow. You can recognise them well, they post a question with a full exception stacktrace from 3rd degree exceptions.
My thought on the new generation programmers.
Today's developers have what we didn't have back in the day: A wide variety of platform independent programming language, too many (open source) frameworks to choose from and web services that are easily found through some UDDI registry or an easy Google search.
There are advantages and disadvantages to these programmers:
- They are mostly the creative bunch. Today's frameworks/libraries/applications, etc. are designed to make development time faster and simpler. This allows that development time are spent building applications and also have fun doing it. This fast learning curve gives rise to creativity in broadening the horizon and bringing new features and new technologies rises. So, the vicious cycle continues.
- They release product quicker. There are too many API's on the rise to make product integration easier. No need to know how the internals actually communicate between protocols as long as the request send and response received meets your requirement, everyone's happy.
- Frameworks have a fast learning curve than traditional API's. This is due to the fact that pre/post conditions of using frameworks are lesser than API's and exceptions are "generally" well handled.
- They lack knowledge of internal systems. if you take those who know JPA and Hibernate, most likely they don't understand fully the JDBC API and how the Hibernate framework works internally. They tend to reference a Hibernate/JPA book when issues arise.
- Debugging is not a strong skill. They haven't been exposed to API when wrong values caused a segmentation fault and a good debugger such as gdb (if you've been a C++ programmer) is a skill. Once stuck in an issue, they are quick to log a issue bug to the company responsible of the framework they use or ask the question to Q&A sites, like StackOverflow.
- Chances are, they might not be able to write a framework themselves. I don't think they are those people who can write a proper Servlet other than using a
@WebServletannotations (Java EE 6 and higher).
Ask them how the SOAP protocol works and you get an answer like: Get a WSDL, generate client code and write a Service to call a method and Bob's your uncle.
I asked one colleague about how to calculate date difference and the first thing he told me is to use Joda time. Gone are the days on learning the Date object and doing proper date calculations.
Are they to be blamed?
No! In today's job market, many companies post (development) jobs with requirements that is no more language specific but technology/product specific. A Java developer, today, should know EJB 3, must know any persistent/ORM framework availble (such as Hibernate or JPA), know Business Process Management (BPM) and create/develop using BPMN (like jBPM/Activiti), and know Web Services (RESTful/SOAP).
SOA architecture have taken rise to the IT world, as we see that Cloud Computing, Application in the cloud, and cloud services are taking the norm.
If you can't think or find a library that solve a problem on the spot, chances are you won't fit in the modern day programmer.
And what happens to us?
We, the old school developer become Application Support Specialist. We maintain and support outdated but fully functional applications which makes the company its revenue. Are these applications going away? Not likely, but we are not considered in the frame as these new component integrators. Think about it this way, mainframe developers still exists today. They are only available to support the ancient mainframe applications and do few enhancements but don't expect to see a brand new system completely written for the mainframe system.
So, if you decide to further your development career, you should ask: Am I willing to provide service solutions to business or be a technical expert and stay in the daisy wheel of an Application Support Specialist?