I used to spend most of the time on understanding the problem clearly. Once that is done I will spend my time on naming the variables and functions I am going to use. Generally I take more time on this area (naming). Based on the problem will draw a rough draft of sequence diagram. I follow this always. It helped me a lot.
If an engineer is operating at their very best, most time would be spent in designing.
Rolling back a few years in time, I used to work on a platform where a team of engineers took 2 whole months to just design the schema of a particular object. It was shot down by the CTO, they went back to the drawing board and came up with another design a month later. The office hours were spent debating the schema and trying to break the workflow and coming up with potential issues that the schema can cause. When the design was finally agreed upon, it took 4 days to write code. The system is so stable right now and their support ticket numbers are in single digits. During my initial days there, we used to jump into code without thinking a lot like morons. Our support ticket numbers used to be in triple digits back then.
So, taking time in designing things is absolutely vital. Spend 80% of your time designing and 20% of your time writing code.
It is a tough call to make. It comes with experience as to how much planning and brainstorming is needed to solve a problem and write the code to solve it. It is one of the primary reasons why just coders do not exist, but exists a big system of project management and system architects. They would generally give guidance to the overall flow of solving the bigger problems and tackle pipeline issues - concept to reality.
On a microscale, it mostly boils down to experience. Where most junior developers would scratch their heads, the senior devs can sail through smoothly. Sometimes, it makes sense to take time out review code and plan it out, sometimes it makes sense to get that big cup of coffee and start the coding grind.
One should focus on strengthening their skills to identify and solve problems and build an efficient system for the same. I personally keep a whiteboard handy to my seating area. I write my problems out, and start by process of elimination for solutions not feasible.
Programming is more about planning and brainstorming than actually typing.........once yu got the algorithm yu just need a mug of coffee and a headphone and of course some IDE..........
Writing code is not job of typing. It's art of thinking.
Two ways, actually.
I would say about 90% of the time planning and 10% writing code. Even that is probably an overestimation of the time spent writing code.
Gergely Polonkai
You have to believe in things that are not true. How else would they become?
As I get more experienced, the planning time goes up, but it still hasn't reached 30%.
I'm the doer kind. I like to get my hands dirty both figuratively and literally.
Unless I do something no one else did before me, I just read some examples or an actual implementation, and start coding. Well, unless…
There are times when I know the stakes are high. Some design decisions are hard to change later. In those cases I do a lot of planning, analysing possible outcomes, checking with the budget and the other devs. I ask for opinions, look for possible solutions, and so on, which might take days or weeks. At the end of it, the coding part will come so easy it will take a fraction of the planning time.
As you see, this is all a matter of circumstances. If you have the time and budget to experiment, and you are a learning-by-doing type like me, you will experiment a lot.
On the other hand, I know a lot of people who do the opposite. They plan everything down to the smallest bit. Some of them get so tired of the problem at the end of planning they will outsource the coding part to someone else.