Answers.Body: <p>For background, I'm answering this question as an individual who got an engineering degree, spent 30 years programming in industry, and now teach and mentor at the local university.</p>
  
  <p>In many respects, I really don't see a big difference from the late 60's until now. Our program still contain the same types of components: computation and assignment; conditionals; repetition and abstraction. I began with Fortran IV and though it lacked both structures and dynamic memory, one was able to get around that by using "parallel" arrays for lists of structures and by allocating huge arrays and managing the contents with our own "pointers".</p>
  
  <p>One big change, however, was in turnaround time. With punch cards, it was often many minutes if not hours before one received "feedback". The consequence of this was that one had to carefully review programs before submission. As soon as "personal" computers were introduced, the feedback became almost instantaneous. This altered my approach to programming as it became possible to code small pieces and test them before moving on to the next piece. I'm surprised that students do not take advantage of this. Rather, many tend to code way too much before testing anything. </p>
  
  <p>The other day I was discussing with a student how to do an assignment. It had three basic parts: read in some data; transform the data; write out some data. I suggested that the student first code the input and output, skipping the transformation entirely until the other two parts worked correctly. The student was baffled by this because the assignment required all THREE parts. "Yes is does, but ONLY when you have completed it". I'm not sure I got through.</p>
  
  <p>Of course, many things got easier as I progressed to Pascal, then C with unix and all of its functionality provided by the shell and the ability to stitch things to together with pipes. Then came Java, C++ and networks. And on to concurrent programs and the many languages that came with the web. Faster hardware made slow programs really quick and allowed work on even bigger problems. I love the choice of languages and the ability to build solutions using several languages. All the standard libraries mean I don't need to reinvent the wheel, but merely integrate well proven code into my program. IDE's and many other tools have made me more productive.</p>
  
  <p>Prior to the web I was limited to the reference texts I had available and the knowledge of those that I worked with. Today I can get thousands of answers to a question, but must sort through and evaluate them for accuracy and appropriateness. A textbook, such as K&amp;R, that was once a necessity on my bookshelf has been replaced by the ability to search the web. I still find discussing things with colleagues to be the most beneficial approach to problem solving. That has stayed constant over the years.</p>
  
  <p>I'm probably like a lobster in a slowly warming pot and don't realize how much things have changed. Yet I look back and don't find the process I use terribly different from years ago. I spend a lot of time thinking about what I'm trying to do, selecting the appropriate technologies and putting it together, piece by piece, with continuous testing. I can't say that my experience is typical as I have been out of industry for more than 10 years. However, my approach and experience has been valued in teaching.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-25T22:00:47.183Z
Answers.LastActivityDate: 2018-09-25T22:00:47.183Z
Answers.UserDisplayName: Fritz Sieker
Answers.Body: <p>I think this question is confusing "Computer Science" and "Software Engineering" / "Software Development" / "Programming".</p>
  
  <p>Computer Science has nothing to do with "cutting &amp; pasting code".</p>
  
  <p>Type Theory is hotter today than it ever was, Type Systems can do more things than they ever could, Programming Language Theory is blooming, Compilers perform optimizations that would make Admiral Hopper's head explode, companies like Microsoft not only <em>use</em> Automated Theorem Proving to prove (parts of) their code correct, they actually employ researchers, scientists and engineers to <em>invent</em> those tools in the first place.</p>
  
  <p>Mainstream programming languages are more and more based on principled, rigorous, mathematically proven foundations, for example look at the evolution of Scala and the Calculus of Dependent Object Types. We have projects like seL4 and L4.verified that produce a mechanically proven correct microkernel. In combination with a verified C compiler (which now exists), a verified assembler (which now exists), and a verified CPU (which now exists), you have a system that has been proven correct from the OS layer down to VHDL. Once you get a verified VHDL compiler, you have a system that is proven correct down to the transistor level.</p>
  
  <p>We have entire subfields like Quantum Computing and Bioinformatics which not that long ago didn't even exist.</p>
  
  <p>Average web programmers now know about things like Monads, Promises, Futures, Vector Clocks, the CAP Theorem. Working programmers in industry casually throw around sentences like "an infinite event loop is actually just finite co-recursion over co-data" and use concepts like monads, co-monads, functors, co-functors, bifunctors, arrows, categories, catamorphisms, hylomorphisms, homomorphisms, isomorphisms, monoids, semigroups, groups, fields to structure their programs.</p>
  
  <blockquote>
    <p><a href="https://stackoverflow.com/a/3870310/2988">All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.</a></p>
  </blockquote>
  
  <p>For example, the <code>IObservable</code>/<code>IObserver</code> pair of interfaces in .NET was mathematically derived as the category-theoretical dual of <code>IEnumerable</code>/<code>IEnumerator</code>. That is CS applied to library API design of one of the most widely-used libraries.</p>
  
  <p>Many programs nowadays are asynchronous, concurrent, parallel, or distributed, or even all of the above. How to make that safe, performant, and accessible to the average programmer (or even non-programmers) is an active area of research in Type Theory, PLT, and Compilers.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-07T17:12:21.380Z
