Is typing speed a factor in programmer productivity? Would you improve at chess if you moved the pieces faster?

Jason Gorman, who appears to be a relatively reflective programmer based on his blog and his twitter, tweeted this comment about chess a few days ago.

A bunch of people I follow ReTweeted, and it caught my attention because I used to think this way, both about chess and programming.

Now I don’t claim to be the greatest at either activity, but I’ve put some time and I have enough ability to claim to be above average at both. (Which is to say, I’m aware of my relative mediocrity when compared with real masters)

I’ve played chess off and on for years. I learned to play when I was quite young and I could usually beat other casual players quite easily. After losing to rated tournament players, I spent some time studying the game.

For a long time, I thought the best way to learn was to methodically look for the best move and I thought playing blitz games was somewhat degenerate. Luckily, someone convinced me to start playing blitz games regularly, and that accelerated my understanding of the game considerably.

I still play better when I take the time to be methodical, but that’s not the same thing as learning. I think the blitz games accelerated my learning for two reasons, first, because playing at that speed put that many more games, positions and patterns in front of me and two, because I didn’t attach as much ego to the games I experimented more, which led to that many more positions.

I do think there is a point of diminished returns to just move the pieces faster, and improvement is predicated on some reflection, but I will contend unequivocally that, unless you are a master, you will improve at chess if you spend a considerable portion of your playing time moving the pieces faster.

The same applies to code. You don’t need to type +100 words per minute, but if you can’t touch type at least 40-50 wpm, spend the 20 minutes a day for a month or so until you can. You will never regret it. (And I worked as a programmer for years before I could touch type.)

I would walk you through the arguments, but there is already a classic Yeggethon on the topic, which articulates all the positions I would and then some.

“Lose Your First 100 Games As Quickly As Possible”
–Proverb for Go Beginners

If you can’t be thankful for what you have, be thankful for what you have escaped.

The difference in so many things just comes down to perspective.

Is that glass half empty or is it half air?

I have so much to be thankful for, a beautiful intelligent wife, two amazing little boys, relatively good health and relatively abundant resources.

Yesterday, I decided to run a race and solicit donations for cancer research.

At the time, I just thought I would run because I wanted to and I’d try to get money for a good cause.

You can learn a lot about people when you ask them for money.

I spent much of the last year asking people for money. Buying or giving, people often have unique reasons and circumstances when they hand over their money.

I watched my sister die from cancer. I edited my goal for donations from $200 (the default) to $1000, because $200 just seemed like so little. Today I was pleasantly surprised by the donations I got and who I got them from.

Initially, I had planned to put a couple pictures of my sister up and write a little more about her, but then someone I respect got upset with that plan. In this persons perspective, doing that was disrespectful to my sister’s memory. I don’t share the same perspective, but this person did make a point that stuck. Which was that $1000 is relatively insignificant in the larger scheme of things.

Though choice and circumstance, I could easily donate $1000 and not sacrifice much. If I was willing to sacrifice for a cause, I could put $10,000 and cut back on a few things to make it work. $100,000 is out of the question for my little family, at least in the near future.

At the same time, my wife is a medical resident and I seem to be relatively adept at generating income and business ideas. If we really want to have an impact on this issue, the future is wide open. Stuff that matters… all in good time…

I want to clarify one detail, I watched my sister die from cancer.

She was diagnosed with Rhabdomyosarcoma with a primary tumor in the pericardium, which had already metastasized to her lungs when diagnosed. Through the process, she met several young people who were battling this form of cancer, and one by one, we saw them all wither. None that I know of lived through this.

At some point, my sister was in a coma and intubated. She came out of the coma, but we never got to hear her voice again. She struggled on and the doctors had basically cut her in half trying to remove the tumors. When it became clear that she was not going to make it much longer, she begged to go home.

The last few days, she laid in my mother’s living room with a machine breathing for her. She couldn’t speak, but she could communicate by mouthing words and making gestures. Even though she hadn’t been home for months, and there was no way to get her up the stairs to her room, she could still remember every detail and would make requests to be brought things.

Everything about her was perfect and beautiful except for her lungs which were decimated by tumors and treatments.

