3 ms·
For personal side projects, I spend at least 80% of my time thinking about the code that I'm going to write, 5% writing it and 15% reading it. The more experie
by jondubois 7y ago
For personal side projects, I spend at least 80% of my time thinking about the code that I'm going to write, 5% writing it and 15% reading it.
The more experienced I become, the less time I spend writing code and the more time I spend thinking about it and drawing diagrams on paper.
Coding should not be the bottleneck. The bottleneck should be deciding what solution to choose because there are usually a lot of factors to consider and it takes a while to identify all the main ones. It's not unusual for me to spend multiple days just thinking through different technical solutions without writing any code.
IMO developers who commit often and too many lines are juniors. Most of these lines will have to be rewritten because there wasn't enough thought behind them.
- seanmcdirmid 7y agoCoding is also a way of thinking. Too much planning up front also has a name (water fall?), the other option is to write now to get understanding and rewrite later as that understanding accumulates (I think that way if working has a name also). Of course, there are many kinds of valid working styles in between. I personally would rather see juniors write, make mistakes, and rewrite than just be paralyzed with thought/planning anxiety, which is perhaps more effective for more experienced developers.
- adrianhel 7y agoI like to plan by coding prototypes. It depends on the task at hand, but for certain problems it can be nice to create a new branch or repo even and test out my ideas. I'll often write sketches on my phone too.
- jondubois 7y agoYou don't necessarily need to plan everything up front. You can identify critical decisions points within your project as you go along. Personally, I try to keep interfaces between modules as simple and restrictive as possible (as simple as they can be while still meeting business requirements) but I keep the option open to add more flexibility/complexity later if it turns out to be absolutely necessary. Often it turns out to not be necessary. Having simple and restrictive module interfaces is extremely valuable if you can figure out what the right restrictions are.