Computer architecture humor

Hil. Ar. I. Ous.

This is the funniest thing I’ve seen in a long time, but maybe it’s only funny to other computer/hardware geeks:

I think that it used to be fun to be a hardware architect. Anything that you invented would be amazing, and the laws of physics were actively trying to help you succeed. Your friend would say, “I wish that we could predict branches more accurately,” and you’d think, “maybe we can leverage three bits of state per branch to implement a simple saturating counter,” and you’d laugh and declare that such a stupid scheme would never work, but then you’d test it and it would be 94% accurate, and the branches would wake up the next morning and read their newspapers and the headlines would say OUR WORLD HAS BEEN SET ON FIRE.

Link: “The Slow Winter” by James Mickens (his bio at Microsoft Research is also funny.)

Learnable Programming, Bret Victor, and Other Two Word Phrases

Bret Victor just published his latest essay, “Learnable Programming.”

In “Learnable Programming” Bret criticizes the Khan Academy’s latest “interactive” programming education tools and suggests a better way to teach programming.

He footnotes the essay with this summary:

This essay was an immune response, triggered by hearing too many times that Inventing on Principle was “about live coding”, and seeing too many attempts to “teach programming” by adorning a JavaScript editor with badges and mascots.

“Inventing on Principle” was the talk he gave at CUSEC 2012.

If you haven’t seen/read both you must immediately:

  1. Get a cup of coffee, tea, or whatever comfort beverage you prefer.
  2. Find a comfortable place to sit and pay attention for about two hours.
  3. Watch the video of Inventing on Principle.
  4. Read the Learnable Programming essay.

It’s fantastically worth your time.

Bret sidenotes* the essay with this exciting teaser:

Forward reference: Some work that I’ve done in automatic visualization of ad-hoc data structures will be published later this year, in collaboration with Viewpoints Research.

I’m looking forward to that!

* I just invented the verb “sidenote,” as in, “He sidenoted the heck out of that teaser in the side note.”

The Architecture of Open Source Applications, Volume II: FreeRTOS… released!

Exciting news!

My chapter on FreeRTOS, the open source real-time operating system, has been officially published in The Architecture of Open Source Applications, Volume II!

You can buy it on here: The Architecture of Open Source Applications, Volume II, dead tree version

Or you can wait a week or two and find the complete text (of my chapter and all the others!) here for free: AOSA online

I’m very happy how it turned out; it was a lot more work than I expected, but it was worth it. Greg Wilson and Amy Brown edited the heck out of it, I would love to work with either (or both) of them again. Thanks to them for pulling the whole thing together! Thanks also to Richard Barry, the primary FreeRTOS developer, for his technical help.

I’m looking forward to reading the whole book myself; so far I’ve only read my chapter.

A few choice chapters that I’m particular looking forward to reading are:

So check out the book, either online or in paperback, and enjoy!

Ember is hiring in Boston!

My company, Ember, is hiring for embedded software engineers and QA engineers in Boston:

We develop the chips, software, and tools for wireless sensor networks.

I’ve worked at Ember since December, and it’s the best place I’ve ever worked (and I’ve worked at some pretty good places!) And, no joke, all of my coworkers say the same thing. So either we’re that great of a place to work, or there’s something in the water, but either way, it’s awesome.

But, as Levar Burton says, you don’t have to take my word for it: We were just voted one of the top places to work in Boston:

Our QA engineers are more “developer-y” than many QA roles, so definitely check it out even if you’re not in the market for a more traditional QA position.

Email me if you’re interested!

Embedded software and open source

Embedded guru and author Jack Ganssle’s latest “Embedded Muse” newsletter has a lot of good commentary on open source in embedded software projects:

I subscribe to very few newsletters, and Jack’s is one of them.  I read every issue, it’s that good.

If you work in embedded software, or software of any kind, you should subscribe!  (I don’t get anything if you subscribe, I just think it’s a worthwhile read.)

While I’m in fanboy mode, I’ll also recommend Jack’s other articles – click on a random one, you’ll probably learn something. My personal favorite is his guide to debouncing.  He does some good experiments and then shows hardware and software solutions to the pesky debouncing problems we embedded folks face.

I love embedded, and so does Woz!

I love working in the embedded world.  Hardware + software = a great time and a great career.

I came across this fantastic quote by Steve Wozniak in “Making it Big in Software,” by Sam Lightstone.  Woz is talking about designing the Apple II:

