Tag Archives: learning

Personality Mapping (not therapy) with AI

Posted on by
Reply

For the last two years, I’ve been doing something with AI that I didn’t expect when I started: trying to figure out why I am the way I am. You know, map where I get certain ways I think and act.

A big part of that has been identifying what I call my “archetypes”. They aren’t heroes. I don’t want to be any of these people or characters. Some of them have enormous flaws. I’m interested in specific things I learned from them. Here is a partial list:

George Carlin taught me to stand outside the system long enough to notice what everyone else has stopped noticing, then be able to explain it plainly.

Bruce Lee taught me to absorb what is useful, discard what isn’t and make the rest my own – and practice it until it becomes part of you rather than something you have to think about.

Steve Vai showed me another version of that. Influences disappear into you. Eventually what comes out isn’t imitation anymore. It’s yours.

Clayton Christensen showed me that incredibly complicated systems can sometimes be explained with surprisingly simple models. Complexity doesn’t require a complicated explanation.

Steve Jobs reinforced something I had already experienced repeatedly: the dots only connect looking backward. Something that seemed unrelated or useless at the time becomes important years later.

Batman gave me one of the simplest definitions of identity I know: “It isn’t who I am underneath, it’s what I DO that defines me. “

Rocky taught me about will. You don’t have to solve forever. You just have to get up one more time.

Then, if necessary, you do it again. Life is iterative – not designed up front.

Iron Man also iterates. The previous version isn’t a failure. It is what taught you how to build the next one.

Superman (Man of Steel version):

Clark: “The world is too big mom.”

Martha: “Then make it smaller”

Focus on the smallest thing that makes a difference. Try not to get overwhelmed. I’m still working on this one.

House investigates until he understands. An accepted answer isn’t necessarily an understood answer.

Dexter is a stranger one. He represents taking something genuinely wrong or dark in yourself, putting constraints around it and finding a way to point it somewhere useful instead of pretending it doesn’t exist.

There are others, and the list keeps changing as I understand it better.

Eventually I found a technical metaphor that explains what I’m doing better than “archetypes” does. They’re external libraries.

I’m the linker.

I don’t link the whole library. Nobody should. I take a procedure from Carlin, another from Bruce Lee, something from Christensen, Batman, Jobs, Rocky or somebody else. I know where they came from because provenance matters to me. But once they’re linked together and running, the executable isn’t any of them.

It’s me.

That is why I think this work matters.

Most of us accumulate influences our entire lives without examining them. Parents, teachers, books, movies, music, bosses, friends, people we admire and people we absolutely do not want to become.

They leave pieces behind.

Looking at my archetypes has let me reverse-engineer some of those pieces. I can see where certain ways of thinking came from, why seemingly unrelated things have always attracted me and why patterns that looked random at the time weren’t necessarily random at all.

AI has been unusually useful for this because it can hold a ridiculous amount of conversation, compare things separated by decades and challenge the story I’m telling myself. Sometimes I see the connection first. Sometimes it does. Sometimes neither of us has it quite right and we beat on it until something survives.

That’s important too. I don’t want AI to tell me who I am.

I want it to help me see what I might have missed.

One thing I’m missing is the bitterness. I haven’t found the root cause of that yet …

Recipes are for Learning, not for Real Life

Posted on by
1

Recipe BookPeople like recipes. We’re always looking for the next ten step way to improve what we do and how we do it. We see it in leadership trainings, “methodologies”, and pretty much any self improvement or team productivity books that we read. Each of the above give frameworks along with classifications of things that you can use to solve a particular problem.

What gets lost a lot of the time is that the classification of things and the frameworks are written to teach, not to use in every day life. While you might have to consciously think about the way to classify something at first, while you’re learning, the key point of these things is to give you a way to classify and deal with information while you are learning. At some point, the idea is that the framework will fade away and you will innately have the tools at your disposal, without having to think of the distinct classifications or step by step instructions to deal with them.

Its like learning to ride a bike. When you are learning to ride a bike, you learn balance, steering, and the fact that you have to push one foot at a time on the pedals to achieve the motion you need in order to propel the bike forward. At first, its very awkward. Your steering is shaky, you don’t pedal fast enough to get the inertia needed to move the bike forward, because you are thinking of all of the things you need to do at the same time to achieve your goal. Pretty soon though, you internalize all of the independent skills you need that make up this thing called “riding a bike” and it becomes one thing rather than many concurrent things you have to think about. Pretty soon, you are modifying or adding to what you know and doing things like riding no-handed, wheelies, or whatever other things you can think of that augment your experience of this thing called “riding a bike” that makes it a little more “your own”.

Methodologies and religious arguments around software development have always put me off. When I’m asked to participate in a “methodology” discussion I usually cringe, because I know that 9 out of 10 people feel that the methodology as it is written is the goal, rather than taking the methodologies as a set of tools that are used in the learning stage to develop competence and later modify for the environment in which you work. This tends to get lost most of the time and you find teams and people doing things as they were specified in the recipe, whether they are useful or not, rather than adapting the tools – or even throwing some of them out if they do not apply.

“Agile” methodologies are a perfect example of this. You have specific formats for standups that are interpreted literally, specific tools like automated builds, unit tests, user stories, and burn down charts. Some methodologies include specific artifact definitions like activity diagrams, object diagrams, 4 + 1 architectural diagrams. In most cases you find people using all of them as they were specified in the book because they haven’t moved to the point where they understand the purpose of these tools, what they accomplish and how they do or do not fit together for a particular situation.

Agile software development is not the format of the standup or the fact that you have automated builds. As far as I can tell, Agile software development achieves the following:

  • Get the customer involved and the team communicating.
  • Break the functionality required into small, incremental, implementable pieces that are prioritized around both business and technical dependencies – with the goal of creating production ready code. Small iterations also give you the ability to adapt to changing requirements. What seems important at the beginning of one iteration might not be as important as something in the next iteration – so you plan incrementally.
  • Create production ready code at the end of each iteration, with rapid feedback cycles – this is the purpose of unit tests, and automated builds – to be able to “stop the line” when something breaks without a lot of manual intervention – and to deliver “just enough value” as soon as possible.

I think the problem is that most of the time people do not look at the philosophy around a methodology. Most of the tools that appear in these methodologies have a purpose to get to a certain philosophical goal, like the bullets listed above. Unless you understand the goal, you can have perfect stand ups and not ever really “implement agile” in the way that it was intended.

Related Articles