She became edematous and faded more and more from this world.

I held her hand when they unplugged the machines.

That was almost 10 year ago.

I am thankful that I had a sister. Her name was Ann Shafer.

One day, I hope to be in a position to honor her name with more than $1000 in donations.

I’m not asking anyone for money, but I do appreciate the support that giving symbolizes.

If you have abundance in your life, do stuff that matters with it.

If you don’t, be thankful for what you have and do what you can to cultivate and be a good steward.

Don’t cry because it’s over. Smile because it happened.
–Dr. Seuss

I’m no longer part of Reductive Labs. While this development is not quite heart breaking, I am always sad to leave behind something that I care about, but I also understand and feel strongly that this will be better for everyone.

Since raising venture funding, Reductive Labs has been building an adept team. That team has a critical mass in Portland, OR. There are now eight people there and I am tied to Salt Lake City for the near future, and who knows where for the next few years. Staying aligned with everything that Reductive Labs was doing and needed was becoming more and more of a challenge.

Puppet is a great tool and organizations get a lot of value from it. There are some exciting Puppet developments underway which present unique challenges and opportunities for both the technology and the business. I will now watch them from afar.

My involvement with Reductive Labs has been a period of pronounced growth. I learn many lessons about business and technology, that would have been difficult to learn any other way. I thank Reductive Labs and Luke Kanies for sharing the opportunity.

For the next month or so, I’ll spend more time with my family (when I’m not at the climbing gym and getting massages) and sort through a couple ideas.

Part of me wants to continue pushing the Infrastructure Renaissance forward in some capacity, and part of me wants to build something awesome, and part of me wants to work on stuff that matters.

Maybe there is a good way to combine them all together…

There are a lot of interesting problems in the world… (to solve or cause)

Insurmountable opportunity…

What are you going to do next?

Today people were tweeting up an old interview with Al3x Payne and some devs from Twitter about using Scala.

Al3x or anyone else has the right to use for whatever programming language they want. No questions asked…

But today I was reflecting on Al3x’s rationalization of the type system motivating a move to Scala. I mean we’ve heard this before and the whole thing got a lot of Ruby panties in a bundle when it first came out.

But checking for nil and kind_of? all over the place is not Ruby’s failing… that’s a big ball of mud in any language and I’ve seen people resort to the (null != foo) && (foo instanceof Bar)) anti-patterns in Java.

Al3x asserts this is an inherent property of large systems in dynamic languages. I’ll assert it is a property of systems that have grown organically to the point where the programmers can’t reason about what is coming or going. I’ll further argue that you get more out of thinking functionally towards solving this issue than you do from stricter typing.

If you find yourself constantly checking for nil/null or really being concerned with types except around the edges of a system, that’s a code smell IMHO.

But maybe another layer of duct tape will fix it…

totally duct'd

I’ve had a lot of things I wanted to get out there, but didn’t have the time to sit down and craft it. The result is a bunch of half formed embryonic posts, which will grow to something hopefully very soon. The past few months have been a whirlwind.

Starting with the investment process and our partnership with True Ventures.

Then there was Agile Roots, which was awesome and I’m not just saying that because I help organize it.

Check out some of the Agile Roots videos. (The sound on some presentations is suboptimal because of issues with the venue’s system, but the content is generally good.)

Then Velocity Conference, face meltingly awesome… the best practioners conference for people who are pushing the boundaries of what is possible. Some of the Velocity videos… my talk didn’t get recorded this time, which I’m sure improved the quality immensely…

Then Structure, similar to Velocity, but for people who wear more buttons and spend less time at the command line.

July was a blurr of phone calls from people wanting to sell Reductive Labs office space and IT management solutions, lunch meetings, podcasts and day trips. Some work got done.

August had more of the same, with more podcasts, Ignite Salt Lake and finally Agile 2009 (where my presentation with Paul Nasrat was recorded by InfoQ)… capped off with a little Reductive Labs love at the Ruby flippin’ Hoedown.

I know I haven’t done any of these events proper justice, but I plan to at least collect some of my thoughts and post my slides, etc. in the next few days.

