# The map is not the territory

## The changing landscape of programming

The one constant in 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). 

When I graduated college we learned Pascal, Modula2 and Ada. Unfortunately those languages were starting to decline in popularity in favor of C. When I started my first "professional" programming position Perl was the language of choice (partially because Perl could be easily transformed into the ubiquitous CGI scripts of the era, and was considered superior to scripting tools like `awk` and traditional shell scripts). As of this writing I'm using Python as my main development language, and I foresee that I'll have to look into other languages to expand my programming career.

Programming requires flexibility. It's difficult to learn only one way of doing things and have that stick for over 20 years. Think back to what was current technology 20 years ago and you'll no doubt notice that things are quite different now. (If you would like a fun exercise see if you can find articles describing the state-of-the-art technology from 20 years ago and see how much of it you recognize.)

## Learning to learn

Learning specific methodologies and technologies is not a good long-term strategy for programmers. We're better served by learning how to learn, and more importantly how we ourselves learn. That sounds simple: once we've cracked how to learn effectively then we'll be effective programmers. Unfortunately there isn't a foolproof way to learn that works for all people. Different folks learn in different ways. All of us have learning styles that work better when certain things are emphasized. Some learn better in a classroom while others learn best with self-directed study (books, video recordings, etc.). Some can read a book and be perfectly fine with understanding the material while others may need more visual approaches. If you have the luxury of trying several different methodologies for learning I encourage you to use as many as you can to figure out what works best for you. Understanding what works for you will be key to helping you progress and grow.

For me I've found that some simple principles work best for me. The first is repetition. I learn better when I do something daily, over and over again, in small chunks. The second is having a small goal that I can achieve. So for me having a daily practice time on a project where I can work toward an end goal works best for me. When I was learning Python I enrolled in PyWeek, which is a one week game programming sprint where the theme is announced near the beginning and all programming happens during the week. For that entire week I made time to complete a game, and by the end of the week I'd learned more about Pygame (the library that I'd used) and Python than I had in the weeks leading up to PyWeek. Doing a one-week game jam (as they're currently called) is a bit extreme but it gave me a clear goal (a working, finished game) and a time-frame to accomplish it (one week). Over the years I've learned more about Python with various projects (both professionally and for myself) that had daily practice and clear end goals.

You'll need to experiment to see what works best for you. The underlying principle is that your learning process should be something that you can use for any language or concept in programming. It should also offer the least amount of resistance to your learning. Your ability to learn and adapt will be vital to your experience as a programmer, so understanding your learning process and what works best for you will help you in this process.

At the very least set aside 10 minutes per day as a container (see previous chapter) for focused reading and learning. There's a lot to learn in programming and creating habit of learning will help you keep up. But also keep it small. A lot of information can overwhelm you into thinking that you can't possibly learn it all. You're right -- you can't learn it all in one sitting. If someone told you to drink one of the Great Lakes in one sitting you'd be hard pressed to complete the task (note: please don't attempt this!). If, however, you filled a glass of water several times a day from one of The Great Lakes and drank it (10 minutes at a time) you'd start to make an appreciable dent in the reduction of that lake over your life-time. (Sure, it might not look like much on the outside, but that's the junction where metaphors and reality break down).

Each day you have an opportunity to learn more about the realm of computers and computer programming. Taking a small part of each of those days to learn a little bit more will help you on your journey.

## How to choose what to learn

There are many opportunities to learn, whether it be via books, tutorials, videos, or computer-based training. There's also a myriad of different topics to learn. How do you decide which one is most important to learn? How do you manage what you're learning? How do you keep from getting overwhelmed with the options available?

This gets back to focusing on one thing at a time and listening to how you learn best. This feedback will help you decide what to learn next. One approach is to think about the things that you're most passionate about right now; what excites you at this moment. If there's something that you're eager to learn then start there. If you have multiple things that are exciting or interesting to you then write them down on a list and see if you are more drawn to one of the topics than the others. If you're still having trouble deciding from this list then pick one at random (roll a die or create a random-number generator to select one -- that could be a project).

