Comments on: The Red Queen, Learning Fatigue, The Cost of Constant Change, the Fallacy of JIT-Learning, and the Siren Call of Superficial Understanding http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/ Miscellaneous musings on life, .NET development, and related things that don't really matter Thu, 17 May 2012 21:38:43 +0000 http://wordpress.org/?v=2.7 hourly 1 By: swebok http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-29489 swebok Sat, 20 Mar 2010 22:25:31 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-29489 [...] they wish to leave IT or stay in IT. Reviews employment trends in IT that may force IT project ...Unhandled Exceptions Blog Archive The Red Queen, Learning ...... software engineering body-of-knowledge (SWEBOK), we must all run in ... Name (required) Mail [...] [...] they wish to leave IT or stay in IT. Reviews employment trends in IT that may force IT project …Unhandled Exceptions Blog Archive The Red Queen, Learning …… software engineering body-of-knowledge (SWEBOK), we must all run in … Name (required) Mail [...]

]]> By: Alper http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10345 Alper Fri, 06 Feb 2009 19:30:03 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10345 Hi Steve, Great post as usual. I guess everyone needs to create their own coping mechanism to deal with the Learning Fatigue. Over the years, I found myself reading and trying to learn about principles and methodology -the knowledge that will not be obsolete with the next framework release. In my opinion, it is less risky and more rewarding to learn SOLID principles, Design Patterns, TDD etc. because they have been around for years and are not likely to be obsolete soon. Once you build a solid core (http://blog.jpboodhoo.com/BuildASolidCore.aspx) then you're in a better position to evaluate the technology du jour. If you're evaluating a technology and you find out that it is difficult to work with that technology while adhering to your principles, that should be a red flag. Maybe this technology is not as great as it sounds. My 2 cents. Thanks, Alper Hi Steve,
Great post as usual. I guess everyone needs to create their own coping mechanism to deal with the Learning Fatigue. Over the years, I found myself reading and trying to learn about principles and methodology -the knowledge that will not be obsolete with the next framework release.

In my opinion, it is less risky and more rewarding to learn SOLID principles, Design Patterns, TDD etc. because they have been around for years and are not likely to be obsolete soon.

Once you build a solid core (http://blog.jpboodhoo.com/BuildASolidCore.aspx) then you’re in a better position to evaluate the technology du jour.

If you’re evaluating a technology and you find out that it is difficult to work with that technology while adhering to your principles, that should be a red flag. Maybe this technology is not as great as it sounds.

My 2 cents.

Thanks,
Alper

]]> By: sbohlen http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10261 sbohlen Thu, 05 Feb 2009 19:01:14 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10261 @Chuck: Thanks for the feedback -- and I completely agree with your strategy: learn the values and not the implementations. Over time, the values and principles will hold you in good stead for much if not all of your career whereas the implementation details are the most fleeting of skills. Appreciate your taking the time to move from listener to caller :) @Chuck:

Thanks for the feedback — and I completely agree with your strategy: learn the values and not the implementations. Over time, the values and principles will hold you in good stead for much if not all of your career whereas the implementation details are the most fleeting of skills.

Appreciate your taking the time to move from listener to caller :)

]]> By: Chuck http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10238 Chuck Thu, 05 Feb 2009 11:43:07 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10238 Steve - Long time listener, first time caller... Where I realized that I had fallen prey to JIT Learning was when I got tired of not really knowing a subject. The problem was that I was casting my net way to wide and trying to learn everything. I am a new student to SOLID. The challenge that I have given to myself is to not worry about code implementation of the principles, just learn the principle. Try to learn how to restate it. For example, Open Closed Pincipal - Classes should be closed to modification, open to extension. When I try to explain that to some of my collegues, I get a "How they heck can you write code like that." But then I state the QBQ (Question Behind the Question) of the principle: you seperate the stuff that changes from the stuff that doesn't. Thanks for all the Screencast Goodness!! C Steve -

Long time listener, first time caller…

Where I realized that I had fallen prey to JIT Learning was when I got tired of not really knowing a subject. The problem was that I was casting my net way to wide and trying to learn everything.

I am a new student to SOLID. The challenge that I have given to myself is to not worry about code implementation of the principles, just learn the principle. Try to learn how to restate it. For example, Open Closed Pincipal - Classes should be closed to modification, open to extension. When I try to explain that to some of my collegues, I get a “How they heck can you write code like that.” But then I state the QBQ (Question Behind the Question) of the principle: you seperate the stuff that changes from the stuff that doesn’t.

Thanks for all the Screencast Goodness!!