Did I mention I have two young sons and a wife in medical residency? Don’t try this at home kids…

People rarely succeed unless they have fun in what they are doing.

–Dale Carnegie

When I penned the immortal words ‘Give me an API or give me death…’ and gifted the meatcloud manifesto to the world while admonishing applications that don’t provide APIs, I was perhaps too focused on GUI installers. That was an artificial limitation which I hope to now rectify.

The automation of repetitive tasks presents an insurmountable opportunity.

Freedom from effort in the present merely means that there has been effort stored up in the past.

–Theodore Roosevelt

DRY should be a familiar principle familiar to anyone writing code and not living in a cave — Don’t Repeat Yourself. Unfortunately, sometimes it’s a lot easier to see the replication in files with code than it is in other aspects of our work, but search your shell history and look for the obvious. The real opportunity is to pop up a level and observe the workflows.

How much of what your organization does with emails and phone calls could be accomplished with a chain of automation?

That’s not so say we don’t want humans to make decisions, but do we really need to have someone push that button or fill out that form? As it turns out, machines are really really good at doing exactly the same thing over and over.

How much of what your organization does is replicated across an industry? industries?

Sometimes the benefits are not in what we can add, but what we can take away…

Opportunity is missed by most people because it is dressed in overalls and looks like work.

–Thomas Alva Edison

As I said… insurmountable opportunity…

viva la meatcloud!

I just read The Four Steps to the Epiphany by Steven Blank and I highly suggest the book to anyone with an interest in business.

The books is mistitled, but ‘The 47 potentially recursive steps to incrementally determine a business model and not waste a lot of money on bad assumptions‘ probably didn’t work.

Blank outlines a ‘Customer Development’ process in parallel with the development of the product.

There is an a clear bias for venture funded tech startups, and a more subtle enterprise bias, but the process and mindset being advocated is generally applicable, even when some of the anecdotes might not be.

The core message is that the ‘build it and they will come’ strategy sets the stage for epic failure, and the book is filled with examples.

In my opinion, the Customer Development strategy is really Test Driven Business Development. The steps are a series of experiments which test hypotheses about the potential product and the market. The end result is the product developed in tandem with the positioning and sales process in line with a strategy appropriate for the market.

The Four Steps outlines a taxonomy of Markets: Existing Markets, New Markets, and Resegmented Markets, for the purpose of matching the market type with an appropriate sales strategy. A reoccurring theme, supported with evidence, is that ramping up a sales team or building expensive infrastructure not aligned with the nature of the market can burn through a lot of cash.

The last section is about building companies. This is after you have a product and a market, and are looking to take things to the next level. The advice here is more philosophical, illuminated by scenarios where founders were unable to lead that transition and the examples where traditional professional management ruined promising startups.

The ideal leader is someone with the passion and vision of a founder who is also able to think strategically and delegate. (which is not to be confused with abdicate…)

If you are thinking about building a business, or in the process now, I recommend you take the time to read ‘The Four Steps’ as soon as possible.

Infrastructure is Code! FTW!

Wait… WTF does that even mean?

On the one hand this is a rallying cry for those of us in the configuration automation space, on the other hand it confuses innocent bystanders.

