The future of software developers

http://theelitegentleman.blogspot.co.uk/2013/01/the-future-of-software-developers.html?m=1

by alanmhughes • 14 years ago

45 49 14 years ago

theelitegentleman.blogspot.co.uk

racbart• 14 years ago

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.

Chris_Newton• 14 years ago

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• 14 years ago

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.

mimog2• 14 years ago

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.

EliRivers2• 14 years ago

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

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.

ippisl• 14 years ago

Another language popularity survey[1] puts c in the fifth place. It uses data on people who searched tutorials on a certain language, so this result do seem interesting.

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

mimog2• 14 years ago

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.

freework• 14 years ago

H didn't imply that its dead, he was implying that its dying. Slowly. In my opinion, 30 years from now C will no longer be in the top 10. It'll still be around though, because there will still be uses for it. Just not as many uses as before.

dasil0035• 14 years ago

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.

blablabla123• 14 years ago

>I sense a hint of bitterness in this article

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

dasil0035• 14 years ago

I'm almost 35 so I'm definitely somewhere in the middle. I'm not at all scared of being sidelined by young guys because I do not define myself by current skillset (currently a web developer doing mostly Ruby/Javascript in various forms). What experience has taught me is that being able to program well is an incredibly valuable skill if and only if it is applied to the right problems at the right time. So while some of my skills over time have had an extremely short half-life (Netscape/IE 4 CSS), and some has had an intermediate half-life (HTTP/SSL/web servers) and some promise dividends for years to come (bash, vim, linux sysadministration), the ability to leverage and apply technology to real business problems is something that will always be valuable. It doesn't matter how many genius kids drop out of the ivy league, they have to earn their experience in how to succeed in the business world. Of course, if I am always looking for a job I am subject to ageism, but that is why increasingly I look to put myself in founder/consultant roles rather than simply coder for hire.

logn• 14 years ago

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-• 14 years ago

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.

andybak• 14 years ago

I'd rather most 'CRUD' developers spent their time getting better at UX and solving user problems than they spent it learning algorithms.

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.

jakejake• 14 years ago

As a CRUD developer myself (who actually has written frameworks in multiple languages I might add) I find your tone somewhat elitist.

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.

shadowmint• 14 years ago

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.

meaty• 14 years ago

That only works until something goes wrong, which it does regularly because the overall quality of the components that are usually used is mediocre.

I would hesitate to build anything without a technical expert on hand.

borplk• 14 years ago

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

zxcdw5• 14 years ago

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.

garagemc2• 14 years ago

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.

zxcdw5• 14 years ago

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

rjknight2• 14 years ago

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.

zxcdw5• 14 years ago

While I think it is great that we can now do things with ease without having to worry about all the details, I also think it limits us when doing things. This is not a problem in entreprise/commercial software development because it gives more control for the manages over the developers and the development process, thus reducing complexity of the process. However, this is a problem for us who are driven by curiosity and the joy of creative problem solving.

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

[2] https://www.youtube.com/watch?v=AWcbj7ksqwE

[3] https://www.youtube.com/watch?v=4DjBq2O0XXk

dasil0035• 14 years ago

People are still pushing the boundaries in every direction, it's just not as easy to see in one place, and not as amazing because we are desensitized to it. I mean we'll never be amazed again the way we were by Doom when it first came out, but don't tell John Carmack he's not trying to squeeze out every ounce of performance from today's hardware.

dasil0035• 14 years ago

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

mattgreenrocks2• 14 years ago

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.

zxcdw5• 14 years ago

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• 14 years ago

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.

jfaucett2• 14 years ago

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.

ucee0543• 14 years ago

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?

jfaucett2• 14 years ago

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.

kabdib• 14 years ago

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• 14 years ago

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

arethuza• 14 years ago

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

lifeisstillgood2• 14 years ago

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)

eurodance• 14 years ago

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

ezequiel-garzon• 14 years ago

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?

FollowSteph3• 14 years ago

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• 14 years ago

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

mattgreenrocks2• 14 years ago

There's a pop engineering mindset that surrounds framework hype, often parading under the label of YAGNI. It wears the banner of "write your application completely within this nice container, and we'll do everything for you!"

Never mind that the framework ends up being more useful when you push on it, not the other way around.

SkyMarshal• 14 years ago

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.

ucee0543• 14 years ago

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.

eliteGentleman1• 14 years ago

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.

The future of software developers

Related Stories