10 ms·

The future of software developers

45 points by alanmhughes 14y ago

deleted 14y ago
[deleted]
racbart 14y 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 14y 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/ http://mailchimp.com/2012/
- anonymouz 14y 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.
mimog 14y 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.
- EliRivers 14y 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.html 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 14y 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-of-Programming-Language https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY...
dasil003 14y 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 14y 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 ;)
shadowmint 14y 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 14y 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 14y 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.."
  - zxcdw 14y 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 14y 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.
- zxcdw 14y 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! :)
rjknight 14y 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.
- zxcdw 14y 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 https://en.wikipedia.org/wiki/Demoscene [2]: https://www.youtube.com/watch?v=AWcbj7ksqwE https://www.youtube.com/watch?v=AWcbj7ksqwE [3]: https://www.youtube.com/watch?v=4DjBq2O0XXk https://www.youtube.com/watch?v=4DjBq2O0XXk
zxcdw 14y 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 14y 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.
jfaucett 14y 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.
- ucee054 14y 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?
  - jfaucett 14y 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.
    - ucee054 14y ago
      "I don't go that low-level" This suggests to me that the OP is on to something. In the 80s, we had to.
kabdib 14y 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 14y ago
  If nothing else, combine enough simple problems and you get a hard one.
arethuza 14y 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.
lifeisstillgood 14y 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 14y ago
According to this article, if I use Hibernate, I don't understand JDBC fully. What a ridiculous premise.
ezequiel-garzon 14y 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 14y 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 14y 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).
- mattgreenrocks 14y 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 14y 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.
ucee054 14y 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 14y 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.

45 points by alanmhughes 14y ago

deleted 14y ago

[deleted]

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 14y 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/ http://mailchimp.com/2012/

anonymouz 14y 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.

mimog 14y 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.

EliRivers 14y 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.html 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 14y 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-of-Programming-Language https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY...

dasil003 14y 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 14y 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 ;)

shadowmint 14y 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 14y 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 14y 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.."
- zxcdw 14y 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 14y 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.

zxcdw 14y 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! :)

rjknight 14y 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.

zxcdw 14y 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 https://en.wikipedia.org/wiki/Demoscene [2]: https://www.youtube.com/watch?v=AWcbj7ksqwE https://www.youtube.com/watch?v=AWcbj7ksqwE [3]: https://www.youtube.com/watch?v=4DjBq2O0XXk https://www.youtube.com/watch?v=4DjBq2O0XXk

zxcdw 14y 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 14y 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.

jfaucett 14y 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.

ucee054 14y 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?
- jfaucett 14y 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.
  - ucee054 14y ago
    "I don't go that low-level" This suggests to me that the OP is on to something. In the 80s, we had to.

kabdib 14y 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 14y ago
If nothing else, combine enough simple problems and you get a hard one.

arethuza 14y 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.

lifeisstillgood 14y 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 14y ago

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

ezequiel-garzon 14y 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 14y 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 14y 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).

mattgreenrocks 14y 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 14y 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.

ucee054 14y 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 14y 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.