The future of software developers
theelitegentleman.blogspot.co.uk
theelitegentleman.blogspot.co.uk
It's true that the new breed doesn't understand the lower levels as well as the old, but that is simply because 30 years ago there wasn't anything except the lower levels to understand. Getting anything done with programming back then was much harder, but on the other hand, the choices were more straightforward. Whereas there was a higher bar of raw intelligence and tenacity just to dip your feet in programming, today there is a higher bar to what true masters can do (the Obama campaign machine comes to mind).
The essence of software development does not change though. Just because you don't understand all the layers today as readily as a 1980 programmers would, doesn't absolve you of the responsibility of being ready and able to dive through the (increasing numbers of) layers to find bugs and leaky abstractions. Equally importantly, you need to develop a sense of where your time is best spent, both in terms of immediate productivity and in terms of long-term ability. This was as true 10, 20, 30 years ago as it is today.
It's intellectually dishonest to pretend that knowledge acquired by programmers of yesteryear was innately better and more detail oriented. Of course there are more mediocre programmers now because there are orders of magnitude more programming jobs, but there are more great programmers too, and it would very foolish to write off someone's talents simply because they do not share the same arcane but relatively useless knowledge that an old-timer posesses.
Me too ;) However I think both kinds of programmers can probably form great teams together. Being able to rapidly build full-featured applications very quickly has become very important. But as the applications evolve, this can come at the cost of scalability and maintainability. Improving that point very often requires knowledge of the low levels of the systems. Same is true for a large class of weird bugs that occur.
Although I'm not sure whether most companies see this the same way. When I went 2 years ago through a number of phone calls with recruiters I realized they were really eager to find young people. Being an advantage for me at same point, this will obviously turn different when I get older. And probably at some point there will be a new kind of developers with a completely different way of thinking and working, while we are still stuck on Github, Stackoverflow and HN.... I wonder how many people are still stuck on Sourcefource, C++ forums and slashdot.org ;)
If so - may I know your area / pitch? Just want to hear how others do it
1. Everyone starts somewhere. There's no reason to place an "us vs. them" lens on things as if a "CRUD-type developer" can never learn, improve or grow the scope of their interest.
2. How many domains (workflows, businesses, entire industries) could be improved via a simple CRUD layer on top of a database, and have yet to have said CRUD app made? IMO many. As software continues to "eat the world", there will be a need for more people to make the latest CRUD applications.
And what happens when a CRUD application needs more advanced features? Either the "CRUD-type developer" will rise to the occasion and learn some new skills, or a more experienced (e.g. the author of the blog post) individual will be hired/tasked with the job.
Even if I want to agree with the concept of the article, overall I find it to be a bit petty and underwhelming in its exploration of the topic. Particularly the "advantages/disadvantages" section.
I'm never going to write a compiler and don't especially want to. However I hope my attention to detail for user-facing features and my ability to solve real-world problems keeps improving and I think we need more of that type of programmer than we do the computer-sciencey type.
I am personally bored to tears delving into algorithms, but I'm perfectly capable of writing them. Though I'm no expert I have dabbled in simple things like sorts and search algorithms. I simply don't enjoy it. I like solving other types of problems.
I have great appreciation for people who are improving the tools that I use. People who write virtual machines and compilers and parsers impress me. I am glad they are interested in the work down in the lower layers, though I have no desire to join them. I think it's unfair to lump everybody together, there is a lot of gray area. People like myself learn skills as necessary for our work as well as personal interest. Not because of mental deficiency.
Web development is, for the most part, write-once run-anywhere, from an x86-on-steroids desktop PC to a pocket-sized RISC device (even for people with very small pockets). Frameworks abstract away a lot of complexity and a modern developer is more of a builder than a wizard, and this is a good thing. If you had told those 80s programmers that programming in the future would have been less like electronic brain surgery and more like building with Lego, they would have, I think, been quite pleased at the notion. Thirty years of software engineering research and practise have gone into making it this easy to build stuff. I wonder if perhaps the fact that development now looks pretty similar to development 30 years ago causes people to overlook just how much has changed; it's also true that despite things getting easier, there are still plenty of frustrations in modern development that a programmer from the 80s would recognise.
Demoscene[1] is a good example of this. Back in the day when people wanted to create great looking audiovisual works of art, they had to program them for the computer. There were no movie/3D/CGI editors to do the job with. The whole scene revolved around the technical limitations and beating them. People formed groups which competed against others by creating ever-more stunning effects with more and more content on the screen. Now, new people wonder why do people bother doing the art by programming some obscure old machine? Sure it would be easier to use Sony Vegas for visuals and FL Studio for audio? But hese people miss the point. Some people are not driven to play with these things in order to create art. They are driven by their desire to do creative problem solving. These days the scene has lost it's appeal in public because there's nothing special in stunning graphics on screen. And very few people really care about the fact that some of the works are created within very tight technical constraints[2][3].
All this is gone and "dead" though. Not only demoscene, but the spirit of ceative problem solving within technical constraints. This is the problem I have.
[1]: https://en.wikipedia.org/wiki/Demoscene
Another interesting domain in which creative problem solving rules the game is computer security. But it too is going away once we move away from C and C++ based infrastructure.
This has always happened, it will always continue to happen, but the creativity will move elsewhere. It won't be too long before people are lamenting the loss of computer programming almost entirely, but by then the creative people will have moved on to, say, synthetic biology or some new system that can be 'hacked'.
I find it shocking how so many old-timers fail to see how amazing the web is in terms of being the first de-facto cross-platform cross-media technology, and instead lament the loss of powerful proprietary GUI toolkits. I mean sure portable HTML/CSS/Javascript is incredibly difficult and it's full of warts, but it's pretty minor considering the accessibility of something that can be accessed on any device running any OS, by people with any disability. Yeah, so the win32 API was more elegant for throwing up a toolbar GUI, big fucking whoop; it's like Louis CK's bit about complaining about the Internet on an airplane, total blindness to the accomplishments in front of us.
I like the promise of the web, but many web apps just feel janky compared to their native counterparts, much like Java never felt quite right compared to native apps. But this time, nobody seems to really care, because it runs in the browser.
Plus, re-inventing things in the browser passes for innovation ("ssh client in JS!") around here.
On the other hand, I think there are also real dangers that the article didn’t highlight. The old sayings that “when all you have is a hammer, everything looks like a nail” and that “it’s dangerous to put all your eggs in one basket” are as true as they ever were, and many of these modern, opinionated frameworks and plug-ins are excellent case studies.
Sometimes, using opinionated tools is a strength. If what you want to build fits a framework’s natural usage, you can get up to speed quickly and avoid much of the laborious infrastructure work that otherwise goes with starting a new project. That can be a big win.
However, sometimes it is a weakness. If you want to do something that isn’t quite what the framework does, breaking out of the box can be expensive, maybe even prohibitively so. Moreover, that applies not just when you first start a project, but also as the project grows and evolves, perhaps beyond the scale/scope the original tools were ever intended to support. And even if someone else comes along with a tool that is more suitable, it can be difficult to migrate.
If all you know is how to glue components together, you can take advantage of the strengths, but you’ll struggle to overcome the weaknesses, and worse, you’ll never create new tools that serve you better or let you create something that isn’t merely a recipe made from the ingredients someone else gave you.
I thought it was sad the other day, when MailChimp’s annual report web page[1] was doing the rounds on the web design forums because of some interesting effects used in its presentation, and the first question asked usually wasn’t “How does that work?” but “Does anyone know a plug-in to do that in $FRAMEWORK?” I’m betting that the next attention-grabbing web page using a new and interesting effect will be written by someone who asked the first question.
As we go up in abstractions, we have less ways to overcome the problems we're facing. The development becomes more streamlined and there's less space for coming up with superior solutions to problems during development. Though, I'm mainly talking from performance considerations, something a modern developer doesn't really care about.
That said, I think the biggest "problem" is that new breed of developers/developing culture is fundamentally very different from how things were 10-20 years ago. Back then what many people did was that they coped with the limitations of the system/industry and got employed that way. They got into it because the system/industry was lacking something. For example 20 years ago being able to understand and write assembly was a crucial skill in many places. It was an essential, just like being able to interface with a remote database is essential today. Now that we've got high-level tools and performance, there's no need to care about assembly. People who originally were valued their weigh in gold because of being able to stretch the limits of the system have become obsolete. This same thing will happen more or less to computer security industry too as we move away from unsecure languages like C and C++, although they aren't the only reason behind local/remote exploits.
If simplified frameworks let people make things, that's awesome in my opinion. More of that!
Low level technical stuff has its place too; but the use cases are far far fewer. Its really much more important as a developer that you can produce something and show it to people, than that you have a detailed knowledge of the platform.
I would hesitate to build anything without a technical expert on hand.
The huge explosion in (OSS) frameworks is only a problem because they are IMHO impeding code reuse rather than encouraging it. let me give an example
WSGI is a (python) means of passing http request info up and down a chain of compatible "apps" - basically they pass in same dictionary and call the same functions. Wsgi middleware does everything from authentication to upper asing replies
It's simple effective and hardly ever can you take one wsgi middleware and drop it into another framework because the authors have made assumptions about their framework (database connections etc) that are not supported in the other frameworks - or rather are supported differently.
In short - too many frameworks build their own exentention approaches - making every framework a silo instead of an Eco system
(Yes I am over exaggerating for effect but not a lot)
Nobody blames the “old school developers” for not building their own computers like probably the “very old school developers” did. Computers are taken for granted and are obvious tools of the trade. Well, today frameworks and API are that tools.
As for developers not understanding of how stuff really works - they were always there. There were always people whose skills were limited to installing PHP-Nuke or osCommerce, adding some modules and changing frontend code. Don't confuse them with software developers.
The most frustrating (yes, I've said it, frustrating) issue I've seen is the quick development of applications that is deployed to market (especially in corporate environment). What's not measured very effectively are the non-functional business requirements and when issues arises, it's usually the developers with technical know-hows and understanding of the internals of a system (whether it be OS level, VM level, etc.) that can shed light to an operational issue and optimise the system to meet non-functional requirements).
Frameworks, etc. are mostly designed to solve functional requirements. Those "developers" that tend to rush quickly to frameworks and libraries tend to use them based on functional issues they've experienced during development/integrations, etc. Most develop business requirements and technical specification but excludes non-functional requirements. This tends to become estimations to development lifecycle.
Over time, the "developers" (I call them component integrators) tend to build business systems and leave before the roof gets on fire, and the experts become problem resolvers. See StackOverflow, many reputable developers are those that have extensive experiences with low-level programming and have manifested as being great help. I don't think that I can say the same for component integrators.
Sorry for the long post, but thanks for all the feedback.
When they start questioning the nature of their platform's memory model, and how cache synchronization and inter-processor interrupts interact, you'll feel better. Because that stuff is not going away, and it's _hard_.
Inside every simple problem is a big problem trying to get out. :-)
Just out of curiosity, can you tell me what the mnemonic LDAC means without looking it up?
This suggests to me that the OP is on to something. In the 80s, we had to.
That seems an awfully contrived constraint to inflict on yourself. Even Alan Turing ~1950 recognised the importance of re-usable libraries and spent time documenting how to create routines that could be used my multiple developers.
That's not true. It's not remotely true. It's so untrue. 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.
Let's take a look at the TIOBE index which, whilst very unscientific, would show up something going extinct as you suggest.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Hey look, there's C at the top, and there are C based languages in three of the top four places.
I suggest that you have fallen victim to a lack of perspective; maybe you don't use C and C++, and the people you work with don't (because if they did, you wouldn't be working with them), and you extrapolated that to the whole world. While you're coding in your frameworks and APIs, there is a vast industry you're not aware of using C and C++ that is not going to go away any time soon.
Another interesting benchmark would be:lines of code written each year in each language, anybody knows such benchmark ?
[1]https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY...
It will happen to this new generation too though. New kids come to rule the courts. Just you wait! :)
Why be bitter about frameworks? Yesterday's succesful frameworks (Struts anyone?) are today's shame. And today's succesful frameworks are today's shame (including the ones plagued with countless security issues).
Frameworks and APIs are easy to learn. Learning the basics is hard.
Norvig's idea is that to be an expert in any domain you basically need to spend ten years learning it.
Why spend ten years learning frameworks? They'll be gone by the time you master them (ok, I'm exaggerating a bit).
Focus your time and energy on the invariants: learn the things that still shall be there and shall still be true in ten years.
I honestly have no fear and no bitterness about the ones amongst the youngsters who can only glue together frameworks and APIs without understanding what's going on behind the hood: they'll never be a match for the ones who understand the basics (both older programmers and youngster ones who realize there's much more to programming than being able to do API/framework plumbing).
Never mind that the framework ends up being more useful when you push on it, not the other way around.
It would be progress if the library based approach were a 1-to-1 replacement for the code a DIY programmer would have written, but that's never the case.
The new library solves maybe 95% of the problem, but then you find that the 5% they don't solve is critical to your project. So then you have to rip it out and start again, or bolt your own solution on top, or add yet another library etc etc etc.
Worse that the needed things the libraries don't do are the unneeded things they do. For example, you often find security problems from using third party components which are bigger than needed and so have a relatively huge attack surface.
Finally, you end up in dependency hell, especially if one of the libraries depends on another which depends on another... and especially if there are incompatibilities between different versions of the library. You can end up with multiple versions of a library, and heaven help you if you connect to the wrong one.
In conclusion, if you are a developer on one of these "Lego" projects, you end up responsible for very many features, but with understanding and control of very few. This is a very unfair working environment and means that you will spend the rest of your life debugging rather than developing.