If you have trouble thinking of something to learn and are struggling to come up with one item that is exciting to you then give yourself permission to browse and see what is out there. Look around and see what people are talking about. Head to a programmer meeting to see what they're talking about. Or, if you're really stuck, browse some job listings to see what employers are looking for and see if that sparks some interest.

This isn't about picking the most important thing or the most useful thing (though your current situation may add some urgency to certain topics over others) it's about figuring out what has your attention and where to put your focus right now. We're not concerned with making the perfect choice that will get you your next job or bolster your career. This exercise is about making a choice to learn something interesting and sticking with it long enough to learn more about it.

Once you have the topic you want to learn then it's time to focus on learning it. If you have a preferred methodology (books, videos, tutorials, classes, etc.) then spend a some time (no more than an hour or so) researching what is available to help you learn it. Some topics have beginner-friendly resources available that list off things that the community believes are helpful for programmers just getting started. Others may require asking questions of the community on where to start. Even something as simple as a tutorial can be a good way to get started with this exercise.

If you can find some resources in a short amount of time that's great! Start your learning process with those resources. Don't worry if they're the right resources or worry that they might lead you down the wrong path, just get started with them; you'll come back and evaluate if those resources are going to work for you. For now we're more interested in just getting started.

One trap that I'm guilty of is trying to find the best resources for learning a topic. I'll spend hours looking for the right book, the right videos, the right courses; whatever it is I want to find the best version available so I can learn with the best material. I want to reduce the amount of false-starts while learning a topic. This seems like a noble pursuit (after all, why wouldn't you want the best materials available?). It's also a trap and can lead you into spending more time thinking about how you're learning rather than actually learning. Worse, if the material starts to confuse you (which is highly likely when you are learning something new) you'll spend your learning-time wondering if you made the right decision picking this material. This diminishes your ability to learn the topic because you're more focused on the quality of instruction and not the actual instruction.

After a few days give yourself the opportunity to check in and see how you're learning. Are you feeling engaged or are you not enjoying this? If you're not feeling engaged (the material is loosely organized, the instructor is confusing, the examples don't work, etc.) then give yourself permission to see if there's better material or a different topic that interests you more. Even if your experience wasn't great you'll have a better idea of what to look for when choosing something new. You'll have a sense of where your gaps are in the topic and will have a better feel for what you're looking for in learning materials.

If you're finding that the topic you're looking to learn is no longer interesting to you then give yourself some moments to reflect on why that is. Is it a difficult topic? Do you feel ready for the topic? Are you currently overwhelmed with other projects and are feeling tired when you approach this topic? Sometimes when we arrive to learn we realize that we need to learn something else before we can fully understand the topic. It's OK to find additional resources and focus on those before we tackle this topic. Just be aware of your internal dialog and struggles and be honest with yourself about why you want to move to something different. See yourself in the difficulty and notice if you're wanting to run because it is difficult or if you are truly unprepared for this topic. See if you can engage more with the difficulty and notice when you start to feel overwhelmed by it. Give yourself permission to stick with the difficulty as long as you can and notice your feelings and urges as you practice with it.

Treat your learning 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. Later you can reflect on those feelings and start to see patterns in your learning process. If you feel tired you may need more sleep, or may need learning material that is more stimulating. If you feel overwhelmed perhaps you need to start with something more basic before tackling this difficult project. If you're confused perhaps there is someone you can ask questions to gain clarity. These answers may not be apparent in the moment (you may be too busy feeling frustrated to understand where that frustration is coming from) but with some practice in noticing these feelings you can learn how your mind works and what it needs in order to keep engaged with your learning.

## 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?

Discomfort and uncertainty are certainly a part of learning, but rather than think of them as something to be avoided we should instead think of them as a beacon. When we're feeling uncertain about what we're doing that means we're pushing into new territory. Instead of wishing for comfort we can instead relish that we're in uncertain territory and feel those brief twinges of fear and doubt.

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.

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.