kip/bot/blog

Here’s what’s on tap. First new soldering irons, with nice solid stands and variable heat.

Need a new one. The old one seems to have lost its heat. We will renew our soldering skills by turning these:


into these:

we will also solder two of these:

Then we will dig into arduinos:

and after some blinking lights and basic programming, we will drive these:

When not burning or gouging ourselves, we will make paneer, some curry pastes, and play Wii.

Geek on.

Several years ago, when I took off a month between jobs, I spent a week geeking out on the Arduino. This weekend, I’m geeking out with my niece – who is a geologist – soldering a bunch of Mintyboost kits for Christmas, mastering the Arduino, and doing some LCD stuff.

As a geologist, my niece has professional reasons to care about electronics and the Arduino. She does field work with instruments and sensors that often need repair, tweaking, and maybe even hacking (that might be my fantasy). A little while ago, she sent me this picture:

A colleague (colleague, ha! they’re just my niece’s friends) was working with a microcontroller to do . . . well, something geology-related. Anyway, after soldering some of her instruments, she’s got enough of a bug for us to hang and do this.

The other exciting thing about this little adventure is that, while I was ordering parts, I discovered that there’s a new thing called the Arduino Mega!

It may be hard to see the cause for excitement, but basically the Mega has 54 output pins (they make up the little walls around the edge of the board), compared to the Uno, which has only 14:

Going past the 14 pins in the Arduino is one of those plateaus that can kill a hobbyist’s momentum. When I had an idea for a project with about 30 LEDs, I was told I needed to get into shift registers. I did so, but it was painful and took a lot of space:

While it was rewarding to get it done, it took up most of my time and posed some other problems (like space and weight of the components), so my project never got off the ground.

These plateaus occur in all sorts of places: GUI controls for mid- to low-level programming languages, pointers in C++, database hooks in most programming languages, PWM and servos in electronics, hell, even setting up the IDE for a relatively simple programming language. One of the things that was cool in the Lady Ada feature of Wired was how she highlighted how much more support there is in overcoming these hurdles in the last 3 – 5 years.

Chris Anderson: We’ve had the notion of garages, workshops, sheds, and DIY tinkering for a long time. And yet there’s a sense that something’s different now. What characterizes the 21st-century maker model to you?

Limor Fried: One of the things about doing projects is that documenting them and sharing them with people used to be really difficult. Now we see so many people putting up videos, and it’s so easy. I can make a five-minute video in an hour, with a preface and edits and nice audio and everything. And I think that makes a difference, because when people are exposed to this stuff and they actually get to see it, they get inspired.

There are also so many really great websites where people can share their projects. We have Instructables and iFixit and Etsy and Make and Hack a Day and our own Adafruit. So people who used to do this stuff alone now have even more community. It used to be just freaks in garages; now it’s freaks in garages working together.

Of course, I live on the second story of a brownstone, so we’re more “freaks in old maid’s quarters working together.” Still, a good time to be alive, tinkery, and not afraid to get a few burns.

In a couple weeks, I’ll be starting a new job (deets later) and thought it was time to clean the rust off the tools in my toolbox. I’m starting an ugly little blog called “Learn to Code Already (and while you’re at it, learn some data, too)”. During my union organizing days, I wrote code to pay the bills (hopeless political causes are romantic and certainly the good fight, but they are financially suspect). When I became a digital/interactive/game designer, some time in 1996 – 1997, I realized that basic computer knowledge could have a huge impact on the quality and innovation of a design. My computer knowledge was basic:

- databases (I wrote programs in C and Java for Paradox and DBase IV and in Visual Basic for Access)
- command loops
- data variables and structures like arrays, lists, and structs
- conditions (if … then)

The only hard part, conceptually was learning about relational databases once my freelance work required me to move past flat file systems. The rest was pretty straightforward, requiring some rote, some instructive debugging, and excitement at what these things might do. (I learned BASIC on TRS-80 and within a week was hooked, writing D&D character generators, lunar lander games, and even the beginnings of a Zork-style adventure game.)

With this small bit of knowledge, some free time, and youthful arrogance and curiosity, I was able to write database programs for health organizations, artificial intelligence routines for a deer hunting game as well as several classic board games, re-write the timesheets reporting program so I could get better data on my clients at R/GA, create small HTML tools that sped up and improved the accuracy of posting to client review sites . . . to name some highlights.