“And I did every piece of software from the ground up, through applications that you can’t pin down for any one of them.  The hardware was so interrelated that I can’t really divide it into software and hardware alone.  Those days were that way.  Today, if you work on embedded processors, you put a little microprocessor into a small product.  That’s the job in the world that I would love to this day! That’s what I did back then; it mixed both hardware and software.”

Sounds like Woz wants my job.  🙂

Technology vs. Psychology

Do you write software for a living?  Or design hardware?  Or maybe some of each?  While the particular projects any two software or hardware designers do may be worlds apart, we can characterize what we do in the same way: our work is 20% technology and 80% psychology.

Most of the work we do is 100% solvable – it “merely” requires people and time to accomplish.  It may be difficult, it may be risky, but it’s doable.  Most projects don’t require quantum leaps in technology to accomplish – current hardware and software platforms will do just fine, thank you.  Most projects don’t fail because the IDE wasn’t up to the task, or the compiler, or the linker.  Most projects fail because of the carbon-based part of the tool chain, not the silicon-based one.

All projects have some inefficiencies and problems.  They always start small but aren’t life- (or project-) threatening:

  • The build process is manual and annoying, and therefore error-prone; but most engineers run it before checking in new code, and the errors are always found quickly enough.
  • Code drops from external groups happen less frequently than we’d like, but it’s been okay so far.
  • The external contracting team has found a few bugs in the spec, but it’s nothing that can’t be fixed later, and we don’t have time to check the spec right now.

None of these problems will doom your project on their own.  And because you can live with the status quo, you won’t fix them now.  “I’ll get to that later when I have more time.”  But as the problems multiply, build in intensity and (gasp!) start to constructively interfere with each other, your forward progress will slow down.  It will take longer and longer to do what used to be quick tasks.  Many aspects of the job will become more frustrating, and morale will go down.

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

That’s an important thought, so I’m going to repeat it:

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

How do we address the psychological aspect?  We need to trick ourselves into doing the Right Things in the Right Ways to make continual progress.

Here are two guidelines for doing the Right Things in the Right Ways:

  1. We MUST make activities that are good for the project as easy as possible and as enjoyable as possible. 
    • Can your pre-commit tests be run automatically?  Yes?  Great – do it!  Make sure they run reasonably quickly, with easy to read status updates.  When the tests are done and passing, can we help the user enter a helpful commit message by supplying a list of the diffs automatically?  Yes?  Great – do it!
  2. We MUST make activities that are bad for the project as difficult and miserable as possible. 
    • Checking in without passing all tests?  Okay, but you have to run this ugly command line, fill out the TPS reports on this slow web page, and get a note from your mom.  Consider making “bad activities” impossible.  Checking in without passing all tests?  IMPOSSIBLE!  Can’t be done.

Two of my favorite geniuses agree with me, so I must be right:

  • Albert Einstein said, “Everything should be made as simple as possible, but not simpler.” We need to worry about making our processes as simple as possible.  Don’t worry about making them too simple, I doubt we’ll get that far.   Can you make it simpler?  Yes?  Then do it!
  • Kathy Sierra said, “Make the right things easy and the wrong things hard.”  She says it much better than me – go read her post!

Of course sometimes we don’t have time to improve a process right now, because we (hopefully) have paying customers banging on the door, deadlines to meet, product to ship.  You’ve got to pick your battles and manage your time wisely.

But we geeks need to spend more time thinking about our psychology – the “how” and “why” of what we do – instead of just focusing on the technology – the “what” we do.

The earlier you find and fix inefficiencies and bugs in a product, the more time and money you save.  In the same way, the earlier you find and fix inefficiencies and bugs in the way you create a product, the more time and money you save.  But you get an extra bonus from improving the way you create a product because it produces not just a one-time boost, it produces a many-time boost!  It’s like compounding interest.  Actually, it’s not just like compounding interest, it IS compounding interest!

Define the problem, define done

I. M. Wright’s latest post “Green fields are full of maggots” talks about defining the problem and defining done.

My favorite quote (which is, itself, a quote):

“What’s so evil about general solutions? After all, your code could be both a floor wax and a dessert topping.”

He makes some great points about building software to solve a real, concrete problem, instead of building software as a semi-abstract-solution-that-could-solve-any-problem-possibly-the-one-people-are-paying-us-for.

My second favorite quote (second favorite only because it doesn’t quote Saturday Night Live) sums up the danger of the abstract:

“You put the problem at the center instead of the customer. When the customer isn’t at the center, your code loses its soul. It goes from being astounding to being adequate, from marvelous to mediocre.”

What is your goal?  Mediocre, or Marvelous?