
The future of software developers - alanmhughes
http://theelitegentleman.blogspot.co.uk/2013/01/the-future-of-software-developers.html?m=1
======
dasil003
I sense a hint of bitterness in this article, which is unfortunate because the
central point is very valid: the growth of open-source frameworks requires
today's programmer to be fluent in picking up new libraries and frameworks at
the drop of a hat.

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.

~~~
logn
I don't know about that. I see this as a slam against CRUD-type developers who
can't actually think algorithmically very well. They're good at wiring stuff
together but it stops there.

~~~
chao-
I would like to make two points on behalf of "CRUD-type developers":

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.

------
rjknight
Isn't the OP describing the world as the older generation _wanted_ it to be?
If you had asked some programming luminaries in the early 80s what they
expected from programming 30 years later, they would have said "it will be
more abstract, higher-level, with less direct knowledge of the underlying
hardware required. Software should be write-once run-anywhere and shouldn't
require arcane knowledge of the lower levels of the stack, and this will be a
good thing." Well, guess what, here we are. I'm afraid I can't remember the
source of the quote, but this is analogous to the belief that "the advancement
of a civilization can be measured in the number of things a person can make
happen without needing to understand how".

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.

~~~
dasil003
> _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)_

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.

~~~
mattgreenrocks
I fall into this camp.

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.

~~~
dasil003
Whether people care or not is a moot point though. The fact is that web
standards continue to evolve whereas GUI toolkits can never become truly
cross-platform and installation-free. The web is never best-of-breed, but its
advantages are unassailable.

------
Chris_Newton
I think there’s a valid point here about the changing nature of programming in
a connected world.

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.

[1] <http://mailchimp.com/2012/>

~~~
anonymouz
I did not read the article as a critique of frameworks themselves, but as a
critique of people using frameworks without knowing what's going on beyond
being able to use the framework strictly as a black box.

------
zxcdw
The biggest problem for me personally is the fact that the progress we're
going through kills everything I was ever interested in. There's far less
space for curious tinkering and exploring of the system today and tomorrow
than what there was yesterday.

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.

~~~
thaddeusmt
That's good someone is still interested in low-level tinkering! There will
always be problems than cannot be solved within the limitations of a framework
or SDK. And the more entrenched in this new "high level" "wire-together"
paradigm people like myself are, the more daunting low-level system
exploration is. IMO, this means fewer developers will be willing to try it,
ensuring demand will continue for the work you are interested in.

------
shadowmint
The only thing that matters is outcomes.

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.

~~~
borplk
In a couple of years I can imagine people going, "back in my days we had to
use Ruby on Rails and Django to make websites...you kids have it too easy
these days and don't understand a thing about the lower level stuff.."

~~~
zxcdw
I doubt the point is that "Booho things are too easy for you! :(". The point
is that there's nothing interesting for a "old-school" programmer in the world
we're progressing towards.

------
lifeisstillgood
I am not sure I can articulate this well but ...

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)

------
racbart
Evolve or die. I am the “old school developer” but that didn't stop me from
staying up to date with technologies and trends. DIY developers are good to
some point. You will never build anything large or build efficiently if you
don't understand that not only DRY has value, but DRO as well (Don't Repeat
Others' work).

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.

------
eliteGentleman1
Guys, I didn't write this as a bitter developer but I merely tried to
summarize the trend that I have picked up over the years. I have nothing
against frameworks or libraries at all, it's just the way the evolution of
development have changed.

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.

------
kabdib
Don't worry. As these "put the blocks together" people grow in their careers,
when things go wrong with the blocks they'll have to dive in and figure it
out.

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. :-)

~~~
yxhuvud
If nothing else, combine enough simple problems and you get a hard one.

------
jfaucett
As a young programmer this article makes me angry. Sure maybe a lot of us
young guys build stuff by using components/libraries/frameworks, heck I don't
want to write my own nginx module when one already exists that works well. But
saying we as a group don't understand the internals of what we use based off
the OP's "asking one collegue" is a bunch of bull. I've read the HTTP Spec, in
my free time I read the source and run debuggers on the libraries I use and I
think regardless of age almost all programmers do the same. Why? Because we
like knowing how things work, we like building things, that's why we're
developers. The only difference is that today there's a lot more you can/need
to know as opposed to 30 yrs ago where everything was low level and HTTP
didn't even exist.

