A reading of Tim Berglund’s “Oh, The Methods You’ll Compose”

Transcription: “Oh, The Methods You’ll Compose”.

When a coder sits down to start banging out code
The first thing to start crowding his cognitive load
Is whether his program will do what it should
Correctness, he says, is what makes my code good

It’s the function that captures the coder’s attention
Behaviors and inputs and outputs are mentioned
As if the one good that a coder can bring
Is to spin the right wheels on some Turing machine

And compiling and linking and running are great
(We need to do these to put food on our plate!)
But the shocker that might leave you scratching your head
Is that actual code is less written than read

We spend more of our time in maintaining our stuff
Than we ever spend writing the simplest of cruft
Which means that unless you’ve got something the matter
You’ll try to learn just a few code style patterns

So coders and countrymen, lend me your ears
As I teach you some lessons won hard through the years
From that Beckian book about implementation
And patterns that derail code suckification

Read the rest.

Thought Provokers From Python’s Guido Van Rossum and Clojure’s Rich Hickey

At Strange Loop 2011 Clojure’s Rich Hickey gave a presentation (video) on programming and simplicity that rankled some feathers and triggered a heated discussion at reddit.

Duncan McGreggor, decided to contact Python’s Guido Van Rossum to interview him about his keynote talk at PyCon US 2012 (video), specifically his thoughts on callbacks.

Talk: “The Web Browser is a Transitional Technology”

Allen Wirfs-Brock, a Mozilla Research Fellow, at YOW 2011, defined what he considers the current era of computing, and some exciting elements of where we are and where we are going in his talk “The Web Browser is a Transitional Technology”.

It looks like YOW 2011 had some fantastic talks to check out.

A James Shore 2006 Post My Favorite Design Read So Far in 2012

James Shore’s post in 2006, “Quality With a Name” summarizes clearly what I try and express and practice in my systems design work.

This is something to not only read and bookmark, but print out to remind folks who are building systems what exactly is good software design.

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

If you’re interested how a number systems I’ve helped design have had such long lives and have grown from small teams to support large ecosystems, “Quality With a Name” is a great place to start

Recently he gave a presentation on evolutionary design that is a good watch.

I’m looking forward to seeing his presentation at Philly’s Emerging Technologies Conference.

Alistar Croll: “much of human interaction has shifted from atoms to bits”

Read his post on O’Reilly Radar: “The feedback economy”:

In a society where every person, tethered to their smartphone, is both a sensor and an end node, we need better ways to observe and orient, whether we’re at home or at work, solving the world’s problems or planning a play date. And we need to be constantly deciding, acting, and experimenting, feeding what we learn back into future behavior.

We’re entering a feedback economy.

Steve Jobs: “computer science is a liberal art, it’s something everyone should know how to use, at least, and harness in their life”

“Quotes from Steve Jobs Lost Interview”:

“Learning to program teaches you how to think. Computer science is a liberal art.”

NPR.org: “Steve Jobs: ‘Computer Science Is A Liberal Art'”:

“In my perspective … science and computer science is a liberal art, it’s something everyone should know how to use, at least, and harness in their life. It’s not something that should be relegated to 5 percent of the population over in the corner. It’s something that everybody should be exposed to and everyone should have mastery of to some extent, and that’s how we viewed computation and these computation devices”

Related:

“Steve Jobs Lost Interview”

YouTube: WGBH: “Steve Jobs 1990 Lost Interview Part 1”:

Reddit.com: “Want: a non-technical description of CS”

Beginner’s Eyes: on storytelling and growth

John D. Cook, in a short, poetic post, describes how experts end up where they started, as beginners, and why, in his blog post “Coming full circle”. A few folks in his comments thread make the connection with Zen’s concept of “Shoshin”, the Beginner’s Mind, and it does, but I hear echoes of another journey just as strongly.

YouTube: “The Hero’s Journey / Monomyth”

Dizzying but invisible depth: on complexity

Jean-Baptiste Queru, on his Google+ profile, posts a poetic and doozy of a post, “Dizzying but invisible depth”:

Today’s computers are so complex that they can only be designed and manufactured with slightly less complex computers. In turn the computers used for the design and manufacture are so complex that they themselves can only be designed and manufactured with slightly less complex computers. You’d have to go through many such loops to get back to a level that could possibly be re-built from scratch.

Once you start to understand how our modern devices work and how they’re created, it’s impossible to not be dizzy about the depth of everything that’s involved, and to not be in awe about the fact that they work at all, when Murphy’s law says that they simply shouldn’t possibly work.

For non-technologists, this is all a black box. That is a great success of technology: all those layers of complexity are entirely hidden and people can use them without even knowing that they exist at all. That is the reason why many people can find computers so frustrating to use: there are so many things that can possibly go wrong that some of them inevitably will, but the complexity goes so deep that it’s impossible for most users to be able to do anything about any error.

Metrics and damn metrics: on systems

Sometimes we get caught in numbers and miss what’s real. This can happen especially when we focus on the wrong numbers writes Arpit Mathur in a sharp post. I’d add even if you were looking at the right numbers, without context, just like a soundbite, you could derive the wrong lessons or encourage behavior that you didn’t desire.

Always ask: What is it we are trying to effect or learn about? Are we looking at the right things? Do we have the context necessary to understand it?

Related:

“Systems Thinking, Lean and Kanban”: “Creating Useful Measures”

Michael Feathers: Rocky Mountan Ruby 2011 Keynote: “Code Blindness” – fantastic – watch the whole thing.