The basics for understanding behaviors
"Until you make the unconscious conscious, it will direct your life and you will call it fate." - C.G. Jung
What separates a beginner from an expert at something is the number of behaviors. Both conscious and automatic, and the degree to which you possess them.
- 🧶 - This icon represents behavior
- ⚙️ - This icon represents logic
A complete beginner starts the journey with no behaviors.
So the first step for a beginner is to figure out something consciously. ⚙️
Once they have figured it out, they take action, and that action can become a behavior: 🧶
Two things are now present: Logic - why I do this - and behavior - the action I must take to do the task.
It looks like this: 🧶⚙️ - Conscious logical behavior
The beginner can now tell you the behavior and why they do it at this point. (Incidentally, it's also what can make beginners good at arguing their point and why you can end up changing technology every few years)
Over time beginners accumulate more and more behaviors:
🧶⚙️ 🧶⚙️ 🧶⚙️
However, many of these behaviors become automatic. The beginner no longer has to think about why they do it; It just is. And thus, the logic is slowly forgotten.
🧶 <> ⚙️
But the behavior remains:
Becoming an expert
Eventually, our beginner becomes an expert, and they have a mixture of automatic behaviors and some with the logic attached.
🧶⚙️ 🧶⚙️ 🧶⚙️ 🧶 🧶 🧶 🧶 🧶 🧶 🧶
This is the normal human process of skill acquisition. Our behaviors over time become habitual. We don't think about them.
But this process is often a problem for software engineering teams. Because opposing behavior that aren't understood logically, causes conflict.
How principles help
Automatic behaviors are beneficial because it allows us to do more complicated things. If we had to be conscious of all our many behaviors, we would not achieve much.
But as soon as you join a team or want to change your ways of working, that automatic behavior can become problematic and create conflict.
Automatic behaviors are essentially habits. And habits are behaviors that have been detached from the logic that created them.
So when we do most of our actions, including programming, much of that behavior exists without the logic attached.
Principles are about attaching logic to behavior, so you can chose and understand your behavior, work better on teams and encode those behaviors into little recipes that you can use in the right situation.
If you are unconscious of your behaviors, you cannot interrogate, quickly replace them, or convince someone else of their merit, and it's bound to create conflict on a team.
Behavioral conflict on teams
With our knowledge of principles, let us introduce another person to our team to see what happens.
- 🏀 - This icon represents behaviors that the second person has which are different to our own.
Here are the second person's behaviors:
🧶⚙️ 🏀⚙️ 🧶⚙️ 🏀 🧶 🏀 🏀 🏀 🧶 🧶
As you can see, some of their behaviors are the same as ours (🧶), but many are different (🏀). As with ourselves, only some of their behaviors have their logic attached.
When two automatic behaviors collide, conflict, in some form, will almost always ensue.
The type of discussions that revolve around automatic behaviors are almost always at the wrong level of the problem. The people involved will grasp onto spurious reasons as they try to remember why they believe something. Each person feels right, but they cannot explain precisely why.
An example might be a disagreement with code structure "we must structure the code like this, because it's cleaner". Whereas the actual behavior driving it might be something completely different, like wanting to separate core logic from the framework: https://principles.dev/p/separate-core-logic-from-the-framework/
If you're arguing about "cleanness" when you really mean something else, the situation won't get resolved in a way that makes sense.
Principles solve this issue as they attach logic to your behavior.
Read next: how conflict is only one of many team behaviors in: The fundamental behavioral interactions on teams.