Computers are the wrong smartness.

From Isaac Asimov’s 1975 short story “Point of View,” talking about Multivac, a malfunctioning computer:

“…if Multivac were as smart as a man, we could talk to it and find out what was wrong no matter how complicated it was. If it were as dumb as a machine, it would go wrong in simple ways that we could catch easily. The trouble is, it’s half-smart, like an idiot. It’s smart enough to go wrong in very complicated ways, but not smart enough to help us find out what’s wrong. And that’s the wrong smartness.”

That accurately describes most computers and software today, almost 40 years later: they’re the wrong smartness.

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.”

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:

http://www.ganssle.com/tem/tem199.htm

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.

Presentation Presence

A software vendor gave a sales presentation at my office today.

The vendor sent two people to present – a sales guy and an engineer.

The sales guy started the pitch with an overview of the software. Sounds great, says us, but we need a bunch of technical details to know if it’s worth pursuing. This is a critical piece of software, it will interact with a lot of internal systems, and so we need to know what we’re getting ourselves into.

So we ask a bunch of questions which the engineer answers to our satisfaction. Probably 30 or 45 minutes go by, mostly a back-and-forth between us and the engineer. He knows his stuff, and he seems to enjoy telling us about their technology.

The sales guy doesn’t have much to contribute, which is fine. Or rather, it would have been fine, if Mr. Salesguy would have appeared to be paying attention, or at least not acting distracted and bored.

Instead Mr. Salesguy checks his email. Checks his voicemail. Fiddles with his pen. Fools around on his computer for a while. Does a lot of things that tell me he doesn’t care about this sale. All with a look of “Get me out of here” on his face. Which doesn’t exactly inspire confidence or help the sale at all.

What’s the lesson here? When you make a sales pitch / presentation / demo / whatever, make sure that every single member of your team is devoting 100% of their attention to the customer. Even if you’re not currently speaking, even if you’ll never speak – act interested! Better yet, BE interested! And if you can’t get interested, then you probably don’t need to be there in the first place.

How to tell you’re a bad programmer

How to tell you’re a bad programmer:

1. You think you’re an awesome programmer.

2. But no one else has ever told you so.

3. You’ve never looked at old code you wrote and thought, “Ewwww! That is horrible code! What was I thinking???”

4. You’ve never looked at someone else’s code and thought, “Dang, whoever wrote this is a freaking genius.”

Note that this also works if you substitute <other profession> for “programmer,” and <output of other profession> for “code.”

If you don’t see growth, it probably ain’t happening.  If you don’t see growth potential, it probably ain’t happening either.

Baby Steps

A few seemingly unrelated thoughts, and then a tie-’em-all-together thought:

1. Rands’ recent post on “Saving Seconds” really resonated with me. I forwarded it to my wife and said, “See, this is how I think!” so that she could better understand why I optimize the shortcuts on our PC, or the way I load the dishwasher, or the other thousand seemingly-OCD-inspired things I do. (Thankfully she understands me very well already!)

