We can acknowledge that we have feelings of wanting to push ourselves to keep learning and doing. We can see ourselves when we think "just one more line of code before bed" or convince ourselves "I can read a few more articles or pages or [insert favorite way to consume more information here]". We can pause and see where these feelings and thoughts come from and understand why we're still pushing ourselves beyond exhaustion.
-### FIXME
+These feelings usually stem from a sense of inadequacy. We feel like we're not measuring up to the ideals we have; whether these ideals are ones we've created or ones that are externally driven. These ideals come from analyzing other programmers (colleagues or folks we admire), and measuring our progress against their work. They also come from our own mythical idea of what the perfect programmer is.
-These feelings usually stem from a sense of inadequacy. We feel like we're not measuring up to whatever ideals we have, whether that's an ideal that is externally driven or one that we made ourselves. This comes from us comparing ourselves to other programmers and seeing their work. It also comes from us comparing ourselves to our own mythical idea of what the perfect programmer is.
+What we need to realize is that those ideas of what makes good and perfect programmers are fantasies. They're a composite of what we think a good and perfect programmer should be. They don't exist in the real world. True, we may see programmers out there that seem to wake up with a keyboard attached to their hands, spend the entire day coding, and go to sleep with dreams of more code formulating in their heads. But we need to realize that we're only seeing one side of their lives. We're not seeing the whole picture of who they are. We need to focus on our own bodies and minds and realize when they're tired and need rest. We can't make ourselves into other people, we need to work with who and what we are.
-What we need to realize is that those ideas of what a perfect programmer is and is doing right now are fantasies. They don't exist in the real world. True, there are programmers out there who seem to wake up with a keyboard in their hands, spend the day coding, and go to sleep only to dream in more code. But those folks are not us, and we need to understand where our bodies and minds can take us and when they need rest.
-
-Our bodies require down-time in order to be most effective. We need to step away from the keyboard and allow ourselves to come down and relax. Our minds are not designed for constant work, especially at the levels that computer programming requires. We need to step back and realize that we need breaks throughout the day in order to recharge ourselves.
+Our bodies require down-time in order to be most effective. We need moments where we can step away from the keyboard and allow ourselves to wind down and relax. Our minds are not designed for constant work, especially at the levels that computer programming requires. The sooner we realize we should step back and take breaks throughout the day to recharge ourselves the happier (and more productive) we will be.
## Taking a break
-Taking a break is more than just flipping to another application. I know my tendency for taking a break is to start checking email or head to one of the various chat programs I have in order to catch up on what's happened since I last took a break. But this is not really taking a break as it is trying ti multi-task at my desk. Real breaks require getting up from the computer. It doesn't have to be a large break; taking a break can be as simple as standing up and walking from your workspace into another room or area. But you you need to stand up from your computer from time to time and get a "context switch" (where your mind can feel like it isn't in the same place as it was earlier). It gives your mind the ability to completely switch out the context of the area you're in and allows it to focus on the new context and new input.
+Taking a break is more than just flipping over to another application on our computer. My tendency while taking a break is to start checking my email or open up one of my various chat programs to catch up on what happened since I last opened it (usually since the last time I took a break). But this really isn't taking a break as it is trying to multi-task at my desk. Real breaks involve getting up from the computer. It doesn't have to be a large break; taking a break can be as simple as standing up and walking away from your work-space into another room or area. But you you need to stand up from your computer to get a "context switch", where your mind can feel like it isn't in the same place as it was earlier. Context Switching lets your mind completely switch out and flush out the context of the area you're in. It allows your mind to focus on new context and new input.
-This can be tricky in an office situation where the expectation is that one must be at their desks in order to be productive. And there are only so many "bio-breaks" someone can take in such situations. How can you give yourself the context switch your mind needs in such situations?
+This can be tricky in an office where the underlying expectation is that one must be at their work space in order to be productive. And there are only so many "bio breaks" (breaks that are related to matters of human biology, also known as using the restroom) someone can take in such situations. How can you give yourself the context switch your mind needs in such situations?
You might be able to achieve the same sort of context-switch by looking away from the computer display for a few moments. It's a good idea to look away from the screen every now-and-again to give your eyes a rest. Giving your mind a rest while you give your eyes a rest can give you the incentive to do both.
-Standing up can also be a good context switch where you give yourself more of a context-switch from the physical location of the computer. Telling yourself that there's two contexts around your desk: the context of sitting at the desk, and the context of standing at the desk you might be able to use that as the context switch and rest that your mind needs.
+Changing your sitting / standing arrangement can also be a good context switch where you give yourself a context-switch around your physical workspace. It can be as simple as just standing up and stretching from time to time, or as complex as raising or lowering your standing desk. Telling yourself that there are two contexts around your desk: sitting and standing at the desk, may be enough to give yourself the context switch and rest that your mind needs.
+
+If your workplace has a culture that allows you to step away from your desk and walk around then that would be a great context switch. Adding a physical component (as much as you are able) to your context switch can help your mind to relax and recharge.
-If you have a culture in your workplace that allows you to step away from your desk and walk around that would be a great context switch. Adding a physical component (as much as you can) to your context switch can help your mind to relax and recharge.
+You'll have to experiment with a few of these and see what works. At the bare minimum you'll want your mind to feel as though it doesn't have to be on all the time. You want your mind to have cool-down periods between coding sessions so it can flush the remnants of that session from your mental "cache" and into longer-term storage. Then when you get back to your coding session you'll be more likely to remember what was going on.
-You'll have to experiment with a few of these and see what works. At the bare minimum you'll want your mind to feel as though it doesn't have to be on all the time. You want your mind to cool down between coding sessions so it can flush it out of "cache" and into longer-term storage. Then when you get back to your coding session you'll be more likely to remember what was going on.
+You may also find that when you step away from the computer that you forget a lot of what you were previously doing. That's OK too. What I would recommend is keeping a journal or log of what you were thinking in as much detail as you need. Either write them on a physical piece of paper or use a text file to keep these notes so you'll have enough clues to allow you to pick up where you left off.
## Productive thinking
-Next we need to realize that productivity is not a constant. There are days where we will find ourselves generating remarkable levels of code and code quality and days where we'll be lucky if we can string together a coherent comment string. We have varying levels of energy and mental focus available to us per day. It's up to us to look at these levels and understand what our productivity might look like for the day.
+Next we need to realize that productivity is not a constant. There are days where we will find ourselves generating remarkable levels of code and code quality and days where we'll be lucky if we can string together a coherent string of words to add to a commit message. We have varying levels of energy and mental focus available to us per day. It's up to us to be mindful of these levels and understand what our productivity might look like for the day.
Understanding these swings of productivity can allow us to better gauge whether or not the day will allow us to generate the code that needs to be generated, but there's a level below that I think is important.
-We make attachments on completion and hitting deadlines. Some of these are external: the project dependencies require that we need to get this done by a certain date and time. But many of them are internal deadlines that we've set for ourselves. We set a goal for ourselves that we will be this productive by the end of the day. The unstated condition of this that if we aren't that productive we'll feel guilty and ashamed. We'll fee unworthy of the task at hand. We'll feel like our day has been wasted and wonder if we're capable of doing anything at all.
+We put a lot of emphasis in our day on completion and hitting deadlines. This emphasis can lead to us creating strong attachments to completion and deadlines. Sometimes this is warranted because of external factors (the "critical-path" of the project require us to get this done by a certain date and time). But many of our deadlines are internal deadlines that we've set for ourselves. We set a goal that we will be this productive by the end of the day. The unstated condition of this internal productivity deadline is that we'll feel guilty and ashamed if we miss the goal. We'll fee like we're not measuring up to our expectations and wonder if we're worthy of the task at hand. We'll feel like our day has been wasted and wonder if we're capable of doing anything at all.
+
+It's better for us to remove deadlines wherever possible. We won't be able to get rid of the external ones where folks are waiting on our contributions (though we may want to renegotiate those if they're not hard deadlines) but we can let go of the desires to hit arbitrary productivity and meet arbitrary deadlines.
+
+Arbitrary goals may work for some tasks. Some game contests only run for a week which makes teams focus on the critical pieces of the game in order to release it in the allotted time. But if you continually feel guilty and unworthy because you can't seem to meet the goals you set for yourself then you'll want to reconsider using them at all.
+
+One thing that I have found is to narrow the focus to the present moment using containers.
-It's better for us to get rid of deadlines wherever possible. We won't be able to get rid of the external ones where folks are waiting on our contributions (though we may want to renegotiate those if they're not hard deadlines) but we can let go of the desires to release this project on an arbitrary deadline.
+#### FIXME
## Containers
projects / themediocreprogrammer.git / blobdiff