C

]]> By: João Guilherme http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10233 João Guilherme Thu, 05 Feb 2009 02:50:09 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10233 Hey Steve ... great post .. I think all of us developers who care for developing systems with quality pass through the same "problem" ... that is that unfortunately we'll never know everything ! Again ... great post ! Hey Steve … great post .. I think all of us developers who care for developing systems with quality pass through the same “problem” … that is that unfortunately we’ll never know everything ! Again … great post !

]]> By: David http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10187 David Wed, 04 Feb 2009 09:53:20 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10187 Thanks for the reply Steve. Completely agree with your point about being aware of vs. having expertise in an area. Thanks for the reply Steve. Completely agree with your point about being aware of vs. having expertise in an area.

]]> By: sbohlen http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10168 sbohlen Wed, 04 Feb 2009 03:04:13 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10168 @David: Since not sleeping obviously isn't a viable option (for most of us that aren't vampires or something), I think the best you can hope for is a good mix of humility (know what you know and don't know) plus good planning to ensure you keep your skills deep in the areas that make yourself valuable and also taking the time to ensure your AWARENESS of other things remains high. As an example, I've never bothered to write a line of WPF code because I just haven't had a need to but I ensure that I read reviews, comments, feedback, and experiences from those that have so I can understand its pros and cons at a high level to ensure I can recommend when and when not to consider using it and I figure when I *do* need to write the code, I'll have to JIT-learn it. But I'll recognize that my reading of blog posts about WPF is no substitute for what I'll learn by actually DOING my first line of code in a WPF app and I will absolutely realize BEFORE I GET STARTED that this area of the proposed solution will have A LOT more risk associated with it since I don't yet know how to program in WPF. I'm just arguing against my mistaking my having read blogs about WPF with my actually having done some WPF work and I think this very kind of conflating reading about something with DOING something is what happened to the stack overflow podcast team in re: unit testing, TDD, SOLID principles, and other ideas and practices that they largely miscaracterized based on their having casually read some blogs about the topics. I find their relative inability to recognize this difference to be reasonably disturbing and that was part of what motivated me to write this post about the more general 'trap' that they seem to have fallen into (which, to be fair, is a pretty common occurence when former software engineers hang up their IDEs to become entertainment pundits, magically at once able to consider themselves capable of commenting at-will on all kinds of things about which they clearly lack knowledge, experience, or authority :D ). @David:

Since not sleeping obviously isn’t a viable option (for most of us that aren’t vampires or something), I think the best you can hope for is a good mix of humility (know what you know and don’t know) plus good planning to ensure you keep your skills deep in the areas that make yourself valuable and also taking the time to ensure your AWARENESS of other things remains high.

As an example, I’ve never bothered to write a line of WPF code because I just haven’t had a need to but I ensure that I read reviews, comments, feedback, and experiences from those that have so I can understand its pros and cons at a high level to ensure I can recommend when and when not to consider using it and I figure when I *do* need to write the code, I’ll have to JIT-learn it.

But I’ll recognize that my reading of blog posts about WPF is no substitute for what I’ll learn by actually DOING my first line of code in a WPF app and I will absolutely realize BEFORE I GET STARTED that this area of the proposed solution will have A LOT more risk associated with it since I don’t yet know how to program in WPF.

I’m just arguing against my mistaking my having read blogs about WPF with my actually having done some WPF work and I think this very kind of conflating reading about something with DOING something is what happened to the stack overflow podcast team in re: unit testing, TDD, SOLID principles, and other ideas and practices that they largely miscaracterized based on their having casually read some blogs about the topics.

I find their relative inability to recognize this difference to be reasonably disturbing and that was part of what motivated me to write this post about the more general ‘trap’ that they seem to have fallen into (which, to be fair, is a pretty common occurence when former software engineers hang up their IDEs to become entertainment pundits, magically at once able to consider themselves capable of commenting at-will on all kinds of things about which they clearly lack knowledge, experience, or authority :D ).

]]> By: sbohlen http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10167 sbohlen Wed, 04 Feb 2009 02:46:42 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10167 @One: >>I think that ‘professional software development malpractice’ is a bit harsh That's a literary device called hyperbole :D For the record, I think you (and a few other commenters) got the point exactly right: KNOW WHAT YOU KNOW. KNOW WHAT YOU DON'T KNOW. AND KNOW THE DIFFERENCE. Its when we get confused about this that we find ourselves in real trouble. >>(If our ancestors were sitting in their caves waiting until they had a deep and profound knowledge on how to kill deer, we’d still be using Cobol these days :-)) I love this example -- great point. We learn by DOING in the software development world. This is true and I'm certainly not arguing against getting started DOING before having completely mastered a thing. I think the point is more to manage risk by recognizing it; know thyself (and thy own limitations) and all will be fine (generally). @One:

>>I think that ‘professional software development malpractice’ is a bit harsh

That’s a literary device called hyperbole :D

For the record, I think you (and a few other commenters) got the point exactly right: KNOW WHAT YOU KNOW. KNOW WHAT YOU DON’T KNOW. AND KNOW THE DIFFERENCE. Its when we get confused about this that we find ourselves in real trouble.

