Copied from InformalHistoryOfProgrammingIdeas:

''Functional Programming: This is very similar in concept to the "mini-language" technique. I've frequently found that an understanding of how processors work internally; how operating systems are typically organized; and how compilers do their jobs, has enabled me to implement solutions with less actual code by designing a language to represent a virtual machine with "instructions" which represent atoms of solution in the problem space. This follows right along with the second point about chaining small chunks of solution together to make a big solution, it's just slightly more formalized.''

I find that I tend to do something similar, although I would not call much of it "functional programming". It is a technique orthogonal to FunctionalProgramming in my opinion. I try to make routines or functions that solve the task at hand without clutter in the way. If it does not '''resemble pseudo-code''', then it is time to re-study it. I write or imagine the same thing in pseudo-code, and then study the difference between that and the suspicious code. 

I often don't try to make them generic, for some things are truly task-specific and trying to make them generic is a waste of time or risks the FragileParentProblem. Of course, one should always keep their eye out for opportunities to make generic thingies, but I tend to find many task-specific things are an unlikely candidate. Perhaps use generic libraries to construct the sub-language elements, but hide non-relevant details from the sub-language user/section.

''Generic doesn't necessarily mean generic across all programs.  A generic routine may only be used by one program, but used a lot.  Generic really means the function was meant to represent an atom of the problem solution, an abstract unit that represents a block that can be combined with other blocks to solve problems in the domain.  Generic is a way of saying this "thing" represents a chunck of the problem domain.  I think many people's objection to abstraction is because they misjudge the scale at which abstractionists like work, or a lack of knowledge of how abstraction is actually used.''
-------------
See also: HowImportantIsLeanCode, QueryAndLoop