Comments:"The Elite Gentleman writes....: The future of software developers."
URL:http://theelitegentleman.blogspot.co.uk/2013/01/the-future-of-software-developers.html?m=1
As a software developer, I have to always try to keep up-to-date as the software industry is growing at an alarming, and 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.
Being an old school developer, who has played with legendary API's, from WinAPI (Windows API) in Delphi, C and C++, to JDBC API in Java. What I'm trying to say, from each language I've used, in my years of as a developer, I always stuck to API delivered from the programming language SDK.
Unfortunately, a new generation of developers are fast-brewing and I call them 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 indepdent 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:
Advantages:
- They are mostly the creative bunch. They don't waste time learning to play with new technologies and quickly build applications that they can quickly sell.
- They release product quicker. They don't really worry about the underlying working of the components they use as long as they know how to use it.
- 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 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.
- Chances are, they might not be able to write a framework themselves. I don't think there are 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 I got 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! Today's job postings, Many companies post jobs with requirements that is no more language specific but technology or product specific. A Java developer today must know EJB 3, must have used Hibernate/EclipseLink. Know how to use jBPM, and know RESTful or SOAP communication for Web Service invocation.
SOA architecture have taken rise to the IT world, as we see that Cloud Computing, Application in the cloud, and clout 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? Are you willing to provide service solutions to business or be a technical expert?