Happy New Year to everyone. May this year be a year full of challenges, hard-work and success in every goal you've subscribed to accomplish.
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:
Advantages:
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?
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:
Advantages:
- 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?
"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."
ReplyDeleteWhy would you want to do that? Ask me how to calculate a date difference and I'll reach for a library too - despite having ported Joda Time myself. There's no shame in abandoning java.util.Date/Calendar, IMO. They're awful.
Would *you* reach for java.util.Date? If so, I suspect you're missing out. I don't see why you would make your life harder than it needs to be.
I got nothing against Joda Time. Heck, We're using it on our new project. I guess after years of using java.util.Date that it comes naturally to do simple date/time difference.
DeleteThis was just an exercise to see how our colleagues thinks and I discovered how quick some jumped to using 3rd party libraries.
In essence, people don't read API's but tend to find libraries that works.
A lot of Java EE have never, ever written a Servlet. Do you believe a developer who does not know how that works is efficient at writing applications?
DeleteJust because he has experience in a specific Technology or 3rd party lib that does not mean he knows the basics.
And I believe that is the main issue here.
Programmers are expected to know the API for X rather than being able to solve problem X and there are more and more new API's every day...
This comment has been removed by the author.
ReplyDeletePoint well taken. However it is confusing that you start with the following
ReplyDelete"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"
But after I read your post the feeling I got is that you don't like how developers work these days and that you miss the good ol' days, you my friend have fallen on the "This is how we used to..." mindset.
Frameworks, libraries and API's are good. What is worrying is that many download these libraries, write simple program, blog them and hopefully everything works the same way in a larger scale.
DeleteNobody sits down and read specifications on how these API works and tend to test their application on a single cluster by pumping threads to it. When the integrated application goes live and issues arise, the quickest thing to do is Google for answers.
The days of doing incident analysis are fast fading.
That's what I tried to emphasise.
You are missing the point when you say there is two types of developers, and put them against each other. No. Every developer needs to be able to be creative and release quickly by using all sorts of third party libraries and frameworks, and esteem their value quickly. Equally important, every skilled developer needs to be able to debug, understand internals. These are not mutually exclusive.
ReplyDeleteYou make a very good point. But I doubt you ever had to program in assembly language either, I certainly haven't. And there are are valid arguments that code written in native assembly language are better than what can be written in C.
ReplyDeleteBut Nicholas DiMucci's point doesn't really hold up. Adams was talking about having the freedom to pursue an intellectual life that was free of the need to confront tyranny. The point of the post was that the new generation of programmers assemble lego bricks without having any depth of understanding about what how things work.
The same thing as happened in Web development. The technical colleges in Phnom Penh are churning out 'web developers' who think they know html, css and php, but really all they have learned out to do is click on menu items in dream weaver.
All they know is how to snap together lego bricks, and that limits what they can build. It would never occur to them to design and build new bricks, and often they wouldn't even know how to mix bricks from different kits.
You loose a lot every time you create a layer of mediation. That's not good or bad, it's just the way things are.
I'll agree that the point I was trying to made was attempted poorly (why I deleted the post). What I was trying to say was that developers today have access to tools, resources and technologies that weren't necessarily available 10 years ago, whether it's the ability to use a new framework that's aimed to replace or improve a similarly poor one (Joda over Date as mentioned above), or the ability to reach out and find a proven solution to a problem quickly, without necessarily having to pour through (sometimes) poorly written API documents and cobble together a new solution from near scratch.
DeleteThat said, I feel it's a horrible blanket statement to say newer developers do this without having intricate knowledge of the lower level details or not having the desire (and ability) to "design and build new bricks", as you put it. In my professional experience, those looming sprint deadlines simply don't allow enough time to always do that.
You were spot right about the downloading a framework part. PHP CodeIgniter, Laravel... You want C++ why do Raw lets just use Qt-Project. JavaScript you say, hell no jQuery!!! etc etc etc... Spot On!
ReplyDeleteI first read this article some 30 years ago. I read it again a few years after that, and again and few years after that, and so on, and here it is again. It's the same old story. People see all the cool kids are coding in high-level language X, and they get all the press, whilst a vast quiet industry behind them continues to churn out code in established languages.
ReplyDeleteC, for example; C code is everywhere. It's in almost every OS I can think of, it's running my dishwasher, it's in my car, it's the standard language of almost every embedded platform I've ever worked on.
The TIOBE index, whilst very unscientific, would reveal the shift away from languages that require the coder to understand the machine; http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
The top four slots contain 3 C based languages. There is a vast amount of code still being done in C based languages.
This is how it was five years ago, ten years ago, twenty years ago; every so often someone starts worrying that since all the cool kids and all the adoring press is talking about high-level travesty X, that soon there won't be anything else. Complaints that new coders only know how to join together existing frameworks have been heard since the first time someone used a computer they didn't build themselves out of transistors. It wasn't true then and I think it's not true now.
This paradigm shift is not due to the developers becoming lazy or not curious enough (although some are, and they existed long before today)! It's due to the fact that our field has become an extremely demanding industry where quality is of no essence, all that matters is speed.
ReplyDeleteSince when did applications have a prototype or an MVP (Minimum viable product) which is nothing but a mesh of "hacked" code that just works?
Currently, we, developers are simply tools of execution of the almighty business strategies. It's no longer a Science unfortunately and CS students are technicians.
Despite what I just said, there remains a lot, yes a lot, of curious minds that are never satisfied by the shell and dig deeper to reach the core and sometimes innovate on that level.
New programmers are very enthusiastic and want to get something they can blog about done quickly. More experienced programmers choose their projects, their language etc. They're not looking for fame as much.
ReplyDeleteThere are not two types of developers. The idea of using something off the shelf if you can is as old as Brook's law. The fact is that we are building software for a market. The market is competitive, and market conditions change rapidly. To be adaptable, software developers no longer can afford to build everything from scratch because it takes too much time.
ReplyDeleteThere are benefits to using a library over something you've built yourself. A library that is in use in many projects has more exposure to interactions with external interfaces, usage patterns, software development lifecycles, dependency collisions, etc. This means that the library or framework has more exposure to obscure bugs and useful feature requests than an internally developed library. It also has more people invested in making the code robust and reusable. Over time, the library or framework is likely to have fewer and fewer problems because of these two factors.
A developer that uses a popular library is taking advantage of the skills of many other developers to get their job done. I don't ever hear of a carpenter or welder complaining that they didn't build their welder or hammer. Or a master contracter complaining that they didn't run the pipes themselves. This is not to say that the carpenter doesn't know when the plumbing is crap. They still understand it and can contribute to it if needed. But that isn't their job. Their job is to build an entire house.
The same is true of an application developer today. Their job is to build an entire application or product, not to build a messaging queue or filesystem or operating system kernel. They pick the components and assemble them, handling bugs that come up by contributing to the components that they choose as needed. The overall result is better software for everyone in the community, and more responsive software design for users and businesses.
This feels like a very elitist post, but I guess should've guessed that from the name of this blog. From this post I guess you can classify me as a new generation programmer. Yes I like to use third party APIs to get things done rather than code my own crappy version of the wheel. You say developers should understand everything about their framework they're using but the whole point of using frameworks is to abstract a part of the code that way you can spend your time doing other things. I agree with you that in a perfect world a developer should know their API inside out but I think that will come with time if the developer needs to work this API for a long time. For something that needs to be done quickly I see no point in understanding every nook and cranny of an API in order to use it.
ReplyDeleteThe point I'm trying to emphasise is this: Modern day development isn't a bad thing. What is bad is when the application reaches production and a process fails because of the internals of the framework condition wasn't met. First thing they do is Google or ask questions on StackOverflow. What I've picked up is mostly, they have not read the API specification or user guide. They are the type to learn as "things" happen but fail to understand why the solution works.
DeleteA developer are solutions provider and as solutions provider, one should know the problem (through incident analysis) and the a reliable solution to resolve the problem in future.
Like at school: Knowledge comes before practice. :-)
Very interesting post and I agree with most of the content. The 'new' generation relies on automated tests a great deal. They will write a bunch of tests against the API to make sure all their use cases are covered (and then who cares how it works).
DeleteI disagree that the new generation cannot debug. They just defer learning about the internals until they are forced to. If StackOverflow cannot help, they will learn just enough to find a hack to get around the specific problem (with gdb or whatever's necessary). Some coders are extremely good and fast with this approach. Again, they will write tests to ensure they are covered. They might inform the maintainers of their findings, but often not, precisely because they haven't got the deep understanding.
What is the result of dividing 23 by 3?
ReplyDeleteHa! I bet u used a calculator rather then a piece of paper and a pencil.
Actually no! I used my brain. It's 7.6 recurring (the 6 is recurring). I used to be taught mathematics from the age of 5, using an Abacus or grains of beans. :-)
Delete"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."
ReplyDeleteThat's so interesting. I've been programming for many years, but a while a go I found myself dealing with Java, a language somewhat new to me. I wanted to count the time difference between two dates (in days; not in 24 hour increments, but days). The Date object was puzzling (me compounded by the fact that it seems to be deprecated, and replaced with a weird Calendar object) so I turned into StackOverflow for an answer. I didn't post anything, but found several similar questions.
I found maybe a dozen answers on how to do it. They were all either wrong (by misunderstanding the problem, and counting 24 hours increments or failing in some edge cases), or using a huge amount of code. And, indeed, many of them suggested this or that framework, Joda time included.
I was a little bit angry by that, to be honest. I decided to have another look at the problem myself and ended up solving it. In one line. Using Date.getTime(). Super readable code that did what I wanted. I felt a little surprise - I should have done that in the first place. Looking for the answer was too easy, I suppose, and something I've found myself trapped into doing. But how come all these answers would go over all these hoops to do the same? Some of them were using the exact same technique I was using, but doing so with an overly complicated code wrapped by a bunch of functions or even classes. Just for a simple subtraction and division. It was like a wake-up call.
Maybe it's part of the platform, or community. The Java mentality seems to be one of copying and pasting code, or just using some third party code to resolve the problem, without actually understanding what's going on. I do have a lot of respect for the content I find on StackOverflow - many times, it's my only way out of a hard problem, when documentation is lacking for a platform or another (terribly common on the Android platform, I'm afraid). But it's obvious it encourages a behavior of gung-ho copying&pasting. It's not creative, in my opinion, it's just people looking for shortcuts without worrying about the consequences.
I couldn't have said it better myself.
DeleteHello friends,
ReplyDeleteI read your site it's rely valuable posting ,i want to read something new in next time.......................
Hi Orelinfotech.
DeleteThanks for your feedback. Yes, I do some occassional posting. You are free to follow my blog for future posts. You also are free to ask what you want me to elaborate and discuss on my blog.
The future of IT will be cloud computing, or software applications delivered and consumed through Web browsers. The concept of packaged software is old now and will be replaced by applications accessible through the Web. The ubiquitous nature of the Internet has produced more informed users, and this factor acts as a driver for frequently changing demands for services, thereby laying the foundation for an uncertain long-term landscape for businesses.
ReplyDeleteDrupal Web Development
As a ASP.NET Developers I really impress your reliable information especially advantages and disadvantages-Thanks
ReplyDelete