We've been conditioned over our human existence to think of the unknown as something to be feared. These emotions have served us well. They've kept us from venturing too far out of our comfort zone and exploring the unknown. When you're living in forests and caves the unknown can house all sorts of dangers. It makes sense not to provoke those dangers by showing up on their doorstep. But programming is not the same as venturing into a dark forest or peeking into a damp cave; programming hardly warrants the amount of fear we give it. Instead we need to realize that we're not in any mortal danger. Our fears are merely letting us know that we're venturing into the uncharted territories of ignorance. It's up to us to let our fears know that this is OK and that by exploring these realms we will only find understanding.
-### FIXME
-
-Steven Pressfield in _The War of Art_ nicknamed these feelings "The Resistance". He considers "The Resistance" as a mythological being who lives to thwart creative acts. As the work progresses The Resistance ratchets up the pressure to stop by introducing the feelings of fear and anxiety that we mentioned above. I think of Resistance as something that also happens whenever we trend toward learning more to help foster creative acts. For creative folks this is about achieving a creative work (book, painting, game, etc.) but in our case we're learning the tools to help us be more creative. Resistance is what tells us that we're not good enough or not worthy enough to learn these things. It tries to keep us safe in what we already know.
+Steven Pressfield in _The War of Art_ nicknamed these feelings "The Resistance". He considers The Resistance as a sort of mythological being who lives in each of us to thwart creative acts. As the work progresses The Resistance ratchets up the pressure to stop by introducing the feelings of fear and anxiety that we mentioned above. I think of The Resistance as something that also happens whenever we are learning, especially if we're learning tools that help us in our creative pursuits. Pressfield limited his definition to creative folks who were working to complete creative work (book, painting, game, etc.) but I'm expanding his definition to the learning process itself. In our case The Resistance shows up when we're learning the tools to help us be more creative. The Resistance is what tells us we're not good enough to learn these things, or we're unworthy of the benefits they'll bring us. It tries to keep us safe in what we already know.
-This is part of why the focus container that we mentioned before is so important: it gives is small doses of discomfort in manageable chunks. We can see our way through a few minutes of discomfort daily and keep at it. And if we focus on one thing at a time we can keep ourselves from the distracting thoughts about whether or not this is the thing we should be working on; at this moment this is exactly what we should be working on. Whatever is in front of us to learn is what we should be learning. We can be secure that for however long the container is that everything we are doing at this moment is exactly as it should be, and when we finish the container we can reassess how it went and where we should go from here.
+This is why the focus container that we mentioned before is so important: it gives us small doses of discomfort in manageable chunks. We can see our way through small amounts of daily discomfort and keep learning through our discomfort. And if we focus on one thing at a time we can keep ourselves from the distracting thoughts about whether or not this is the thing we should be working on. Whatever we're working on in this moment is exactly what we should be working on. Whatever is in front of us to learn is what we should be learning. We can be secure in knowing that however long the container is that everything we are doing during this container is exactly as it should be. When we finish the container we can reassess how it went and what challenges lay ahead.
## Mapping out longer-term goals
Rather than give specific advice on which concepts will serve you best in your pursuit of programming I'm going to suggest a technique that might help you map out what could help you.
-Programming languages usually are quick to 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 shows up. See if there are other things that show up and write them 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.
+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.
-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?
+Sometimes we'll find ourselves learning something that's a dead end. We look at our progress and see no real improvement. We don't find the topic as engaging or as exciting as we'd imagined. We realize 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 understanding that our expectations of how something will turn out can be completely different from how things actually do 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 what we expect we'd be doing with our newfound knowledge isn't panning out. Or we may find that our expectations for how quickly we'd learn the topic aren't being met and we see more and more ahead of us. We may also expect that our career will be bolstered by learning this topic and yet all we hear from the job market is resounding silence.
-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 unlikely to want to continue being engaged with learning that topic. Our minds begin wanting something else to engage us and we crave anything other than to continue with this learning process. After all, shouldn't we be enjoying this? If there's no engagement and enjoyment then the learning becomes drudgery. We become distracted more easily while trying to learn and our minds drift away rather than focus on our learning experience.
-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.
+And then there's the problem of learning things that are evolutionary dead ends. The world of computing is littered with the remains of technologies and methodologies that are either no longer relevant or are considered "out-of-fashion". What once was cutting edge is now considered moribund, and the community around that technology / methodology scoot on to new technology / methodologies and leave their previous work as a technological ghost town. When we mention that we're learning these things we get curious looks from developers when we mention what we're learning. "Why would you learn that? We've moved on to this other thing". It's as if we've heard about a party and arrive in time to see the clean-up crew picking up the litter and breaking down the tables and chairs. We feel like we missed out on the good parts and wonder if it's even worth trying to keep up and find the next thing.
-All three of these can pose their own problems for learning but it's up to us to take a more critical look at why we started this whole process of learning. What did we bring into this?
+All of these can pose their own problems for learning but it's up to us to take a more critical look at why we started this whole process of learning. What did we bring into this?
-In each of these cases we brought our expectations of how the learning would progress. We brought the expectation that it would always be fun, engaging, and relevant. Sometimes our expectations about learning do pan out, but when they don't we get discouraged and disappointed.
+In each of these cases we brought our expectations of how the learning would progress. We brought the expectation that it would always be fun, engaging, and relevant. Sometimes our learning expectations do pan out, but when they don't we get discouraged and disappointed.
-Rather than being upset with how the learning didn't meet our expectations we can take a more mindful approach. We can see ourselves in the moment of learning and see if we're trying to bring more than our focused attention into the container. We can realize that learning is not always going to be fun or engaging and that we can concentrate on the learning.
+Rather than being upset at how our expectations of learning this technology / methodology weren't met we can take a more mindful approach. We can see ourselves in the moment of learning and see if we're trying to bring more than our focused attention into the container. We can realize that learning is about changing ourselves and change is not always fun, engaging or pleasant. We can put aside our expectations and concentrate on the learning.
+
+### FIXME
That doesn't mean we shouldn't acknowledge our feelings. We can certainly feel the feelings of boredom, anxiety, disillusionment, and so on. But we can also be mindful of where those feelings come from. Are we truly bored or is this our mind trying to tell us to stop so we can do something more fun? Is this really a dead-end in our learning or are we just feeling stuck right now? Notice the feeling when it comes up and be curious about the feeling. Note when you get the feeling and where it is in your body. Then continue the work, continuing to notice all of the feelings you're having. When you're done you can reflect more on those feelings and make an honest determination of whether those feelings were the result of what you were learning or were because you're having doubts.
projects / themediocreprogrammer.git / blobdiff