Sometimes I stare blankly into space or sketch ideas and write some pseudo codes on paper. Then I scratch it out and start again, then when I think I have the correct solution for the problem I begin writing the code.
Is it normal to think for days without writing any code? Is this a sign that I am approaching the problem entirely wrong? It makes me nervous to not getting any tangible code written in my IDE.
Depending on the problem you are trying to solve, the design phase can take weeks and months (if not years), not just days.
It takes experience to not start bashing out code immediately. Thinking about the architecture and high level design should take days if not longer - definitely something that should happen before you start writing your code.
This is commonly referred to as "Analysis Paralysis"
It's common but wrong. At some point you need to test out the various ideas to see what will work best for you, then incrementally improve on it.
Recommended reading the Pragmatic programmer Specifically Chapter 2 the section on "Tracer Bullets"
This is completely common. However if you take a "Test first" or TDD approach, it is less common and might help you formulate your ideas better.
Habits are usually a result of trial and error approaches to things and continuing what gives us the desired results and avoiding what doesn't. Doing what we like and avoiding what we dislike comes into play as well. That works up to a point because eventually, we'll do something we don't like in order to get the rent paid.
It depends what lead you to this and your reasons. Here are a few:
Hopefully, you've discovered that if you design longer, your code is better. If you can look back and see that it doesn't matter how long you spend on design, you may want to change. Another consideration is how often you are discovering problems after you've written code compared to working with your designs. If you are not finding issues until after you write some code, you should consider a balance and get to coding something sooner rather than later. Maybe this approach could be applied to the use of newer technologies or a very complex feature.
I don't know if I have the discipline to stick with one approach or the other even when I discover one works better than the other. Sometimes I feel a need to go to the white board; others the keyboard.
It's very common and i feel it's a better way to handle and understand things. While working on a project, I get stuck many a times and it take a day or two to understand as to how can i approach it better. Even after the problem is solved, i wait for a day to pass. This makes me more refreshed and get going.
It's a natural phenomenon and good for a developer to intercept his mind time and between.
When I took a course in project management, one of the things the instructor related to us about planning, that stuck in my head, was that the rule of thumb that they taught in the military was to figure 1/3 of the time for planning. So if you had an operation that required you to be complete 3 months from now, figure on spending one month on planning before you start execution.
In my view, there are three approaches, each suited for a specific coding situation
I've seen a similar problem before so I have a pretty good idea of the patterns to apply, and its clear how the solution should behave and respond.
=> Use BDD/TDD starting from the desired solutions and working in to the code. (Ok, sometimes I cheat and write the a bit of code and then the test - kind of a nested 2. -> 1. approach).
I have a good idea of patterns to apply, but I'm not sure what the solution should look like.
=> Prototype to see what kinds of interesting things pop out. Move to 1. when I figure out which interesting things are desired.
I'm not sure what patterns to apply.
=> Think about it the problem and how the various ways of approaching the problem influence the code. Move to 2) or 1) depending on the outcome of that exercise.
In other words, the answer is the engineer's favorite: It depends.
Better to spend a month thinking and designing than to whip up a quick prototype based on a substandard design that you then have to beat into shape. Especially if you're on a team; once others start depending on your code it's much harder to implement a better design with a different API.
I agree with the other answers that, in principle, taking time to think through a problem/solution is a good idea. However, if you feel like you're stuck, I have a few recommendations for ways to get the planning process a bit more coherent:
Create design artifacts. So what if you don't write code? Maybe you just write down a journal of your thoughts. Or a sketch of a general solution. Or even just a really good summary of the problem that you refine over time. As you consider ideas and accept/reject them, keep a log of your reasoning on the subject. This way, at the end of the day you can still point to real-world deliverables as evidence of your labor.
Talk to people! There's nothing like having a living, breathing human being with whom to discuss ideas. If you think you're stuck, talk it through with someone. Grab someone--anyone!--and explain the problem to them. Sketch out your thoughts on how to solve the problem. Even if all they do is inhale, exhale, and blink for ten minutes while you babble, chances are you'll discover new insight just in the process of explaining the problem.
As Satchel Paige said, "Sometimes I sits and thinks, and sometimes I just sits."
I guess what he was getting at is that it's sometimes good to clear your mind since it may lead you to think about your problem in a different way. So, if you're not banging away at code you may come up with a solution or idea that might have evaded you otherwise. So, yes, it's normal and a good practice to not jump right into coding.
There are two ways I do this process myself. I create a folder where I have a text file and any drawings related to the project. I jot down my ideas there and try and save the entire thought process as best I can. I'll also create a scratchpad project where I can quickly test out simple ideas from algorithms to CSS layouts.
Program = Algorithm + Data Structure
IMHO, the design(problem solving) process totally rules. Implementation(technical issue) details follow and solve naturally.
Here's my thought case.
Starting from scratch First a rough idea of what you want is required. Try to get a list of some requirements, or create them. It should take a bit of time to figure things out here. Once you have at least a piece that you are confident you want, knowing most of the interface of that piece, then start coding.
Fixing a problem with existing code First of all, track through the problem. This might require some time of not writing real code (Some debug code might be written, but this typically won't be kept). Once you find the problem, depending on the complexity, start writing code to try and fix it. Little thought should be required once the bug is known. If the issue works out to be a major design flaw, see the next section.
Design changes/ major features This is most likely the one which will require the most thought. Thought as to preserving structure, backwards compatibility, etc. must be included. Thinking through for the best change could save a significant time, but typically for me is not more than a few days.
Adding a simple feature If no significant design change is required, then simply code in your feature, using some trial/error. This shouldn't require a ton of time in general.
I'm going to disagree with the consensus on this one. I'd rather start prototyping something as soon as I have even the vaguest written-on-a-napkin idea of how I want my system to work. It's nearly impossible for me to think of all of the little details that might cause problems unless I'm specifying things in a very precise way. If I'm just discussing design with people, it's too easy to just hand-wave around some of the more complex problems. Once I'm specifying things like this, it may as well be directly in source code rather than some other means of expression that's just as precise and formal but can't be compiled and executed.
It depends on what do you mean for "normal". Speaking about myself, I think code is a great learning tool. So, when facing a complex problem, I do sketches on paper but I also do some Test-driven coding. Code tells me thinks that a whiteboard can't say and vice-versa, and maybe the result is insight or the need to a couple more questions to the domain expert.
So the real advice is: "Use every learning tool needed to get closer to the problem definition", but also "remember that these are learning tools, so don't fall in love with them" both code and sketches are meant to be throwaway.
In this era of RAD and agile programming, you should start developing as soon as you can identify major parts of the system, details will come along. Since Softwares are getting bigger, focusing prematurely on every single detail will lead you nowhere.