Today, those skills are rusty and there are new languages and types of languages that make me want back in. As I wrote to a programmer friend of mine:

* I’m frustrated that I no longer have a coding language or tool to play with ideas (I used to have VB and that allowed me to write bulletmaker and a new timesheets program for Nike as well as a deer AI).
* I’m frustrated that it’s so hard to find a place to start
* I want to start a new language
* I want to blog about coding. I bought “learntocodealready.com” and want to make it a group blog for four or five people to record their progress, save resources, share tips, and build the case that code is the cell unit of creativity

He wrote back:

Nice. Just last weekend I realized there were far more powerpoints on my computer than source code files. Not good.

So starting digging in with jquery tutorials.

It’s also worth highlighting Douglas Rushkoff’s Program or Be Programmed argument. Read it yourself, but the short version is: we can master our tools, or let them drag us along by the nose and hope we go somewhere interesting. Or as the good folks at Whole Earth Catalog used to say, “We are as gods and might as well get good at it.”

I’m starting with Python, using Zed Shaw’s Learn Python the Hard Way, a book targeted at absolute beginners and which strives not to teach Python in a hard way, but in a way that has lasting value.

Three goals for the site:

1) convince people that learning to code is valuable, fun, and attainable. Further, that it should be part of our literacy in the digital age, especially if we’re in that business.

2) Collect resources, inspirations, code snippets, and advice that clears the way for people to start learning at a level and in an environment that works for them.

3) Collect little tidbits of information, inspiration and wisdom from my own experience working through some Python books, then getting into HTML 5, then PHP/MySQL.

Ping me if you want to join up: kip dot voytek at gmail dot com.

Tim Ferris had an amazing idea when he was finalizing his breakout book, The Four Hour Workweek. He and his agent couldn’t decide on a title for the book — actually they couldn’t pick among the final four candidates. Ferriss did a very clever thing: he advertised for the as yet unpublished book under each of the four titles with AdSense and used the traffic results to help form his final decision as to which would sell the most books.

Now, with his next book, he’s taking it several steps further. First, he outsourced the design of the book cover to 99 Designs, a site that lets you post a commission and a brief for the kind of work you want done and then designers submit their ideas. If you pick a design, you pay the commission, if you hate the work, you get the money back.

Now that Ferriss has his designs (46 designers responded to his $300 commission and brief), he’s asking users, namely blog and twitter followers to rate and comment.

All sort of interesting in his sourcing ideas.

A couple months ago, I posted about the need to improve the way we celebrate failure. My big beef was the lack of accountability within the word fail and the inability to distinguish between a useful failure and a f#$%-up. Still think that, but have found two expressions of failure that have boundaries, express the point of failing, and are useful.

The first one comes from Mark Frauenfelder’s Made by Hand: Searching for Meaning in a Throwaway World. Frauenfelder is a founder of boingboing and editor in chief of Make Magazine. The book covers his post-dot-boom look for a less expensive, less frivolous, more meaningful life. Three goals he and his wife set out for themselves were: 1) “take more control of our lives”; 2) “cut throught the absurd chaos of modern life and find a path that was simple, direct, and clear”; and 3)”forge a deeper connection and a more rewarding sense of involvement with the world around us.” The book’s chapter are walks through of various moments and types of DIY living, thinking and playing: how to kill your front lawn to make room for a garden; DIYing a better, cheaper source of coffee than Starbucks; making music with homemade instruments. (Sadly, no electronics.)

Anyway, the second chapter is titled “The Courage to Screw Things Up.” It’s designed to get people over the learning curve of DIY, one which is messy, costs some money, might get you an electric shock, some nasty cuts, some ruined clothes, and the occasional hole in a wall. DIY types classically take on a project that’s too big for them, muck it up, and then quit. MisterJalopy, a legendary maker (who remains anonymous), counsels that you embrace those early screw-ups, not just to get past them:

No one talks of failure as anything but shameful; this is wrong-headed and foolish. Mistakes are synonymous with learning. Failing is unavoidable. Making is a process, not an end. It is true that deep experience helps avoid problems, but mainly it gives you mental tools with which to solve inevitable problems when they come up

Fraunefelder summarizes: the act of failing “is the only way to equip [yourself] with the mental toolbox of a successful DIYer”. That works for me. Fits in with the notion of failing as experimenting — failures are paths to learning more about your materials, the techniques of the craft and how they interact with environmental factors, and in taking apart a problem and putting together solutions. Dig it.

