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.

Does it happen only to me or is this familiar to you too?

It's like this: You have to create something; a module, a feature, an entire application... whatever. It is something interesting that you have never done before, it is challenging.

So you start to think how you are going to do it. You draw some sketches. You write some prototypes to test your ideas. You are putting different pieces together to get the complete view.

You finally end up with a design that you like, something that is simple, clear to everybody, easy maintainable... you name it. You covered every base, you thought of everything. You know that you are going to have this class and that file and that database schema. Configure this here, adapt this other thingy there etc.

But now, after everything is settled, you have to sit down and actually write the code for it. And is not challenging anymore.... Been there, done that! Writing the code now is just "formalities" and makes it look like re-iterating what you've just finished.

At my previous job I sometimes got away with it because someone else did the coding based on my specifications, but at my new gig I'm in charge of the entire process so I have to do this too ('cause I get payed to do it).

But I have a pet project I'm working on at home, after work and there is just me and no one is paying me to do it. I do the creative work and then when time comes to write it down I just don't feel like it (lets browse the web a little, see what's new on P.SE, on SO etc).

I just want to move to the next challenging thing, and then to the next, and the next...

Does this happen to you too? How do you deal with it?

How do you convince yourself to go in and write the freaking code?

I'll take any answer.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, Bart van Ingen Schenau, Kilian Foth, GlenH7 Dec 8 at 16:15

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
What is your estimate on the size of your project? What are your goals? Who will benefit from the project if it becomes successful? What kind of benefits? –  rwong Dec 24 '10 at 20:07
1  
@rwong: My primary goal is to extend my knowledge. I experiment on my personal project with different ideas, techniques, libs etc for the purpose of self-improvement. But I do wanted to build something with a real use case scenario and not just a mangle of unrelated prototypes. –  user7197 Dec 24 '10 at 20:32
1  
If you only design and never code, how do you even know if you design is going to work? Code either validates or disproves the feasability of a "design". Stated differently, it's easy to "design" by vague hand-waving, but actually implementing is usually a huge amount of work. It's sometimes frustrating, sometimes tedious, but ultimately, for me at least, fulfilling. –  Kevin May 16 '11 at 2:01
    
I answered this over 3 years ago, but as I'm re-reading your question, I'm wondering if this isn't a sign of ADHD (which I happen to have). I also struggle with what your question describes, and although what I answered does help me a bit, it is still extremely difficult. Russell Barkley explains why quite well: youtu.be/LyDliT0GZpE –  Mark Freedman Feb 6 at 20:55

14 Answers 14

up vote 5 down vote accepted

If the challenge for you is in designing and not implementing, maybe you need a different motivating factor:

If it's a pet project (not for work), I actually look forward to seeing it come alive, so designing it isn't enough for me. When you come up with your own pet projects, what's the goal? Is it for something you need to use? If so, you can use that as the motivation for implementing it. To see it work. To provide the functionality you were looking to get out of it.

Are you planning on making it available for others? A motivating factor could be seeing them benefit from the final product. They're not going to get the utility out of it if it's just in design mode. And if you plan on marketing it, use the fact that nobody is going to pay for your pet project while it's stuck in design mode, as a motivating factor.

When I work on my own thing, I take a more iterative approach than I could at work -- I don't worry about all the details before generating something. It may take longer, but 1) since it's only for me (or for someone who doesn't even know it exists in any form yet), then I have the flexibility to experiment and take my time. 2) I spend a bunch of cycles refactoring and learning better ways of doing things. On my own dime, figuratively speaking.

Ultimately, though, isn't the real satisfaction in seeing something come to life out of thin air? That's what does it for me. If that doesn't do it for you, unless your motivation is the final product, then I'm not sure I understand why you want to work on the pet project at all. If designing is what juices you, and you do that at work, you seem to already get the satisfaction you're looking for.

share|improve this answer

It's definitely not just you! I'm actually putting a project off right now.

Nobody can motivate you but yourself.

Create a realistic time-line and challenge yourself to complete each section on time. You have nothing to show for projects if they never get passed the design phase.

share|improve this answer

I can definitely relate to that. I love taking on the challenge of things I haven't encountered, but I have a hard time starting working on anything that I have already solved. The biggest thing I do is just force myself to sit down with a goal of getting X done and functioning. Usually once I get going I end up having fun and get more than done than I set out in the first place, but if I don't force a goal, ill just drft for hours.

I'm also with you in that this happens more at home on sidework than in the office. I don't know if its more distractions, being burnt from work or what...

share|improve this answer

I do certainly understand your frustration as I've been through it myself before.

Despite fearing some flames from the community as I know this isn't a great approach, I'll share my approach for side projects with you. Please note that this method works for me and I use it on medium/long term projects, I wouldn't do it for something small (as I usually have the motivation to finish it in one go).

Grab the whole project and break it into 'packages', each one consisting of parts that are going to interact with each other often. Then divide each package into small pieces (think a few hours max) that you can design and code.

Ideally you'd be able to complete each piece in whatever time you allocate for your side project for a day but that's not required (depends on the person).

Personally, I don't set myself up with an estimated timeframe for each piece because I just get dissapointed and demotivated once I fail that estimate, hence, I do not recommend that. Take your time but don't take too long either.

Now each small piece gets all of the stages in your normal development process, designing, testing, implementation and whatever else you need to do. The idea is to give each piece a good kick-start but not a full blown finishing touch, yet.

This keeps my motivation up because I know that after a couple hours of actual coding boring stuff I'll have more designing to do (yummy). Don't let yourself stray from your goals, just keep doing that dreadful task and it'll soon be over and done with.

After you've been through all of the pieces, look at the package. See how it works, what's it doing, review the whole package again. I'm sure there will be changes and tweaks, do those now. Keep the most vital information in your mind as you will need it when working on all the other packages. Keep notes too, they help a lot.

Go through each package and keep remembering all the others you did before, how is the new code you're writing going to interact with stuff you wrote a week ago? Don't be afraid to lookup stuff you've already written and maybe forgot.

Finally, when you're all out of packages, I usually let it go for a few days, give myself a rest and focus on something else.

Normally I'm itching to go back and start interwining the packages and do some playful testing, there's not that much more code to write and the goal is near, that's motivation enough for me then.

Hope this helps you with your endeavours.

share|improve this answer

You need rapid prototyping, at home.

When you apply the same level of professional rigor on a private personal project, it easily results in over-engineering.

It is perfectly acceptable to set a high standard for a personal project, but you must understand that you may not have enough resources (coding hours, in addition to your 8 hours of daily work) to make progress on the project.

What is the most essential goal in your pet project? To prove the usefulness of one of your insights? If this is the case, then trim down the project until it becomes a proof-of-concept project. Then, use rapid prototyping so that you can accomplish more with less coding time.

share|improve this answer

I guess it's just me, but I have the opposite problem. I usually have trouble thinking of all the details before I start writing the code and actually run into the relevant issues. Realistically, I usually have only a vague design in my head when I start coding something. My big challenge is getting myself to think of all the details and have a design upfront.

share|improve this answer
4  
Why has this been voted so high, it doesn't really answer the main question "How do you convince yourself to go in and write the freaking code?"? –  dan_waterworth Dec 26 '10 at 14:03
1  
@dan_waterworth: I think because a lot of people can relate to the answer. When I was a junior I also did the same thing, jumping head first into codding with no planning up front. I since then learned (the hard way) that is better to actually sit down and think before going to the typing stage. –  user7197 Jan 1 '11 at 13:39

I think problem is in incorrect goal. It look like that you set goal "design system". And then you do it well, and goal is reached. So one suggestion is to set another goal "implement system", but then it is more related to motivation and how you do it.

There is one other way that worked for me well: set initial goal as "deliver system to specific users" instead of "design system" or "make system". In this way, you won't be satisfied, until users get something valuable. And you do it well from beginning (including testing and other modern fancy stuff).

share|improve this answer

Apart from being indeed a matter of motivation, I think that a part of the solution can be found in combining the designing and the coding process. That's how I do it mostly. Basically it comes down to implement the basics of your design when you thought of that, and then move to the next step.

Eg : If I have designed my basic classes, I write them out and run some tests on it. Then I have designed an underlying database, I set it up and test it out. Next I have the methods and functions I need for getting everything in/out of the database, I go on that. The testing is done more easily as I have my basic classes ready already. And when I finally come to design the user interface, I have already a whole set of code ready to play around with.

Now this assumes you also design in blocks that are linked through interfaces. I don't know the expensive word for it, as I'm not a programmer by education, but you know what I mean.

Hope this helps.

share|improve this answer

I have always found that the original assumptions did not hold entirely and more or less of the original design had to be changed based on experience gathered while doing the actual implementation.

If you consider your design to be absolutely infallible and perfect after drawing some boxes, but before actually trying it out, I would consider you a perfect candidate for some project implementations.

Shipping is a feature. If you don't go the whole distance, you are just an architect.

share|improve this answer
1  
+1 Overall good, one concern architects have their place, "just an architect" sounds a little demeaning, unintentional of course. –  Orbling Dec 24 '10 at 23:54
    
@Orbling: Thorbjørn was refraining from (a whole lot more demeaning) architecture astronaut. –  rwong Dec 25 '10 at 0:10
    
@Orbing, could well be. How would you phrase the fact that you cannot do yourself what you tell others to do? –  user1249 Dec 25 '10 at 9:33

Things I do:

  • Put a big timer in front of me (can be in reverse mode, in chunks of 1 hour)
  • Force me to stay up until reached some goal (sometimes with a beer, I've found that a little alcohol helps)

Not always work, though

PS. I work from home

share|improve this answer

Then just write down your design ideas, publish it (in a blog), make your best to explain the problem and the solution you've come up to others.

A trick: write your explanation of the design as a literate program! :) Then you occupy yourself with the interesting part (your design ideas), but actually justify them with the real code you supply alongside.

And post the literate program as a presentation of your new ideas to others!

share|improve this answer

Judging by your question, your problem is that you seem to be reinventing the wheel. If you've done all this already, why do you need to do it again? Is there no framework to do it for you? If not (although this rather improbable), why not write one?

A key task in programming is not doing boring stuff all over again, but doing it once, doing it properly and then reusing it. Or even better: finding someone who already did it once and properly.

share|improve this answer

This is going to sound trite, but just start. You are probably going to need to open your development environment, so do it. You are probably going to need to define each of the classes in your design, and write out their method signatures, so do it. You'll need to start implementing the most important methods, so do it.

Usually around this time, I've forgotten that I had trouble starting, and I'm in the zone.

Works about 80% of the time. For the rest, there's Tetris.

share|improve this answer

I totally understand where you're coming from. It's the problem that interests you, and once you figure it out, implementation's just work.

Why don't you just architect the solution, and have others implement?

share|improve this answer