~~~
ucee054
_But saying we as a group don't understand the internals of what we use ... is
a bunch of bull_

Just out of curiosity, can you tell me what the mnemonic _LDAC_ means without
looking it up?

~~~
jfaucett
nope, think it probably has something to do with a data register, loading
maybe? If not then no idea, I don't go that low-level, c and some x86 is a low
level as I care to get.

~~~
ucee054
"I don't go that low-level"

This suggests to me that the OP is on to something. In the 80s, _we had to_.

------
ezequiel-garzon
Off-topic, this foreigner begs for mercy and enlightenment. The author uses
the phrase "Are they to be blamed", which makes perfect sense to me. However,
I've come across the bewildering alternative "Are they to blame?" (Typically,
"Am _I_ to blame?") Do you native English speakers (or else) see the reasoning
behind this construct?

------
arethuza
"in my years of as a developer, I always stuck to API delivered from the
programming language SDK"

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.

------
mimog
I remember reading an article years back claiming that companies were
frustrated with the new crop of software developers being schooled in java
during their education rather than C and C++ since they were becoming used to
development being the wiring together of already existing objects and
components, and not really having a feeling of how the computer works. Well,
turns out C and in particular C++ development is going the way of the dodo and
the ability to wire objects and components together in a well designed even
beautiful way is a pretty important skill when it comes to developing large
systems. Of course there are developers out their who are basically the sw
developer equivalent of a script kiddie, but a good modern developer today is
far from that even though he might use a lot of frameworks and apis.

~~~
EliRivers
"Well, turns out C and in particular C++ development is going the way of the
dodo"

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....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

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.

~~~
mimog
In my experience C and C++ development are becoming more and more niche
skills. Sure operating systems are written in those languages but I would call
that a niche. And a small one at that. Then there is the embedded world, of
course embedded systems are written in C or C++ either because of hardware
constraints or real time requirements. Turns out however that even embedded
systems are becoming so powerfull that C is no longer the only contender. Sure
tiobe index claims that C is the king, but if you look at the job market you
will quickly realise that C and C++ are not very sought after skills and are
relatively low paid ones at that. Thats at least the case in my country, and
has been so for many years.

~~~
EliRivers
Fair enough. In my personal experience, C is the big coding skill looked for,
but I mostly work for defence companies and major manufacturers. If you don't
look at job listings for that sort of company, or your country simply doesn't
have those industries in significant size, you'll see something else. I
regularly see skilled embedded coders being poached with ridiculous pay rises
because they're so useful and so hard to get (40 or 50 percent increase in
salary upon being poached/headhunted isn't uncommon for someone a few years
out of university who spent those few years learning how to code for embedded
systems, but that's usually being poached between defence companies and major
appliance makers - Lockheed, Thales, Honeywell, that kind of thing).

------
garagemc2
Without getting to meta, but couldn't the same critique/argument be applied to
this gentlemans approach by a developer from the generation before him. And
the same before that.

~~~
zxcdw
In a sense yes. People into analog electronics cried out loud when digital
electronics started to reign their game. Now, people who were into dealing
with low-level things out of their own interest are crying out loud because
new era of abstractness is taking it's dawn and starting to take over.

It will happen to this new generation too though. New kids come to rule the
courts. Just you wait! :)

------
eurodance
According to this article, if I use Hibernate, I don't understand JDBC fully.
What a ridiculous premise.

------
FollowSteph3
And the generation before could complain similarly that we don't do anything
in assembly today. There's a reason the author wasn't using assembly, same as
there's a reason people use frameworks like Joda.

------
martinced
Frameworks come and go. Languages come and go (albeit at a slower pace). But
the basics do not change.

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).

~~~
SkyMarshal
Indeed, my first manager after college taught me something I still remember -
programming is trendy. The same fundamental concepts keep getting
reimplemented every 5-10 years, hopefully in some new-and-improved way but not
necessarily. It behooves professionals to have some deep grounding in the
fundamental, enduring concepts to be able to evaluate that.

------
ucee054
OK this trend is _NOT_ "progress".

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.