The other one comes from the Make: Electronics book. It’s a simple slogan: “Burn things out, mess things up — that’s how you learn.” Again, a call for experimenting. When you burn out a component, like an LED light, you learn about polarity (especially if it’s your last one), you learn about current, surges in electricity, resistance and capacitance. Mess things up is a nice phrase to use, since it pushes you into a ‘mixing things up’ place — the tinkerer’s idea of grabbing anything that works, taking it apart and seeing if you can’t make it work a little better or differently or just figure out what it does. Frauenfelder has a nice line about Misterjalopy:

I was charmed by his perspective of the world as a hackable platform, something to be remade and remodelled to his exacting, eccentric, yet infectiously appealing aesthetic sensibilities … In his world, the things around you should have meaning, and his way of giving them meaning is by collecting, customizing, rebuilding, and combining them in ways that make him happy.

(Mister Jalopy can be found at www.hooptyrides.com)

When I was learning to program in C/C++, for several days/weeks and on several attempts I hit the pointers plateau — that thing which, conceptually, I couldn’t get my head around sufficiently to really grok the damn things. I eventually took a class that spent three weeks on it and now I understand them — their purpose, their usage, their style and how to troubleshoot them. A couple summers ago, I took a geek vacation between jobs and worked my way through the NYU ITP Physical Computing class curriculum and dug deeper into some Arduino stuff.

After a couple weeks, I hit a plateau. I needed things like shift registers to multiply the number of LEDs I could manage with the Arduino’s 13 pins; I needed to use a 555 timer chip to get pulsing, and there was a whole range of chips starting named 74______ that were described as “hugely useful” or “workhorses”. These things were critical and basic, like pointers, but (like pointers) it was impossible to find documentation for them that was comprehensible to someone with my level of experience. It was one of the weird places where the web let me down. I must have done dozens of searches, asked everyone I could for help, and could find nothing. Which is a drag, cuz those chips are what give real ooomph to physical computing projects.

Make Magazine has fixed that with Make: Electronics, an unusually good book even by O’Reilly standards. It contains in-depth explanations of how transistors and logic gates work at the physical level — giving you a more intuitive sense of how to work with them (rather than following steps by rote); detailed descriptions of the pins at three levels: the official specs, the occasional nomenclature, and the actual function; and some simple circuits that show what the thing does. The last might be the most important. Even the most basic 555 Timer chip examples I could find had so much stuff going on that it was impossible to isolate the chip and learn, iteratively through tweaking the code, what the things does. To top it off, the Maker Shed Store has a components kit that pulls all the stuff (including jumper wires) together for you.

The one weird thing about the book is in the index:

What the hell kind of alphabetization system is this?

Of course, it’s not like I have time to do anything on my nifty hand-made workbench. But it’s nice to have it when I’m ready. Hope springs eternal. Put differently.

while (!endOfUniverse)
hope.spring();
;

Ha!

I continue to be crotchety about generalism and the speed with which people think they can learn to be something (see crotchety posts here, here, and here. Here too. Oh, and here. God, do I ever stop? Well, no, but this one here isn’t grumpy.). Listening to Studio 360′s podcast about Moby-Dick today (while I was engaged in the years-long journey of becoming a better cook — in this moment by trying to improve my chicken stock and mushroom barley soup), there was a surprisingly great interview with Ray Bradbury. Why surprising? First, because, despite my love of SF and other genre fiction, I tend not to expect profundity from SF writers. Second, having never read Bradbury, I assumed whatever acclaim he gets is because of the ideas behind and the clever titling of Fahrenheit 451, not for any skill as a writer. (I need to make that right and at least buy, if not actually read, something of his on my Kindle.) Third, it’s just such a nice way of putting something I and the voices in my head are often on about that my head snapped up and I almost cut off the tip of my left index finger when he said it.

Anyway, I spend lots of time trying to convince people to respect craft and the time it takes and the value behind going deep in subject areas. But I see lots of people assuming they’re experts in things after they’ve done something once, or read a couple articles and books about it, or memorized a couple catchy phrases. Malcolm Gladwell recently helped highlight the fallacy that conversancy == expertise or that once is enough to be a guru when he highlighted the thinking that indicates you need 10,000 hours to get really good at something. But that factoid alone doesn’t quite get it across, because it’s not 10,000 accretive hours only that get you there. It’s 10,000 accretive and repetitive hours, with an emphasis on repetitive — you don’t learn new things so much as you learn more about the richness of the things you know. Describing this process and helping people understand it is challenging.

