Don’t go crazy… rudimentary dev pratices
Writing code can be downright discouraging at times.
Like so many other things in life, there are times when you get everything right the very first time. You smile… and move on to the next thing.
Then there are times when nothing seems to works. The app breaks every time you introduce a new feature. (The saying “it’s not a bug it’s a feature” almost rings true here.)
These times, when nothing seems to work, show up fairly often.
Here are a few things that psychologically help me work through these “rough patches” in my coding experience.
I don’t think anything will ever make writing code “easy” so learning to deal with the inherent discouraging times is important.
Take a Break
At the beginning of this Ruby on Rails course at the Iron Yard, someone talked to us about how to survive the next twelve weeks of our lives. Or maybe it was my teacher imparting wisdom to me when I couldn’t seem to break through a brick wall of broken code. Either way, somewhere in there we were encouraged to take breaks from coding.
It is so easy for me to sit in front of my computer, whether my code writing is going well or not, and become an unmoving fixture in the landscape of my chair.
I find though that if I take a walk occasionally throughout the day, even if it’s just five minutes, the clarity that it can bring to my head is impressive. Occasionally I even figure my problem out while I’m away from my computer.
I’ve noticed the same thing is true with going to bed at night. Some nights I’ll be sitting at my “kitchen counter top” working on something and not getting anywhere. I’ll eventually decide that it just isn’t worth staying awake. Staying awake longer won’t really help in getting closer to the ultimate goal of completing whatever homework tasks need to be turned in the next morning.
On several occasions, during the night I’ll wake up and find that whatever I was working on is still on my mind. So, I’ll ponder it a bit. Once or twice during those moments of sheer clarity (or insanity) I’ll realize what exactly I was doing wrong. (The key here is to make sure you don’t forget it before the next morning. I’ve not gotten out of bed to fix anything yet.) For this reason I found Tom McFarlins article on solving problems in your sleep, interesting.
Take breaks man… schedule it into your day. Do it even if you don’t feel like you need it at the time.
And don’t forget to go to bed at night.
Positive Thinking Actually Works
I don’t believe that simply thinking positive will get you very far in most aspects of life. The reality of life is often not as good as we would like to positively think about it. (but then I tend to be a “realist…” much to the chagrin of friends/family at times.)
However, there is something to be said for having a positive outlook on life. Approaching things with the idea that, “I really doubt this will work” or “I just don’t know how I’m going to approach building out this feature in my application,” let’s just say that it isn’t a good state of mind to attack anything with.
It’s more than positive thinking, it is a way of life. Looking for the good in people, looking at the strengths that you know you possess, recognizing when you need to walk away for a while just to keep your sanity… these things will help you have a more positive outlook on life.
Not only will your perceived value of life be better, you will be a lot easier to work with. A recent post by John Saddington really drove that home for me. You should totally go read it.
Don’t be a bottom feeder. Get your mind out of the dumps, approach things believing that you can do them, but be honest if you don’t think you will be able to figure things out.
Be a positive person, don’t just think positively.
Talk To Ducks
This came from a talk from Tim Whitacre. He was here talking to us about the life of a programmer (or something along those lines) and mentioned a number of really helpful things. (Total side note here, but Tim is going to be teaching the Front End classes in Atlanta. First class is June 2.)
One thing that I didn’t immedietly connect to real life was the idea of “talking to a rubber duck.”
Here is the basic premise (and its so right). There are loads of times when a programmer gets stuck and finally asks for help. The first thing that is required of that programmer is to explain exactly what is happening in his code to whoever he is asking for help. Many times in completing that exercise of explaining how things are working the problem is found.
The concept then is this: walk through your code, explain what your code does to a rubber duck (I need to get myself one of those) and you just might find the answer that you were looking for.
Wrapping it Up
That’s it for today folks.
This of course is not an exhaustive look at how to psychologically approach writing better code. I’d love your input!
What tips for writing good code and keeping your sanity would you have for a programmer?