2. I think it’s incredibly important to be good to “the environment.” Whether you believe in the global warming story or not, it needs to be done. I recycle everything possible (and I got really excited when I found out that Ecology Action, our local recycling place started recycling #3 – #7 plastics!), am a vegetarian, use reusable grocery bags (and don’t use individual plastic bags for bagging fruit or veggies), use BioBag compostable trash bags, and the list goes on.

3. Joel’s “Fire and Motion” post also resonates with me. Forward progress, even if it’s just a tiny bit of progress, is good. And necessary, in fact, to getting anything done.

If your goal is to save the Earth it’s easy to get overwhelmed because you can’t do it all yourself. What possible difference can a single person make? There’s too much to do!

If your goal is to improve some software or improve a software development process itself, it’s also easy to get overwhelmed because you can’t do it all yourself. What possible difference can a single person make? There’s too much to do!

Guess what? Maybe you’re right. Maybe you can’t save the Earth by yourself, or single-handedly improve the festering swamp that is your team’s software development process, but there is something that you can do – you can take baby steps.

Recycle something. Get a reusable bag or two for your groceries. Turn off the lights when you leave the office conference room. Ask a coworker to look over your code for bugs before you checkin a change. Create an automated test suite for your software, start with a single “does it compile?” test.

It will require an intentional change in your thinking and behavior to do these things the first time, and the second time, and the seventh time. But soon enough doing a little bit extra for the environment or your software will become a habit, and those small bits of effort will add up into something meaningful over time.

And you will be motivated to keep adding more good habits over time because you will see the internal (“Yay! I feel better about myself!”) and external (“Yay! I found a bug!”) benefits from those habits you’ve already adopted.

And as you develop those small habits, you will be noticed by others around you who may even join you in small improvements – “viral marketing” at work.


A Couple Of Resources:

Joel’s “Getting Things Done When You’re Only a Grunt” post has more software development improvement ideas.

http://science.howstuffworks.com/save-earth-top-ten.htm has a few Earth-friendly things you can do.

Using Stack Overflow

Joel Spolsky and Jeff Atwood are starting a new website called Stack Overflow, it’s going to be a free programming Q&A website.

I’m a fan of both of those guys (I even have an autographed copy of Joel’s book!), so I signed up to be a beta user to see how it develops. I was trying to come up with a good way to give Stack Overflow a test drive, and I think I’ve hit on something: use it to build a web 2.0-ish site. I’ve been wanting to build a site for myself for at least the last year – I can picture it in my head (and on paper), what it should do and what the user interaction should look like, but I haven’t spent any time actually figuring out how to build the darn thing.

You see, I’m comfortable in C/C++/Perl/Python/x86 assembly (really), but I’ve never done any database or web-y development. Enter Stack Overflow – hopefully it will be a good place to learn about web programming.

I’ll update this blog with my progress once Stack Overflow goes live, wish me luck.

And Jeff: Give me a call when you decide to learn C, I taught it at Purdue for a few years back in grad school and really enjoyed teaching it – maybe you could trade me some .NET lessons for some C lessons. You check my post on pointers to get started. 🙂

Data is more agile than code

Peter Norvig talks about the need for a startup company to go fast – and also in the right direction – at his Startup School 2008 talk.

“Sure you gotta go fast, but if you’re not getting feedback to figure out if you’re going in the right direction it doesn’t matter how fast you go.” (2:47 in the video.)

That advice can apply to both technology and the business sides of a company, but here Norvig focuses on the feedback necessary to make sure the technology you’re developing succeeds.

He suggests you can get this vital feedback by:

“Acquiring lots of data [and] running machine learning over it… The key here is that no matter how agile you are as coders, and I understand that you’re all great, data is going to be more agile than code. Because you’ve got to right the code yourself, but the data you can leverage… there’s an immense multiplying factor that way.”

I guess this Lisp/AI guru from Google knows a thing or two about using lots of data, eh?

He goes on to describe how Google has used machine learning over large data sets for their image search, text segmentation and Google Sets. It’s a great talk, I highly recommend it.

I like the idea of letting the data and algorithms do as much of the heavy lifting as possible – the knowledge I want to share with my users may already be in the data, I’ve just got to dig it out!

Knuth hates XP

In this recent interview, Donald Knuth says:

“Still, I hate to duck your questions even though I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term “extreme programming” sounds like exactly the wrong way to go…with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.”

There are only a few people who can get away with saying that and actually have people listen to them – and Knuth is definitely one of them. I would love to hear him expand on the “terrible aspects of extreme programming.” If he had an email address I would ask him about it, but unfortunately he doesn’t.

Understanding C pointers: Part 1

As I said in “Understanding C pointers: Part 0,” I’m going to try to explain how C pointers work.

Let’s start with the basics. Here’s some simple C code:

  int x = 23;
  int y = x;


You can think of each variable as a box which holds the value of that variable. So in this example we have 2 boxes, named “x” and “y”. After these two statements execute the “x” box contains 23, and the “y” box also contains 23. The picture looks like this:
Example 1-1

Pretty straightforward stuff. If we add this code:

  x = 17;


the pictures changes to look like this:
Example 1-2

Nothing too fancy there.

Next example: let’s add a pointer into the mix.

  int x = 23;
  int y = x;
  int * p = & x;


If the * or & in the above code scare you, please take a deep breath and relax. We’ll get through this, I promise. 🙂

“x” is a variable of type integer. So is “y”. The “int *” before p means that p is a variable of type “pointer to integer” otherwise known as an “integer pointer.” Nothing magical there. The “&” before “x” can be read as the “address of x,” or “the box named x.” Which means the pointer “p” points to the box named “x”.

As in the previous examples we have a box named “x” and another box named “y”. This example adds a pointer to an integer called “p”. You can think of this pointer as simply another box, named “p”. The value in the “p” box is a pointer to another box. For the boxes “x” and “y” we can say things like “x holds the number 23,” but for the box “p” we say “p holds a pointer to the box named “x””.

A picture is worth at least a few words:

Example 1-3
Watch what happens when we add this next line to the example:

  *p = 17;


The * before the “p” tells us we’re changing the value of what “p” points to. We are not changing the value of “p” itself. The number 17 gets put wherever the value of the “p” box point to – which is the “x” box in this case. After this code runs our picture looks like this:

Example 1-4

Notice that “p” has not changed. “p” still points to box “x”. Only the value in the box that “p” was pointing to changed.

Let’s add a couple more lines to that example:

   p = & y;
  *p = 42;


The first line changes the value in the box “p” to be a pointer to the box “y”. The 2nd line changes the value in the box that “p” points to be 42. The result looks like this:

Example 1-5

Drawing these pictures may seem unnecessary, but I guarantee that drawing them will help you understand your code. Even if you understand pointers completely, when faced with a pointer-laden interview question it’s a good idea to draw your data structures and pointers. This way the interviewer can see how you’re thinking about the question, which is frequently more useful than simply getting the “right” answer.

Okay, that’s the basics. See – pointers aren’t that bad.

And it turns out that the way a computer actually implements variables/pointers is a lot like our simple “boxes” model. Tune in next time for more about that.