Movin' on up...

I'm moving to a new, hosted blog powered by WordPress. At the same time I'm combining my two blogs into one.

The new url is: www.losingfight.com.

Enjoy.

Context Switches

I'm about three weeks into my new partnership at Order N Development. Its a lot different from my previous job as a full time software engineer at Macromedia.

First, I'm an actual partner, meaning I own a large part of the company. That comes with a lot more responsibility. I have to fill out a lot more paperwork and just in general do a lot of non-engineering tasks. Expense reports, reading contracts, making bids, and so on. Of course, the fact that there only four of us influences this too.

There's a lot more multitasking involved. For example, I've already written up a spec for a potential client, hammered out a rough schedule for another client, reviewed a couple of contracts from potential clients, and brainstormed ideas for our own product. Oh, and somewhere in there I did some actual coding on a contract that we already have. Hopefully this is making me more "well-rounded" as opposed to "crazy".

I have to say, the contracts are the most disturbing part of the whole process. I can deal with generating product ideas, writing specs, architecting a feature, coding it, and debugging it. Contracts are a whole 'nother story. They aren't written in code or English, the only written languages I happen to understand. Contracts are written by lawyers with the express intent of trying to pull a fast one on you. The contract is a legal attempt to put all the responsibility on you while removing all responsibility from the client. But that's not clearly stated, its written in legalese so you have to spend $400 paying another lawyer to tell you how screwed you really are. A good measure of screwedness appears to be how hard the lawyer is laughing when he hands the contract back to you.

I'd go into specifics, but a lot of contracts say we're not allowed to mention the client's name without their express written consent. I understand that the clients are trying to protect their name, but come on. I just did a bunch of work and I'd like to be able to tell people about it. I'll admit that telling people "I can't tell you who I'm working for" sounds all cool and mysterious, but it doesn't really seem to bring in more contracts.

The other scary part is the money doesn't come in regularly. Well, since we're working several contracts right now, it kind of does, but nothing is guaranteed. I don't draw a salary; I just get money when the company actually makes money. The flip side is I'm not limited in how much money I can make. And that's kind of cool.

One of the things I am enjoying is ability to freely think of product ideas. What's so "free" about it is that I own any idea that I come up with. Yep. I'm not sure how many people would want a hamster powered beanie, but that's my idea, and I get to keep it. Seriously though, knowing that I get to keep any idea I generate is a pretty liberating feeling. It also makes the whole brainstorming process a lot more fun. I'm not trying to come up with an idea to make some large corporation another $100 million, I'm trying to come up with an idea that I'd like to work on and that I'm interested in.

And that's my goal: work on something that interests me.

Always Outnumbered

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

The Losing Fight

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.

Its all about style, baby

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.