>>(If our ancestors were sitting in their caves waiting until they had a deep and profound knowledge on how to kill deer, we’d still be using Cobol these days :-))

I love this example — great point. We learn by DOING in the software development world. This is true and I’m certainly not arguing against getting started DOING before having completely mastered a thing.

I think the point is more to manage risk by recognizing it; know thyself (and thy own limitations) and all will be fine (generally).

]]> By: One http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10108 One Tue, 03 Feb 2009 01:21:23 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10108 Hey Steve Great post. However, I'm not sure about the point you're trying to make. (unless it's more of a warning) I don't think that superficial learning is bad in itself. As you stated in your post it's impossible to be an expert, or even 'good', in all technologies available to us. (unless your last name is Guthrie-Hanselman of course:-) ) IMO, superficial knowledge is way better than no knowledge at all. If you're faced with problem X and you've read the books 'learn technology Y in 10 hours' and 'learn technology Z in 10 minutes', you're better of than someone who hasn't read them. I guess the point I'm trying to make is that you as a developer should know what you don't know (yet) and be honest (to yourself) about it. An example: last summer I canceled my vacation to watch a NHibernate screencast series that some dude put up on the net. Does that make me an expert on NHibernate ? Am I'm getting tired of answering Ayende's questions ? Of course not, but that 'superficial knowledge' gives me a possible alternative solution to my 'problem' and with additional study of the resources that I learned about, I might be able to actually implement it in my future projects. >> Without understanding a technology in sufficient detail that can only come from actually experimenting with its use, I would submit that you are committing professional software development malpractice to make a recommendation for its use in any solution you are attempting to develop. Only by knowing a thing at a deep and experiential level can one hope to be able to make the right choice about its use. << I agree (although I think that 'professional software development malpractice' is a bit harsh) but what do you suggest then ? How does a developer (/small team of developers) make a recommendation about the use of technology X ? How do you achieve a deep and experiential knowledge of a technology without applying it in a real-world scenario ? (If our ancestors were sitting in their caves waiting until they had a deep and profound knowledge on how to kill deer, we'd still be using Cobol these days :-)) One Hey Steve

Great post.

However, I’m not sure about the point you’re trying to make. (unless it’s more of a warning)

I don’t think that superficial learning is bad in itself. As you stated in your post it’s impossible to be an expert, or even ‘good’, in all technologies available to us. (unless your last name is Guthrie-Hanselman of course:-) )

IMO, superficial knowledge is way better than no knowledge at all. If you’re faced with problem X and you’ve read the books ‘learn technology Y in 10 hours’ and ‘learn technology Z in 10 minutes’, you’re better of than someone who hasn’t read them.

I guess the point I’m trying to make is that you as a developer should know what you don’t know (yet) and be honest (to yourself) about it.

An example: last summer I canceled my vacation to watch a NHibernate screencast series that some dude put up on the net. Does that make me an expert on NHibernate ? Am I’m getting tired of answering Ayende’s questions ? Of course not, but that ’superficial knowledge’ gives me a possible alternative solution to my ‘problem’ and with additional study of the resources that I learned about, I might be able to actually implement it in my future projects.

>>
Without understanding a technology in sufficient detail that can only come from actually experimenting with its use, I would submit that you are committing professional software development malpractice to make a recommendation for its use in any solution you are attempting to develop. Only by knowing a thing at a deep and experiential level can one hope to be able to make the right choice about its use.
<<

I agree (although I think that ‘professional software development malpractice’ is a bit harsh) but what do you suggest then ? How does a developer (/small team of developers) make a recommendation about the use of technology X ? How do you achieve a deep and experiential knowledge of a technology without applying it in a real-world scenario ? (If our ancestors were sitting in their caves waiting until they had a deep and profound knowledge on how to kill deer, we’d still be using Cobol these days :-))

One

]]> By: mknopf http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/comment-page-1/#comment-10103 mknopf Mon, 02 Feb 2009 22:43:45 +0000 http://unhandled-exceptions.com/blog/index.php/2009/01/31/the-red-queen-learning-fatigue-the-cost-of-constant-change-the-fallacy-of-jit-learning-and-the-siren-call-of-superficial-understanding/#comment-10103 GREAT ARTICLE! Well said in every way. I have been suffering for some time with Learning Fatigue, constantly battling to stay ahead and finally realizing that I must pick what I think will serve my needs best and learn those as much as my time permits. I'm fortunate enough to work at Kennedy Space Center developing some very cool applications for NASA and our department is headed up by a very knowledgeable person who keeps up working on the front edge of technologies that are out now. GREAT ARTICLE! Well said in every way. I have been suffering for some time with Learning Fatigue, constantly battling to stay ahead and finally realizing that I must pick what I think will serve my needs best and learn those as much as my time permits. I’m fortunate enough to work at Kennedy Space Center developing some very cool applications for NASA and our department is headed up by a very knowledgeable person who keeps up working on the front edge of technologies that are out now.

]]>