Safe from the Losing Fight

Its hard being a Mac guy. Even if you’re not an engineer you have to deal with no tech support, lack of Mac friendly services, and Windows users teasing you that Photoshop is the only game available on the Mac. psh. They always forget about Microsoft Excel.

So what’s different when you’re a Mac engineer on a cross platform product? A lot. Let me tell you, if you’re going to be a Mac user, you might as well be an engineer. Its that good.

First, IT is thrilled when you come around and line up to help you. Back when I first joined Macromedia they were just getting around to installing Airport networks. In addition to setting up the base stations they obviously had to get wireless cards for all the computers and get them installed. During that time I had one of the Pismo Powerbooks which required a somewhat involved procedure to get the Airport card installed. You had to pry up the keyboard, use a screwdriver to remove the harddrive, and then somehow wedge the darn thing into place without bending any of the pins. I’m pretty sure the packaged instructions also suggested sacrificing a squirrel to ensure it’d fit, but I wasn’t sure how I’d explain all the blood to facilities. I mean, it wasn’t Thursday.

When I first got my Airport card I was just going to install it myself until I realized what was involved. It also occurred to me that we had an IT guy whose sole job was to be “the Mac guy.” I’ll call him Dick, because it just seems appropriate. Dick didn’t work on PC’s or the network, he only worked on Macs. That was it; his sole purpose in life. I thought I could drop off the PowerBook to get the Airport card installed and continue doing “engineering things”[1]. I moseyed on down to Dick’s office and cheerfully asked if he’d install the Airport card for me. Without even looking up, he said “Most Mac users are more self reliant.”

Feel the love.

Oddly enough, Dick was one of the first people let go when the layoffs came. I don’t know why.

But don’t worry, the loving support of your corporate family doesn’t end there. As the sole Mac engineer[2] you get to be everybody’s mother. You get to clean up their messes in the Mac code when they didn’t feel like doing it right. This experience is heightened by it being like an Easter Egg hunt. They’re not going to tell you about their mistakes, you get to go look for them when the bug reports roll in. And no, rubbing their noses in the naughty code doesn’t improve the Windows engineers’ behavior. It only seems to encourage them.

However, the biggest gift your engineering brothers can give you is the opportunity to interact with the Mothership, and impress the smart people at Apple. When Apple releases a new version of Mac OS X sometimes existing versions of applications break. This is often because engineers were relying on undocumented or unsupported behavior. When Tiger was released I had the great fortune of finding one of those special “Easter Eggs” that one of my fellow engineers had thoughtfully left for me.

The easter egg was pretty simple. Mac OS X is now a version of Unix and uses the Unix path separator, “/”. In a previous life, the Mac had its very own path separator, “:”. The result is sometimes Mac OS X wants an old school Mac paths, but other times it insists on the new style Unix paths. In this case Dreamweaver was given a Unix path but needed a Mac path. The solution is simple: you give the Mac your Unix path and tell its a Unix path and ask for a Mac path back. Well, this was apparently beyond my fellow engineer, who was apparently convinced the correct way to handle the situation was to give the Mac his Unix path, but call it a Mac path, and ask for a Windows style path back. For reasons that probably baffled him, this didn’t do exactly what he wanted. So he wrote some special code to hack up the resulting path so it would work on his machine.

The problem here is that this was all in shipping code when Tiger came out. Management didn’t want to go back and re-release the previous version with this one bug fix for obvious reasons. The only solution they saw was to ask me to ask Apple to change their API’s to do something random instead of what they were documented to do. And let me tell you, Apple was thrilled to change their code. I ended up speaking with an Apple engineer about it:

Me: Hey, do you know that API that converts Unix paths into Mac paths?

Apple Engineer: You mean the one that’s so well designed and documented that a brain-dead chimp could figure it out?

Me: Um… yeah, that one. We… we need you to make that not do what it supposed to do.

Apple Engineer: ….

Me: Yeah, so a Windows engineer got into the code and…

Apple Engineer: Are you on crack?

Me: No, no, a Windows engineer wrote the code. They didn’t know what they were doing.

Apple Engineer: …right….

Me: Honest, I would never write code like that!

Apple Engineer: But you need an API to do the opposite of what its documented and designed to do?

Me: Right, right. But its not for me. Its for a Windows engineer.

Apple Engineer: ….

Me: ….

Apple Engineer: …

Me: Are you guys hiring?

Apple Engineer: click

Me: Hello?

I’m expecting a call from them any day now.