Answers.Text: I'm pretty sure that your "average" web programmer does not know all of the things you suggest.  I just polled four of them from three different companies, and only one had even a notion of what a monad was.  It's a small sample, but I'm fairly certain that if you polled 10,000 web programmers at random, you wouldn't get anywhere close to a simple majority.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-05T13:02:12.190Z
Answers.LastActivityDate: 2018-09-05T13:02:12.190Z
Answers.UserDisplayName: Jörg W Mittag
Answers.Body: <p>Like any field with an active research community, Computer Science changes over the decades, sometimes quite drastically. If a practitioner doesn't keep up he or she will be left behind, not understanding the new work. </p>
  
  <p>Decades ago problems tended to be a bit smaller in scope. How do I sort an array? Now they are massive. How do I scale a cloud environment and make it immune from failure and attack? </p>
  
  <p>For this change in scope and scale to occur we need to learn to think at higher and higher levels of abstraction. It is hard to write complex programs in languages that permit only simple constructs. </p>
  
  <p>Language research is still an active pursuit. The ACM still has a special interest group POPL interested in the Principles of Programming Languages, for example. The papers and discussions are deep and "modern." </p>
  
  <p>There are many other <a href="https://www.acm.org/special-interest-groups" rel="noreferrer">ACM SIGs</a>, some of which, say SIGMobile, couldn't have existed a couple of decades ago, prior to smartphones. </p>
  
  <p>The other thing is that such a field grows so much that no single practitioner can grasp all of it after a certain point in time. In mathematics, for example, this point was passed around 1900. It has probably been passed in CS as well. </p>
  
  <hr>
  
  <p>Regarding education, the changes in the field have also generated changes in teaching, both the content and the methodology. I can speak only for what happens in the US since all my experience is here. But an undergraduate CS major will get two things. First a broad education, including History, Philosophy, and the rest, including some writing. Second they will get enough education in the major field to either go on to a graduate degree or obtain an entry level position in industry. But they will normally never be deeply taught in any one aspect of CS (or Math, or Literature, or ...), nor broadly enough to say they know much about the whole field. </p>
  
  <p>The Master's degree, on the other hand should, in a technical field teach students the things that every working professional needs to know. Again, this isn't necessarily very deep nor broad, but it has to be vaguely comprehensive for the working pro. It should also get you a bit closer to the ability to do research if it doesn't already include some research component. But usually the research required there is into what is known about a possibly new or arcane topic, rather than the creation of new knowledge in a field. That is for doctoral programs. </p>
  
  <p>The effect of this is that undergraduate teaching now includes more options that were not studied in the past (big data, machine learning, ...) through elective subjects at the upper level. It also means that some things that were needed by working pros in the past (numeric algorithms, say) are not taught to the same degree as much of what was once hard is now captured in standard libraries. But methodologies also change, and now teamwork is much more used in the classroom than was typical a few decades ago. </p>
  
  <p>The conclusion I draw from all of this is that students need to start higher up the learning tree if they are to get where they need to go. In my view, recapitulating the history of computation, starting with low level concepts and tools and building everything up incrementally is a mistake. There is also no need. Students can start at any level of abstraction and work upwards from there intensively. They make excursions down the abstraction hierarchy on occasion as some of that helps the understanding, but a complete understanding of the foundations of, say, IEEE Floating Point algorithms is only needed by a very few working pros. If you start the education, today, the same way it was done 20 years ago there will be no time to get to today's problems and solutions. </p>
  
  <p>I used to tell my students that my job is <em>not</em> to teach them what <em>I</em> know, because much of that is now obsolete. My job was to teach them what <em>they</em> need to know. Not the same thing. One example is the <em>hidden bit</em> in IEEE Floating Point. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-20T20:03:29.090Z
