That might not be the kind of answer you wanted or expected, but believe me, taking it slow and working for the future will net the most efficiency in the long term.
The way to write less code is to (a) better understand the problem and (b) have a mental toolbox full of good tools you can apply in different situations.
For (a) you need to delay coding - which admittedly really hard until you have a good picture of how you want things to work. For me, when I'm in front of the computer, I don't think as deeply as when I'm away from the computer. Many of my aha! moments come when there are no distraction like when I'm in the shower laying in bed before I get up.
(b) Is just study, curiosity and research.
Would you say you were able to write less code (perhaps reuse more code)? Were the productivity savings mostly on the fact maintenance costs are lower?
As far as more code reuse, the tools I mentioned don't affect that. A good rule of thumb is not to write the same code twice. If you write it a third time, move it into a reusable function. I actually rarely write the same code even twice.
So yes, most of the savings come from 1) not having to debug and 2) not doing maintenance until I want the code's behavior to change. With great static analysis and a type system, you might spend 5x more time writing before you run your code the first time, but it always just works when you do run it the first time. It's amazing.
This is a famous talk by Rich Hickey that will discuss some of these issues much better than I can:
https://www.infoq.com/presentations/Simple-Made-Easy
(Video on the left)
