7 ms·

Umm the more comparable parable would be "or the proverbial graybeard who has done it kidney surgery a thousand times" The stuff you did in software 20 yea

Umm the more comparable parable would be "or the proverbial graybeard who has done ~~it~~ kidney surgery a thousand times" The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it. People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. Security was abysmal - you didn't even have process isolation on OS-es. The languages and the practices are also completely different - disregarding the "we did it in the 60s with LISP in this paper" crowd - outside of academia people were just getting in to the OOP which was the pinnacle of abstractions back then. This is the drag&drop and copy-paste as an abstraction VB shit era. Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.

clockwerx 10y ago
Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc. Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems. If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
- bshimmin 10y ago
  One thing I've found that's significantly changed since I began my career, before my beard went grey, is that projects are now in general run much better. People never make a total mess of estimating timings, and the Agile methodology (and Kanban boards, and Trello, and JIRA, and of course Slack) really fix all organisational and prioritisation problems such that projects never end in disaster; gone are the days of frantic last minute firefighting and all-nighters, as we desperately work out which features are critical to getting the project live before everything explodes. Clearly the experience of older, wiser heads in moments of crisis is now basically never required because projects run so smoothly. Haha, sorry, I'm only kidding.
  - ryandrake 10y ago
    Love it--Thanks for the last line there. I'm glad I didn't have any food in my mouth while reading this because it'd be all over the screen right now.
  - rcurry 10y ago
    This made my day. I only wish I could have read it around 3:00 this morning when I was still up writing code.
emodendroket 10y ago
Most programs don't really use algorithms or data structures that were discovered much later than the '70s. This idea that old experience is worthless because we're using different libraries now strikes me as altogether wrongheaded.
- rubber_duck 10y ago
  The stuff you learned in your CS course is still just as relevant as it was 20 years ago. The things you did in your development career are nowhere near so. Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ? I'm not saying those things are the only relevant things, I'm just pointing out the obvious examples of how much things have changed since then. I've said in another comment, we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today. Even on the low-level end the basic design constraints such as the difference between CPU instruction speed/memory access/cache miss dramatically changed what it means to write optimized code, nobody these days rolls their own SQRT function to squeeze out a few extra CPU cycles, now days it's about making sure your memory is laid out so that you get as few cache misses as possible.
  - emodendroket 10y ago
    I was in high school and didn't know the first thing about programming 20 years ago. But it seems to me that "design patterns," SCM, and automated testing aren't the hard part of this discipline.
    - rubber_duck 10y ago
      Sure they are. They are the "hard part" of what every 9-5 LOB dev has to do, and even in the more CS heavy fields from my experience the algorithms and the fancy CS is 20% of the work and the rest is implementing mundane details, bug fixing, testing, cooperating with team members, etc. And that's the stuff that improved since the 90s. Delivering reliable software is hard - but we've gotten a lot better at it in the last 20 years, if you don't believe me boot up some old windows 95/98 image install some random software and see for yourself.
amcrouch 10y ago
Hmmm ... disagree! 18 years ago we had much of what we had today. Things might move on but they do not change. I mean hey, everyone still hates Visual Basic! At least 18 years ago we were actually writing the majority of our code rather than relying so heavily on libraries and third party code. I mean someone only has to pull a Node.js plugin for padding and there is complete melt down!
optionalparens 10y ago
If the parent is sarcasm, please disregard my reply. > The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before. Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share. I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone. > This is the drag&drop and copy-paste as an abstraction VB shit era. And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful. > People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level. > Security was abysmal - you didn't even have process isolation on OS-es. Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse. > Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics. The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things. Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).
eropple 10y ago
I've been programming in functional languages for twelve years and recognizably modern C++ for fifteen at this point. And yet, I'm not a graybeard; I'm 28. But what I learned at that point still informs what I do today. And it's why I respect that those graybeards' old work still has impact today.
ChoHag 10y ago
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. This is basically false in every way it's possible to be false.
ryandrake 10y ago
> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. The longer I'm in software the more and more I find this not to be true. The stuff that has changed is all surface level. The underlying principles are the same. The skills needed are the same. The attention to detail and other attributes needed to get the job done is the same. The problems are basically recycled or scaled up versions of the problems we had years ago.
- deleted 10y ago
  [deleted]
- Animats 10y ago
  There's new stuff that's a significant advance (machine learning that really works), there's stuff that's just different (like most of the web backend technologies), and there's stuff that's worse (security).
