In the Beginning...

[Note: This was the first post of my personal blog, Type 11 Error. The idea was have a blog that wasn’t restricted to professional endeavors. If you can’t bore them with code, bore them with your personal life, I always say.]

Its all Elaine’s fault, as usual. I was going about my merry way when she starts pestering me that I haven’t posted to my blog recently. That’s why this atrocity was born.

I actually have another blog, Safe from the Losing Fight, but I haven’t posted to it in a while. Its mainly about professional endeavors and thoughts, and I’d like to keep it that way. I haven’t updated it recently because of various NDAs and just simple lack of time. Since I’d like it to be professional the posts there take longer to compose and edit than the simple “what I had for breakfast this morning…” posts.

I’m starting this blog for several reasons:

  1. I have a new toy to play with (i.e. iWeb. A hint to those with engineers in their lives: If want something done, buy the engineer a toy that does said job. They still might not finish the job, but at least they’ll be happy for a while. And really, isn’t that the point? To make your engineer happy?)
  2. A place to log thoughts that aren’t necessarily professional, well composed, logical, or human.
  3. For the proud llamas. You know who you are.

As you might note, with some dismay no doubt, the name of this blog is even geekier than that of my “professional” geek blog. I’m quite proud of that. It just goes to show I’m even more of a dork in my personal life than in my professional. I try not to disappoint.

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