I go through phases where I spend far too much time stressing out over the best way to program something instead of just programming the damn thing - a trait I don't think is uncommon among programmers. So, does anyone have techniques for psyching oneself out so one can relax and let oneself code something which, while not 100% perfect code, is good enough?
I know the reasons why (believe me!)... I'd like to know ways of overcoming this mental block.
Actually, I think it is an uncommon trait - almost all programmers I've ever met were all to ready to jump in there and start hacking away!
Start on the easy parts to get the ball rolling. As you finish pieces, you can feel the momentum building up.
Tell yourself you are going to do some exploring in code and get hacking. Worrying that you're designing everything perfectly is stopping you from finding the solution. Don't even worry if you're going to code something to throw away the first time.
Overdesigning is a common mistake perfectionists run into. Realize that you'll have to iterate, and design loosely and modularly.
I know the feeling. I will put off a project because its hard or its intimidating -- and goofing off is just so much easier :)
So how do I get into a project? I cut out all distractions. Email, IM, turn off the phone and if Im developing on localhost, I unplug the internet. I even put up a big Do Not Disturb sign and put on my noise canceling headphones. It's amazing what I can get done then.
In addition, I'll just talk to my co-workers and friends. I'll let them know that I'm working all day on a project. After doing that, I get the feeling that they are watching me and holding me accountable. This can also keep me motivated.
I do the same thing, all the time. The problem for me is that usually there are so many good ways to do X that the design options are overwhelming. If that's the case for you, I would recommend going ahead and jumping into it.
You're never going to get it right the first time, that's why the waterfall method went the way of the dodo. Much more important is trying to stay flexible, so when (not if) you find you want to make changes, you can. This sets your code up to be maintainable, as well.
It will suck the first time. It will. Just get in there, and plan for changes.
When I am in a situation like this often I have a number of tasks to do/program I will do the easiest ones first, this allows me to be productive while still thinking about the design of the more complicated project/task. Additionally I always keep paper around to write down ideas as I get them.
Obviously this approach doesn't work for every situation.
When faced with this kind of block, I try to break the required work down into "micro-requirements". Then I look at each of those "micro-requirements" one at a time, and try to implement it without thinking about the rest of the requirements. After a while, I start to realize that I have a good portion of the work done, and the rest doesn't seem too intimidating. This technique works well with TDD, too.
I'll take unforgiven3's Prototype suggestion a little deeper and say that you should code an outline of the highest level containers (or components) of execution logic, so that you can visualize the main pieces. Then you will find yourself naturally refactoring as you go, deciding certain things belong in a class library, etc.
Start by thinking monolithically and then start expanding the number of components in the design as you reach a roadblock, like the fact that you need an additional thread or that you need to organize code centrally.
First off, I think it is a good idea to take some time to analyze the problem at hand, instead of just diving in and writing code. It never hurts to build a thorough flowchart in your head before starting to code.
As far as getting psyched for it, I would pick a "piece of the puzzle" that piques your interest the most and just dive in. After that piece is complete, move to the next relative piece. Once you get the ball rolling and have an idea of what it's going to take to complete the project, in full, write down a target date and try your hardest to follow it.
Chances are (based on my experience), you will not finish early, or even on time. The point is, once that date passes, it's real easy to convince yourself that you are procrastinating way too much.
Once you have a handle on what needs to be done, I think it's best to start coding knowing that you may begin refactoring almost immediately. You need to apply your knowledge to understand it. Every time you apply your knowledge and then refactor, you have learned something.
When I find that I need to do something difficult or I'm not happy with my planned solution for the problem I will divide and conquer. If there is stuff that I can trim away that I know I will use no matter what my ultimate solution ends up being, I will start working on that. While I'm working on that stuff I will try to break down the difficult part and work on some of that if I can. Again I will try to work on things that I know I can end up using.
When I go to sleep at night I will think about the things that I'm having a difficult time with, because I come up with some of my best ideas after sleeping on it.
If it gets close to when I actually need to work on something that I've been putting off and I still don't have a solution I'm happy with, I will talk to others about my ideas and get their feedback.
Almost every time that this has happened to me I have ended up with a simpler and better solution to the problem by waiting then I would have if I had charged in and tried to force a solution out of myself.
Sometimes when under a tight deadline you have to implement the poor solution and put in a better one at a later time.
You should to understand the main point, Its almost impossible to make something perfect, so take it as a fact, this is helping to relax, even it untruth :) .
Take some time before starting, to relax, don't code immediately. Only when you feel that "new task panic" is off, you can start to design and coding. Its take less then half of hour, but really help to the program future.(something like short walk, or relax music)
Never do big tasks, split him to the small tasks as much as possible.
Take a step back!
I don't even know how many times I was just not in the mood to do a job that was too dull or too boring, too complicated, or too something for me to want to do it.
Mainly, what generates my mental blocks are related to database work, I generally dislike working with databases, SQL or anything in that general direction, so every time I have to do some project that relies on databases, I go on a tangent, start finding cool new ways of not having to really touch the database.
I did this quite recently with a project where I am the one responsible for creating Business Intelligence Cubes for our call center performance report.
The way out is to take a step back, do a different project if you have to, something you like, this will give you some energies/enthusiasm to spend on the assignments you care less about.
So my advise mainly consists of taking your head out of the problem at hand, to have a different approach:
Take a step back, stop doing the horrible thing you don't want to do for a while
Talk to someone about how much you dislike/don't want to do it, hearing yourself whine will put you off your own lack of willpower and kick you into action
Finish the other project (there is always one) that you didn't finish before and its just lying there making mental clutter
READ, reading about the problem, (not just googling for a solution) but really doing some proper reading, again, not just filtering and searching for the direct solution, but reading:
In my case, I read books by people who like databases and SQL, from beginning to end, sometime in the middle I will feel like I don't hate the damn thngs so much any more, and better yet, the problem as I was seeing it before, is actually something covered in 101 basics xyz, pet talk near the Introduction of those books.
We all feel your pain :^)
It all really depend on the size and importance of the project you are working on. If it is something that is going to be quite important and at least moderately complicated, then proper planning and design is required. Just worrying about is not good enough! On the other hand, if it's something that you are coding for fun and relatively short, what is the harm in hacking at it right away?
Maybe you can start asking yourself how you developed this fear? Where does this perfectionist attitude come from? Are you like this just for programming or rest of the things you do too? If it's everything, I suggest looking at tackling perfectionism.
Perhaps you are afraid of having to change your code later on? One of the traits of a great programmer is that he/she is brave enough to code for the present and worry about changing the code later on if requirement changes/something else doesn't fit the model. Of course, the smart programmers will also learn from his and others mistakes; so, the more you code and make mistakes, the better understanding you will have the less mistakes you will like make in the future. The best way to learn from others is to read programming construction books and read/post on forums such as this one!
divide the project into things you know how to do and things you don't know how to do; for each, determine the next action to be done to advance the project, e.g. prototype a piece of it, read something, ask a question on SO, etc., then just pick whatever next-action you feel like doing (or pick one at random) and do it, then pick the next action for that piece and put it back on the list. Repeat until the project is done.
if your next-actions are small enough, you can nibble away at the edges while the details get filled in, and soon you'll discover that you've finished; this also makes it easier to do 'a little bit' when you have a spare hour without getting overwhelmed with everything you're not doing
and keep a development log for the project of what issues you encounter and decisions you've made, so you don't repeat yourself and can jump back into context faster
[yes, I'm a fan of GTD]
Start with the fun bit! There's always a fun bit somewhere. Once you're up and running and in the zone, that's half the battle won.
Stop worrying about what others will think about your design/coding decisions.
If you have reasonable programming experience you are not going to make many major design errors. But even if you do, performing the work in iterations means you can pick these errors up very early, and have a chance to refactor.
The biggest cause of stress over how to "best" build something is really just peer pressure. You are trying to second guess what another programmer will say about your code/design.
While this "different viewpoint" is useful to iron out obvious issues, perform this process just once on each new part of your design/code. Make any obvious changes, but then forget about it and get going on the implementation.
My mantra -- and I know some people will disagree -- is "code is flexible". There is no decision that you make that cannot be reverted at some later point.
Its called "Analysis Paralysis" and its not limited to programming. I have it very bad. I have just started implementing my strategy to deal with it which is to write down a "To Do" list and start with the items that are easiest. Ive been doing this for a few days and it is working. I have actually made progress and do not in any way feel that i am missing out on some grand ideas. Youll be thinking of "best ways" while you are doing the work and much of it could not have been anticipated by simply sitting back staring at screen and speculating.
I find that having my clients bitching away that they want it now! And at half the hours I've quoted the project at just sucks the "is this the right way to do this?" right out of me. (Really) Time is money. get 're done! Sorry - this is all I got.
If the project's getting frustrating, get away from the computer and do something else, maybe come back the next day.
When you're back, remove distractions. Close email, IM, etc
Then write down a list of TODOs of tasks to complete the project, cross them off as you go. If you discover you have 'sub-tasks', write them down too and cross them off as you go.
Crossing things off keeps you focus, and is very satisfying.
Meditation works for me. It calms your mind and clearing out the clutter that is causing you anxiety. Then, you can focus on enjoying the process of writing the code, without focusing on the end result.
I recommend the book "Mental Resilience" as a good, pragmatic introduction to meditation that mostly skips over any of the metaphysical/mystical aspects of meditation that has the potential to turn people off.
Visit the Loo :) !!!
I spend 5 minutes of quiet-time on the potty during which I prepare myself mentally.
I try to calm down and decide for myself that when I get out I'm going to go straight to my comp and jump into that code.
If you don't enjoy those soothing 'bathroom sounds' (or you don't need to poop), any quiet place would probably work just as well.
*You will not bother with step 2
Thank you, Astral Projection and Infected Mushroom, you have no idea have much you have helped throughout the years.
Think agile
"Make it run, make it right, make it fast, make it small" - Kent Beck
Write a prototype and/or test cases first, then you'll suddenly find yourself filling in the gaps
For me, it depends on the project. I try to start from small, independent pieces of software and build up from there, while ignoring the big picture at first. I'm not saying that it's the best thing to do, but it makes easier at the beginning.After all, there is a Chinese proverb saying: " A journey of a thousand miles starts with a single step".
What's usually helping me is to have good conversation with some coworker/friend. It has to be in person and away from computers. The thing is, it relaxes me and rarely go on for more than an hour (a lunch break) and sometimes you could even clear out some task challenges during the conversation. Too bad I'm working from home now and can't use that technique myself.
The other way that sometimes helping me is to have coffee/coca cola drink and some aggressive music in my headphones. But that's not as good.
Short walk outside also seems to be helpful. But it won't work if you're working in the city center or if the weather is awful.
The bottom line I think is - you have to relax somehow and cut off all the annoyances. But it's usually what's hard to do in the first place and there's always a danger of over relaxing :)
I first google in order to avoid "Reinventing the wheel" and reducing the time. Then I code expecting the worst inputs.
I find that giving a problem some good thought, then getting some code written help clear the head. The code doesn't have to be perfect right away (if ever), and further perfection tends to reveal itself over time. It's code. You can always make it better.
Build the thing from the bottom up... Use a dynamic language that's forgiving, like Python. Try things out in the REPL in small pieces and then glue the pieces together to form a whole. That's the essence of hacking!
Happens to me all the time - it's very common, so don't worry that it's something bad in you.
The most efficient way of getting out of such slumps for me is a bit of self-trickery. I convince myself to start coding "just for 15 minutes". So I open the editor and start writing code. After 15 minutes, chances are (99%) that I'm already into it so I keep going. This actually works very well most of the time.
Don't waste your time on projects where finishing them / getting stuff up and running does not benefit you in some way. If it does, the motivation to just write the damn thing will be there. Projects without such motivation are best worked on when you are really bored...
Perhaps your problem is that you are too concerned with details to realize the value of the finished project.
(by "benefit" I don't mean only financially of course)
Promise yourself it's just a prototype and you'll rewrite it later.
I find headphones and good music a good place to start. I have to admit I do things backwards most of the time and tend to start coding before I have a solid design. this leads to a lot of code being thrown away and rewritten, but I find if I spend to long worrying about the design like you say nothing gets done. I suposed its a case of finding a happy medium
Track your project like the big dogs do, with meaningful version numbers that serve as milestones for you. Your first try will never be version 1.0, it'll be version 0.1, an alpha release, and that is a-ok.
Tell yourself that jumping to version 1.0 in your first release violates the most basic development tenets. That should free up your mind to get cracking on version 0.1.
Just do a "good enough" design, doesn't have to be perfect.
"Shipping is a feature too" - i.e. part of design is getting it done, consider prototyping something out and let that morph into the development if it makes sense.
“Premature optimization is the root of all evil.” Start with a simple design, refactor later if is worthwhile.
Focus on some part of the problem, then make a list of some of items that can be done. Use TDD to implement them, then review the list items and implement more. At the very least you'll have implemented some of the project, possibly more than you realised.
Be prepared to throw at least one version away.
Relax - take walks during lunch or in the evening. Stress may be a driving force for some, others find it can drive them into panic.
Not that my experience necessarily mirrors your own, but I've found almost all my code to be one of three types:
When I get coding block it has never been blocking all three of those types at once, so I switch gears to keep coding.
I'm going to suggest something contrary to the general opinion here...
I don't see a problem with trying to get it right. Not perfect, but on fairly hard problem, spend a few damn hours on it so that the next 20 guys to read your code don't have to spend an hour staring it trying to figure out what the hell you hacked together.
If you are really really stuck and you don't feel your design is moving forward, you start with what you can do. Get it coded--even if it's a little sloppy, but just be prepared to delete it all and start over if you get to a dead-end.
At first it will seem a little painful, but eventually you'll notice patterns that work and some that don't and you'll become quicker at doing a much better coding job.
I guess I'm saying that at one point I just decided I'm never going to do it "Fast" when I can see that there is a "Right" way--and I've never regretted it.
Also, the "Right" way, more often than not, turns out to actually BE the "Fast" way.
Do not fool yourself that there's a way to stop perfectionism. I say embrace perfectionism, and I'll explain why I think perfectionism is a good thing.
It has been reported that 80% or more of software projects fail. There are of course a myriad of reasons for this including but not limited to failure to understand the scope of the project's requirements, lack of skill to produce high-quality software, lack of budget, change of focus by the client (e.g. your boss), and lack of sufficient research into the problem domain as a side effect of the omnipresent need to get the project to the market.
In my experience, the more one analyzes any given project's problem domain the better suited one will be to reason about it in its future.
Obsessing over the perfect solution to a project scales well with project complexity. One's understanding of the problem domain will be higher than those who simply start hacking away on day one. Thus, one will able to quickly consider the applicability and scope of new features, the possible reasons for reported defects, and other issues that might arise in the project's lifetime.
The majority of a project's life is spent in maintenance. "Getting it right" from the start could make maintenance a breeze.
There's an implicit tradeoff here between time-to-market/completion and "getting it right." This tradeoff can be at times black and white (don't choose assembler for your next desktop GUI project), and in other scenarios gray (build vs. buy). Experience in doing things the wrong way will also help you embody the lessons of effectively handling this tradeoff for each project you work on.
You are never alone. Many programmers suffer from analysis paralysis and try to build the perfect solution the first time. Check out the 37signals.com book, they have some strategies that might be fun for you to try out.
The thing I found was the most useful is to set yourself a short time limit.
Like 1 hour, maybe 2, at most 3.
The time limit should be short enough so that if you don't start coding soon then you will not get anything done.
Recognise that your code is more beautiful when it exists with imperfections, than when it is perfect with no implementation.
I often suffer from the same mental block, as do many.
What I normally do is bring up my specific programming problem at a weekly team meeting. If anyone else at my company has tackled a similar assignment, they can usually provide some insight as to what direction to try first. These meetings often get me started down the right path, but just as often the answer is "I don't know, just try something and see if it works." Either way it's helpful. If I get the "I don't know" answer, then at least I know that I really am up against a hard problem, and I won't get slammed in a code review because everyone already had a chance to weigh in.
Lately I've found that Stack Overflow is another place that's helpful to ask around to see if anyone else has had a similar problem.
I suggest doing some planning, such as making lists, flowcharts, and such. If plan in extreme enough detail, either one of the things listed below could happen:
You convince yourself that the task isn't as hard as you thought.
You find that the planning has made the task easier.
You have found that you put so much work into planning that it would be rather silly to not just do the whole darn thing now.
You find that you've wasted too much time planning.
Hopefully, you will feel something along the lines of one of the first three items in the list, and the planning will have helped you.
Just write it. Write it any old how at first, then after every 5-10 line refactor it into patterns (using resharper if you are .net).
** rant * Ughh! I’m surprised to be reading so many comments about just start coding on this thread, where I thought the caliber of developer is a little higher. I’ve had to fix way too many programs where the philosophy was something working is better than nothing, so just code it. Those are the programs where each fix creates 2 new problems. THAT IS the reason for the poor level of software quality out there. It is a deserved reputation. It is the attitude that allows software jobs to be shipped overseas without the dramatic loss in quality that one would expect.** end rant *
Back to the original question:)
I solved the answer to your question by establishing a personal methodology for developing software. I follow the process every time and improve what didn’t work last time. I then back fit it into the company process. Eventually the process becomes fairly automatic. I keep a checklist of steps so it is available next time as each step feeds into the next.
I think a lot of the reason for not knowing which design approach to take is because you truly don’t understand the problem at hand. You may think you know what it is supposed to do, but you don’t really know what the system is supposed to do. Thus, you are worried about making the wrong choice because you have a lot of what ifs in the back of your mind. I solve this problem by always starting with the Use-Cases. The Use-Cases make you define the problem and identify exactly what the system is supposed to do.
I don't necessarily follow the strict definition of a Use-Case, I make the Use-Case a tool for what I need to get my job done, not what the theorists say it is supposed to be. Through practice, I have learned to write them in such a way that the architectural design just naturally falls out with little effort on my part (if I wrote the Use-Cases correctly). Then each of the modules will either design itself, or I write some more Use-Cases at the module level to understand the problem further where it’s needed.
Since I adopted this approach, I can’t remember the last time I got stuck in the analysis paralysis phase. I also like my designs a lot better because there is a natural ordering and flow-down. And most importantly, the designs are easy to understand.
When i stuck on this stage, i tell myself following: Premature optimization is harmful. Finding perfect solution is a premature optimization. Make something working now, and if you are not satisfied, you can optimize it later.
I learned this trick from school
Try to get through three iterations of any significant piece of code for best results. Deadlines get in the way of this quite a bit, so beware.
To get me started:
To get me over the finish line:
the speed of your programming is related to the speed of the questions you ask yourself, so if you get stuck ask a different question, ask a better question, break a problem down into multiple questions, whatever it takes, just don't keep asking the same question over and over again.
I like to use a tool like Rescue Time or oDesk Team being able to see metrics of how much time I've wasted inspires me to actually create something.
Urgh. I am a terrible procrastinator. Here are my tips:
Make sure I've had just enough coffee (too much and i'll end up browsing the web with 50 tabs open)
Just do it for 10 minutes. Find some small task that you are confident you know how to approach and make yourself sit there for a few minutes to bust out a couple of classes. Someone else has already said it, but I find that after this period I usually have enough momentum to keep going.
If you are dealing with Analysis Paralysis, I have found it helps to not worry about doing it 'correctly' and just start hacking. As you continue to hack the 'correct' way will become clearer to you as you get a better grip on the problem at hand. Of course the more you do practice this, the more you'll find that your hacking instincts are closer to what the 'correct' solution is.
Refactor, refactor, refactor. This is related to the last point. Dont leave refactoring to the end. Do it whilst your coding. All the time.
Usually a combination of a few things will help to put me back into a productive mode:
Determine what is a reasonable minimal amount of work that can be done so that there is something to test and use. Do you need to build a class, a web method, a page, a control, or something else?
Break down anything too big to take more than a day and possibly get second opinions about your approach to have some confidence that you are going down a good path.
Accept that you are human and code is rarely uber-optimized.
Sometimes it helps to think about seeing the end user with whatever you are building and imagine getting that, "Thank you!" once something is done.
Commit yourself to giving a hands-on demo by the end of the week to the management team.
I think this is my biggest downfall as a programmer, and/or a person in general. Sad, but I make myself get around it. Sounds extreme, but I wouldn't be able to do it any other way:
I have a friend drive me to a Starbucks. I refuse to pay for internet so that eliminates that distraction.
I give the barista my iPhone so it doesn't become a distraction either (they know me, so this step is up to your discretion).
I have said friend leave me here for hours with nothing but my computer.
Begrudgingly, I get into it and start getting work done. It's weird, cause I even enjoy programming. I do the same thing with video games. I love to game, but I just can't bring myself to do it. Maybe I am a little bit more broken than you are.