coldtea 10y ago
>The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it. That stuff a competent graybeard knows already. You don't think they disappeared in 1990 and re-appeared magically today, or that they didn't kept up with the times during their career, right? In addition, they would know all the solid stuff -- the things programmers before the internet had to learn the hard way, and lots of today's dilettantes lack. And you must be very young (20 something?) if you really believe that "the stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today". That's simply not true -- and triply not true for 15 years ago.
- rubber_duck 10y ago
  I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career. I started programming in late 90s but not professionally until 2006 I think, this was probably the late phase of transition to internet as a dominant factor in computing - so I think it gave me enough perspective as to how things changed, plus talking to older developers, reading stuff online and on the forums I know we've come a loong way as an industry.
  - coldtea 10y ago
    >I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career. Or you just don't like management / like programming?
    - AnimalMuppet 10y ago
      My last two jobs I got hired for, I said while interviewing that it was my explicit career goal to never become a manager.
collyw 10y ago
I see the opposite, rehashes of old ideas rebranded as the latest new hottness. NoSQL was basically what everyone was doing before relational databases came along. Clojure is a Lisp dialect running on the JVM. ORM's are great until you need some complex query, then it helps to know SQL. Algorithmic complexities are the same whether you were squeezing things into a tiny underpowered computer or if you are dealing with terrabytes of data. Security was abysmal probably because there were nowhere near as many threats. Some things change. None of it goes away.
cunac 10y ago
you would actually be surprised how things are the same. You just can't see it because you didn't experience it and than you are confusing transferable knowledge with tools knowledge. Latter is easy , anybody can learn new language/tool , using a tool properly and efficiently is a problem.
ksenzee 10y ago
I've only been in the industry 13 years, and I'm not using a single tool today that I used back then, but I'm still using the lessons I learned: How much time should my team spend on testing vs. code review vs. building new features? How risky is this feature, and how much QA does it need? Which of the brand-new engineers on my team needs a careful eye on their code so they don't blow everything up? When is it time to say screw it, we have to ship? Which new hip framework is likely to have staying power, because of the people and the commitment behind it? How do I convince open-source maintainer X to accept my new feature, so I'm not maintaining patches into eternity? Those are the important questions I deal with every day. I couldn't answer them as well 10 years ago, and I bet I can answer them better 10 years from now.
tjl 10y ago
Back in 1996 I was using CVS at work. Before that it was RCS or SCCS (RCS was the first version control system I used). This was at Bell-Northern Research and Nortel, which was not a bastion of cutting edge techniques. ClearCase was pretty commonly used as well (it came out in 1992). Automated testing wasn't science fiction. It was regularly done, just as system or integration tests. You'd see who did the commit that broke the build. This was before QA even got to do their work. This was something done across the company and I'm certain that it wasn't the only company that did this.

Umm the more comparable parable would be "or the proverbial graybeard who has done ~~it~~ kidney surgery a thousand times" The stuff you did in software 20 yea

clockwerx 10y ago

Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc. Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems. If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees

bshimmin 10y ago
One thing I've found that's significantly changed since I began my career, before my beard went grey, is that projects are now in general run much better. People never make a total mess of estimating timings, and the Agile methodology (and Kanban boards, and Trello, and JIRA, and of course Slack) really fix all organisational and prioritisation problems such that projects never end in disaster; gone are the days of frantic last minute firefighting and all-nighters, as we desperately work out which features are critical to getting the project live before everything explodes. Clearly the experience of older, wiser heads in moments of crisis is now basically never required because projects run so smoothly. Haha, sorry, I'm only kidding.
- ryandrake 10y ago
  Love it--Thanks for the last line there. I'm glad I didn't have any food in my mouth while reading this because it'd be all over the screen right now.
- rcurry 10y ago
  This made my day. I only wish I could have read it around 3:00 this morning when I was still up writing code.

emodendroket 10y ago

Most programs don't really use algorithms or data structures that were discovered much later than the '70s. This idea that old experience is worthless because we're using different libraries now strikes me as altogether wrongheaded.

rubber_duck 10y ago
The stuff you learned in your CS course is still just as relevant as it was 20 years ago. The things you did in your development career are nowhere near so. Did you use SCM, automated testing and design patterns 20 years ago ? If yes do you think this was the norm in the industry ? I'm not saying those things are the only relevant things, I'm just pointing out the obvious examples of how much things have changed since then. I've said in another comment, we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today. Even on the low-level end the basic design constraints such as the difference between CPU instruction speed/memory access/cache miss dramatically changed what it means to write optimized code, nobody these days rolls their own SQRT function to squeeze out a few extra CPU cycles, now days it's about making sure your memory is laid out so that you get as few cache misses as possible.
- emodendroket 10y ago
  I was in high school and didn't know the first thing about programming 20 years ago. But it seems to me that "design patterns," SCM, and automated testing aren't the hard part of this discipline.
  - rubber_duck 10y ago
    Sure they are. They are the "hard part" of what every 9-5 LOB dev has to do, and even in the more CS heavy fields from my experience the algorithms and the fancy CS is 20% of the work and the rest is implementing mundane details, bug fixing, testing, cooperating with team members, etc. And that's the stuff that improved since the 90s. Delivering reliable software is hard - but we've gotten a lot better at it in the last 20 years, if you don't believe me boot up some old windows 95/98 image install some random software and see for yourself.

