# The map is not the territory
-Discuss the ever-changing facets of programming and how keeping current with it all is both a challenge and a myth
## The changing landscape of programming
The one constant about the field of programming is that it is always in flux. Programming languages come into prominence and the fade away over time. What once was a given is now considered obsolete (or even "harmful", as many essays will point out).
Treat this as an iterative process, with regular check-in periods to see how you're doing. Think about how you feel when you're learning. Are you excited and engaged or do you feel tired and withdrawn? Do you try to procrastinate when you think about this topic? When you are focusing on your learning does your mind wander? Note these feelings as they occur to you during your focusing sessions and come back to them when you think about your learning process.
-## Resistance
+## Resistance and The Container
Any time we learn new things we put ourselves into a vulnerable and uncomfortable place. We take the things we are familiar with and push into new territory. We become uncertain of the outcome; will it be successful or will it be a failure? Will it help us or hurt us? Will we choose the wrong thing to learn and will it cost us opportunities in the long run?
We've been conditioned over our human existence to think of the unknown as something to be feared. These emotions have served us well and have kept us from venturing too far out of our comfort zone. When the unknown can house all sorts of dangers it makes sense not to provoke them 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 and our fears are merely letting us know that we're venturing into the uncharted territory of ignorance where we shall find understanding.
-(talk about learning, feelings, and resistance to new learning. Talk about the discomfort of learning new things)
+Steven Pressfield in _The War of Art_ nicknamed these feelings "resistance". He uses the term "Resistance" as a sort of mythological being that thwarts 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.
+
+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.
+
+## Mapping out longer-term goals
+
+As you progress with learning you'll start to see that a lot of what we call programming is interconnected. Languages borrow heavily from each other and ideas that seem new and innovative have their roots in concepts dating back to the genesis of computing. But rather than dissuade us it should encourage us. We can open the doors of programming by learning simple, transferable concepts. The question is, which ones?
+
+The simplest answer is "all of them", but that's hardly satisfactory (or possible). A less cheeky answer would be "enough of them to start seeing the patterns emerge" but that sounds more like a truism than something we can take to start making our longer term goals for learning.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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?
+
+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.
+
+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?
+
+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.
+
+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?
+
+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.
+
+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.
+
+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.
+
+If, however, you realize that you're really not enjoying the learning; if you feel like you're constantly having to muster the courage to sit and learn, then you may want to have an honest discussion with yourself about why you're learning this in the first place. Is this still relevant to you or has the moment passed? Are you learning this out of an obligation to yourself or others, and is that obligation still present? Are you trying to learn whatever it is because you're worried you'll be left behind, whether that's personally or professionally? Think about what brought you to start learning this and see if the situation has changed. If someone came up to your computer and asked you if you wanted to learn this would you still jump at the chance?
+
+There have been many things in my career that I have tried to learn, but there have been many more that I haven't learned. Part of those is because the computing landscape changed. At school I learned the Pascal language. I got reasonably good at it but over time those skills faded. Right now there's very little need for being a proficient Pascal programmer so continuing to develop my Pascal skills would be purely for my own enjoyment. I find other things enjoyable so those skills lay dormant. Should Pascal arise from its moribund state I can revisit the decision. But for now I'm content that I've made the right call. Later in my career the Java language came to prominence. I spent many sessions learning Java until I realized that I didn't enjoy the language. It felt too cumbersome to me and the directions it was taking weren't ones that I cared to pursue. So after some reflection I stopped learning Java. Was this all wasted time? Hardly. During my sessions I learned more about Object Oriented Programming and how objects fit together. I learned more about recursion while trying to solve a problem for one of my projects. These skills transcend Java, so when I started learning Python I was more up to speed on how objects worked so I could better understand what Python was doing and how it was different from Java. And should the need arise I can revisit my decision to learn Java and see if it's something that interests me again.
+
+It's OK to give up on learning something for a while. We are complex beings and our interests change. We also exist in a complex industry of changing technologies and whims. What was interesting and necessary at the beginning of the year might be uninteresting and unnecessary at the end of the year. It's up to us as programmers to understand our learning process and adapt as our needs and desires change.
+
+## Approach with curiosity
+
+As beginners we engaged the computer with curiosity and enthusiasm. We don't know what to expect or how long it will take so we take everything at face value. As we learn we trade our curiosity with certainty, and our enthusiasm with expectations. The excitement we got from learning becomes the drudgery of having to continue to learn. But we can re-capture that beginner's spirit by looking at each opportunity to learn as a new experience. We can let go of our expectations of how our learning will progress and instead approach each learning session with curiosity for what we will learn during the session. We can re-kindle the spark that we had when we were beginners with infinite possibilities, and that spark will sustain us through the periods of uncertainty and drudgery.
+
+With each focus container we can begin again, with no preconceived notions of how it will end.
projects / themediocreprogrammer.git / blobdiff