Other side of the CAR, not the POST.

First look at this video...

We can have a laugh at this poor lady's bad moment (and frankly, I did -- don't judge me).

But it is funny because we see this all the time in different forms. How many times have you seen a team crank up the size of its sprint "commitment" because they didn't make the last one?

How many times have you seen people struggle with a practice by doing it "wrong" over and over until they simply got sick of trying and quit?

When we're focused on something else (getting the release out, dealing with a bad review, feeling bad about a skill we need but don't have) we can easily get into this kind of a mess.

Here you know that she knew intuitively that her problem was that the gas cap was on the other side, but she somehow got it into her head that it was the wrong side of the post and not the car. She kept pulling up to one side and then the other, sure that she got on the right side of the post this time.

It was not the post that needed re-orienting, it was the car. It was easier and simpler to reorient when she knew what she needed to do, but that was only after she finally took responsibility for understanding and thinking through the problem -- which almost certainly meant letting go of something else she was mentally preoccupied with.

Are we driving in an attentional fog, too focused on what we're not doing to be able to accomplish what we really need?

Confession: Yeah, I've had the same kind of attention tunnel vision, and I've had days that were consumed in things that weren't work. I've spent many hours trying to work but trying to not put my full attention on it.

We can do better.

Here's what I'm learning:

1. Intend to have accomplishments, or at least one, soon.
   Try the pomodoro technique perhaps so you're focusing in smaller bursts.
2. Catch it sooner. Don't spend the whole day in attentional fog. 
3. Recognize "overwhelm" and take a walk or a break rather than trying to push through.
4. Consider taking time out and dealing with the distractions so you can have your whole brain back instead of dealing with the Ziergarnik effect.
5. Use someone else's attention. Their focus will help support your focus.

I've not mastered this yet, but all of these things seem to be helping when I'm aware enough to "catch it sooner" and use one of these techniques. 

Years' End, Years' Begin

2014 was the year of the brain. 

I decided to put aside most of my other reading materials and concentrate on reading books about brain function. I read up on neuroleadership and cognitive science and motivation.

I got into a lot of content, and learned a lot of interesting things which should help me not only to coach and lead others, but to manage my own mental state better than I ever have before.

Some of that learning was from The Leadership Gift, where my involvement was kindly sponsored by Industrial Logic.

Underneath all of these studies and stories and new understandings, I learned a lot about empathy and sympathy and caring for others. What it means to be human is essentially that we're stumbling through a paltry handful of decades with impaired ability to gather, assess, judge, and accept reality. We're all from different places, with different mental models and mindsets, and we can work this all out together if we're willing to open up.

But we can. We can improve ourselves and we can support each other, and we don't have to be "stuck."  We can get "unstuck" if we're willing to learn, thing, examine, and put aside judgement and frustration for a little while and let our curiosity and natural intellect lead us to clarity.

That's a lot of stuff for a quick blog post.

Let's leave it here: I know enough (head-knowledge) to have a much better impact on my own behaviors and habits and on helping others deal with theirs than I've ever had before.

I'm still burning down the reading list, so 2014's Year Of The Brain will spill over a bit. But no rush now.

2015 is upon us.

2015 is the year I throw on as many skills as I can afford/tolerate/enjoy. Last year I learned a (very) little bit of Groovy and Swift and Javascript even though it was The Year of The Brain, because my work required it and I like learning new stuff.

But this year will be more intensely pursuing skills, using what I've learned about my brain in the meantime.

I intend to deepen my javascript skills and develop cloud computing skills. That's a lot to learn already, but will be fun.

I need and want to learn at least one proper functional language (python's semi-functional features, C# LINQ, etc don't count).

My son bought me a mandolin for Christmas. I'm going to play some songs on it publicly by the end of the year.  I'm also going to deepen my guitar skills. I will learn some sight-reading and some music theory. After all these years of playing, I should learn something about music, I think. ;-)

I don't know what other skills I'm going to learn, but I'm basically going to stop procrastinating and eat what's in front of my nose. I have awesome resources (computers, the internet, books, friends) and there's no reason I don't soak up a ton of tech in 12 months.

Wish me luck.

Working Well Enough: the Four Questions

The question asked was "how do we know we need a coach?" The more general question is "how do we know if we need help?"

