Levels of abstraction

The other day I was .. "surfing the web" (which these days means looking at an endless twitter feed) when I stumbled across an interesting (and very long) post about a programmer's career and how to not screw it up, basically. One point Patrick made was about communication. Let me copy the paragraph and discuss it later:

Communication is a skill. Practice it: you will get better. One key sub-skill is being able to quickly, concisely, and confidently explain how you create value to someone who is not an expert in your field and who does not have a priori reasons to love you. If when you attempt to do this technical buzzwords keep coming up (“Reduced 99th percentile query times by 200 ms by optimizing indexes on…”), take them out and try again. You should be able to explain what you do to a bright 8 year old, the CFO of your company, or a programmer in a different specialty, at whatever the appropriate level of abstraction is.

Now, it's been clear to me for some time that communication is a really important skill if one wants to be a successful programmer, perhaps even more important than specific technical skills, but I'd never thought of it beyond learning to speak and write properly. Being able to explain what I do to most people, adjusting the "level of abstraction" is an interesting exercise. You could say to people "One of the things I'm working on is building a dynamic user group interface that lets you create rules for these groups based on different criteria such as specific fields or whether the users already belong to other groups..." (note the lack of breathing pauses), or something like "I use OOP techniques to create complex rules between User and UserGroup objects, which are represented in a class called UserGroupDefinition, which runs this background process that dynamically attaches users to the group, and the rules are set according to User field comparisons or whether the users are attached to other UserGroup objects...", or even "I'm building a piece of software that makes user groups that are automatically maintained based on criteria about the users."

All of these may accurately describe what you do, but certain groups of people may either not understand what you're saying, or they'll want more detailed information. Which leads me to my target audience for this blog. Initially I'd imagined a mixed audience, so lots of different abstraction levels across blog posts, since I sometimes like to talk about very general issues but I also love discussing specific technicalities. And, thinking now about whether to focus on one particular group, I find it limiting. What I might end up doing is adding labels to my posts so these groups are properly partitioned, and maybe have a very small explanation at the top of the site explaining why this is such a messy place.