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

I’m convinced it is impossible for a Mac engineer to be happy at a large company. It simply can’t work; it is fundamentally flawed.

For the past 5 years I’ve worked for Macromedia as “the Mac guy” on various projects. I started out on Fireworks for a few cycles before moving on to Dreamweaver. My job as “the Mac guy” was to maintain the Mac porting layer, write any significant Mac specific code, fix Mac specific bugs, help the other engineers get stuff working on the Mac, and in general handle anything relating to the Mac. For most part, I was the only Mac guy on the team.

When I first started at Macromedia, working for a well known company on a pretty well known product was an attractive proposition. People would know what I did, and lots of people would see and enjoy the fruits of my labor. I could influence an important product to be more Mac friendly. To me my greatest asset to the team was helping ship a great Mac product. Unfortunately I personally feel that I’ve never shipped a great Mac product. Fireworks was pretty good and Dreamweaver can only be described as “adequate.” Neither lived up to my expectations.

I began examining myself and the development process to figure out what went wrong to cause the Mac product to not live up to my expectations. It wasn’t a lack of observation; I knew what was holding us up. It wasn’t a lack of knowledge; I knew how to fix all the various problems. It was a matter of resources. I wasn’t given enough time to fix all the problems or add all the enhancements we needed. Furthermore I became increasingly aware that I was doing the job of two people, and we really needed at least two Mac engineers.

But the real problem wasn’t resources; it was economics. Both Fireworks and Dreamweaver are cross platform products. They run both on Windows and Mac. I’m not sure what the exact platform splits are, but the Windows product definitely sells more than the Mac product. Therefore it makes sense that the company invests more in that platform since it yields better results. It only makes sense to invest in the Mac platform so that the investment is lower than the returns. In this case, that apparently means only having one Mac engineer per team.

Its hard for me to fault Macromedia. Their decision makes perfect business sense. But it doesn’t make sense for me personally. My goal isn’t to make as much money as possible; I just want to write some software that I can be proud of, for the platform that I enjoy. Oh, and make enough money that I can eat.

My point is Mac engineers can’t be happy working for a large company that builds cross platform products. The goals of the engineer and the company contradict each other. The company wants to invest as little as possible into the Mac platform, while the engineer will want to invest as much as possible [1]. The engineer will end up stressed out, with no free time, a substandard Mac product, and a lot of frustration .

At the beginning I thought I could influence Macromedia to spend more money and time on the Mac product. After a while I realized that wasn’t in their best interest. My second idea was to try to do as much as I could personally. That had a small effect when I worked on Fireworks because the project was small enough and well designed enough. But when I arrived on Dreamweaver I realized that the project was too huge for me to make a difference alone. Unless the company decided to devote more resources I was only go to burn myself out. As I stated before, it wasn’t in Macromedia’s best interest to add more resources.

This is the reason I’m leaving Macromedia. It is a losing fight that I can’t win. Continuing there would only serve to burn me out even more. Of course, this begs the question: if not work for Macromedia, who? Given most large companies that have Mac products would be in the same boat as Macromedia, that didn’t leave many options. I am convinced the only way to ensure that my and the company’s goals align is to either own the company or work for a company that only makes Mac products. To that end, I am joining Order N Development.

I realize this post might sound like a whiney “I can’t win so I’m taking my ball and going home” rant. But its not. I’m saying I can win. I just have to play for a different team.

[1] The only contrary example to this is the Microsoft Mac Business Unit. Although Microsoft takes a lot of abuse from the Mac community, as far as I’m concerned they’re the only large company that has gotten it right. The Mac products are split out into their own business unit and can focus on making on a great Mac product.