Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are times when working on my programming projects, and I get to a point where I'm ready to move on to the next part of my program. However, when I sit down to implement this new feature I get stuck, in a sense. It's not that I don't know how to implement the feature, it's that I get stuck on figuring out the best way to implement said feature. So I sit back for a day or two and let the ideas ferment until I am comfortable with a design. I get worried that I may not write something as well as it could be, or that I might have to go back and rework the whole thing; so I put it off. This is a big reason why I've never really finished many personal projects. Anyone else experience this, and how do you keep your self moving forward in your project?

share|improve this question

8 Answers 8

up vote 7 down vote accepted

My advice is to not get "stuck" on trying to come up with the best way to do something. Just do it! It might totally suck, but the bottom line is that you still did something. Nothing trumps experience...so just do it and learn from your mistakes.

share|improve this answer
    
+1 and you probably will rewrite it anyway :) –  Maglob Jan 31 '11 at 10:17
    
I agree, although a day or two of pondering the best way to re-implement something can be very good and improving the code in the long run. A lot of people believe they need to ouput x lines of code everyday to be productive, when some of the best coders put out 'less' code but which is much higher quality –  Patrick Jan 31 '11 at 18:03

Actually, writing it the wrong way and then having to go back and rework it can be a good learning experience. We can sit all day and think about the best way to implement the feature, but that's not going to be nearly as informative as actually writing the code and observing how it works.

So just go with your first idea and see how it works. Learn what's right and what's wrong. Then you can rework it or rewrite it as necessary; it will be easier the second time because you've got experience.

share|improve this answer

I would say write an acceptance test (BDD/TDD) to confirm the feature is complete and then write the simplest possible solution and when it comes to times to refactor you have the confirmation of the acceptance that you have not broke it

share|improve this answer

This is the same problem I've been having. It's a personality disorder. I'm trying to subscribe to the Sit down and do it philosophy. It's difficult, as it results in some refactoring. BUT, in the same time that I could've done nothing ("thinking"), I've accomplished something, and have moved the development forward.

This usually happens when the specifications aren't properly spelled out. Since we're single-developers we set the specifications, and have too many options. Just nail one down (the first one the comes to mind) and go with it.

I've had many times where I forced myself to sit down and implement Option 1, only to realize (from actually using Option 1), that it's a bad option. I had to discard all changes and start over. But there's no way I would've known unless I implemented it (or could've guessed how and where it will go wrong in the future - very difficult without tight specification and a crystal ball.) But in the mean time I've programmed something, and know the result won't work. Vs. spending that day thinking and accomplishing nothing.

Also, if you're overworked, don't confuse it with "thinking" about a solution. If you need rest from programming and the development-cycle, then take a break. Don't do any active thinking. Just write a short to-do / "what I was thinking" before you take the day break. Set an alarm in a few days to start back up, and program Option 1. Refactor. Discard. Option 2. Next.

share|improve this answer

Two strategies: 1) work on other parts of the project while you give that one time to "stew". 2) Write something you can live with, even if it may be sub-optimal. I prefer the former as a rule, but sometimes decide I can live with the latter, at least for a short time. Frequently, especially after users play with things a bit, it turns out the whole general area needs enough revision that the general direction I was thinking would be better is entirely irrelevant.

share|improve this answer

I do
I try to avoid writing code until it seems perfect. Once i realized that almost any personal project (if it's big enough) is doomed to endless evolution, so i decided to focus on creating a library of useful classes: animation manager, custom event subsystem, some uis, wrappers for playing media etc. And from that moment every time i need to implement anything - new features or projects - writing new code and creating new entities comes along with evolution of my beloved lib. By the way i'm going to share it when i consider it perfect ;)

share|improve this answer

As someone said, Just Do it - You will have issues and challenges but keep moving forward, everyday implement very small feature and see it working, this will give you lots and lots of motivation to keep going.

I need to see some success, does not matter if it is small one also, to keep me motivated and moving.

Never ever give up.

share|improve this answer

Write a simple/naive implementation that works. Hard code stuff if you have to. Check in the code. Then refactor it to make it nicer. Or, if you like it, write some tests before refactoring.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.