So, Bradbury wrote the screenplay/adaptation for the Gregory Peck film version of Moby Dick. (I didn’t know that, so already I’m happily smarter as I chop my leeks — working on getting more rhythm and precision and speed with my 8″ knife.) He apparently rather famously talked about being Herman Melville for a day during the writing of the screenplay and the Studio 360 host asked him to explain the why and the how of that:

what you try to do is get it into your bloodstream, get it into your unconscious. You can’t intellectualize it, that won’t work. But if you read a book 80 or 90 times, which I did, some sections I read 120 times, and you put that all into your bloodstream . . . and then you ignore it and let it come to the surface, emotionally, passionately . . . then you become the chaser and chased.

I like the image of getting it into you bloodstream and waiting for it to surface. Even more, though, I like the idea of ignoring the material and letting it sit in your unconscious.

I’m starting to look for a piano teacher (my previous teacher has, alas, moved to the west coast. A moment’s homage to her: she was awesome, played my piano beautifully when she walked me through Mozart sonatas and had a fun mix of stern teacher (reflexively pushing my elbows up and straightening my back) and music lover (listening to any vague musical connection I made between a theory assignment and something I was listening to.

So, a teacher I’m looking at has all sorts of things to love, chief among them his professional/academic work around Mahler. But he has a section on his site called Why study music? which highlights some of the benefits of taking a craft seriously and going deep into something. His key reasons, paraphrased below:

Dealing with pressure — the site refers to children learning to deal with pressure, but there’s something impressive for adults to, on a weekly basis, confront a piece of music that doesn’t come easily to them. Knowing that a lesson is coming up is just enough pressure to force you to take a longer view, break the piece down and work on it. It’s also long enough to be rewarding when, by the end of the week, you being to master it.

Responding to Criticism — I’m surprised how many design focused places don’t ‘workshop’ things and how many times we hold back from really working over a piece of work. One of the key, but most frequently overlooked, tenets of design thinking should be/is iteration and revision. While anyone’s first rev should be excellent, it should be understood that further revs will only improve the final product. Even if you come back to the original design, you’ll have a stronger, more confident understanding of it.

Persistence — in my world of marketing and interactive, there’s a borderline obsessive interest in the next thing, newness, novelty and never seen before. Sitting with someone for a while, working on something for longer than a quarter, doing a truly better v2.0 that is continuous with the previous version is not only hard to do, but often scorned. That said, however, there are a lot of creative types in the field who know when to dig in and fight the good fight or keep on pushing to validate an idea.

Multi-leveled focus – inset Steve Jobs quote about zooming in and zooming out and the design trope of ‘rinse and repeat’.

Project management – taking a long view of mastering a craft or something within the craft requires some PM like thinking. For a piano piece, my instructors regularly tell me how to break it down: “start with the left hand until it feels smooth and you find some melody in it, then focus on the melody right hand only, and work on the middle section until it feels clean, then you can add the intro, do dynamics last.”

The bolded names of the benefit are his, the interpretation mine. His page about why we should study music is pretty nice read, highlighting brain age as well as craft/life lesson benefits . . . and, oh yeah, the joy of playing music you love!

Perhaps is because I’m getting old. Perhaps it’s because, having gone through 2.5 career changes and paid my dues/been schooled 2.5 times. Perhaps I’m wrong, but I found this Zen Habits article about
how to become amazingly great at something refreshing. I’ve been to so many places where people are going to “get digital” in 3 months, or pick up a new competency through a couple hires, or “spend a weekend” with something to plumb its depth and master its rhythms. I loved the setup to this article:

Very often you’ll see blog posts or books teaching you to “master” a skill in only 10 days, or 3 days … in fact, it used to be 30 days but the time frame to master something seems to be shrinking rapidly.

I’ve even seen tutorials claiming to teach a skill in just a few hours. Pretty soon we’ll be demanding to know how to do something in seconds.

Instant mastery of skills and knowledge! Hey presto!

Unfortunately, the reality is something a little less magical. Or maybe that’s a fortunate thing.

It’s got a look (or maybe it’s the music):