Get Back On Track

There are hard times, and things can pile up. Don't wallow. Don't spend time trying to feel better.  Try to get back on track.

1. Things can get you down, so you need to borrow energy from others.  Try user groups, pairing, friends, fun programming exercises. 
2. Quit thinking you should be able to do new things all alone.  Getting up to speed is always dicey, and best done with someone who is already up to speed. 
3. If problems are short-term, like a flooded basement, broken lawnmower, minor health troubles, a child's academic crisis,  take time for them so you can get back on track sooner. Get it over with.
4. If the problem is long-term, start building up the emotional muscle to deal with it, which means getting on with life despite the long-term trouble and trying to cope with whatever "long-term trouble" is going to mean.
5. When you're not feeling particularly confident (ie depressed) don't get caught up in large meta-issues. Keep your focus on smaller things you can achieve. Build a quick triage rule to help determine what you can deal with right now.  Big issues will stop you dead in your tracks.
6. Get UNSTUCK.
7. Don't waste time, find new uses for it.

GOing to Software Craftsmanship McHenry County

I was a little overwhelmed with how slowly I'm absorbing information, especially while dealing with household issues (like gas fumes from garage and flooding in basement) on top of trying to do something worthwhile (ANYthing) at work. It's just the way life comes at you sometimes.

My escape for the night was running out to a meeting of Software Craftsmenship McHenry County (SCMC). This was my second meeting ever.  I mis-timed the trip and ended up a few minutes behind the start of Steven Degutis' slide show. Pizza and pop were in good supply though, so I settled in and enjoyed a presentation on the language Go.

Go is a strange little language, but a lot of fun. We had a quick presentation, thankfully mostly consisting of code examples, and then were given time to dive in.  Even though I'd been kind of blue and a little angry all day, I was soon laughing and having a great time while we tried to find ways to clutter a perfectly simple little problem's solution with threads and channels and anonymous functions. It was almost a reverse kata, where the goal was to be as overly sophisticated and absurd as possible.

In the course of making and fixing mistakes, we learned a little, shared a little, and bonded over the absurd joy of it.  I left in a much better mood than I came, and in that joyful mood I'm writing this blog entry.

I'm reminded again that when I stagnate, it's because I allow myself to feel the enormity of the world of things I don't know and to feel alone in the face of it.  I find again that the answer is to join into a little community; pairing or comparing, learning or teaching, playing or working. Sometimes there is a lot of release in having a silly little problem and some crazy peers to share it with.

If you are in the far NW burbs and like to program or like to learn about programming, give SCMC a chance. It's a group of people of varying ages and experiences where you can feel unashamed and enjoy programming education as a harmless pastime. Heck, you might even learn something useful. 

Chicago Code Camp 2011

I spent the day at Chicago Code Camp.  It's a good thing because it's a pretty pure conference for programmers. It's all run by volunteers, all free, all in one day, all short talks (1 hour).

CLC had good wifi, plenty of space. Actually, one of the problems we had was finding out where the registration desk and refreshments were "hidden" in the huge Technology Building.  I came in a different door than organizers expected, as did dozens of us who were found wandering the halls.  We like calling that the "mandatory fitness segment."

One of the things that is particularly good is that you can quickly guage where you stand with the community, what people want to hear about, and what people want to talk about.

The first presentation I attended was on refactoring javascript, and programmers were rapt. They wanted to know about testing and test frameworks, how to do the refactoring steps, and how to incorporate the tests in in CI. The introductory topics included refactoring, unit testing, and dealing emotionally with 'tangled code'.  I sometimes felt that the presenter was quoting from things I have written about naming and the like, but I think that mostly he was pulling from the same sources as Jeff and I did with agile in a flash. I picked on the presenter a little, and gave him a deck of Agile In A Flash cards as a kind of apology.  I hope he likes them.

The second talk was on git. I was surprised how few people knew about git and how to use it. There were more microsofters there than I expected, and they were using VSS and the m$ team server stuff, subversion, and cvs.  There were few of us who used git, bzr, hg.  I suppose that means we need to talk and write and present more on agile version control, or it means we're far enough ahead of the parade taht nobody is really interested.  Folks in the group would get confused and walk out.

The third session I had planned to listen to either Michael Norton (@docondev), but against my earlier plans I ended up checking out the talk on WebSockets and Pusher   with Damien Tanner (@dctanner) and Dave Hoover (@redsquirrel).  Damien was a surprise guest.  It was handy that the author of the pusher shows up to join Dave's talk. One feature of the talk was the audience's impatience to see code. God bless the Code Camp audience. Questions about performance were not long in coming. 

The latter part of the day was spent in Clojure with Micah Martin (a face from my old Object Mentor days) and Gnu Smalltalk with Steve Kim. Both were enjoyable. I am not a Clojure nor a Smalltalk guy, but I was able to keep up and enjoy both the presentation and the conversation.

A few quick observations:
* People were using vim, textmate, and emacs; they were not using IDEs much
* Macs are platform of choice even though this conference series is known for windows devs.
* The ratio of sexes was far skewed to the male side.
* The age mix was much more even. There were probably as many 50+ as teens, and 40s as 20s.
* Even with a rep for having microsoft developers, there were many platform-agnostic language talks.
* Organizers did a very good job for a free (sponsor-supported) conference.
* CLC in Greyslake, IL has a great facility.

