How to stop thinking the design and start coding?

Question

I think it is laziness, thinking is comfortable and coding, well it pure hard work :). Does going offline increases productivity.
How to limit net browsing.
Do you think, Mutliple Screens (eq - Linux Desktops) help achieving productivty. Do many screen u think increases productivity, and how many make you feel lost, and you spend time remember which and where?

Answer 1

Nike has this right: "Just Do It".

Answer 2

Personally I need to alternate between design and throw-away implementation because it helps reveal issues that I may not have thought of on my own. At some point though you need to just get that first iteration implemented, or else you'll never get anything done.

Maybe set some basic goals that are easy to achieve for version 1, and then make improvements for version 2.

Answer 3

For me, i would do a small baby step by creating functions by functions, and then unit test those. This is similar to TDD.

Always keep small functions and do tests, and when it's getting complex, you can perform refactor.

EDIT:

Here is the reference http://stackoverflow.com/questions/107541/what-is-your-single-favorite-book-or-online-resource-for-getting-started-with-uni , if you would like to apply TDD in your project

Answer 4

I would "think" to a point where I get some high level clarity and the elements would glue well with each othen and then start to code.

Often the first cut is not the best. I would also try to write test code/sample code etc and continuously use what I built. This will give me insights into the user experience and makes me avoid building the outcome I would hate to use!

Answer 5

Put your ideas and design plans into a bug tracker. Give yourself the goal of closing as many bugs as possible per day. I think the key to successful programming is breaking down the large project into smaller manageable steps.

By using a bug or issue tracker you can force yourself into these small steps. If you enjoy programing, once you get started it is quite fun. For me solving bugs is sometime the most rewarding work. It is tangible and direct. I have this one little problem to focus on right now nothing else matters.

Obviously not all features or ideas or implementation details can be solved in one simple step. But that is where the prioritization comes in.

Answer 6

As a general rule, stop designing further as soon as you feel that the granularity you're reaching would overlap with code. Otherwise after a few weeks or months, your design documentation (as design is mainly documentation after all, no matter using UML or something else) will certainly tell something different than the actual code under development, and don't forget that at the end, the only truth is what the code "says".

That said, don't refrain from designing some particular parts in more details, maybe with a mix of code and diagrams, to address tough parts of your application (algorithms, maybe some design patterns, things like that).

In such a way, your design and your code should fit along happily for the entire life of your application : design providing the global frame, code telling all the details.

In fact there is a third pillar of the building, that is tests, especially automated ones. It's another powerful way to describe "what the application does".