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.

A Great Quote From “Dreaming in Code”

“What are the odds your software is going to change?”[David] Cook asked in a jovial blare. “Oh, 100 percent. It’s going to be around for 10 years. You’re going to have to modify it more times than you can imagine. You’re gonna have to change it for different hardware and software environments, change languages three times, and go through four personnel turnovers. What you have to do is fight as hard as you can to keep quality up so that ten years from now you have something left.

“It’s like, when you grab the software that’s in your hands, it’s sand. And as you stand here doing the best you can, sand starts leaking between your fingers. Ten years from now there’s a few grains of sand left, and that’s all you have to work with. Your job is to keep your hands as tight as possible.”

From page 259 of Scott Rosenberg’s “Dreaming in Code.”

How Much Do You Make?

This piece from FastCompany.com talks about what would happen at a company if everyone knew what everyone else made. I’ve had that conversation a number of times, but I didn’t know of any company that had actually done it until I read that article: Whole Foods lets any employee see what any other employee makes.

“Our books are open to our Team Members, including our annual individual compensation report.”

There it is in their Core Values, plain as day. Another interesting bit from their Core Values:

We recognize there is a community of interest among all of our stakeholders. There are no entitlements; we share together in our collective fate. To that end we have a salary cap that limits the compensation (wages plus profit incentive bonuses) of any Team Member to nineteen times the average total compensation of all full-time Team Members in the company.

A quick look at Whole Foods over at Yahoo Finance says that their highest paid exec made $371,000 of pay (salary + bonuses). If that’s the high end of the “19 times average total compensation” figure then the average full time Whole Foods employee makes $19,500. That works out to about $9.39 per hour, assuming 52 forty-hour work weeks per year.

Is that a lot of money for a grocery store employee? I don’t know, I’ve never worked in a grocery store.

But I do know this: I shop at Whole Foods a lot, and I am almost always struck by how happy their employees seem. The girl at the register seems to be enjoying her job as she chats with customers and coworkers. The folks in the wine and beer sections are excited to help me track down a particular beverage, and seem as satisfied as I am when they find it. The gelato guy really wants to know what I think about the new mint-pineapple-ginger flavor.

Does the company’s openness about compensation make their employees any happier? I don’t know, but it sure doesn’t look like it hurts.

Live Search is Lost

If you search for “instant coffee” on Microsoft’s search.live.com, my “Instant Coffee == Instant Yuck” appears in the top 50 results.  Which is a shame.

My post basically says, “Instant coffee bad, home roasted coffee beans good.”  I don’t think anyone searching for “instant coffee” really cares about that.  They probably want to research or buy instant coffee.  Other search.live.com results are equally lame.  Not 100% lame, a lot of the search results are good, but come on, my drivel shouldn’t be in the top 50.

Google’s results are more what I would expect – a bunch of instant coffee reviews and purchase information.  My post doesn’t show up in Google’s top 500, or Yahoo’s top 500 either.

Microsoft gives me no reason to even try their search engine again.  The Yellow Pages would probably be more helpful.

Smart Bear Software – Peer Code Review Book

A while back I promised to read and review Smart Bear Software’s book “Best Kept Secrets of Peer Code Review” – I read the book right away, but haven’t yet made the time to actually write up a review – so let me give a brief review now: I like it.

The book is easy to read, with a relatively conversational style of writing. It covers “old school code review” – big formal affairs – and introduces lightweight code reviews as well. It also presents results from a number of code review studies (including Smart Bear’s Cisco study which they call “the largest case study of peer code review”) which show that code reviews of any form are a good idea.

The book is a good summary of code reviews, and Smart Bear’s brand of lightweight peer code review sounds like a great way to implement them.