Hacks and Hack-Nots

The world is divided into two kinds of people: Hacks and Hack-Nots.

Hacks people hack.  They want hardware and software (aka “technology” or “tech”) they can change, optimize, use as they please, modify, destroy, etc. – in short, they want to hack.

Hack-Nots people do not hack. They don’t want to know what “hacking” means. They want their hardware and software to Just Work.  They don’t want to be aware of technology at all, they just don’t care.  They want to email, work, check Facebook, etc. – in short, they want to do something other than use the tech.  Technology is a means to an end, nothing more.

Hacks check email, Facebook, blogs, etc. just like Hack-Nots, but for Hacks the journey is more important than the destination.  The experience of checking email is more important than the email itself.  Configurability is key.  Even if it Just Works out of the box, Hacks will optimize it to their liking.  Technology is an end in itself.

For Hacks, optimization and configurability are more than just a Nice To Have, they are Moral Imperatives.  They believe it is actually morally wrong to not be able to mess with their technology.  They believe that being told they can only use C++ is slavery.  Even if C++ is their favorite programming language in the world, not having a choice is wrong.

For Hack-Nots, optimization and configurability are a distraction. Putzing around with settings is a waste of time.  They do not want to mess with technology that already works.  They do not care that software can only be written in C++.  They do not know what C++ is, and they will never care.

Until the last five or ten years most computing technology was made by, and for, Hacks.  Recently this trend has changed. Most technology is still made by Hacks, by definition.  Somewhere, however,  someone with an eye for the desires and dollars of the Hack-Nots took notice and is now telling the Hacks what to make.

Not in all cases, of course.  Most technology is still Hacks-only.

But the Hack-Nots are coming, and technology is on its way to meet them.  Hack-Nots will drive the marketplace simply because they are more numerous than the Hacks.

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.

The Death Of the Desktop

And no, this “death of the desktop” post is not about how mobile devices or the browser is taking over the world – it’s about taking a step back and rethinking how we actually use computers (desktop, mobile or otherwise), and then trying to take a more usable step forward.

Thanks to Chris Jones for writing about a very interesting talk by Aza Raskin:

Video: Away with Applications: The Death of the Desktop

You should check out Chris’s summary, and the video as well.

This is one of the few videos I’m glad I watched instead of just ripped to mp3 and listened to – a lot of visual stuff, well worth the time.

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.

Why bother with RSS?

(cut-n-pasted from my reply to a “Business of Software” forum question)

I resisted using an RSS reader for quite a while, mainly because it was “the new hotness” that I didn’t see any use for.

What made me start using it?

I read a fair number of websites, and I like to know when something new shows up. So I used to check each website every day and scan it for new content. Slashdot. Anything new? Yup, read a couple. Joel on Software. Anything new? No. Paul Graham’s rants. Anything new? No. Steve Yegge. Anything new? Yes, read it. You get the point.

The “load page – see if anything new” loop was getting tedious, especially since frequently there was nothing new to read, so loading the page was a waste of time.

Enter RSS. I chose NewsGator Online, subscribed to the websites/blogs I like, and *bam* – all the new content comes right to me, only one website (NewsGator) to load, no wasted time.

Well, unless you count the time I spend reading stuff on the web as wasted time, which might be accurate.

Note to Dell: You are forcing me to waste your money.

I have a Dell LCD monitor, still under warranty. It has stuck pixels. A lot of them. I would like to get a replacement monitor.

I would like to get the replacement taken care of with the minimum hassle for either of us. A simple email with my customer #, perhaps. Or maybe a web form with the order #.

Should be easy, I figure. I figured wrong.

Dell’s website has email and online chat customer support, but they require a Service Tag Number. Standalone monitors (not purchased with a Dell system) do not have Service Tag Numbers. The “Where is my Service Tag Number?” link on Dell’s website doesn’t mention that standalone purchase LCDs don’t have the Service Tag Number. I had to search for it myself. So I was forced to call their 800 for support.

Dell: you forced me to waste your money.

I spent 43 minutes with Dell’s phone support people getting the replacement monitor arranged. That’s 43 minutes of Dell’s money. Probably not much if it’s just me, but I imagine I’m not the only customer with this kind of issue – especially since this is my 2nd Dell LCD return for stuck pixels. On the positive side their rep’s were pleasant.

Can someone from Dell please allow me to use a customer number or order number instead of the Service Tag Number to contact your support people? It’s cheaper for Dell – and faster for both of us. Win-win!

I won’t even charge for my idea.

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.

Understanding C pointers: Part 0

“C/C++ Pointers are evil. Ditto direct control of memory via malloc, free, new and delete. Java, C# and other ’safe’ languages are the wave of the future, man!”

Even if you shouted a hearty, “Amen, brother!” after reading those sentences, the C/C++ languages can teach you something useful. Understanding how to directly control memory with “close to the metal” languages like C and C++ can make you smarter, which is a good goal even if you won’t admit to having used such old-school languages.

Of course that new knowledge may displace other knowledge you want to retain, like Mr. Belvedere episode plot lines or your wedding anniversary. You’ve been warned.

Over the next few posts I’m going to try to explain how C pointers work. I assume you’re at least a little familiar with a C-type imperative programming language – if you’ve ever seen Pascal, BASIC, Fortran, C# or Java you should be fine.

I’ve always heard pointers introduced to students as “a difficult thing, this is hard, you won’t understand it…” – which is baloney. It’s worse than just baloney, actually – it’s spoiled baloney (or bologna, I guess), because it not only tastes bad, but also makes you sick. It sets you up for failure. Telling someone that they can’t learn something, and then attempting to teach it to them is… well, I’ll just say it’s foolish and leave it at that.

Pointers are NOT difficult to understand when explained well – I hope that I’m able to explain C/C++ pointers in an easy to understand way – please let me know if anything doesn’t make sense!

Understanding C pointers: Part 1” is now available, check it out.

Blog, Cringely

Robert Cringely’s “I, Cringely” site has changed from a non-interactive plain ol’ web page to a blog format.

I can’t say that I care too much about the comments, but I do like the new page design.

Mostly I’m looking forward to more NerdTV interviews: “NerdTV is essentially Charlie Rose for geeks – a one-hour interview show with a single guest from the world of technology. Guests like Sun Microsystems co-founder Bill Joy or Apple computer inventor Steve Wozniak are household names if your household is nerdy enough, but as historical figures and geniuses in their own right, they have plenty to say to ALL of us.”

Cringely does the best interviews I’ve heard – he has awesome guests (that you frequently can’t hear elsewhere) and asks great questions. The production of the first season of NerdTV was hit or miss – some episodes had barely audible audio – but I’m guessing that will be cleaned up a lot in Season Two.