Fear of Programming(rubyconf2008.confreaks.com)
rubyconf2008.confreaks.com
Fear of Programming
http://rubyconf2008.confreaks.com/fear-of-programming.html
6 comments
It's good to be thinking about what the right thing to be working on is. It's bad to feel the emotion of fear as you're doing this, because fear triggers your evolved instinct to stop giving your cerebral cortex cognitive resources and get the hell away from whatever is making you afraid. (If there's a car or wildebeest coming at you contemplating it in depth is not going to help you survive and reproduce.)
Playing strategic computer games like Civilization is a good way to convince yourself that you can make decisions about complicated stuff without feeling the emotion of fear.
Playing strategic computer games like Civilization is a good way to convince yourself that you can make decisions about complicated stuff without feeling the emotion of fear.
As someone who's created a number of open source projects, not many of which have even been the slightest bit successful (even though a few have), I can say that just throwing things out there is fine, but I always wonder how much more successful one of the projects would have been if I would have devoted all of that time to it.
I think that fear is the wrong way of describing it. I might be frustrated or annoyed by undocumented spaghetti code, or be puzzled about some aspect of a project, but I wouldn't describe this in terms of fear. If software development made me frightened I would have given up with it at an early age.
What else would you call the emotion that paralizes you into inaction?
Because that's what we're talking about here. The developer is unable to get started or continue because they are unable to take the next step. They are afraid to get it wrong.
The usual solution to this that I've heard is Research. Learn more about what you are trying to do so that you can eliminate the fear.
The solution I used when I was learning to program was to just jump in and start trying things. It's very time-consuming and more than a little stressful, but it works.
At any rate, ANY action is better than inaction when faced with programmer fear.
Because that's what we're talking about here. The developer is unable to get started or continue because they are unable to take the next step. They are afraid to get it wrong.
The usual solution to this that I've heard is Research. Learn more about what you are trying to do so that you can eliminate the fear.
The solution I used when I was learning to program was to just jump in and start trying things. It's very time-consuming and more than a little stressful, but it works.
At any rate, ANY action is better than inaction when faced with programmer fear.
Boredom? When I'm debugging someone else's spaghetti code it's not interesting or rewarding. It's mostly tedious bookkeeping that shouldn't even be necessary. It's the difference between compiling a custom linux kernel for yourself and removing malware for a friend. The former is intellectually engaging, rewarding, and fosters a sense of accomplishment in making something work. The latter is a tedious abomination that should have never happened.
The only times I enjoy spaghetti code is when I have to learn a tool or more about a language or library to debug or understand it. At least then I'm engaged and learning what to avoid and how to fix it.
The only times I enjoy spaghetti code is when I have to learn a tool or more about a language or library to debug or understand it. At least then I'm engaged and learning what to avoid and how to fix it.
I'd call it lack of belief in success and lack of belief in value of success even if it is achieved.
I don't agree when he says that knowledge is one of the most important things to combat fear. In my case learning just makes me feel better because I think I've done something towards the wrong direction. But often there is fear although you probably know very well what you're dealing with.
By the way, I found the "one fear gets replaced by a bigger fear" theory very interesting. It's a very logical explanation but I never consciously thought about it.
In this case, even though it isn't fun and sometimes very painful, I'd suggest a brute-force approach. Try as many ways as possible and discard all the drafts & don't feel bad about it.
By the way, I found the "one fear gets replaced by a bigger fear" theory very interesting. It's a very logical explanation but I never consciously thought about it.
In this case, even though it isn't fun and sometimes very painful, I'd suggest a brute-force approach. Try as many ways as possible and discard all the drafts & don't feel bad about it.
It is worth being able to tell between two types of fears - one that is genuinely yours and one that you've picked up from other people. Speaking for myself, I find quite a lot of them are of the second variety, which melt away when I ask this question. That leaves me with the first kind which is truly useful. The second kind seems to go with interested sounding warning phrases like "don't do this" and "be careful".
It seems very interesting talk. I guess it will be interesting for researchers in other areas. I will be watching tonight
I'm not really sure I buy the idea that any of these fears would be substantial enough to impact the allocation of time on programming unless the person in question had some issues to work out such as procrastination.
Afraid of what others will say? Don't tell them. The practice is still going to be worthwhile.
Afraid of not finishing? Break down the project into small chunks, write tests to make sure the small chunks work properly, and iterate between planning out the next steps and executing the next step in the queue (in theory, any number of subsequent steps can be added, removed, deleted, or re-arranged after executing any single step).
Afraid you won't know how to solve a problem? Which problem? Did you read the Wikipedia article and consult the relevant textbooks?
Afraid you're not working on the right thing? First figure out what the right thing is, and justify why it is right. If you're working on anything else, stop. Now start planning how to approach the right thing. You are now working on the right thing, for a discussion on when to transition to coding, see Code Complete.