Results tagged “manifesto”

The "Choose Python" Manifesto


Yes! A Python manifesto to add to my informal collection. It’s nice to have such passion around a language.

Here’s a funny part:

Choose to finish early and laugh at your colleagues as they waste their miserable lives bowing down in subservience to that sadistic little C++ compiler.

Busting on C++ never seems to go out of style.

Near as I can tell, this comes from Alan Issac, associate professor at American University. If you know better, please holler at me.

Update: This was the work of Tim Lesher. Thanks Tim!

Chose Python [Aftermarket Pipes]

via “Choose Python” [For Some Value of “Magic”]

Grow or Die


Programmers often emphasize mastery, wisdom, and skill. We’ll even say “I love to learn new things”.

Awesome. High five. Learning new things is good, but take care to avoid becoming just a sponge. Growth is important, and different from learning.

I can learn Scala, and I can learn Django; but the mere act of learning doesn’t really help me grow as a creator of awesomeness. I need to do that on my own.

My brother is an architect by trade, and we often talk about how designing buildings and making software are the same. In my previous post, he pointed out Bruce Mau’s Manifesto for Growth.

Bruce’s list is excellent reading. Here are some of my favorites:

Allow events to change you. You have to be willing to grow. Growth is different from something that happens to you. You produce it. You live it. The prerequisites for growth: the openness to experience events and the willingness to be changed by them.

Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces — what Dr. Seuss calls “the waiting place.” Hans Ulrich Obrist once organized a science and art conference with all of the infrastructure of a conference — the parties, chats, lunches, airport arrivals — but with no actual conference. Apparently it was hugely successful and spawned many ongoing collaborations.

The target audience is visual designers (so ignore the one about “avoid software”), but the similarity to how our brains are forced to work as programmers is impressive.

Just Effing Do It

The first chapter of Ben Hunt’s book Save the Pixel contains a great snippet of advice:

Once you’re clear what needs to be done, stop all analysis, and apply the JFDI process (“Just F*ing Do It”).

I love this. I’ve been developing an analysis allergy over the past few years. In design meetings, I can’t help but think how much quicker it would be to just try one of the options, or ALL of them, and find out the best design by experimentation.

Now, when I feel like I’m stuck in a rut, I start writing code. It crystallizes my understanding of the problem and has the pleasant side-effect of producing something useful.

The order of statements in the Agile Manifesto is important, and first on the list is

Individuals and interactions over processes and tools.

It’s easy to gloss right over it. I did at first; but then I realized that people do the exact opposite all the time. When process improvements are presented, it’s often with the assumption that the new process is an end in and of itself, ignoring the actual problem.

“Our documentation is bad, so from now on all projects need to submit design documentation for approval before development can begin.”

This has almost zero chance of working. With a deadline looming, this rule crumbles under an onslaught of “business need”. Any documentation that does manage to squirt out is crappy.

The “people over process” part of the manifesto tells us that instead of instituting a policy to magically fix the problem, we need to focus on people. We need to win over hearts and minds. Yes, it’s that dramatic and that important. Once the people are convinced that they want a solution, change happens quickly. It’s the whole carrot/stick honey/vinegar thing.

In the previous case, winning hearts means helping people understand how better documentation will benefit them, and to make them want it. Someone’s going to have to talk to all those people. Someone’s going to have to keep at it for as long as it takes.

It’s way easier to declare a policy and walk away than change peoples’ minds, but the policy won’t really get anything done.

Write Code. Not Too Much. Lots of Tests.

In his New York Times essay “Unhappy Meals”, Michael Pollan outlines a manifesto for eating right: Eat food. Not too much. Mostly plants.

I’ve gone and adapted it to building software:

Write Code. Not Too Much. Lots of Tests.

Write Code

You need to keep up to date with building software. That means participating in the act of coding. If you’re an architect, senior engineer, or development manager, you’ve got to do it.

Not Too Much

This is the essence of lean development. Only build what is needed. Cruft and verbosity are evil.

Lots of Tests

Testing is the key to quality software. If you aren’t writing tests, your’e doing it wrong.

This is a simplification, but a useful one. If you’re lost, overwhelmed, or pissed off, try reciting this a few times (when nobody’s looking). You might feel better.



Find recent content on the main index or look in the archives to find all content.


Creative Commons License
This blog is licensed under a Creative Commons License.