When I program, I tend to hack things out rather than follow some set plan. The reason is because I’m not very good at writing plans yet. If I try to make a plan, I end up questioning everything and never get anything started, let alone completed. It’s known as analysis paralysis. Basically, you become so afraid of doing something wrong that you end up not doing anything at all.
So I hack. In this way, I’ll have something to work with. Maybe when I started I was clueless about the problem domain, but every moment I spend taking actions means I learn just a little bit more about what I am doing. Some planning can be good, of course, but if I don’t know what I am doing, there is only so much I can plan. Hacking is like chipping away at a stone.
Of course, hacking only gets me so far. By definition, hacking means I am blindly working, and so I can expect to hit a wall or two. Sometimes hacking allows me to make a lot of progress quickly. Other times, I can’t seem to figure out how to do what I think I need to do. It’s at those points when I start to doubt my abilities. I begin to think “I might not be able to do this.” Eventually it can become “I can’t do this.”
So how do you deal with “I can’t”? I realize that such thoughts are due to doubt. It’s kind of funny since the point of hacking, for me, was to avoid not knowing what to do. So to have more productive thoughts, I change “I can’t” into “How can I?”
“How” is much better because it forces you to think. Whenever I start to question if I can do a task, I always ask myself, “Well, how would you do the task?” It puts you into an entirely different level of creative thinking, and I’ve found that being creative is always motivating.
For example, I was working on a project recently, and I hit one of those walls. I couldn’t figure out how to design some classes to get the kind of behavior I wanted. Up to that point, the code was flowing, and then…nothing. So I started to ask “How can I do this?” And I started getting detailed. What is it I am trying to do exactly? I know the basic idea, but how do I get from here to there?
I suppose you could say that this is the kind of thing I should have done in the first place. If I knew I would have had such a problem, I probably could have prepared for it. Since I didn’t, I think what I’m doing will help me gain the experience I need. Eventually I’ll be able to anticipate all manner of problems, but for now I’ll have to hit those walls before scaling them. The important thing is that I don’t hit that wall and decide that I’m permanently stuck.
Edit: It seems that Steve Pavlina’s article for today also covered this topic, but in a more general sense. Check out How to Squash Negative Thought Patterns for a good way to change “I Can’t” into “How?”
5 replies on “Dealing with “I Can’t””
I tend to do this alot. I’m always worried about the “right way” instead of just doing it. You’re partly to blame… no not you specifically GB, but almost every programmer I talk to. When I need help with a problem, I always get people telling me I should have done it this way. Or I need to know this or do this. So basically people need to stop telling other people what to do, instead help them, decide not to help them, or simply state you don’t know. [end rant] — Okay sorry for that GB.
In any case, hacking is the way to go about it. Planning is knowing what not to do, and writing down the opposite. How are you going to know until you do it? I’m sure most people have heard the Thomas Edison story, where some guy asked him if he failed several thousand times and where he replied “No but I found X times how not to do it” (obviously i’m paraphrasing here, as I don’t have the exact quote handy) — but essentially he wasn’t planning it, he was trying different things till something worked. And that’s often how you have to do it. Only then will you be able gauge your work, to hopefully “plan” for the next time
Keith
I am reminded of two great quotes from Winston Churchill:
“Success consists of going from failure to failure without a loss of enthusiam.”
“Success is not final, failure is not fatal: it is the courage to continue that counts.”
I suggest hacking and getting features working in the simplest way possible rather than trying to pre-design a complex system that may or may not work.
There is the risk of spaghetti code, but its also relatively easy to refactor if you do it early and often. If you are running into problems with design you might want to try test driven development (http://www.gamesfromwithin.com). Its a little to formal for me to seriously do it, but it seems to force you to develop what you NEED rather than what you think you need.
You seem to get stuck on design issues rather than implementation (algorithms, etc.) For a lone programmer, getting stuck on implementation is much more difficult than getting stuck on design. You can work within a hacked design if you know the codebase, if you just don’t know how to do something, you’ll have to learn it, which can really slow you down.
I still think you kind of need to force yourself into a mode of development where you don’t need a complex hiearchy of classes to implement player-ball collision. Write the simpliest thing possible and make it more complex as necessary.
Keith: I think I know what you mean. In C++ channels on IRC, I’ve seen people ask for advice on outputting strings. The advice will almost always be about string streams. I know that I’ve never used sstream, and I’m sure that if the advice was for homework that the student isn’t likely to use it either.
Impossible: As for TDD, I think I might try it for my next project. I liked what Noel Llopis had to say about it. And the architecture I’m experimenting with now is only complex when I’m trying to code the engine, and it’s really only due to my inexperience. The concept is relatively simple. Once it is up and running, adding entities and interactions between them is a breeze.
I’m a big advocate of the use of hackery when it comes to code — especially if the project isn’t too complicated overall. One thing worth warning against though is hackery in design of the game itself. This, combined with feature creep (the two are intertwined) will stretch a game’s implementation from 4 months to 10 easily.
If you sit down to start coding and the game itself has a complete design, your hackery will at least be well guided by the big picture — even if only subconsciously. If, on the other hand, you find your previous hackeries to be incompatible with features that you’re in the middle of implementing that weren’t even considered in the original design, you’re in a quagmire of doom. I’m learning these lessons the hard way… : (