“Creation is entirely dependent on ownership.

Ownership not as a percentage of equity, but as a measure of your ability to change things for the better. To build and grow and fail and learn. This is no small thing. Creativity is the manifestation of lateral thinking, and without tangible results, it becomes stunted. We have to see the fruits of our labors, good or bad, or there’s no motivation to proceed, nothing to learn from to inform the next decision. States of approval and decisions-by-committee and constant compromises are third-party interruptions of an internal dialog that needs to come to its own conclusions.”

Check out Ben’s full post: http://pieratt.tumblr.com/post/977179815/in-praise-of-quitting-your-job

Don’t let the title of “In Praise of Quitting Your Job” fool you into thinking it’s a negative post – it’s not.  It’s a positive post, which lines up well with Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.”

Drive looks at “the three elements of true motivation—autonomy, mastery, and purpose,” which is another way of talking about what Ben calls “ownership.”

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.  :-)

I’m glad that Randall has the guts to tackle the tough issues facing the world today: emoticons in parenthesis. Check out the comic.

Since I’m starting my own copyediting and proofreading business, this issue is particularly timely and relevant for me.

Randall outlines the basic options:

• blah (or blah :)
• blah (or blah :) )

The first option looks like the author threw an extra colon in there.  The second option looks like the author mashed the keyboard with her elbow.

We also need to consider these options:

• blah (or blah :-)
• blah (or blah :-) )
• blah (or blah :-D)
• blah (or blah :-D )
• blah (or blah :-)-)
• and what about (this (or this (it gets ridiculous fast :) ) )

“American” English writing style is primarily dictated by two style guides: The Chicago Manual of Style (CMOS) and The AP Stylebook.

I could only find references to emoticons and parenthesis in CMOS, and it dodges the question (source):

Until academic standards decline enough to accommodate the use of emoticons, I’m afraid CMOS is unlikely to treat their styling, since the manual is aimed primarily at scholarly publications. And the problems you’ve posed in this note give us added incentive to keep our distance.

If the experts are no help, what are we to do?

Thankfully the web makes everyone a Certified Internet Expert (including me :) ), so follow along as I puzzle it out.

Round One

• As a programmer I want each open parenthesis “(” to match exactly one close parenthesis “)”.
• As a writer I realize that an emoticon must be considered as a whole, not merely as a collection of individual characters.  Therefore any parenthesis or other character within an emoticon should have no bearing on the punctuation of other words.

Round Two

• As a programmer I know that I will try to visually match each parenthesis pair I see.
• As a writer I find “) )” slightly less offensive than “))”.

Round Three

• As a programmer I will use sed or vim or a Firefox hack to rewrite any text I don’t like, so I don’t really care what you writers think.
• As a writer I want the rules that govern “:)” to match the rules that govern “:D”.

The Decision

As a Certified Internet Expert I decree that emoticons shall be considered as a single symbol.  An emoticon shall always be followed by a space.  If an emoticon ends a parenthetical phrase, the closing parenthesis that matches the opening parenthesis must be used, regardless of whether the emoticon itself contains a parenthesis.

Correct examples:

• He said he would be happy to do it (he lied :) ).
• He lied (she knew he would :D ).

Tune in next time for another exciting episode of geeky grammar.

• What do you call it when you get exactly 6 M&M’s in a single turn of the dispenser, one of each color?  M&M Yahtzee?  Full House?
• And how about when you get more than 6 M&M’s in a single turn of the dispenser, with at least one of each color?

Suggestions?  Please leave a comment!

PS: the 6 M&M’s colors are red, orange, yellow, green, blue and brown.  See for yourself.

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.

I love xkcd.

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.

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.

http://www.tokyoflash.com/en/watches/1/

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:

Pretty straightforward stuff. If we add this code:

  x = 17;

the pictures changes to look like this:

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:

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:

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:

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.