Agile Coaching Stories

This is your turn to brag, complain, and post observations.

If you were on an agile transition, it is likely that your company hired a coach.  The coach may have been awesome, may have been horrible, and may even have been me.  

I'm interested in your stories. Were you pleased? Disappointed? Did you learn things you didn't even know you needed to learn? What was the long-term impact on the coach your team, your skillset, or your company? 

  

Adhesion Example

A while back, Glenn Vanderburg wrote an article about software cohesion v. software adhesion. Today I got a great example of adhesion.

We are starting our second year in the house. It is a quirky house and I know it was managed by people who were self-reliant, so there are always some odd surprises here and there. It kind of reminds me of a legacy code base, because the product (house) is pretty good, and mostly meets our needs and many of our desires.  We got it because we liked it and because it fit our price range, and it helps us with other goals (close to train station, 15 minutes from church, nearer friends, nearer my son's school, etc).

Today I needed to change a bulb in the upstairs shower for the first time.  I was stymied at first, because the cover didn't have any visible way to remove it.  The glass cover didn't have a catch, didn't screw off, didn't have a release detent that I could twist to release, nothing.  I finally decided that the outer plastic ring must drop down, but it didn't want to.

The cover had been caulked and painted to the ceiling, rendering the incandescent 70-watt bulb a permanent fixture of the house.  Think about that for a minute. In order to change a lightbulb, I have to tear into the ceiling of the shower. When I pulled down the outer ring, I found it was indeed made to pull down and release in order to change light bulbs, but I suppose the former owners were in a hurry when they put it in.

The ceiling was cut a little larger than it needed to be for the fixture. With the ring up, it leaves a little opening here and there.  To fix that, it looks like they just glued the hole with caulk and then painted it over so it didn't look so bad.  It seemed fine when I bought the place.

It sounds like a particularly bad design to me, because in order to solve one problem (not enough light in the shower) I have cause and then fix another one (holes in the ceiling). It is more disturbing to me because I'm not skilled in drywall repair or showers.  I'm going to have to ask for help now (another problem for me) to make sure I fix this in a way that doesn't cause more trouble in the future.

It didn't have to be that way.

This house really is organic in the way that legacy code is organic: things just sort of become the way they are through minimal effort and short-term problem-solving.  Nobody designed the house to have a hole in the ceiling or a permanent lightbulb, but that's how it is.  It's is as if "crappy" was a feature, and it probably sounded like a good cost/benefit tradeoff at the time. After all, a lightbulb over the shower should last for years, and caulking and painting are not hard to do.

I am not going to obsess over the issue, and I've got the bulb changed, but I am going to put in a fix that makes the lightbulb a supply instead of a permanent fixture. I'm putting in a florescent bulb this time, and it may last a long time, but the next time we need to make a change it won't be a big hassle. It will be easy.  I don't want to become accustomed to doing unsatisfying hacks in my house.

Organizing Stepwise Considered Harmful

There are different ways to organize repeating code.

One is step-wise, in which near-identical steps are stacked together:

button1 = QPushButton('Button 1')
button2 = QPushButton('Button 2')

button1.clicked.connect(lambda: self.on_button(1))
button2.clicked.connect(lambda: self.on_button(2))

layout.addWidget(button1)
layout.addWidget(button2)

The other is subject-wise where the code for button1 is separated from the code for button2:

button1 = QPushButton('Button 1')
button1.clicked.connect(lambda: self.on_button(1))
layout.addWidget(button1)

button2 = QPushButton('Button 2')
button2.clicked.connect(lambda: self.on_button(2))
layout.addWidget(button2)

The step-wise version makes the code repetition more obvious, but the novice code-cleaner is likely to extract constants to variables and leave it alone.  In the second case (subject-wise) the code-cleaner is more likely to realize that there is a multiple-step process that can be extracted to a function, leaving something more like:

CreateButtonWithAction(layout, 'Button 1', lambda: self.on_button(1))

CreateButtonWithAction(layout, 'Button 2', lambda: self.on_button(2))

At this point it becomes obvious that the only difference in the two lines is two constant values, which might suggest more ways to simplify the code.  The astute observer will also recognize that the first parameter in the call is always the layout class, which suggests a wrapper class or "move method" which will in turn result in a more well-developed abstraction. Well-developed abstractions make writing client code easier and quicker.

layout.CreateButtonWithAction('Button 1', lambda: self.on_button(1))

layout.CreateButtonWithAction('Button 2', lambda: self.on_button(2))

I'm not saying that this is the ultimate, optimal form for the code to take.  I'm only saying that once it is organized subject-wise, the refactoring starts to flow very naturally.

Why Not?

I have officially declared 2011 the year of "Why not?"

I don't mean "why not" in the sense of doing anything possible without thinking about it. I'm actually thinking it is a good year to ask why we can't do things, or why we won't do things, because it is interesting to understand the forces behind it.

Take personal development. Who among us has done all they planned to do regarding new tech, new languages, projects to start, products to build in the past year? Who would not have benefitted from reading a book, doing some kata, learning a new language, or writing something new? And yet we do not.

Let's refuse to commit the Fundamental Attribution Error here, and not say "because they don't care" or "because they're lazy."  A ton of information is available about improving a person's ability to program, or the number of platforms and tools they can program with, and yet most people don't reach beyond the level that is absolutely necessary for them to muddle through at work.

Why not?