<p>Educators have to agree that's we're teaching skills, not technology.  Reaching that agreement is harder than you might think.  It's especially hard in the web-development area.  (Disclaimer: that's distant from my area.)  What are the key questions or skills that have lasting value?  Here are some speculations:</p>

<ul>
<li><p>What does it mean to split a computation between database, server, and client-side browser?</p></li>
<li><p>How do you manage the cost tradeoff between fast loading (which means don't bloat your web pages with scripts and frameworks) versus rich interaction within the browser (which requires some sort of scripting)?</p></li>
<li><p>In five years, new languages/tools/frameworks will be fashionable.  What are the skills needed to work with a large API, continually changing, and too complex to master?  (Good luck with that one.)</p></li>
</ul>

<p>In my own area, programming languages, I don't have to speculate.  I know that the important things are functions, types, and objects (maybe also modules).  I am confident that in thirty years, these things will still be important.  And I can teach these things without using the latest technologies: Scheme, ML, and Smalltalk were all known and usable in 1980.  The newest "technology" I teach is actually the math (syntactic methods of semantics popularized around 1995).</p>

<p>What you don't see here are the traps avoided.  I don't have to worry about teaching currently fashionable languages like Swift, Rust, or Go.  I don't have to worry about whether I am teaching the "right" version of Python.  To avoid this trap, I had to do an enormous amount of intellectual work.  Such work may not be rewarded, as universities tend to focus their rewards on research.</p>

<p>A final trap for educators: in the US at least, courses focused on timeless skills are much less popular than courses focused on currently fashionable technology.  Many students are short-term optimizers, and they want something they believe they can use.</p>

CC BY-SA 3.0
2017-07-03T09:11:46.743Z
It does depend at what level you're teaching. A good proportion of the workforce (even in developed countries) are applying technology (they call them trades) in a static framework. Even in technical subjects, this is true - do you want your lab tech. running consistent and repeatable tests, or do you want them making tweaks to the machine calibration every weekend?
Sean Houlihane
CC BY-SA 3.0
2017-07-02T15:43:17.813Z
2017-07-02T15:43:17.813Z
Norman Ramsey
<p>Basically, you can't, unless you have some teaching staff who are actively involved in industry. </p>

<p>Anybody who has spent say 10 years working their way through the academic system from undergraduate to lecturer is at least <strong>20</strong> years out of date, and probably more like 30 years: 10 for their time isolated from the "real world" in academia, plus another 10 or 20 because what they were taught as an undergrad was out of date when they were taught it!</p>

<p>(This may also explain why so much terrible code, and so many terrible textbooks, are written in academia - but that's a different issue!)</p>

<p>I suspect this problem is basically incurable. As a working programmer, I have lost count of the number of languages I've learned (and mostly forgotten again!) over the decades, but it's about one every 18 months on average. I don't see any way that a teaching organization could handle that pace of continuous change. </p>

<p>Another significant difference between industry and academia is that the people constantly learning "new stuff" in industry aren't learning it because they want to say up to date with the latest research. They are learning it because <em>they need to use it</em>. For all I know, the <em>next</em> language I need to learn might be COBOL, to understand some legacy system! In the past I've had to learn enough ALGOL 68 to understand some algorithms in an old published paper, at least 30 years after the language was effectively dead and buried! </p>

CC BY-SA 3.0
2017-07-01T19:48:36.183Z
Nonsense. Teachers are not idiots. You don't need to be actively involved to keep up with an evolving topic.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-07-01T21:55:12.533Z
I think you're over-generalizing -- while I don't doubt that some schools are out-of-date, it seems a stretch to claim they're all that way. It might even be the other way around sometimes: if teachers are doing cutting-edge research on various topics (databases, 3d printing, data visualization, machine learning...), it's entirely possible they'd be more prepared to predict and teach future trends vs teachers from industry. For example, functional programming used to be purely academic but is practically mainstream now; FRP is starting to become influential (see react & related frameworks)...
Michael0x2a
CC BY-SA 3.0
2017-07-02T17:16:53.913Z
Most teaching organisations (in the UK, I don't know about anywhere else) are forced to operate within the pace of continuous change. There's no reason why some academics, teachers or even students can't be at least as up to date (if not more so) than some working in industry.
pddring
CC BY-SA 3.0
2017-07-01T19:32:44.357Z
2017-07-01T19:44:29.363Z
2017-07-01T19:44:29.363Z
alephzero
<p>I think about this question a lot. I agree that, if faculty are teaching things close to their research area, then courses should be naturally updated. The issue is: what do you do if your department has no one in a certain research area, but still wants to offer courses in that area? A similar problem comes up in Buffy's answer: who is going to teach the "Bleeding Edge computing" course?</p>

<p>You can ask some poor junior professor to try and develop a course on new things where no one has expertise, but it's a huge amount of work for that person, and doesn't solve the problem of the course becoming outdated as that field develops. I say "junior professor" because a senior professor seems less likely to do course development like this, because they have families, they have administrative responsibilities, etc.</p>

<p>The person who develops the new course can, of course, go to lots of conferences and maybe even give up part of their sabbatical to learn more about the topic (e.g. by working at Google). But that just makes the burden on this person even greater. I think this problem can only be solved with help from the administration. Specifically, I think CS faculty should have a lower teaching load than faculty in other parts of campus, to make these kinds of curricular renewal a real part of their job. Otherwise, it's too tempting to just develop the course once and teach it the same way forever (as folks in many other departments seem to do).</p>

CC BY-SA 3.0
2017-07-09T12:43:14.873Z
I think different loads between departments is not feasible (both for real and political reasons), but a department _can_ give new faculty a lighter load so that they can get established both with research and teaching. We senior faculty can take up the slack, but it takes a very cooperative environment to achieve. Some places have done this. I think Dartmouth is (or was, at least) pretty good about this.
Buffy
CC BY-SA 3.0
2017-07-09T13:18:00.453Z
Denison has a lower load for faculty in CS. I think that Richmond and Davidson do too. At one point I made a list of liberal arts colleges that did. One way to sell it is to give credit for "labs", since it's very common for faculty in, say, biology to get teaching credit for their labs. Plus, keeping a course up to date with modern advances will often happen in the lab part of the class!
David White
CC BY-SA 3.0
2017-07-09T06:50:05.380Z
2017-07-09T06:50:05.380Z
David White
<p>One way is to have an industry advisory committee consisting of alumni or friends of your institution. (I was on such a committee for a community college when I worked in industry.) Once a year, the committee meets with faculty to learn about the current curriculum and suggest changes based on their active professional knowledge of the field.</p>

<p>Another way is for faculty members to spend sabbatical years in industry. I learned more about software engineering from a year at Google than from my entire formal education.</p>

CC BY-SA 3.0
2017-07-03T12:35:43.800Z
@nocomprende Do you and your colleagues find their input helpful?
Ellen Spertus
CC BY-SA 3.0
2017-07-02T17:43:34.643Z
2017-07-02T17:43:34.643Z
Ellen Spertus
<p>I see you are in the UK. I think the constraints are different in different places and at different levels. But most of the examples you give are of the ephemera of computing - current languages, frameworks. That may be a misplaced focus. There are other topics, more fundamental, that increase in value over time: encryption, quantum computing, Big Data, Massively Parallel computing, etc. </p>

<p>You need to teach within some current framework, of course, but also to think about how you are preparing your students for taking a wider view. I used Java/Eclipse for a long time, but realize that it wasn't a "forever" solution. I don't think I really did enough preparing for the day when Eclipse won't be available (or desirable), however. </p>

<p>But one concrete thing you may be able to do, subject to constraints, is to have one "Over the Horizon" course, named that, perhaps, or "Bleeding Edge Computing" maybe. It covers the latest and greatest even if you know that the topics may not have the legs to last. A more boring name, but probably a good focus, is "Current Trends in Computing." Students are warned in such a class that this may seem "cool" today, but "cold" tomorrow. </p>

<p>A second thing, not quite the same, is to rotate a series of courses on the rising but likely important things, as listed above, that you can't justify putting into the curriculum as a continuing course. Big Data one term, Quantum Computing the next, etc. </p>

<p>The second solution is much more work, of course, since the course development is harder and maybe won't be amortized over several years. </p>

<p>A third choice is just to let one Prof (in rotation) teach whatever he/she think is the most interesting thing they know and work on. "Professor Williams' Current Research" or something. </p>

<p>As for yourself, go to a lot of conferences (constraints again). Visit the real world when/where possible to see what goes on in the trenches. See what is going on now. Experiment a bit as time permits. </p>

CC BY-SA 3.0
2017-07-01T16:55:59.137Z
2017-07-01T16:55:59.137Z
Buffy
<p>As a wise man once said, <em>"We are preparing students to solve problems that don't exist / using technologies that haven't been invented."</em></p>

<p>I agree with alephzero in the sense that you can't avoid this issue.  Every sign is that technologies will keep changing rapidly, at least for the foreseeable future.</p>

<p>This is why we must always keep our instruction oriented towards concepts, not languages.  The syntaxes for arrays and lists will differ in different languages, but the trade-offs between the two remain the same.</p>

<p>One easy way to keep the emphasis on the conceptual is to utilize more than one language.  Over the first 3 years of our major, all students work in Python, Java, C, 6502 Assembly, and Scheme.  Additional languages are used for electives, depending on the nature of the course content.  By providing a more varied exposure, students can easily come to differentiate the underlying concepts from the syntaxes of the languages they are learning.</p>

CC BY-SA 3.0
2017-07-01T19:47:01.493Z
2017-07-01T19:47:01.493Z
Ben I.
<p>I'm sure we can agree that there are some parts of theoretical CS that are unlikely to change - topics such as computation theory (Turing machines, automata) will be useful and applicable for many years to come, [or at least until quantum computing becomes hugely pervasive]! I think a strong theoretical base is extremely important and I greatly enjoyed the modules I took at university which covered this sort of theory.</p>

<p>Most courses do include a practical aspect, though. One of my frustrations as a student who started at university with experince in professional software engineering in industry, was that a lot of the more practical content was incredibly outdated, not in line with industry best practices or just downright irrelevant.</p>

<p>As a concrete example, I took a web development module in 2015 which focussed on PHP 4, taught us to write code riddled with XSS, CSRF and SQLi vulnerabilities and didn't place any emphasis on architecture design. Some parts of the course were useful (such as the primer on how HTTP works at a protocol level) but it was obvious the same slide deck had been reused year after year and I came away feeling like I'd wasted my time. Some of these details seem to be out of the lecturer's hands and determined by the department, but the end result is still the same. I do realise web is perhaps one of the worst areas for this, but it's equally applicable when e.g. introducing Java and not covering the "new" generics support, or the more functional features in Java 8. </p>

<p>What can educators do to try and prevent this from becoming too big an issue? I think trying to keep up with each new shiny JavaScript framework that becomes momentarily popular is unrealistic and useful for neither student nor educator - but there must be some middle ground. Should these sort of modules be entirely theoretical to avoid this problem, or perhaps collaboration with industry could be sought out to explain how things really work in practice?</p>

CC BY-SA 3.0
2017-07-01T19:34:07.383Z
This reminds me of my college days, learning PASCAL. Or my years of programming in BASIC. :P
Ben I.
CC BY-SA 3.0
2017-07-03T04:25:15.740Z
Don't teach them the language, framework, or shiny new gizmo. Also don't teach them any development model or workflow process. Rather, teach them to explore and learn the language, framework, or other tool. If they can learn how to learn, their skills will never be _out of date_ even when AI and quantum computing blend to produce SkyNet. The last time I learned a new language it took me 5 days to be "job ready" including passing the hiring exam with the best code they'd seen. Teach skills, not facts.
Gypsy Spellweaver
<curriculum-design><undergraduate>
How should educators ensure their curriculum remains relevant over time?
# How should educators ensure their curriculum remains relevant over time?

(Asked by: username_0 on 2017-07-01)

I'm sure we can agree that there are some parts of theoretical CS that are unlikely to change - topics such as computation theory (Turing machines, automata) will be useful and applicable for many years to come, [or at least until quantum computing becomes hugely pervasive]! I think a strong theoretical base is extremely important and I greatly enjoyed the modules I took at university which covered this sort of theory.

Most courses do include a practical aspect, though. One of my frustrations as a student who started at university with experince in professional software engineering in industry, was that a lot of the more practical content was incredibly outdated, not in line with industry best practices or just downright irrelevant.

As a concrete example, I took a web development module in 2015 which focussed on PHP 4, taught us to write code riddled with XSS, CSRF and SQLi vulnerabilities and didn't place any emphasis on architecture design. Some parts of the course were useful (such as the primer on how HTTP works at a protocol level) but it was obvious the same slide deck had been reused year after year and I came away feeling like I'd wasted my time. Some of these details seem to be out of the lecturer's hands and determined by the department, but the end result is still the same. I do realise web is perhaps one of the worst areas for this, but it's equally applicable when e.g. introducing Java and not covering the "new" generics support, or the more functional features in Java 8.

What can educators do to try and prevent this from becoming too big an issue? I think trying to keep up with each new shiny JavaScript framework that becomes momentarily popular is unrealistic and useful for neither student nor educator - but there must be some middle ground. Should these sort of modules be entirely theoretical to avoid this problem, or perhaps collaboration with industry could be sought out to explain how things really work in practice?

**Tags:** curriculum-design, undergraduate

> **Comments:**
> **username_1**: This reminds me of my college days, learning PASCAL. Or my years of programming in BASIC. :P  
> **username_2**: Don't teach them the language, framework, or shiny new gizmo. Also don't teach them any development model or workflow process. Rather, teach them to explore and learn the language, framework, or other tool. If they can learn how to learn, their skills will never be _out of date_ even when AI and quantum computing blend to produce SkyNet. The last time I learned a new language it took me 5 days to be "job ready" including passing the hiring exam with the best code they'd seen. Teach skills, not facts.  

---

## 6 answers

### Answer by username_10 on 2017-07-01. Score: 8 | Accepted answer

I see you are in the UK. I think the constraints are different in different places and at different levels. But most of the examples you give are of the ephemera of computing - current languages, frameworks. That may be a misplaced focus. There are other topics, more fundamental, that increase in value over time: encryption, quantum computing, Big Data, Massively Parallel computing, etc.

You need to teach within some current framework, of course, but also to think about how you are preparing your students for taking a wider view. I used Java/Eclipse for a long time, but realize that it wasn't a "forever" solution. I don't think I really did enough preparing for the day when Eclipse won't be available (or desirable), however.

But one concrete thing you may be able to do, subject to constraints, is to have one "Over the Horizon" course, named that, perhaps, or "Bleeding Edge Computing" maybe. It covers the latest and greatest even if you know that the topics may not have the legs to last. A more boring name, but probably a good focus, is "Current Trends in Computing." Students are warned in such a class that this may seem "cool" today, but "cold" tomorrow.

A second thing, not quite the same, is to rotate a series of courses on the rising but likely important things, as listed above, that you can't justify putting into the curriculum as a continuing course. Big Data one term, Quantum Computing the next, etc.

The second solution is much more work, of course, since the course development is harder and maybe won't be amortized over several years.

A third choice is just to let one Prof (in rotation) teach whatever he/she think is the most interesting thing they know and work on. "Professor Williams' Current Research" or something.

As for yourself, go to a lot of conferences (constraints again). Visit the real world when/where possible to see what goes on in the trenches. See what is going on now. Experiment a bit as time permits.


---

### Answer by username_1 on 2017-07-01. Score: 9

As a wise man once said, *"We are preparing students to solve problems that don't exist / using technologies that haven't been invented."*

I agree with username_5 in the sense that you can't avoid this issue. Every sign is that technologies will keep changing rapidly, at least for the foreseeable future.

This is why we must always keep our instruction oriented towards concepts, not languages. The syntaxes for arrays and lists will differ in different languages, but the trade-offs between the two remain the same.

One easy way to keep the emphasis on the conceptual is to utilize more than one language. Over the first 3 years of our major, all students work in Python, Java, C, 6502 Assembly, and Scheme. Additional languages are used for electives, depending on the nature of the course content. By providing a more varied exposure, students can easily come to differentiate the underlying concepts from the syntaxes of the languages they are learning.


---

### Answer by username_3 on 2017-07-02. Score: 6

Educators have to agree that's we're teaching skills, not technology. Reaching that agreement is harder than you might think. It's especially hard in the web-development area. (Disclaimer: that's distant from my area.) What are the key questions or skills that have lasting value? Here are some speculations:

* What does it mean to split a computation between database, server, and client-side browser?
* How do you manage the cost tradeoff between fast loading (which means don't bloat your web pages with scripts and frameworks) versus rich interaction within the browser (which requires some sort of scripting)?
* In five years, new languages/tools/frameworks will be fashionable. What are the skills needed to work with a large API, continually changing, and too complex to master? (Good luck with that one.)

In my own area, programming languages, I don't have to speculate. I know that the important things are functions, types, and objects (maybe also modules). I am confident that in thirty years, these things will still be important. And I can teach these things without using the latest technologies: Scheme, ML, and Smalltalk were all known and usable in 1980. The newest "technology" I teach is actually the math (syntactic methods of semantics popularized around 1995).

What you don't see here are the traps avoided. I don't have to worry about teaching currently fashionable languages like Swift, Rust, or Go. I don't have to worry about whether I am teaching the "right" version of Python. To avoid this trap, I had to do an enormous amount of intellectual work. Such work may not be rewarded, as universities tend to focus their rewards on research.

A final trap for educators: in the US at least, courses focused on timeless skills are much less popular than courses focused on currently fashionable technology. Many students are short-term optimizers, and they want something they believe they can use.

> **Comments:**
> **username_4**: It does depend at what level you're teaching. A good proportion of the workforce (even in developed countries) are applying technology (they call them trades) in a static framework. Even in technical subjects, this is true - do you want your lab tech. running consistent and repeatable tests, or do you want them making tweaks to the machine calibration every weekend?  

---

### Answer by username_9 on 2017-07-09. Score: 4

I think about this question a lot. I agree that, if faculty are teaching things close to their research area, then courses should be naturally updated. The issue is: what do you do if your department has no one in a certain research area, but still wants to offer courses in that area? A similar problem comes up in username_10's answer: who is going to teach the "Bleeding Edge computing" course?

You can ask some poor junior professor to try and develop a course on new things where no one has expertise, but it's a huge amount of work for that person, and doesn't solve the problem of the course becoming outdated as that field develops. I say "junior professor" because a senior professor seems less likely to do course development like this, because they have families, they have administrative responsibilities, etc.

The person who develops the new course can, of course, go to lots of conferences and maybe even give up part of their sabbatical to learn more about the topic (e.g. by working at Google). But that just makes the burden on this person even greater. I think this problem can only be solved with help from the administration. Specifically, I think CS faculty should have a lower teaching load than faculty in other parts of campus, to make these kinds of curricular renewal a real part of their job. Otherwise, it's too tempting to just develop the course once and teach it the same way forever (as folks in many other departments seem to do).

> **Comments:**
> **username_10**: I think different loads between departments is not feasible (both for real and political reasons), but a department _can_ give new faculty a lighter load so that they can get established both with research and teaching. We senior faculty can take up the slack, but it takes a very cooperative environment to achieve. Some places have done this. I think Dartmouth is (or was, at least) pretty good about this.  
> **username_9**: Denison has a lower load for faculty in CS. I think that Richmond and Davidson do too. At one point I made a list of liberal arts colleges that did. One way to sell it is to give credit for "labs", since it's very common for faculty in, say, biology to get teaching credit for their labs. Plus, keeping a course up to date with modern advances will often happen in the lab part of the class!  

---

### Answer by username_5 on 2017-07-01. Score: 3

Basically, you can't, unless you have some teaching staff who are actively involved in industry.

Anybody who has spent say 10 years working their way through the academic system from undergraduate to lecturer is at least **20** years out of date, and probably more like 30 years: 10 for their time isolated from the "real world" in academia, plus another 10 or 20 because what they were taught as an undergrad was out of date when they were taught it!

(This may also explain why so much terrible code, and so many terrible textbooks, are written in academia - but that's a different issue!)

I suspect this problem is basically incurable. As a working programmer, I have lost count of the number of languages I've learned (and mostly forgotten again!) over the decades, but it's about one every 18 months on average. I don't see any way that a teaching organization could handle that pace of continuous change.

Another significant difference between industry and academia is that the people constantly learning "new stuff" in industry aren't learning it because they want to say up to date with the latest research. They are learning it because *they need to use it*. For all I know, the *next* language I need to learn might be COBOL, to understand some legacy system! In the past I've had to learn enough ALGOL 68 to understand some algorithms in an old published paper, at least 30 years after the language was effectively dead and buried!

> **Comments:**
> **username_6**: Nonsense. Teachers are not idiots. You don't need to be actively involved to keep up with an evolving topic.  
> **username_7**: I think you're over-generalizing -- while I don't doubt that some schools are out-of-date, it seems a stretch to claim they're all that way. It might even be the other way around sometimes: if teachers are doing cutting-edge research on various topics (databases, 3d printing, data visualization, machine learning...), it's entirely possible they'd be more prepared to predict and teach future trends vs teachers from industry. For example, functional programming used to be purely academic but is practically mainstream now; FRP is starting to become influential (see react & related frameworks)...  
> **username_8**: Most teaching organisations (in the UK, I don't know about anywhere else) are forced to operate within the pace of continuous change. There's no reason why some academics, teachers or even students can't be at least as up to date (if not more so) than some working in industry.  

---

### Answer by username_11 on 2017-07-02. Score: 2

One way is to have an industry advisory committee consisting of alumni or friends of your institution. (I was on such a committee for a community college when I worked in industry.) Once a year, the committee meets with faculty to learn about the current curriculum and suggest changes based on their active professional knowledge of the field.

Another way is for faculty members to spend sabbatical years in industry. I learned more about software engineering from a year at Google than from my entire formal education.

> **Comments:**
> **username_11**: @nocomprende Do you and your colleagues find their input helpful?  

---