amcrouch 10y ago

Hmmm ... disagree! 18 years ago we had much of what we had today. Things might move on but they do not change. I mean hey, everyone still hates Visual Basic! At least 18 years ago we were actually writing the majority of our code rather than relying so heavily on libraries and third party code. I mean someone only has to pull a Node.js plugin for padding and there is complete melt down!

optionalparens 10y ago

If the parent is sarcasm, please disregard my reply. > The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before. Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share. I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone. > This is the drag&drop and copy-paste as an abstraction VB shit era. And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful. > People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level. > Security was abysmal - you didn't even have process isolation on OS-es. Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse. > Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics. The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things. Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).

eropple 10y ago

I've been programming in functional languages for twelve years and recognizably modern C++ for fifteen at this point. And yet, I'm not a graybeard; I'm 28. But what I learned at that point still informs what I do today. And it's why I respect that those graybeards' old work still has impact today.

ChoHag 10y ago

> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. This is basically false in every way it's possible to be false.

ryandrake 10y ago

> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. The longer I'm in software the more and more I find this not to be true. The stuff that has changed is all surface level. The underlying principles are the same. The skills needed are the same. The attention to detail and other attributes needed to get the job done is the same. The problems are basically recycled or scaled up versions of the problems we had years ago.

deleted 10y ago
[deleted]
Animats 10y ago
There's new stuff that's a significant advance (machine learning that really works), there's stuff that's just different (like most of the web backend technologies), and there's stuff that's worse (security).

coldtea 10y ago

>The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it. That stuff a competent graybeard knows already. You don't think they disappeared in 1990 and re-appeared magically today, or that they didn't kept up with the times during their career, right? In addition, they would know all the solid stuff -- the things programmers before the internet had to learn the hard way, and lots of today's dilettantes lack. And you must be very young (20 something?) if you really believe that "the stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today". That's simply not true -- and triply not true for 15 years ago.

rubber_duck 10y ago
I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career. I started programming in late 90s but not professionally until 2006 I think, this was probably the late phase of transition to internet as a dominant factor in computing - so I think it gave me enough perspective as to how things changed, plus talking to older developers, reading stuff online and on the forums I know we've come a loong way as an industry.
- coldtea 10y ago
  >I mean if you were a good dev in the 90s chances are right now you're in some senior architect/management/consultant position. If you're competing for the same jobs as 20 something devs then you've probably screwed up somewhere in your career. Or you just don't like management / like programming?
  - AnimalMuppet 10y ago
    My last two jobs I got hired for, I said while interviewing that it was my explicit career goal to never become a manager.

collyw 10y ago

I see the opposite, rehashes of old ideas rebranded as the latest new hottness. NoSQL was basically what everyone was doing before relational databases came along. Clojure is a Lisp dialect running on the JVM. ORM's are great until you need some complex query, then it helps to know SQL. Algorithmic complexities are the same whether you were squeezing things into a tiny underpowered computer or if you are dealing with terrabytes of data. Security was abysmal probably because there were nowhere near as many threats. Some things change. None of it goes away.

cunac 10y ago

you would actually be surprised how things are the same. You just can't see it because you didn't experience it and than you are confusing transferable knowledge with tools knowledge. Latter is easy , anybody can learn new language/tool , using a tool properly and efficiently is a problem.

ksenzee 10y ago

I've only been in the industry 13 years, and I'm not using a single tool today that I used back then, but I'm still using the lessons I learned: How much time should my team spend on testing vs. code review vs. building new features? How risky is this feature, and how much QA does it need? Which of the brand-new engineers on my team needs a careful eye on their code so they don't blow everything up? When is it time to say screw it, we have to ship? Which new hip framework is likely to have staying power, because of the people and the commitment behind it? How do I convince open-source maintainer X to accept my new feature, so I'm not maintaining patches into eternity? Those are the important questions I deal with every day. I couldn't answer them as well 10 years ago, and I bet I can answer them better 10 years from now.

tjl 10y ago

Back in 1996 I was using CVS at work. Before that it was RCS or SCCS (RCS was the first version control system I used). This was at Bell-Northern Research and Nortel, which was not a bastion of cutting edge techniques. ClearCase was pretty commonly used as well (it came out in 1992). Automated testing wasn't science fiction. It was regularly done, just as system or integration tests. You'd see who did the commit that broke the build. This was before QA even got to do their work. This was something done across the company and I'm certain that it wasn't the only company that did this.