BOOKNAME = the_mediocre_programmer
TITLE = title.txt
METADATA = metadata.xml
-CHAPTERS = intro.md chapter01.md chapter02.md chapter03.md chapter04.md chapter05.md chapter06.md epilogue.md gratitude.md appendixa.md
+CHAPTERS = intro.md chapter01.md chapter02.md chapter03.md chapter04.md chapter05.md chapter06.md chapter07.md epilogue.md gratitude.md appendixa.md
TOC = --toc --toc-depth=2
COVER_IMAGE = images/cover.jpg
LATEX_CLASS = book
# Appendix A {-}
-Write down my own journey through programming?
+My journey as a programmer started early in my life. I became interested in computers after reading about them in the World Book Encyclopedia and hoped to work with them some day. What I hadn't realized was those encyclopedias were rather out of date and only showed the larger, more expensive mainframe and mini computers of the 1960s and not the more modern microcomputers of the 1970s. When I saw that an Apple II was a microcomputer and was designed for the home I began my quest to get a computer (AKA: dropping not-so-subtle hints to my parents that I wanted a computer). I scoured magazines looking for the right computer; from the Commodore VIC-20 and Sinclair ZX-80 to the Radio Shack TRS-80 Model III. My parents took me to computer stores and I marveled at the machines that were there (and likely made a few sales-people nervous as I poked and prodded the rather new and expensive machines). Finally my dad picked up an Atari 400 computer with tape drive and I began learning BASIC programming in earnest. Around the same time my school got a "lab" of three Commodore PET 4032 machines (with floppy disk drives) and I spent every moment I could with those machines. In high school I took several programming courses, both in BASIC and in Pascal (which was my first exposure to a higher-level language, and the concepts of computer science). In college I majored in Computer Science (with a bachelor of science) and did my best to keep up with all of the things that they tried to teach me. Unfortunately I wasn't a great student, especially in mathematics. I struggled with (and later dropped) my compilers class, and felt like I was falling behind where other students succeeded. Most of our classes used Pascal but there were a few that used COBOL, Ada, SNOBOL, and assembly language. I graduated with modest scores and returned home.
+
+Throughout my career I've straddled the line between system administration and programming. My first few jobs were all related to maintaining various sorts of computers: desktop PCs, UNIX-based machines, and so forth. It wasn't until folks needed websites and realized I knew how to program that my career slid over into programming. From there I learned Perl, SQL, databases, and HTML. At that time the web was new so we were all learning at the same time. I leveraged my Perl knowledge into several jobs doing web-based programming. Perl is a language that is both simple and complex. Perl and CGI made it incredibly easy to get something displayed to a web page. Where it is complex is the syntax for things like regular expressions, and the tendency for Perl programmers to value code that does multiple things on the same line. There was also a lot of value placed on code that was clever, which lead me to wonder on several occasions if I was clever enough to be a Perl programmer.
+
+One of the companies I worked at decided to migrate a Perl system over to a Java-based environment. They looked at the skills of the existing developers and decided they needed to outsource the project to another company. This was a common trend in the early 2000s for reasons that are outside of the scope of this book. This gave me my first taste as a team leader. I know a lot of programmers enjoy being in a managerial role but at the time I didn't feel I had fully explored my programming potential. I sat down on several occasions and tried to learn Java but it never clicked for me. It always felt more cumbersome than Perl CGI scripts that I created. It also didn't help that we were shipping .war files into a Tomcat system, which seemed like they were comprised of a lot of metadata and very little code. This is what I meant when I spoke about being OK with giving up on learning something - sometimes what we try to learn is more of a chore. Having something that is a chore isn't going to provide a good learning experience.
+
+It was around this time that I started learning Python on my own using Pygame and entered my first Pyweek competition. Pyweek is a week-long competition where folks build a game from scratch in one week's time. It was a challenge but was also one of the most rewarding experiences I've had in programming. I build something that was playable when I didn't know what the hell I was doing. In many ways I was learning to swim by throwing myself into the deep end. I wasn't in any danger but the desire to get something done at the end of a week drove me in ways I hadn't thought possible.
+
+AS the technical lead position wore on I found myself wanting to do something else. I managed to get a position with Sourceforge as a member of the Systems Operations Group. Sourceforge was an amazing experience for me. I had long wanted to work for an Open Source company, and few companies were more well-regarded than Sourceforge and Slashdot in the Open Source community. But my insecurities and "impostor syndrome" kicked in. Would I be able to cut it? Would they hire me only to realize they'd made a horrible error? It didn't help that I was friends with and had gone to school with some of the people who worked at Sourceforge / Slashdot. Was this going to be an elaborate prank, or was I getting in because they knew me? All of these thoughts ran through my head as I started work. It didn't help that my position was primarily system administration at a level that I was inexperienced at. There was also a programming component to the position, but I constantly felt like I was in way over my head. I lived in constant fear that I was going to be found out and that the job that I wanted would no longer be available to me.
+
+I'd love to say that it had a happy ending and that my fears were unfounded, but sadly I was let go from that position due to budgetary constraints. I'm grateful for the opportunities I had there, the friends I made, and the experiences I had but I'd be lying if the layoff didn't come with a mixture of sadness and relief. Sadness that I might never have a cool job like that again, and relief that I could put away those impostor syndrome feelings.
+
+Later on I got a position doing more Python full-time. I created a lot of interesting projects there and kept on learning more about Python. It helped me to recuperate and strengthen my skills. The folks there were very supportive. There were times where it got stressful but overall it was a positive experience.
+
+Sadly I was also laid off from that position (money sucks, y'know?).
+
+I started my job search in earnest and went to a bunch of interviews. While everyone seemed impressed with my skills and my career I fell into one of two categories: either I wasn't a good fit for the position, or I didn't have enough skills in areas they were looking for. I found myself taking timed coding tests that seemed like they were testing if I got stressed easily rather than my coding skills. I sat in coding sessions with shadowy figures that barked out commands and requirements while I tried my best to follow them. I did math puzzles and logic problems. Promising leads turned into rejection letters, and desperation set in as I faced the real prospect that I would have to give up programming if I wanted to make a living. Visions of heading back to the beginning of my career filled me with dread. It seemed like nobody wanted to take a chance on me anymore and I couldn't compete with so many fresh faces who hadn't made the mistakes from my career.
+
+I registered themediocreprogrammer.com during this period. If I was going to be a fuck-up then I might as well own it.
+
+Fortunately I've had a community of friends and fellow programmers to help support me. My current position is contracting with one of these friends to help him with programming tasks. That position came about from showing up to a programming conference every year (PyOhio). Throughout my struggles I've been fortunate to have a community there to help me. This is why I think communities are so great - they give us a network of folks that we might not otherwise have.
+
+I'm a collection of all of these experiences. They all make me who I am. Sometimes I wonder if I could have done some of these things different, but that's a futile exercise. The best I can hope to do is learn from them and move on. Each day I work to improve and strengthen myself. Each day I make new mistakes, but that's part of the learning process.
+
+My journey continues.
## Whoops!
-It's bound to happen. Something that you thought was good didn't work the way you planned and now you're realizing that you've made a terrible error. Sometimes it's something that could have been avoided (committing in code that was meant for debugging for instance). The ones that really frighten me though are the ones that I did not expect at all. It's the side-effect from using a module in a way that you later learn wasn't intended to be used that way. It's the realization that this small module will be part of a larger module and your code isn't designed to make a smooth transition.
+It's bound to happen. Something that you thought was a good idea didn't work the way you planned and now you're realizing that you've made a terrible error. Sometimes it's something that could have been easily avoided (committing in code that was meant for debugging for instance). Sometimes it's a cascade of errors, each piling on the efforts on the previous error. There's the side-effects of using a module in a way that you later learn wasn't intended to be used that way. Or it's the realization that you've designed a small module and later realize that module will be part of a larger piece of software and your code isn't designed to make a smooth transition. Whoops!
+
+The ones that really frighten me though are the ones that I did not expect at all where the unintended consequences run rampant throughout the system. Those sorts of errors keep me up at night.
Programmers make mistakes. The nature of our jobs requires us to be aware at all times of what is going on in multiple sections of code and no matter what safeguards we put into place we lose track of the state of our program and committed code. We rush and rely on muscle memory to pick up the slack. We deny ourselves areas where we can adequately test code because we feel we need to get things done sooner.
## Avoiding mistakes
-Let's be clear: there's no way to eliminate mistakes. Software is too complex to be completely bug free. But what we can do is create places where we can tease out as many bugs as possible from the code before we put it out in front of others. When we have the ability to debug and test our code we get to better places of understanding what the code is doing and how it behaves under certain circumstances. Creating a model environment of the target system allows us to test our code against what we think the target system will do and how it will behave.
+Let's be clear: there's no way to eliminate mistakes. Software is too complex to be completely bug-free. But what we can do is create places where we can tease out as many bugs as possible from the code before we put it out in front of others. When we have the ability to debug and test our code in a safe environment we can better understanding what the code is doing and how it will behave under certain circumstances. Creating a model environment of the target system allows us to test our code against a miniaturized version of the target system's reality and see how it behaves under those conditions.
-We put a lot of emphasis on avoiding mistakes, both in programming and in programming culture. There are horror stories told of how a small bug in a program caused enormous pain for those involved. The morals of the story tend to illuminate that a simple mistake can be a costly mistake and we need to be more diligent about avoiding mistakes. All these tales do is make programmers more paranoid about making any mistakes. And when we operate in a fear-based mode we begin to panic. Telling programmers to make no mistakes is akin to telling someone not to be afraid - they then become afraid of being afraid.
+We put a lot of emphasis on avoiding mistakes, both in programming and in programming culture. There are horror stories of how small bugs in a program caused enormous pain for those involved. The morals of those stories illuminate that a simple mistake can be costly and we need to be doubly careful about avoiding mistakes. All these tales do is make programmers paranoid about making any mistakes at all, and when we operate in a fear-based mode we begin to panic. Telling programmers to make no mistakes is similar to telling someone not to be afraid: they become more afraid of being afraid.
-The only way we learn is by making mistakes. When we deprive ourselves of making mistakes we deprive ourselves of the opportunity to make mistakes. That doesn't mean we have to make every mistake that other developers have made before us (that would be a lot of mistakes). But we need to make our own mistakes in order to keep learning and to figure out where our gaps in understanding are.
+The only way we learn is by making mistakes. When we deprive ourselves of the freedom to make mistakes we deprive ourselves of the learning opportunities in making those mistakes. That doesn't mean we have to make every mistake that other developers have made before us (that would be a lot of mistakes). Nor does it mean that we need to introduce chaos into our development process in order to learn better. What it means is that we need to make our own mistakes in our own way in order to keep learning and figure out where the gaps in our understanding exist.
## Making a model
-What we need instead are areas where programmers can set up environments where they can safely learn from their mistakes. We need areas where developers can feel OK about trying new things. But we also need an area where developers can test those changes and ensure that they don't have other rippling effects on other code.
+We need an environment where programmers can safely learn from their mistakes. We need areas where programmers can feel good about trying new things. We need to have places where developers can try out their ideas and not have those changes ripple to other unrelated systems. This is the best way that developers can learn and be brave in their learning process.
+
+These environments must model the target systems, and they must be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments but you do need to have models of production environments that test enough of the pieces your code will come in contact. Having models that mirror production systems means you'll be less likely to introduce changes that have unintended consequences. You'll give yourself some comfort in knowing that the changes you enact in these models will be the same changes that will appear on the target system.
+
+Ideally you'll need to have an environment like this on a machine that you control. This means that you're not competing with other programmers in your organization that are also being brave with their changes. But you'll also want to ensure that you keep your environment up-to-date with their changes (and any production changes) so you're development model matches what's on the target system and what will be on the target system.
+
+This also means having an environment that you can quickly rebuild and replicate as needed. Having a model that becomes its own separate reality becomes one more system to maintain. This model should be something that you can destroy and rebuild at will in order to remove any previous experiments. It's best to think of it as an ephemeral copy of your target environment that has limited use and can be tossed when no longer necessary. It should be quick to replicate this environment so there's little friction in creating new environments to play in. That can mean scripting the building process for these environments. How you decide to do this is up to you but keep in mind that you want something that's as simple as you can make it and requires as little thought as you can manage to replicate it.
+
+Again, it doesn't have to be perfect - it's only a model. But it does need to be close enough where your code will behave in a similar fashion between the model and the target environment.
+
+## Time machines
-We also need environments that model the target system. They need to be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments, but you do need to make models of production environments that test enough of the pieces your code will come in contact. That also means keeping this model updated as systems change.
+There are plenty of other folks who will tell you the benefits of revision control (and many folks who will show you the exact steps for how to set up revision control). Having a good revision control system will allow you to create areas where you can test code without having to merge these tests into production. Good revision control will allow you to create a space (or "branch" in git parlance) based off of existing code that you can use to experiment and develop on. It also allows you to commit to that space and diverge as much as you need to in order to fully explore the changes you're making. What's most important though is that good revision control will allow you to abandon that space if you need to - you're not forced to commit those changes back to a production machine. This allows you to see if something might work and abandon those changes if they don't pan out. Good revision control affords the programmers the ability to branch off from any point in time and explore what happened in the code base. In a sense they're time machines, allowing you to play "what if?" scenarios with your code. This is vital for your learning because you can feel secure in testing and trying things and have the ability to rewind those changes (or delete them entirely) without affecting the work of others.
-Again it doesn't have to be perfect - it's only a model. But it does need to be close enough where your code will behave in a similar fashion between the model and the target environment.
+Learning how your revision control system works will give you freedom in making mistakes. Many of these systems can seem complex at first but with continued practice and patience you'll understand what the revision control is doing and what its capabilities are. You'll be able to judge how many risks you can take with your code and be more confident with the risks you take.
## Learning from failure
Sometimes we fail. Sometimes the code that we wrote isn't up to the realities of the system it's implemented on. Sometimes we push code that does something that we didn't expect and does any number of things. In all of these cases it causes discomfort, whether to us, the folks we support, or the folks we work with.
-I'm not going to lie. Failure sucks. It makes us feel like we're somehow less of a person because we failed. We feel inadequate and wonder how others think of us. Do they think less of us? Have we damaged our relationship with those who use whatever we've programmed? Have I damaged my relationship with my co-workers? All of these questions come at the forefront and they all stem from a desire to do our best and make sure that we don't cause harm to others. We want others to think well of us and our skills and failure amplifies whatever feelings of inadequacy we might have. We wonder if we should eve be doing this at all, or if our talents lie elsewhere. We feel like giving up.
+I'm not going to lie: failure sucks. It makes us feel like we're less of a person because we failed. We feel inadequate and wonder how others think of us. Do they think less of us? Have we damaged our relationship with those who use whatever we've programmed? Have I damaged my relationship with my co-workers? All of these questions come at the forefront and they all stem from a desire to do our best and make sure that we don't cause harm to others. We want others to think well of us and our skills and failure amplifies whatever feelings of inadequacy we might have. We wonder if we should eve be doing this at all, or if our talents lie elsewhere. We feel like giving up.
We don't usually let failure be part of the learning process. Failing feels a lot like and end-point of the journey. In school a failing grade doesn't usually mean "I need to practice this some more"; it usually means that we're going to cause shame and discomfort to ourselves and our loved ones. I think there's a huge disservice we give ourselves if we don't acknowledge that failure is part of a process and that it's OK to fail. Not everything we do will be perfect. Mistakes will creep into the best code we write. We'll slip up and deploy to the wrong system. We'll cause discomfort to others.
--- /dev/null
+# The struggle within
+
+## The emotions of programming
+
+There's a stereotype of a programmer sitting emotionless in front of the computer entering lines of code as though they were just transcribing them from memory. But if you've been around programmers you know that it's more like the stereotype of the frustrated composer. We bask in the glories of code that works perfectly the first time. We glower at code that misbehaves. We go from cheering ourselves in victory to cursing the machine with clenched fists. We swing from emotion to emotion: exuberance, joy, fear, anger, resentment, sadness, loneliness, guilt, and shame.
+
+No wonder we're exhausted by the end of the day.
+
+Programming is a taxing process. Not only do we need to keep a mental model of the software we're working on, but we also have our emotional attachment the software. Our emotional state can mirror what we feel about what we're creating; whether we're excited, bored, or stuck. Keeping a positive attitude about software that isn't measuring up to our expectations is exhausting. Couple that with our own insecurities, fears, and doubts and you begin to see why programmers tend to burn out - it's a combination of the stress of the job and our emotional reaction to that stress.
+
+## Emotional drains
+
+There are several factors that can cause us emotional highs and lows. These are some that I've noticed in my own programming.
+
+### Purpose and utility
+
+If we clearly see where this code will become useful we can get a sense of drive and purpose. We're working toward something that will benefit folks! Whatever pitfalls lie in wait for us we can be assured that we will do our best to make sure that we conquer them as best we can because people are depending on us. We can tap into the emotional high of self-worth and purpose to help buoy us along.
+
+The opposite is true, of course. If we don't see the purpose then our work will seem in vain. We'll struggle to meet deadlines and feel a sense of worthlessness in our pursuits. Sometimes it's just a bad project, or it's a project that isn't aligned with our underlying purposes and goals. We can be frustrated trying to meet some arbitrary deadline if we don't see the point of what we're working on.
+
+### Engagement vs. boredom
+
+You've already experienced several layers of engagement with your programming. There are projects and topics that don't feel like a chore. You feel like you're learning something each step of the way. Time disappears.
+
+Conversely you've likely experienced the opposite: boredom. The code base doesn't engage you at all. The topic being covered is just re-hashing something you already know. It's a chore to get started and the minutes drag along throughout the whole process.
+
+### Awake vs. tired
+
+Sleep is a major contributor to how we perceive the world. Getting enough sleep manifests in feeling refreshed, awake, and inspired. We have the energy reserves at the ready to take on whatever challenges befall us. But when we don't get enough sleep (or enough quality sleep) we become irritable and less-open to engagement. We conserve our resources as best we can lest we use them up too quickly.
+
+### Mental state
+
+I'm using "mental state" in a broad sense to cover any of our existing feelings and current mental well-being. These can range from temporary feelings of unhappiness and melancholy to complex topics like clinical depression and PTSD. Our minds are complex machines that do their best to adapt to the situations and environment presented to them. At times this can clash with our desires to be productive and the struggle between our mental state and our desires can cause further emotional drain, discomfort, and despair.
+
+There are more things that can affect our emotions but these are the ones that I'd like to focus on as they cover a broad spectrum of what we bring to the tasks of learning and programming.
+
+## Awareness of our Emotional State
+
+Being aware of our emotional state (what we're feeling right now) gives us our current emotional location. We can see where we are and understand what our mind is telling us. Giving ourselves a few moments to truly see what emotional state our mind is in will help us to move forward.
+
+Note that we're not trying to change our emotional state. We're not trying to force ourselves to be something we're not. If we're truly unhappy with where we are or what we're doing it's more helpful to see what's causing this unhappiness than to try to paper over those emotions. Seeing our emotions clearly allows us to see what is causing them. Being present with these emotions allows us to better understand our mental state and what we're capable of in the moment.
+
+You can do this in the context of mindfulness meditation but even sitting still in your desk and saying "for one to two minutes I'm just going to sit here and explore my emotional state" should suffice. Seeing our emotions for what they are and thinking to what is causing them can help us understand what we're feeling.
+
+
+## Our story
+
+Each one of us have a story that we tell ourselves. The stories we tell ourselves shape our perception of the world. We tell ourselves stories of how the day will be, and how we will engage with the day. We create a world in which we are the central protagonist of our story (which we are). We tell ourselves stories like "the work I'm about to do will be amazing" or "I'm going to work through this problem quickly and will have an awesome solution when I'm done". Or we tell ourselves a story about how we're not good at what we're doing and will likely fail in the attempt. We weave a tale of struggle, pain, and misery.
+
+Our emotions inform the story we tell. If we're feeling amazing we tell ourselves that what lies ahead will also be amazing. If we're feeling down and defeated our story reflects that.
+
+The story is just that - a story. Our stories are not a guarantee of how the day will progress. We can tell ourselves that today will be amazing but watch in horror as each interaction we have causes that story to reflect a different reality. Or we can say that today will totally suck and we won't accomplish anything but instead have a pretty decent day.
+
+What we can do instead of creating these grand stories is focus more on the things that we love about the present moment. Instead of saying that we're going to have an amazing day we can say that there are things that we are looking forward to in this project and we hope to work on them. Instead of filling your day with dread you can focus on the little victories along the way. Yes, even something as small as "my computer booted without crashing" can be a victory.
+
+Giving ourselves the power to focus more on the present and the very next steps we're about to take gives us the freedom to recalibrate as the day progresses. We can focus on the positive aspects of what we're doing instead of seeing how reality is diverging from our internal stories.
+
+## Awareness in action
+
+Say in this moment that we're feeling anxious. We've just received a bug report and it's related to something we're working on. The bug report states that code that we committed earlier isn't working and probably has never worked the way we thought it worked. As we read the bug report our anxiety levels increase. Our inner monologue kicks in and we start telling ourselves that we aren't nearly as good as we thought. We're not perfect. We suck. We didn't get enough sleep the night before so our emotions are in a state of heightened awareness. Our mind races to the other times when we've failed. As we keep reading our sense of dread kicks in. What will they think of me? What do they think of me now? Am I going to lose my job over this?
+
+Before we've even finished the bug report we've created a story where we can only think of our past failures. Worse, we've already added this one to the list of failures. We also added to the stakes of this bug report. Not only do we have to fix whatever broke but now we have to fix our reputation and start a job search.
+
+The story we've created isn't a good story, but I'm sure you can relate to it. You've had this story play out in your head. It's a story based on our insecurities and feelings of inadequacy. It's fueled by a feeling of fear: fear that you'll ruin your reputation, fear they won't trust you, and fear that you'll fail.
+
+Fear is one of the most powerful emotions we have but it's not the only one. Reading that bug report may also elicit other emotions like grief (we thought that code was good and now that thought is gone), uncertainty (how will we fix the problem?), and anger (how could we have deluded ourselves into thinking this worked?). We may also feel sadness and loneliness. We could feel disconnected and adrift.
+
+Being aware of the feelings we have can help us diagnose the story we told ourselves and how it didn't match reality. They can give us feedback on how we are perceiving our world and the work we're doing. Pausing for a moment to acknowledge our feelings and understand where they are coming from give us an understanding of what our emotions are trying to tell us.
+
+## Finding our feelings
+
+Our feelings manifest themselves in our bodies in some shape or form. Fear can be a knot in our stomach or tension in our chest. Anger can feel like our head is getting hot and our jaw clenching. We can pause for a moment and just sit with our feelings and notice them. Think of like you are scanning your body looking for the feelings you have. Notice where your mind is drawn: tightness of your chest, tightness in your stomach, a clenched jaw, or whatever you may feel. Notice the sensation of that feeling. You can dig deeper and try to find the underlying causes of the feeling but for now just notice that it exists. Sit for a few moments more and be curious about how it feels. Let the feeling exist - be kind and gentle with it. Give it space. Above all don't try to fight the feeling or wish that it would end; just notice it. Eventually the feeling may subside but for now just acknowledge that you have this feeling and you're going to be curious about it.
+
+Some feelings and emotions may be more painful than others. Give them space and be curious about them as long as you can. If you notice yourself starting to panic or feel overwhelmed by the feeling then you may stop before they overtake you. Remind yourself that these are emotions and are a part of you. You and your emotions work together. You're on the same team.
+
+## Emotional Triage
+
+There's a tendency to want to run away from our feelings, or try to suppress them. Our feelings aren't always pleasant and we want to avoid things that make us unhappy or uncomfortable. And we want our internal narrative to be one of someone who is smart and capable of doing anything we put our mind to doing. But when we feel negative emotions or fail to live up to our stories we start to feel crappy about ourselves. We wonder if this is worth it and wonder if we will ever be happy working with computers.
+
+Think of this practice as emotional triage. Hopefully you've never had to go to a hospital emergency room, but if you have you'll see a whole string of doctors and nurses who are trained to diagnose what just walked through the door and determine the severity of the problem. When we recognize that we're having an emotion we too are diagnosing what emotion we're having and the severity of the emotion. We take these moments when we're having these emotions to see what the emotion is. As we review our emotions we are gentle with them and see them for what they are. A good doctor or nurse doesn't impose their desires on the patient; the simply accept the patient for who they are and act accordingly. When we recognize our emotions for what they are and see where they are coming from we can better understand what we're facing.
+
+The more we do this practice the better we'll become at recognizing our emotions and why we're having them. We'll be better able to see what we're feeling and understand why we're feeling them. When we feel anxious we can recognize that we might be in an area of development where we don't fully know what we're doing. We can then feel the anxiety for a bit (don't try to chase it away just yet) and then think about what we're currently working on and the areas that might be new to us. We can then mentally note them, or (better still) write them down or journal them so when we complete what we're doing we can review the areas that caused us anxiety.
+
+With this practice we can turn our emotions from something that drives us into something that guides us. We can use our emotions as a tool to better calibrate our internal stories. Instead of thinking that we're going to be amazing programmers generating bug-free code (which is amazing fiction, no doubt) we can instead say that we're going to spend the next 10 minutes exploring this area of our work and see where the gaps are in there. As we explore our emotions and anxiety can let us know where we feel we need to improve and adapt. We can then change our plans as needed to address those areas we feel are lacking or need improvement.
+
+## Burnout
+
+One thing that our emotional triage can help us diagnose is feeling burned out. Burnout is a collection of emotions coupled with emotional and physical exhaustion.
+
+Burnout can manifest itself in different ways. For some it may be the feeling of dread for working on a project. They feel like they are ineffectual in making any changes. For others burnout can be feelings of exhaustion. They feel as though they're on a treadmill that just will not stop and they wanted to stop a long time ago. Burnout can also manifest in feeling creatively drained, where imagining a different future is difficult and nothing that you do is interesting.
+
+Burnout can be something as simple as boredom or being overworked but it can also be the sign of something more serious. Burnout can lead to physical complications if we're not careful. We can work ourselves to exhaustion and think that's just part of the price we have to pay as programmers.
+
+Burnout is tricky to self-diagnose because it is a collection of seemingly unrelated emotions. Our feelings of boredom, fear, exhaustion, and anxiety can all have different root causes, but when we couple them together with unrelenting working schedules we amplify them. Left unchecked and unexamined we can lead ourselves into places where we don't want to program anymore. We can cause ourselves more undue suffering by just "powering through it" which can lead us to compound our emotional state.
+
+There are some things we can do to understand and help alleviate burnout:
+
+1. Realize that we're burned out, or about to burn out. Acknowledging that we're about to burn out is key to not experiencing the burnout. That seems simple enough but we tend to realize it when we're in it. If we can recognize that we're about to burn out then we can take measures to avoid it. And if we realize that we've burned out we can take measures to be kind to ourselves and help ourselves out of this burned-out state.
+1. Examine our emotions. Sit for a while and see what emotions come into view. Are we feeling stress, fear, anxiety, nervousness, or anger? See what feelings emerge and recognize these feelings. Examine where these feelings are coming from and what might be triggering these emotions.
+1. Re-negotiate our commitments. Many times burnout is the result of overcommitment, whether to others or ourselves. We have too much to do and despite our best efforts we can't meet the obligations. Perhaps they were too aggressive, or something caused the world to change when the plan was made. Whatever the reason we may need to re-evaluate what is expected of us and what we are capable of doing. And if we see that we've created an intractable situation for ourselves then we need to figure out how to cut away some of these obligations.
+1. Give our drive a rest. Unlike our mechanical counterparts we need downtime and rest. We can't work a straight 8 hours without at least some moments where we aren't working. Programming demands a lot of mental bandwidth and pushing ourselves to exhaustion can lead to emotional instability, stress, and burnout.
+1. Examine if this is truly how we want to live our lives. We need to be aware if what we're doing is really what we want to be doing. If we're not happy doing this then every moment we do this can compound our feelings of unhappiness. If we look deep in ourselves and feel nothing but dread for our current situation then we may need to renegotiate our commitments. That can be something as simple as agreeing not to learn something right now, or can be as complex as taking on different work or changing careers.
+
+By understanding that we're headed toward burnout (or are burned-out already) we can take measures to course-correct so we can approach our programming practice with joy and enthusiasm. Sometimes taking a step back and re-evaluating what we're doing can help us not sit in the constant loops of frustration, anger, and guilt. Changing our story to better fit reality can keep us from trying to match an impossible dream.
+
+You will experience burnout in your programming career. Things will come at you that will overwhelm your ability to cope with them. You will find yourself stuck in loops wondering if this is really what you should be doing. Understanding what you're feeling and acknowledging your feelings as valid is the first step to changing the course from one of burnout and stress. Programming shouldn't be drudgery (no work should be drudgery). There should be something in your programming day that keeps you motivated, and helps you grow your skills. Adding bits of learning, joy and wonder (along with periods of downtime) will help sustain you through the emotional turbulence that awaits.
+
+## Giving up
+
+Programmers don't like to think about giving up. We work on machines that have so many possibilities that we feel we should be able to make things work. But sometimes we can't see those possibilities. Sometimes we look at the list of things we should be learning and wonder if it's all worth it. We look at lists of job prospects and see nothing but meaningless work. Students ask us what it's like to be a programmer and we wonder if it's OK to crush their dreams this early in their careers. The joy that sustained us into learning the craft disappears and we're left wondering if we will ever cultivate that feeling again.
+
+Programming isn't for everyone. There are times when I've wondered if I should be working as a programmer. I feel as though I can't learn everything that I need to know, and wonder if what I'm learning will not matter because in 10 seconds everything out there will have completely changed. I struggle looking at job positions that seem like they won't matter in 3 years, let alone 100. I feel like the computing future I was promised never happened and we're stuck in a world where computers are little more than levers for companies to pry open the wallets of their customers.
+
+It's easy to become fatalistic about the practice of programming but I've realized that there's more to computing and programming than what I see in the job market.
+
+Part of the joy of programming is the curiosity. If we can continually tap into that curiosity then we have so many avenues to explore. From game programming to some of the more esoteric languages there are always topics and ideas to discover. What the job market uses is but a fraction of what is out there. There's also a whole host of emulators and retro-computers available with good documentation. One of the things that I'm curious about is how older computers work. But there are also newer, lower-powered machines out there in the embedded space that are fascinating to look at and understand.
+
+But there can also be the realization that there's no joy left in programming. The thought of programming no longer excites us and even the thought of trying something new fills us with dread. We no longer want to even try. What then?
+
+If we no longer find joy in programming then we need to understand why we feel that way. Perhaps we're tired and have been through a project that drained all of the fun and excitement of programming. Or we found that the communities in our area and online are hostile and unwelcoming. Maybe we thought programming would be fun but every time we start we wish we were doing something / anything else instead.
+
+Programming is not for everyone. I strongly feel that programming is something that is best when you really want to do it. But if you're stuck in a situation where you don't want to do this anymore then it's perfectly reasonable to step away from it and give up. There's no shame in this at all - many programmers have decided they lost the spark and the desire and have gone into other fields. Stepping away from the computer is perfectly fine.
+
+It's OK to walk away from programming and do something else. Programming is only one facet of our lives. True, it may be a big facet, and it may feel scary to give up something that we've worked so hard to accomplish. But if we examine our feelings and realize that we're just going through the motions, or see that we're no longer finding any joy in programming then it's time to think about what else we can be doing with our lives. We're granted a limited amount of time to live our lives and doing something we don't enjoy robs us of a meaningful life.
+
+Giving up doesn't have to be a negative experience. Taking time away from being a programmer is perfectly fine and is not a mark of shame. Plenty of programmers have taken a "sabbatical" from programming to allow themselves to explore other interests and recharge themselves. Breaking the loop of negative experiences in programming can help us clearly see what we want out of programming and a programming career. It can help confirm our innermost feelings about programming and see if it's right for us to pursue any further.
+
+There are several fears that can keep us from making this break with programming. The first fear goes by the fancy name of the "sunk cost fallacy". This fallacy is the belief that we have invested too much time and effort that will be wasted if we quit. I would argue that learning any sort of programming is not a wasted skill and can be applied to many facets of our lives, such as simplifying tasks into manageable steps, and basic Boolean logic.
+
+The second fear is that if we stop programming that we are letting down our fellow programmers in some way. This one is tricky because we might be on a team where we have a large load of tasks to complete and our decision to quit may mean these tasks won't get done the way we wanted them to get done. Or we may fear that our absence will cause harm to the enterprise and its eventual collapse. This fear requires us to choose between which is more important: our well-being or the well-being of others. It also requires us to explore whether those fears are true or whether they are groundless. Are we really that irreplaceable or can someone take our place? Sometimes the answer may be "no, but I need to do this for me or I will cause harm to both of us if this continues". Thinking in terms of the well-being of both you and the organizations you belong to in longer-term prospect may help you make this decision.
+
+The third fear deals with our own personal fears of identity and the memory of our community. If we decide to stop being a programmer will that somehow erase a part of our identity. Will our community stop identifying us as a programmer and will we lose contact with folks that have become friends, colleagues, and such. Again, this is tricky to overcome because programming may be a large part of the identity you crafted for yourself. Letting go of that can lead to you feeling less like yourself. And the fear that folks will stop calling you for programming projects can be compounded if you feel that you might just need a break from programming and may wish to return.
+
+Each of these fears is a valid fear, but they may not be the truth. We can't control how others perceive us or how organizations move on without us. What we can control is our participation in each of these communities. We can determine if a hard break from programming would be better than gradually easing ourselves out of our commitments. We can clarify to others what our current standing is and if this is something that is permanent or temporary. But what is most important is that we don't let others persuade us into doing something that is harmful to us. If we need to stop programming because we are emotionally drained and burned out then we need to make it clear to others that we will be doing them a disservice if we continue.
+
+Mature communities will understand the need to stop programming and walk away. They will understand that your mental and emotional well-being is more important for you than their needs to continue. And they will be able to piece together what needs to be done and heal from your absence. It is natural and normal for folks to move on from organizations and pursue other priorities.
+
+What's important to remember is that it's OK not to be a programmer and to turn off that portion of your being. Whether or not that is a permanent change is up to you and your desires. Programming is hard enough. Feeling emotionally drained, uninspired, and burned out is counterproductive to your programming exercise. Taking a break from programming to explore other interests is natural and doesn't mean you're less of a programmer for wanting to recharge yourself. And should you realize that you are happiest when you're not programming then we can appreciate the time that you were a programmer and promise to meet again someday should you return.
## The Mediocre Programmer?
-Let's face it; we don't want to be mediocre programmers. We want to be great programmers; superlative programmers. We want to be the programmers they call whenever they're in a bind and we want to be the programmers that rush into the code base and produce perfect code in a matter of minutes. Code that would sit in the Louvre as a work of art, studied by generations of programmers for its intrinsic beauty and exceptional functionality.
+Let's face it: we don't want to be mediocre programmers. We want to be ``[great|amazing|superlative]`` programmers! We want to be the programmers they call whenever they're in a bind and we want to be the programmers that rush into unfamiliar code bases and produce perfect code in a matter of minutes. Code that would sit in the Louvre as a work of art, studied by generations of programmers for its intrinsic beauty and exceptional functionality.
-Why would we want to be mediocre programmers? Mediocre is the opposite of great. Shouldn't we strive to be great programmers?
+Why would we want to be mediocre programmers? Isn't mediocre the opposite of great? Shouldn't we strive to be great programmers instead?
-Sure, we should strive to be great programmers in the long term. But to become great programmers we have to pass through being mediocre programmers first.
+Sure, we should strive to be great programmers in the long term, but to become great programmers we have to pass through being mediocre programmers first.
-Mediocre programmers know that they're not great yet. Mediocre programmers see the distance between where they are and where they want to go in their programming career. They see the work that goes into a being a great programmer and they know that one day they'd like to be that great programmer.
+Mediocre programmers know they're not great programmers yet. Mediocre programmers see the distance between where they are and the greatness they want in their programming career. They see the work that goes into a being a great programmer and believe that if they do the work that one day they too will be great programmer.
-But they also see their own faults and failings. They see their browser history littered with online-searches for basic syntax and concepts. They see their email archives of questions they've asked other developers. They look at their code from several months back and wonder if they'll ever get to be great programmers with all of those mistakes and missteps. They see the gap between them and the great developer they wish to be and it feels like that gap widens every step of the way.
+But they also see their own faults and failings. They see their browser history littered with online-searches for basic syntax and concepts. They see their email archives of questions they've asked other programmers. They look at their code from several months before and wonder if they'll ever get to be great programmers with all of those mistakes and missteps. They see the gap between them and being a great programmer and it feels like the gap widens every step of the way.
-The mediocre developer wonders if it's even worth it; if they should do something else with their lives other then computer programming. Maybe they're not as good as they thought they were, or maybe they lack that special talent that great developers have. Maybe they learned the wrong things early on in their journey, or maybe they think they should have started sooner.
+The mediocre programmer wonders if it's even worth it; if they should do something else with their lives other then computer programming. Maybe they're not as good as they thought they were, or maybe they lack that special talent that great programmers have. Maybe they learned the wrong things early on in their journey, or maybe they think they should have started sooner.
-They see others being wildly successful and wonder if they were absent the day that the good programming genes were handed out.
+They see others being wildly successful and wonder if they were absent the day the great programmer genes were handed out.
-The truth is we're all mediocre developers in some way. We all still ask questions and have to look up syntax and concepts in our day-to-day programming. Computers continue to add complexity to everyday programming tasks and it takes a lot of mental bandwidth to keep all of those concepts fresh in our mind.
+The truth is we're all mediocre programmers in some way. We all still ask questions and have to look up syntax and concepts in our day-to-day programming. Computers continue to add complexity to everyday programming tasks and it takes a lot of mental bandwidth to keep all of those concepts fresh in our mind.
## Why this book?
-This book is about helping you along on the journey of being a mediocre developer. Together we'll uncover some of common misconceptions we have about programming, failure, and growth and come to understand that the act of programming and development is something we undertake each day and improve in small ways. It's these small changes that over time transform us from being mediocre developers into better developers.
+This book is about helping you along on the journey of being a mediocre programmer. Together we'll uncover some of common misconceptions we have about programming, failure, and growth and come to understand that the act of programming and development is something we undertake each day and improve in small ways. It's these small changes that over time transform us from being mediocre programmers into better programmers.
-There are plenty of books on how to become a better developer out there. Usually they have checklists and other things that the author deems important for you to do in order to become a better developer. This book will try not to saddle you with more work (you likely have enough as it is). Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotion of being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll talk about those feelings you have of giving up and walking away from computing and whether those feelings come from a place of love or a worry that you're not keeping up.
+There are plenty of books on how to become a better programmer out there. Usually they have checklists and other things that the author deems important for you to do in order to become a better programmer. They tend to focus on specifics like choosing a better editor, writing better test cases, or drinking lots of water. Those books have a lot of useful advice, but they read like a laundry list of things that you must do all at once in order to succeed. This book will try not to saddle you with more work (you likely have enough as it is). Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotions in being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll cover the struggles in learning new things and keeping your skills current. We'll talk about those times when you feel like giving up and walking away from computing and whether those feelings come from a place of love or a worry that you're not keeping up.
This book is a personal journey for both of us. It's a memoir of my time as a programmer and my feelings along the way. I've thought many times about giving up and finding a different career path but doing anything other than being a computer programmer scares me even more. Does that mean I'm stuck in a perverse ouroboros of self-pity and self-doubt? Hardly. It means that I need to dig deeper to understand why I chose the path of being a programmer and realize that it took a lot to get here and it's going to take a lot more to get where I want to be. It's a commitment to seeing things as they are now and moving forward from wherever I'm standing.
% The Mediocre Programmer
-% Craig Maloney
-% Released under the CC-BY-SA International 4.0 license
+% Written by Craig Maloney
+% \textcopyright 2018 by Craig Maloney. \break Released under the CC-BY-SA International 4.0 license
projects / themediocreprogrammer.git / commitdiff