Further edits on engagement
authorCraig Maloney <craig@decafbad.net>
Sun, 28 Oct 2018 14:02:31 +0000 (10:02 -0400)
committerCraig Maloney <craig@decafbad.net>
Sun, 28 Oct 2018 14:02:31 +0000 (10:02 -0400)
chapter06.md

index 83705610ba05d571342a2a5cc347ca963ee0ae9b..dfd1d2ea695612c5acbe0d42e9a55ad847c9a38a 100644 (file)
@@ -64,25 +64,25 @@ Rather than give specific advice on which concepts will serve you best in your p
 
 Programming languages will mention the concepts they borrow from. Whenever you're learning and you see mention of one of these other concepts make a note of it and keep focusing on what you're learning now. When you've completed your learning for the day take a look at that list and do some searching to see what else shows up. If there are other things that show up then write them down on your list. These concepts might not make sense at the moment but having that list available and referring to it might help you make connections about programming that you might otherwise not make.
 
-### FIXME
-
-When I was learning JavaScript I noticed someone mentioned that JavaScript borrowed from languages like Scheme. Scheme is a functional language that was based on Lisp and was created as a teaching language for functional programming and recursion. So I took a brief detour into learning Scheme (partly because it was more interesting to me than JavaScript. Call it creative procrastination, if you're being charitable). What I learned while learning scheme piqued my interest in other  functional languages and functional programming. This in turn helped me understand some of the functional programming paradigms that were becoming popular in Python (list comprehensions, lambdas, etc.). By taking a brief detour in my learning of JavaScript I learned a whole family of languages and now I feel like I understand JavaScript with more clarity than when I started.
+When I was learning JavaScript I noticed someone mentioned that JavaScript borrowed from languages like Scheme. Scheme is a functional language that was based on Lisp and was created as a teaching language for functional programming and recursion. So I took a brief detour into learning Scheme (partly because it was more interesting to me than JavaScript. Call it "creative procrastination", if you're being charitable.). What I learned while learning scheme piqued my interest into other functional languages and functional programming. This in turn helped me understand some of the functional programming paradigms that were becoming popular in Python (list comprehensions, lambdas, etc.). By taking a brief detour in my learning of JavaScript I learned more about a whole family of languages and now I feel like I understand JavaScript and Python with more clarity than when I started.
 
-I'm not suggesting that everyone take such creative procrastination steps like I have (I'm still learning JavaScript as of this writing), but it does help to make notes of the concepts you encounter and dig further.
+I'm not suggesting that everyone take the "creative procrastination" steps like I have (I'm still in the process of learning JavaScript as of this writing), but it does help to make notes of the concepts you encounter and dig further.
 
 This is one way to map out learning goals (see what shows up and be curious about how they fit together), but some folks may need a different approach. Perhaps they're under pressure to learn something to remain marketable or require some skill for their job that needs to be learned quickly. How do you map out those goals?
 
-Part of the approach I'm outlining is to help you learn how to learn. Being able to pick up something quickly is due in part to understanding how other concepts fit in with whatever you're learning. This is great if you have a lot of experience with different languages and concepts, but for those who haven't had much experiences yet it will seem like you're trying to shove an elephant through a small funnel. This is where practicing learning every day will help you. It will help you break apart larger learning goals into smaller chunks and will help you see the fear and discomfort for what they truly are: acknowledgment  that you're expanding your skills into new territory.
+The approach I'm outlining is designed to help you learn how to learn. The best way to learn something quickly is to understand how other concepts fit together with what you're learning. This is great when you have experience with a lot of different languages and concepts, but for those who don't have much experience yet it will feel like you're trying to shove an elephant through a small funnel. This is where practicing learning every day will help you. It will help you break apart larger learning goals into smaller chunks and will help you see the fear and discomfort for what they truly are: acknowledgment that you're expanding your skills into new territory.
 
 Longer-term goals are just goals that have been broken down into shorter-term goals. Focus on the short-term goals and allow yourself to course-correct as needed and follow a few connections as you desire.
 
 ## Dead ends and changing topography
 
-Sometimes we'll find ourselves learning something that's a dead end. We're not making the progress that we thought we'd be making. We're not finding it as engaging or as exciting as we'd imagined. We're realizing that what we're learning is an evolutionary dead-end in the realm of programming. What then?
+### FIXME
+
+Sometimes we'll find ourselves learning something that's a dead end. We're not making the progress that we think we should be making. We're not finding it as engaging or as exciting as we'd imagined. We're realizing that what we're learning is an evolutionary dead-end in the realm of programming. What then?
 
-Part of the learning process is in realizing our expectations of how something will turn out can be completely different from how things actually turn out. We can envision all sorts of rewards and platitudes that never come. Does that mean we're at a dead end? I don't think so. What we can realize is that we brought our own expectations of how we'd be engaging with this material and realize that it's not what we thought it would be. 
+Part of our learning process is realizing that our expectations of how something will turn out can be completely different from how things actually turn out. We envision all sorts of rewards and platitudes that never come. Does that mean we're at a dead end? I don't think so. What it might be is a case where we brought our expectations for how we thought we'd be learning and we're now realizing that those expectations aren't being met. Our expectations of our progress may be too high, or we may find that the topic is much less interesting than we thought.
 
-Engagement can also be related to our expectations. Programming demands a certain amount of fun and reward and if we're not finding the experience fun or rewarding then we're more likely not to engage with whatever topic we're learning. When we're not engaged with the material we dread learning the material and wish we were doing anything else. We wonder if we're doing the right thing by still trying to learn this. Shouldn't we be enjoying this?
+Our engagement is related to our expectations. Programming demands a certain amount of fun and reward and if we're not finding the experience fun or rewarding then we're more likely not to engage with whatever topic we're learning. When we're not engaged with the material we dread learning the material and wish we were doing anything else. We wonder if we're doing the right thing by still trying to learn this. Shouldn't we be enjoying this?
 
 And then there's the things that we're learning that are evolutionary dead ends. The community of developers around this concept have abandoned it in favor of something else: new technology, new methodology, or just plain lack of engagement. We find ourselves getting curious looks from developers when we mention what we're learning. "Why would you learn that? We've moved on to this other thing". We find our support withering from neglect and our motivation to learn dwindles.