@zhenjl: @botchagalupe but ops ppl have always coded using perl, tcl (if u remembr that …now we just have ’sexier’ langs like ruby and python (original)

Sure, there has always been scripts, which is technically code, but this is missing the point a bit.

For starters, getting ops teams to recognize and steal all applicable processes and tools from developers to produce and version there scripts would be a win, but that’s just the starting line…

The point isn’t just that you can write some scripts to help you do something with your infrastructure then exit.

The ‘Infrastructure’ IS an application, a long running process with inputs, outputs and state. Or at least infrastructure is very close to becoming one…

Everyone paying attention knows something is happening… what is it?  Hazy, foggy, smoky, cloudy, whatever…

EC2 is the herald of an infrastructure enlightenment, leading us out of the dark ages.

(We’ll ignore the history of virtualization technology, and ESX Server for now, but I’m sure someone has an opinion on all this.)

The bottom line is there are resources, and I can manipulate them through an API. With EC2, these are compute resources of various shapes and sizes, with some storage resources.

Virtualized networking is not exposed through a public API yet, but we’re still climbing abstraction mountain together and we all know it is just a little higher in this cloud. (What’s up Cisco, where you at? Oh, there you are… and these guys too… thanks Ben )

At some point in the not too distant future, web service calls and a credit card will be enough to create and manipulate arbitrary compute, storage and network resources.

So now what?

Until someone provides Sysadmin as a Service, there is still quite a bit of work left to be done. These resources need to be configured to provide services.

When adding capacity was a purchase order, then wait for weeks to rack and cable, taking a day or so to configure the machines was not rate limiting, and lost in the noise. When you can bring up new server instances in minutes, that same configuration step is conspicuous waste.

You might be thinking you’ll make images for each of your services and manage those. This approach to management exchanges the configuration drift of tradition IT management for image sprawl. Do those notes that got scribbled six months ago when the web server image was created have accurate details about how that machine is configured? Are you sure? The only way to know is start the VM and inspect it. Frankly, the same thing applies to the running instances started yesterday.

That’s where tools like Puppet comes in. The benefit is not just that a machine gets configured by running a script. Puppet is an application that audits your system configuration, and changes the details out of sync with policy. That policy is code with semantics that can be developed like software.

That’s the shift. Instead of thinking about managing server counts, we can reason about abstractions of service configurations. The pieces exposed by an API are not just instances of server and storage resources, but abstractions of services. The configuration of proxies, monitoring, middleware, web servers and databases are components to be composed in the dynamic ‘infrastructure’ application.

This is just the beginning, but I don’t want to spoil the rest of the story… at least not yet.

It is not necessary to change. Survival is not mandatory.

W. Edwards Deming

And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful in its success, than to set up as the leader in the introduction of changes.  For he who innovates will have for his enemies all those who are well off under the existing order of things, and only lukewarm supporters in those who might be better off under the new.

Niccolò Machiavell

I’m taking a break from trying to be useful. You know how the song goes:

• “If the top three items in your browser history include the words “twitter”, “innovation” or “interoperability”, you might be a cloud computing expert”
• “If you’ve ever asked Amazon to Open Source their API, you might be a cloud computing expert”
• “If you think ‘Open Sourcing’ an API makes any sense, you might be a cloud computing expert”
• “If you think there is a difference between ‘business investors’ and ’speculators’, you might be a cloud computing expert”
• “If you think cloud computing will save the rain forest, you might be a cloud computing expert”
• “If you believe building in EC2 always has a lower TCO, you might be a cloud computing expert”
• “If you are not preparing for ‘The Trough of Disillusionment’, you might be a cloud computing expert”
• “If you just can’t get enough *aaS, you might be a cloud computing expert”
• “If you want to debate public vs private, you might be a cloud computing expert”
• “If you spend a day talking about which Star Wars character you should be and it is a good day at work, you might be a cloud computing expert”
• “If you understood more than two points on this list, you’re def. a fscking cloud computing expert”

I’m sure this list is much longer, I’m just trying to do my part and get you started…

Make us all proud…

GUI installers are evil…

Period.

You might need to have a little wizard to walk through setting stuff up the first time for the uninitiated, but if you think you are doing the poor hack who has to install your stuff on hundreds of machines any favors, you got another thing coming.

If you don’t provide some way to install your software fully unattended, please do not sell it to schools, businesses, non-profits or religious organizations with more than one person.

You might as well be killing kittens.

Actually, that goes for the interface to running applications as well.

I think we need the Open Meatcloud Manifesto… (because the world needs more manifestos and this is the perfect date to start a movement)

Let me see what I can work up…

• scribble* *scribble* *erase* *scribble* *crumple* *scribble*

I’ll keep it short and simple:

We hold these truths to be self-evident

Show your support for this movement by making your own copy of the manifesto and posting the pictures.

(Special privileges will be bestowed on those willing to tattoo the manifesto… on their forehead.)

No meatclouds were harmed in the making of this manifesto.

Viva La Revolución