From Ken MacLeod?

When you write a specification, an article, develop software or a web site, or administer your systems, are you aware of how you do it? why you do things in certain ways and not others? can you draw a quick diagram of the major approaches you use, connecting them in the way that they support or interact with each other? If you are and can, that is "self aware", you recognize how you do what you do, not just what you do.

Self awareness is a characteristic that spans from individuals to teams to organizations. Self awareness can be a natural skill or a learned skill. Most teams or organizations that are self aware generally were formed with self awareness, as it is much harder to learn and gain momentum or habit as an organization than it is as an individual. Most "methodologists" are explicitly self aware, but self awareness does not imply methodology.

There are three stages of self awareness. The first stage is where you only know what you do. You have technical or social skills, you gain more skills as you go along. Often those skills interact and you use the ones that work well together (or sometimes you don't). Like picking tools, you'll often pick the skills that are handy to the job at hand and not concern yourself with their overall interaction. Coders would call this "casual hacking".

The second stage is where you can identify a few of the approaches you take to reach a goal, and have possibly chosen between approaches based more on their unique merits irrespective of whether you would have to rearrange or learn new skills to use the approach. The biggest distinction between the first stage and the second stage is that you realize that this is an approach (a principle, practice, or pattern) and not a specific skill (a technique or tactic).

The third stage is where you know you are using a variety of approaches to achieve a goal, you know how those approaches interact and support or counter each other, you select specific approaches when starting a project, and you pro-actively vary the chosen approaches as you learn or as your needs change. If you are on a team or in an organization, you share names of the approaches and have quick descriptions available. If you take the effort to document or formalize your approaches, you often call them "patterns", "habits", "practices", or "methodologies". A master will recognize that the novice will apply approaches too literally or too forcefully, as if they were simply a technique or a tool.

So when you find that you can't come to consensus on what a "permalink" is or a model should be; or your articles don't flow naturally from you and you don't know why; or your software, web site, or systems don't work trouble-free virtually all the time, maybe it's not some specific definition that's missing, or that you're not a "natural", or that the tools are broken, maybe you need to step back, take a look at your approach to achieving goals and see if you can identify the approaches you are using and if other approaches might not be better.