Typing well and being fast with the tools changes the code you end up with, not when you end up with the code. It drives the “activation energy” for trying a different approach, or fixing some structural flaw that’s on the bubble of being “good enough”.
People who can tear down and rebuild a piece of software quickly and fearlessly just try more things, just like mechanics who can rebuild an engine have usually have higher performance cars than the rest of us.
It is obviously not a substitute for thinking deeply, but it can be an aid to thinking deeply.
And outside of some rarified hyper-elite of Thompsons and Carmacks or something, thinking deeply is not a substitute for trying a lot of things.
Now time is finite, and learning to type properly or mastering your tools might not be the highest ROI at a given time, but this meme that “I can type faster than I think so I’m not bounded by typing” (which may not be your view, but you’ll agree is often said) is misleading bollocks that young hackers hear and often heed: which is setting them up to settle for less than their potential.
Maybe just different styles and approaches and typing speed is a easy, obviously, and measurable metric to focus on but this sounds like brute force problem solving. I tend to prefer to build a mental model/plan such that once I start writing the first draft is probably within 90% of the final, some iteration taking place on that last 10%. But I don’t write and delete large swaths of code. This sounds like real time refactoring/lack of planning and completely erases any gain I’d get from being able to type twice as fast (I’m probably middle/average speed).
To use your mechanic analogy, the difference is the mechanic is confident in his abilities to tinker. The confidence is built on having a plan and some background knowledge. When he disassembles a carburetor he already knows the performance tweaks he’s going to make and how he’ll reassemble it. He doesn’t just start taking things apart with no plan, or start playing swapping on and off a handful of carburetors to see which performs best. He probably did his research and chose the carburetor/mod that was appropriate. It’s actually even more important with the tangible world because he has to plan and acquire the parts and tools before getting started or risk having a bricked vehicle for some period of time.
Non-mechanics know better than to tinker at all because they’ll likely break something they can’t figure out how to fix. So they might do low risk things like put high performance fluids in, or air filters, but they’ll never match up to the guys that have upgraded the mechanical systems.
While true depending what’s meant by the “best” way. I feel like I can mostly do this mentally without typing it out. I utilize my experience instead of a try and see approach. I know what not to try.
Trying many things is usually far beyond an acceptable threshold of diminishing return. Premature optimization and such.
That’s not to say I am unfaltering, sometimes things don’t work out and I need to rethink it. But I don’t approach a problem with this approach of trying a bunch of stuff.
Comments
Typing well and being fast with the tools changes the code you end up with, not when you end up with the code. It drives the “activation energy” for trying a different approach, or fixing some structural flaw that’s on the bubble of being “good enough”.
People who can tear down and rebuild a piece of software quickly and fearlessly just try more things, just like mechanics who can rebuild an engine have usually have higher performance cars than the rest of us.
It is obviously not a substitute for thinking deeply, but it can be an aid to thinking deeply.
And outside of some rarified hyper-elite of Thompsons and Carmacks or something, thinking deeply is not a substitute for trying a lot of things.
Now time is finite, and learning to type properly or mastering your tools might not be the highest ROI at a given time, but this meme that “I can type faster than I think so I’m not bounded by typing” (which may not be your view, but you’ll agree is often said) is misleading bollocks that young hackers hear and often heed: which is setting them up to settle for less than their potential.
Maybe just different styles and approaches and typing speed is a easy, obviously, and measurable metric to focus on but this sounds like brute force problem solving. I tend to prefer to build a mental model/plan such that once I start writing the first draft is probably within 90% of the final, some iteration taking place on that last 10%. But I don’t write and delete large swaths of code. This sounds like real time refactoring/lack of planning and completely erases any gain I’d get from being able to type twice as fast (I’m probably middle/average speed).
To use your mechanic analogy, the difference is the mechanic is confident in his abilities to tinker. The confidence is built on having a plan and some background knowledge. When he disassembles a carburetor he already knows the performance tweaks he’s going to make and how he’ll reassemble it. He doesn’t just start taking things apart with no plan, or start playing swapping on and off a handful of carburetors to see which performs best. He probably did his research and chose the carburetor/mod that was appropriate. It’s actually even more important with the tangible world because he has to plan and acquire the parts and tools before getting started or risk having a bricked vehicle for some period of time.
Non-mechanics know better than to tinker at all because they’ll likely break something they can’t figure out how to fix. So they might do low risk things like put high performance fluids in, or air filters, but they’ll never match up to the guys that have upgraded the mechanical systems.
Sometimes times the only way to know which way is best is to try all the options.
While true depending what’s meant by the “best” way. I feel like I can mostly do this mentally without typing it out. I utilize my experience instead of a try and see approach. I know what not to try.
Trying many things is usually far beyond an acceptable threshold of diminishing return. Premature optimization and such.
That’s not to say I am unfaltering, sometimes things don’t work out and I need to rethink it. But I don’t approach a problem with this approach of trying a bunch of stuff.