Starting Coding Projects

It helps to ask it to first split the implementation into a plan and then to ask to implement each step individually. Also, it is faster to fix tiny errors on your own instead of leading it into it. Sometimes it also helps to redo the full process with a good task definition and requirements list. The code isn't ideal but it could be more inspirational than an empty editor when starting something new.

Though it sounds like the right way to go, my personal experience points to the exact opposite.I'm unfortunately cursed that I have a lot of trouble starting a problem till I really really understand all it's details and the details of my solution. I basically write down exactly what I want and am going to do on paperI find that my coworkers that start with a vague idea of what they want (without a complete understanding of the system) but work in quick hack->fix iterations pr

A thing that has helped me is, instead of starting to code or design, just starting a Word doc and putting all my ideas down. Sometimes you just need to get things out of your system, no matter if it's coding or writing. The advantage of writing a project outline is that it's easier to pick up later, since it's not a bunch of half-finished code. The second advantage is that it's easy to add on ideas spontaneously, since you just need to write them down instead of coding them. Third advantage is

Strongly agree. I often reach for pen/paper first and doodle a problem, just think about it deeply, poke at the shortcomings, think of scenarios where it might be inflexible, decide where not to over-engineer, etc before starting to write anything.

I don't get great results myself from diving into coding immediately. I personally get better results if I have some storyboards, workflows, ins/outs, etc. identified and worked-over first.But when I do get down to writing code, it very much takes an evolutionary path. Typically the first thing I start writing is bloated, inefficient, or otherwise suboptimal in a variety of ways. Mostly it's to get the relationships between concepts established and start modeling the pro

When faced with a big task and not knowing where and how to start, a trick I like is writing something crappy that is roughly a step in the right direction. For example, if you're building a web browser (huge monumental task), just load a page with your favorite http lib and display it, html tags and all. You know that none of that code will survive, but it's something that you can build on, and in due time you'll come around and replace it with the right design.

Just go for it straight away, don't plan anything, just start typing. Just keep in the back of your mind that what you're writing is a prototype. After a while of tapping away at the keyboard (minutes, or hours, or days, ...) you will suddenly see the problem in a much clearer way.At that point don't be afraid to:1) Rewrite large sections of your prototype where your initial assumptions were wrong2) Start againOnce you feel you've got a real handle on the proble

Set time aside where you won’t do anything except your task. Even 15 minutes helps. No big deal spending 15 minutes on something, right? Get a stack of sheets of paper and a pencil. Start laying thoughts down, some bullet points and a basic diagram. Imagine a bit how you’d implement it. Concurrently open a text editor and type some code sketches, non working code that carries a bit of the structure you’re thinking about. Go back and forth between paper and code, diagram, write down bullet points

I would recommend you try writing hacky code and then throwing it away and starting from scratch a couple times on the same project idea, just to see how it goes. It might teach you something.The people I know who regularly take this approach end up with a really fantastic code architecture in the end, and avoid a lot of pitfalls from their first naïve attempts.

From personal experience, start with something small (max a few 100s lines) but that can improve your everyday life (work or personal) so you can stick to it. Identify your need, think what functionality could solve it, then decompose the solution and read some doc.