The question seems to assume that the goal of coaching and training are rescue; that the team is in trouble or incapable of success. That's horsefeathers.

I think that the more valid question is "are we working as well as we can?"

Here are my criteria for teams that don't need anything:

1. We deliver
2. Delivering software keeps getting easier
3. We are always learning
4. We have fun

If all four of those are true for a team, then that team probably doesn't need help. Of course if those are true, then the team is poised to provide a lot of help to other teams by describing how they work.

My itsy-bitsy contribution to Git

This is from 2005, when I was at an all-linux, all-python shop called Progeny Linux Systems. A lovely time, really. Great people, interesting technology, challenges and opportunities every day. Not everything we did was stellar, but we were moving together in a good direction.

We started using git when it really was a "git" (a stupid person or thing) and the tools were very confusing because they mixed noun names and verbs, and people were just kind of used to it being confusing.

You used to have to go by hand into the innards of the .git directory structor to create tags and branches. 

A "porcelain" was a wrapper around git to make it more useful and tolerable, and ours was specific to building custom Linux distributions. It was a cool project. 

My contribution was very meager: I complained about the inconsistent naming of git tools at the time. 

I started with a question here:

So when this gets all settled, will we see a lot of tool renaming? 

While it would cause me and my team some personal effort (we have a special-purpose porcelain), it would be welcome to have a lexicon that is sane and consistent, and in tune with all the documentation. 

Others may feel differently, I understand. 

Started getting serious here:

Junio C Hamano wrote:
> Tim Ottinger writes:
> > git-update-cache for instance?
> > I am not sure which 'cache' commands need to be 'index' now.

> Logically you are right, but I suspect that may not fly well in
> practice. Too many of us have already got our fingers wired to
> type cache, and the glossary is there to describe both cache and
> index.

I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time
go by and do it later, it will hurt much more.

Pre-1.0 is the last chance, AFAICS.

Daniel turns it into a plan:

OK. As Horst also says, we should do this before 1.0.

0.99.6::
This hopefully will be done on Sep 7th. Tool renames
will not happen in this release, but the set of cleaned
up names will be discussed on the list during this
timeperiod. I'll draw up a strawman tonight unless
somebody else does it first.

0.99.7::
We install symbolic links for the old names. For the
documentation, we do not bother --- just install under
new names. Also remove support for ancient environment
variable names from gitenv(). Aim for Sep 17th.

0.99.8::
Aim for Oct 1st; we do not install symbolic links
anymore and supply "clean-old-install" target in the
Makefile that removes symlinks installed by 0.99.7 from
DESTDIR. This target is not run automatically from other
usual make targets; it is just there for your convenience.

Junio gets down to cases:

I said:
> I'll draw up a strawman tonight unless somebody else
> does it first.

1. Say 'index' when you are tempted to say 'cache'.

git-checkout-cache git-checkout-index
git-convert-cache git-convert-index
git-diff-cache git-diff-index
git-fsck-cache git-fsck-index
git-merge-cache git-merge-index
git-update-cache git-update-index


2. The act of combining two or more heads is called 'merging';
fetching immediately followed by merging is called 'pulling'.

git-resolve-script git-merge-script

The commit walkers are called *-pull, but this is probably
confusing. They are not pulling.

git-http-pull git-http-walk
git-local-pull git-local-walk
git-ssh-pull git-ssh-walk

3. Non-binaries are called '*-scripts'.

In earlier discussions some people seem to like the
distinction between *-script and others; I did not
particularly like it, but I am throwing this in for
discussion.

git-applymbox git-applymbox-script
git-applypatch git-applypatch-script
git-cherry git-cherry-script
git-shortlog git-shortlog-script
git-whatchanged git-whatchanged-script


4. To be removed shortly.

git-clone-dumb-http should be folded into git-clone-script

... the rest, as they say, is version control history.

To this day the git toolset is consistent. 

I think it's remarkable now, because the dev team listened to me and answered even though I was not really a part of the group. I didn't have to earn voice, it was okay. 

Even though I did nothing more than ask a question, it has always made git feel like "my" version control system. 

I guess any little interaction that leads to action will create a sense of engagement and participation.

Thanks Git team from 2005. You were great.