Answers.Text: Actually, @ScottRowe, a field grows with the size of its practitioners. Math grows fast also, but there is already so much of it  and so many practitioners that you can't see much of the horizon. Much like the universe itself.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-21T10:44:29.253Z
Answers.Text: @scottrowe I don't think it has changed very fast (Hardware has improved very fast, exponential growth, but software has not always even been positive). see bret victor's future of programming https://www.youtube.com/watch?v=8pTEmbeENF4 it is set in the 1960s, but aimed at people in the 2010s. Why don't we learn, from what has been done before? Why is software getting slower?, using more memory?
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-21T10:54:01.170Z
Answers.Text: @ctrl-alt-delor I challenge that we haven't learned from the old stuff. A lot of it is just in the libraries now. You don't need to build a lot of the things today that you needed to in years past. We have faster, bigger machines so that (a) the optimization that every programmer needed to do in the past in every program is now less important and (b) much of it is done by the compiler and associated tools. The problems that we can now solve are  also bigger now and were infeasible in the past.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-21T12:34:05.643Z
Answers.Text: @ctrl-alt-delor I have definitely watched "*The Future of Programming*" and showed it to my students. Bret seems to have disappeared from the public stage, the past few years. I wonder what he is doing now?
Answers.UserDisplayName: Scott Rowe
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-21T12:35:02.827Z
Answers.Text: @ScottRowe. Sorry, your metaphor fails the smell test. People to teach beginning students starting at a higher level than the absolute base. I have a doctorate and fifty years of experience. I know quite a lot. Do I expect my students to follow my path in every detail to learn what I know. That would be profoundly stupid. And if they did it they would be 70 years behind the curve. You are ignoring the power of abstraction. Sorry. No.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-21T13:29:44.863Z
Answers.Text: I want someone with a doctorate and 50 years experience writing any software that is safety-related, or that holds my personal information. For anything not connected to those two, whatever. Unfortunately, now everything is connected.
Answers.UserDisplayName: Scott Rowe
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-20T12:33:43.853Z
Answers.LastActivityDate: 2018-08-20T17:56:00.757Z
Answers.LastEditDate: 2018-08-20T17:56:00.757Z
Answers.UserDisplayName: Buffy
Body: <p>My sister, her husband and I (the older generation) were sitting at the dinner table with their two children (the younger generation), discussing computer science.</p>
  
  <p>One of the members of the older generation said, "From what I understand, most programming (except for cutting edge applications like nanotechnology) has already been done, and can be looked up. A lot of computer science nowadays is choosing and cutting and pasting the formula that most appropriate/efficient for your application. This was different from "my time," when there was a much greater emphasis on discovering new ways/languages, for programming."</p>
  
  <p>One of the younger generation agreed that computer science nowadays was much more of a "copy-editing" job than what she remembered from her teachers' descriptions.</p>
  
  <p>Has computer science/education in fact changed in this way within the past three or four decades? Assuming that it has, what would be the implications for classroom practices today? (For instance, when I was studying computer science in the 1970s, very limited use was made of "library" functions, and we were encouraged to do things from scratch.)</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-08-20T13:57:49.210Z
