[hsitz]

"Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging."

This part of your post is correct. If you don't spend much time coding then you don't have much reason to use Vim. ON the other hand, for those "fake" software guys who do spend a lot of time coding, especially editing code, then . . .

[rebootthesystem]

There have always been at least two camps in software development, and I'll throw in hardware in there due to FPGA's.

One goes to code right away and just hacks their way towards a solution.

The other camp is one where the problem is well understood first, design is done "on paper" and coding is simply the embodiment of that design process.

I say "on paper" because today it is likely to be a set of software tools such as state-machine editors, Excel, CAD, MATHLAB, etc.

It is my opinion that to write bug-free code that solves the problem efficiently, elegantly and as close as possible to on time and budget one has no choice but to design first and code as the end-result of the design process.

That's not to say that sometimes you need to write some test code as part of the design process in order to understand what might be going on. This happens a lot in embedded systems. Another scenario is web development where you need to interact with an API a bit before you can really understand how to work with it.

So I am not proposing not coding at all. What I am saying is that those code experiments are part of the "First Seek To Understand" rule (from "The 7 Habits...") that will make the project a success. The code experiments don't seek to solve the problem but rather add knowledge and understanding to the design process that will form the foundation for the actual solution.