Being a Mac engineer means your fellow engineers will always keep you on your toes and have the upmost respect for you. I often had to update the Mac tools to get new features or improved support. This required the other engineers to upgrade the tools on their machines as well to maintain the ability to build the product. So after making the appropriate changes and checking them in, I’d send out an email with instructions. They were promptly ignored. Without fail, a few days later the following conversation would occur at least once:

Fellow Engineer: (Agitated, as if something’s wrong) Hey, did you know the Mac doesn’t build?

Me: hmm… well we had an automated build this morning and I just sync’d and built. Maybe its something on your machine?

Fellow Engineer: No, no. I reinstalled all the tools on my machine and did a clean sync. Something is definitely broken.

Me: OK, what errors are you getting?

Fellow Engineer: (Proceeds to describe the exact errors I outlined in my email that you would get if you didn’t upgrade)

Me: Did you follow the instructions in my email that I sent out?

Fellow Engineer: What email?

Me: The one titled “Follow these instructions if you ever want to build on the Mac again”.

Fellow Engineer: Oh….. was that important?

Me: If you want to build on the Mac, it is.

Fellow Engineer: Oh…. I’m pretty sure I deleted that immediately.

Me: (sighs) Do you want me to resend you those instructions?

Fellow Engineer: Well… I just have this Mac specific bug here. Maybe you could take it?

Me: I don’t know…

Fellow Engineer: Great! I’ll go assign it to you now!

Me: (mumbles obscenities)

Fortunately upper management is always there to offer guidance, like any good parent would. At one point we were getting unsubstantiated reports of performance problems. Upper management knew the best way to handle it was to ask Apple what the problem was. Being the naive engineer, I suggested that we might actually try to figure out what was allegedly slow and work on it. I was assured that wasn’t acceptable. We definitely needed to ask Apple what the problem was before we did anything. I’m not sure what my email was supposed to say. Maybe “Hi. We don’t have a clue. Do you have an app that fixes that?”

But in the end, its the customers that make it all worth while. They always have encouraging things to say. Like “Who wrote this? A trained squirrel? Hire a real Mac programmer!” It warms my heart. But without a doubt, I always enjoy the interaction with customers that I get on the beta lists. After spending months on a feature you have uplifting conversations like this:

Customer: This feature you just spent the past six months on sucks!

Me: Oh. Well what’s wrong with it?

Customer: It uses blue. Blue! What were you thinking?!?!

Me: Oh… ok. Um, what should have we used?

Customer: I don’t know! But not blue! You guys suck! I hate you!

Me: Well its just a preference. You can change it to whatever color you want.

Customer: But what about the newbies? huh? The blue is just going to confuse them and they’re not going to know how to change it!

Me: (sighs) OK. Write up a bug report and we’ll find something to change it to.

Customer: What?!?! I don’t have that sort of time!

Me: OK, OK. I’ll write it up.

Customer: Hey! The bug report doesn’t say exactly what I want it to!

Me: Well I had to write it up for you…

Customer: So? You guys don’t care about customers at all! I wouldn’t buy this with your money!

Me: …

Customer: I’m getting the software for free, right?

Me: (sighs) Yes.

Customer: Awesome!

Why would you ever want to do anything else?

[1] Its not my fault that doing “engineering things” sometimes looks like playing Quake.
[2] What? You think you’re going to get help? Didn’t you read the previous paragraph? “Most Mac users are more self reliant!”

Seriously, people. You’d think we’d have learned this by now. Style is vitally important when you’re an engineer.

Now when I say “style” most engineers think about aesthetic stuff, like where they should put their curly braces. Why, I’m not sure. There are two basic camps here. Either the curly brace on the same line:

if( foo ) {
}

or each brace on a separate line:

if( foo )
{
}

I’ll refer to these as “humdinger” and “hootinanny” because calling them “style A” and “style B” is just plain boring.

Anyway, engineers will argue for hours if not days about which one is the One True Curly Brace Style. While this can lead to an amusing “Family Guy” type conversation, it doesn’t usually accomplish anything. Then someone, usually a troublemaker, will suggest a style I call “wazzat?”:

if( foo )
 {
 }

and the arguments will start anew. The truth is, it doesn’t matter. It simply won’t effect the user in any way. I’ve switched between “humdinger” and “hootinanny” when switching projects with no problems. It turns out humans are remarkably adaptable. Sure, I’ll ask God when I get to heaven which one is the One True Curly Brace Style, but right now, it doesn’t matter. (I expect to be told “wazzat?” was invented by Satan himself.)

No, when I speak of style, I’m talking about stuff that will actually effect the stability and quality of the product. For example, always initializing your variables as soon as you declare them.

A lot of engineers do this:

int i;
// go use i

I say that that’s incorrect and you should do something like:

int i = 0;
// go use i

I suspect that I wouldn’t get many arguments about this. Sure someone might say “well I initialize the variable on the very next line” or “I have rugged good looks, so uninitialized variables don’t effect me.” [1] The problem with waiting to the next line to initialize the variable is your fellow engineers (aka “those sniveling weasels”) are going to insert code between your declaration and when you use the variable. Sure it’ll start out with something innocent, but eventually someone will use the variable before you initialize it and pandemonium will ensue. I don’t know how many uninitialized variable bugs I’ve fixed in Dreamweaver, but its enough that its become a pet-peeve of mine. It concerned me enough to send an email to all the engineers pleading for everyone to initialize their variables.

So that’s it, right? Once an engineer learns about a coding style that will improve their code they immediately employ it. After reading this, no one will ever declare a variable without initializing it in the same statement. No one on Dreamweaver’s engineering team ever checks in code with uninitalized variables now. Right?

Well, unfortunately no. I was quite surprised to see the change notifications that rolled past after my impassioned message about uninitialized variables. Sure there were a couple of engineers who picked it up and even started cleaning up code as they saw it. But the surprising majority ignored my request. And why is that? Didn’t they care about the users suffering through crashes? Couldn’t they see the brilliance of my suggestion? Wasn’t I condescending enough?

Engineers resist change for a variety of reasons. First, change might imply they were doing something wrong in the first place. Some engineers hate to admit that. Typically, these aren’t good engineers in the first place, so I’ll ignore them for this discussion.[2] Second, engineers have strong coding reflexes. They typically aren’t thinking about the syntax of the language, but the logic they’re writing. As a result, its hard to add new coding styles to their repertoire. They have to stop and think “oh yeah, I need to initialize this variable immediately.” That slows them down and is sometimes skipped. As a result, the new coding style doesn’t become a reflex.

And that’s the key. The new coding style must become a reflex or it will be unused and the engineer’s code will not improve. When I’m trying to pick up a new style I have to type slower and think harder about what I’m doing. Also, if I mess up and don’t employ the new style, I force myself to go back and fix it immediately. A lot of engineers make the mistake of saying “oh, I’ll come back later and fix this.” No you won’t so stop lying to yourself. Its time for an intervention, Sparky. If you don’t start using a coding style pretty much immediately, you won’t use it, ever. You’ll forget about it. So slow down and start using the new style right now. Also, as you go through old code start “upgrading” it to use the new style. It will not only improve the code, but help you build your reflexes.

I’ve seen innumerable articles about various coding styles. Most are about the author’s personal preferences and what visually looks good to them. And that’s fine if that’s what they care about. However a good engineer has to be able to separate the wheat from the chaff. Fortunately, that’s easy; just ask yourself “will this improve the user’s experience?” If yes, then adopt the coding style immediately. If no, leave the trained squirrels to argue about how much space should go between an if statement and the first parenthesis.

Although its hard to argue that coding style is as important as selecting the correct algorithm or data structure, style is still vital. Its something that can be improved without too much effort. In fact, after it becomes a reflex its not any extra effort. Improving your coding style can improve your code and more importantly, improve the user’s experience.

[1] People with rugged good looks don’t seem to worry about much of anything. I’m not sure why.

[2] A dicussion on trained squirrels would take up an entire article.

[Note: This was the orginal post for my “professional” blog. It attempts to describe why I started a blog. It certainly wasn’t because I’m interesting.]

Or writing is hard, I should say. But “math is hard” is what one of my coworkers told me. I was trying to explain something technical (like how virtual memory works) when her eyes glazed over. I get that a lot. Anyway, she got some terms mixed up and said something like “so should I test the multiflange array for tacheon emissions?” Or something like that; I don’t really pay attention to the QA people. But her response to my laughter was “math is hard.”

Although math has never been all that hard for me, it did remind of what is. Writing. Being a software engineer I’m more used to communicating with computers in written form than humans. That means writing interesting specs or design documents or just communicating with coworkers is pretty difficult for me. Unfortunately submitting instructions via email to someone isn’t like writing a program to run on a computer. People don’t listen well and take exception to being called “buggy.”

Recently Joel Spolsky has been writing about the lack of good writing in the software engineering field. He’s asserted that good writing skills are essential to a software engineer’s career, and even compiled a book on what he considers to be good writing. Among his suggestions for engineers wanting to get better is something he calls “practice.” I decided to give that revolutionary idea a chance before Microsoft patents it.

So that’s the point. This is just practice. i.e. This is pre-alpha quality writing not meant to be used in a production environment. Use at your own risk, and keep all appendages inside the cart at all times.