Comments.Text: When it was said, "most programming can be looked up" were they referring to things like Open Source, or other pre-written or pre-defined libraries or collections? It would be like saying that most woodworking has already been done, we can just fit together wooden parts, because the power tools are so widely available. Programming is partly about creating the means to do something, and partly about actually doing it. The actually doing will go on, no matter how good the means have become. Deciding what to do and how to use a power tool is still a creative activity.
Comments.UserDisplayName: Scott Rowe
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-08-21T14:50:31.167Z
Comments.Text: I'm not sure if this is quite on-topic for the site, as written. It seems more like a history question than a problem needing a solution. Perhaps, with the acknowledgment of the difference between practice now and instructor descriptions given by the younger generation, a better question might be about converting classroom practice to accommodate that change.
Comments.UserDisplayName: Gypsy Spellweaver
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-08-25T00:31:34.257Z
Comments.Text: Uh... better interfaces, better documentations, powerful PCs.  Need I go on?
Comments.UserDisplayName: ncmathsadist
Tags: <programming-paradigms>
Title: How is computer science (and education) different today than some decades ago?
ThreadText: # How is computer science (and education) different today than some decades ago?
  
  (Asked by: username_0 on 2018-08-20)
  
  My sister, her husband and I (the older generation) were sitting at the dinner table with their two children (the younger generation), discussing computer science.
  
  One of the members of the older generation said, "From what I understand, most programming (except for cutting edge applications like nanotechnology) has already been done, and can be looked up. A lot of computer science nowadays is choosing and cutting and pasting the formula that most appropriate/efficient for your application. This was different from "my time," when there was a much greater emphasis on discovering new ways/languages, for programming."
  
  One of the younger generation agreed that computer science nowadays was much more of a "copy-editing" job than what she remembered from her teachers' descriptions.
  
  Has computer science/education in fact changed in this way within the past three or four decades? Assuming that it has, what would be the implications for classroom practices today? (For instance, when I was studying computer science in the 1970s, very limited use was made of "library" functions, and we were encouraged to do things from scratch.)
  
  **Tags:** programming-paradigms
  
  > **Comments:**
  > **username_1**: When it was said, "most programming can be looked up" were they referring to things like Open Source, or other pre-written or pre-defined libraries or collections? It would be like saying that most woodworking has already been done, we can just fit together wooden parts, because the power tools are so widely available. Programming is partly about creating the means to do something, and partly about actually doing it. The actually doing will go on, no matter how good the means have become. Deciding what to do and how to use a power tool is still a creative activity.  
  > **username_2**: I'm not sure if this is quite on-topic for the site, as written. It seems more like a history question than a problem needing a solution. Perhaps, with the acknowledgment of the difference between practice now and instructor descriptions given by the younger generation, a better question might be about converting classroom practice to accommodate that change.  
  > **username_3**: Uh... better interfaces, better documentations, powerful PCs.  Need I go on?  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_5 on 2018-09-05. Score: 6 | Accepted answer
  
  I think this question is confusing "Computer Science" and "Software Engineering" / "Software Development" / "Programming".
  
  Computer Science has nothing to do with "cutting & pasting code".
  
  Type Theory is hotter today than it ever was, Type Systems can do more things than they ever could, Programming Language Theory is blooming, Compilers perform optimizations that would make Admiral Hopper's head explode, companies like Microsoft not only *use* Automated Theorem Proving to prove (parts of) their code correct, they actually employ researchers, scientists and engineers to *invent* those tools in the first place.
  
  Mainstream programming languages are more and more based on principled, rigorous, mathematically proven foundations, for example look at the evolution of Scala and the Calculus of Dependent Object Types. We have projects like seL4 and L4.verified that produce a mechanically proven correct microkernel. In combination with a verified C compiler (which now exists), a verified assembler (which now exists), and a verified CPU (which now exists), you have a system that has been proven correct from the OS layer down to VHDL. Once you get a verified VHDL compiler, you have a system that is proven correct down to the transistor level.
  
  We have entire subfields like Quantum Computing and Bioinformatics which not that long ago didn't even exist.
  
  Average web programmers now know about things like Monads, Promises, Futures, Vector Clocks, the CAP Theorem. Working programmers in industry casually throw around sentences like "an infinite event loop is actually just finite co-recursion over co-data" and use concepts like monads, co-monads, functors, co-functors, bifunctors, arrows, categories, catamorphisms, hylomorphisms, homomorphisms, isomorphisms, monoids, semigroups, groups, fields to structure their programs.
  
  > [All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.](https://stackoverflow.com/a/3870310/2988)
  
  For example, the `IObservable`/`IObserver` pair of interfaces in .NET was mathematically derived as the category-theoretical dual of `IEnumerable`/`IEnumerator`. That is CS applied to library API design of one of the most widely-used libraries.
  
  Many programs nowadays are asynchronous, concurrent, parallel, or distributed, or even all of the above. How to make that safe, performant, and accessible to the average programmer (or even non-programmers) is an active area of research in Type Theory, PLT, and Compilers.
  
  > **Comments:**
  > **username_6**: I'm pretty sure that your "average" web programmer does not know all of the things you suggest.  I just polled four of them from three different companies, and only one had even a notion of what a monad was.  It's a small sample, but I'm fairly certain that if you polled 10,000 web programmers at random, you wouldn't get anywhere close to a simple majority.  
  
  ---
  
  ### Answer by username_7 on 2018-08-20. Score: 8
  
  Like any field with an active research community, Computer Science changes over the decades, sometimes quite drastically. If a practitioner doesn't keep up he or she will be left behind, not understanding the new work.
  
  Decades ago problems tended to be a bit smaller in scope. How do I sort an array? Now they are massive. How do I scale a cloud environment and make it immune from failure and attack?
  
  For this change in scope and scale to occur we need to learn to think at higher and higher levels of abstraction. It is hard to write complex programs in languages that permit only simple constructs.
  
  Language research is still an active pursuit. The ACM still has a special interest group POPL interested in the Principles of Programming Languages, for example. The papers and discussions are deep and "modern."
  
  There are many other [ACM SIGs](https://www.acm.org/special-interest-groups), some of which, say SIGMobile, couldn't have existed a couple of decades ago, prior to smartphones.
  
  The other thing is that such a field grows so much that no single practitioner can grasp all of it after a certain point in time. In mathematics, for example, this point was passed around 1900. It has probably been passed in CS as well.
  
  ---
  
  Regarding education, the changes in the field have also generated changes in teaching, both the content and the methodology. I can speak only for what happens in the US since all my experience is here. But an undergraduate CS major will get two things. First a broad education, including History, Philosophy, and the rest, including some writing. Second they will get enough education in the major field to either go on to a graduate degree or obtain an entry level position in industry. But they will normally never be deeply taught in any one aspect of CS (or Math, or Literature, or ...), nor broadly enough to say they know much about the whole field.
  
  The Master's degree, on the other hand should, in a technical field teach students the things that every working professional needs to know. Again, this isn't necessarily very deep nor broad, but it has to be vaguely comprehensive for the working pro. It should also get you a bit closer to the ability to do research if it doesn't already include some research component. But usually the research required there is into what is known about a possibly new or arcane topic, rather than the creation of new knowledge in a field. That is for doctoral programs.
  
  The effect of this is that undergraduate teaching now includes more options that were not studied in the past (big data, machine learning, ...) through elective subjects at the upper level. It also means that some things that were needed by working pros in the past (numeric algorithms, say) are not taught to the same degree as much of what was once hard is now captured in standard libraries. But methodologies also change, and now teamwork is much more used in the classroom than was typical a few decades ago.
  
  The conclusion I draw from all of this is that students need to start higher up the learning tree if they are to get where they need to go. In my view, recapitulating the history of computation, starting with low level concepts and tools and building everything up incrementally is a mistake. There is also no need. Students can start at any level of abstraction and work upwards from there intensively. They make excursions down the abstraction hierarchy on occasion as some of that helps the understanding, but a complete understanding of the foundations of, say, IEEE Floating Point algorithms is only needed by a very few working pros. If you start the education, today, the same way it was done 20 years ago there will be no time to get to today's problems and solutions.
  
  I used to tell my students that my job is *not* to teach them what *I* know, because much of that is now obsolete. My job was to teach them what *they* need to know. Not the same thing. One example is the *hidden bit* in IEEE Floating Point.
  
  > **Comments:**
  > **username_7**: Actually, @username_1, a field grows with the size of its practitioners. Math grows fast also, but there is already so much of it  and so many practitioners that you can't see much of the horizon. Much like the universe itself.  
  > **username_8**: @username_1 I don't think it has changed very fast (Hardware has improved very fast, exponential growth, but software has not always even been positive). see bret victor's future of programming https://www.youtube.com/watch?v=8pTEmbeENF4 it is set in the 1960s, but aimed at people in the 2010s. Why don't we learn, from what has been done before? Why is software getting slower?, using more memory?  
  > **username_7**: @username_8 I challenge that we haven't learned from the old stuff. A lot of it is just in the libraries now. You don't need to build a lot of the things today that you needed to in years past. We have faster, bigger machines so that (a) the optimization that every programmer needed to do in the past in every program is now less important and (b) much of it is done by the compiler and associated tools. The problems that we can now solve are  also bigger now and were infeasible in the past.  
  > **username_1**: @username_8 I have definitely watched "*The Future of Programming*" and showed it to my students. Bret seems to have disappeared from the public stage, the past few years. I wonder what he is doing now?  
  > **username_7**: @username_1. Sorry, your metaphor fails the smell test. People to teach beginning students starting at a higher level than the absolute base. I have a doctorate and fifty years of experience. I know quite a lot. Do I expect my students to follow my path in every detail to learn what I know. That would be profoundly stupid. And if they did it they would be 70 years behind the curve. You are ignoring the power of abstraction. Sorry. No.  
  > **username_1**: I want someone with a doctorate and 50 years experience writing any software that is safety-related, or that holds my personal information. For anything not connected to those two, whatever. Unfortunately, now everything is connected.  
  
  ---
  
  ### Answer by username_4 on 2018-09-25. Score: 1
  
  For background, I'm answering this question as an individual who got an engineering degree, spent 30 years programming in industry, and now teach and mentor at the local university.
  
  In many respects, I really don't see a big difference from the late 60's until now. Our program still contain the same types of components: computation and assignment; conditionals; repetition and abstraction. I began with Fortran IV and though it lacked both structures and dynamic memory, one was able to get around that by using "parallel" arrays for lists of structures and by allocating huge arrays and managing the contents with our own "pointers".
  
  One big change, however, was in turnaround time. With punch cards, it was often many minutes if not hours before one received "feedback". The consequence of this was that one had to carefully review programs before submission. As soon as "personal" computers were introduced, the feedback became almost instantaneous. This altered my approach to programming as it became possible to code small pieces and test them before moving on to the next piece. I'm surprised that students do not take advantage of this. Rather, many tend to code way too much before testing anything.
  
  The other day I was discussing with a student how to do an assignment. It had three basic parts: read in some data; transform the data; write out some data. I suggested that the student first code the input and output, skipping the transformation entirely until the other two parts worked correctly. The student was baffled by this because the assignment required all THREE parts. "Yes is does, but ONLY when you have completed it". I'm not sure I got through.
  
  Of course, many things got easier as I progressed to Pascal, then C with unix and all of its functionality provided by the shell and the ability to stitch things to together with pipes. Then came Java, C++ and networks. And on to concurrent programs and the many languages that came with the web. Faster hardware made slow programs really quick and allowed work on even bigger problems. I love the choice of languages and the ability to build solutions using several languages. All the standard libraries mean I don't need to reinvent the wheel, but merely integrate well proven code into my program. IDE's and many other tools have made me more productive.
  
  Prior to the web I was limited to the reference texts I had available and the knowledge of those that I worked with. Today I can get thousands of answers to a question, but must sort through and evaluate them for accuracy and appropriateness. A textbook, such as K&R, that was once a necessity on my bookshelf has been replaced by the ability to search the web. I still find discussing things with colleagues to be the most beneficial approach to problem solving. That has stayed constant over the years.
  
  I'm probably like a lobster in a slowly warming pot and don't realize how much things have changed. Yet I look back and don't find the process I use terribly different from years ago. I spend a lot of time thinking about what I'm trying to do, selecting the appropriate technologies and putting it together, piece by piece, with continuous testing. I can't say that my experience is typical as I have been out of industry for more than 10 years. However, my approach and experience has been valued in teaching.
  
  
  ---
  
  