Proudly Serving My Corporate Masters

Danny Yee popped up this review from down under of the provacatively titled Proudly Serving My Corporate Masters: What I Learned in Ten Years as a Microsoft Programmer . This sounds like a fun read, but not without flaws.

Proudly Serving My Corporate Masters author Adam Barr pages 342 publisher Writers Club Press rating 8 reviewer Danny Yee ISBN 0-595-16128-6 summary What Adam Barr Learned in Ten Years as a Microsoft Programmer

Barr worked as a low-level developer at Microsoft and his account in Proudly Serving My Corporate Masters, built around his firsthand experience, offers a perspective on the company "from the ranks". This is combined with more general commentary on recent computing issues, with reflections on evangelism, community, and open source. The result has something for a range of people: those curious about Microsoft, involved in debates about the merits of open source, responsible for recruitment and management of programmers, or just interested in computing history.

Barr begins by describing how he came to work for Microsoft. This is the start of four chapters on Microsoft's recruitment system, covering both the initial selection on campus, the interview system, and the overall effectiveness. There is also an introduction to how work is structured at Microsoft, in particular the division between developers, program managers, and testers. Three chapters then describe Barr's time at SoftImage, a Microsoft acquisition producing digital editing software. Here we are introduced to the different types of "demos" (from carefully scripted sessions presented by special "demo artists" to genuine "hands-on" demos) and the complexities of dealing with third-party hardware suppliers.

Three chapters then present a potted history of computing over the last twenty years or so, beginning with an account Barr wrote as a teenager back in 1982, after visiting ComDex. Barr focuses on evangelism - on the factors that contribute to one platform or operating system winning out over others - and in particular why IBM PC hardware became ubiquitous, why MSDOS beat CP/M-86, and why Windows beat OS/2. None of this is particularly novel, but it's a nice lively account.

This leads naturally to more recent conflicts and debates which pit (as flagship icons) Microsoft against Linux. Again, there is nothing spectacular here, but Barr offers an intelligent, informed, and balanced perspective, coming up with some points that were new to me. Of the claim that it will be difficult to find programmers to do the "unsexy" work with Linux, for example, he writes

"Microsoft, being a company with salaries and a supervisory hierarchy, has the ability to order someone to work on something he or she doesn't want to work on, but I never recall this happening. People worked on things that interested them and projects still got complete coverage. There is no reason that the same should not be true of Linux, especially given the size of the Linux community."

Two chapters evaluate attacks against Microsoft, the first addressing popular criticisms and the second the various legal attacks. Here Barr is level-headed, calmly rebutting some of the sillier attacks while accepting valid criticisms.

A major weakness of this material is that Barr only ever talks about "open source" (a development methodology) and never about "free software" (a much broader movement). One major reason for techs ranting at Microsoft is their unhappiness with loss of choice, freedom, and control - and this has been articulated as an ethical and political position by the Free Software Foundation and others. But Barr never considers this argument against Microsoft at all.

A chapter on online community is really a digression. The final two chapters then consider the future of Microsoft. Barr argues that Microsoft should stick to its core PC business and not get distracted by ventures such as the XBox. He ends where he started, arguing that the key to Microsoft's future lies in its handling of employees, in its ability to attract, recruit, and retain good people.

Proudly Serving is nicely laid out and has obviously been carefully edited. Barr avoids most technical details (an exception is some discussion of buses and video hardware in the chapters on SoftImage) and offers separate digressions on Code, APIs, and Middleware. A minor complaint is that the workings of Microsoft stock options are only explained in the last chapter, by which point the reader will either have worked it out for themselves or decided they don't care.

Purchase this book from FatBrain. Visit the author's web site or check out Danny Yee's five hundred other book reviews.

Comments

excerpt from the book:

[selectspec]

...which is when they took me to the elevator with the granite doors. My Controller put his hand over the elevator access panel. A strange growl seemed to bellow up from the floor, and the doors creaked apart. This elevator was more suited for a gothic asylumn than a software company. We stepped inside the spacious elevator.

There were no buttons. The walls were inlaid with strange runes and glyphs. Once we'd entered the doors closed quickly behind, and we began our decent. The air seemed to quiver, and I felt a great uneasiness. My Controller's face was unmoved. He still wore his dark glasses despite the relatively dim lighting.

We came to slow halt, and the doors opened. What images then came into view are so horrific that the very thought of them puts me into a terrible panic.

A vast hall stretched forth lined with arches the likes my eyes had never seen. Arrayed in a great grid were hundreds of people strapped into black chairs which seemed to envelope their bodies. My God. It was them. All of those ex-Mac developers. So, here is where they'd all gone. Their bodies shaved and naked were bristling with wires and tubes anchoring them into some kind of demonic machine beneath the floor. I could feel the dark energies churning beneath my feet and imagined huge gears grinding in an alien orchestra devised for some purpose beyond comprehension.

Two Controllers approached from the far side of the hall. In their hands were strange surgical tools. But, these warped, metallic devices were for no humane medical operations, but for some preverted task of which I wanted no part. I tried to run, but my Controller grapped my arm with a cold grip of uncanny strength. Then I remembered what the crazy old man had told me in the town...

karam whoring

[jon_c]

Funny enough I was just reading about the author and some of his columns: here's some links

columns
home page
comments posted at kur5shin.org
stories posted to kuro5hin.org. one i like is where he talked about NT's TCP/IP stack history and why it's not from BSD
He's no MS shrill he was the one a while back proposed that we use the XBox as a cheap web farm

anyway interesting stuff.

-Jon

Re:Ten years as a low-level programmer?

[friedo]

I took that to mean "low-level" as in device drivers and hardware interfaces, not rank.

But I guess I'll have to go read the book. :)

Internship program

[ccf]

I did a summer internship as a Software Design Engineer in Test at MS a few years ago. I found it kinda weak. The interview process was really rigorous, they make you jump through all sorts of hoops, solve programming and logic problems etc. But the work itself I found held little of the excitement of the interviews. It didn't have the challenge I wanted, I felt overqualified for the work. I felt like they were trying to sucker me into to working there with all kinds of benefits, free bike, free sodas, subsidized car and apartment, gym membership, etc, but really the work was not fulfilling.

Free, liberated, and zero-cost software

[Frank T. Lofaro Jr.]

Maybe we should call it liberated software, so people will understand what we mean. Free is more often used to mean without cost, rather than with liberty, and people assume the most common meaning.

Software that is given away, but not open source, we should refer to as zero-cost software.

Saying liberated software versus zero-cost software makes everything completely unambigous.

Book is also online

[General_Corto]

for those that don't want to shell out for the book, you can read it here. That's certainly what I've been doing.

Wow! I had no idea Microsoft was evil

[tenzig_112]

It is reprehensible that Microsoft would "force someone to work on something they don't want to work on." Dammit, Microsoft! This whole work full time and get paid weekly thing has got to stop! What's next? Demanding that people meet deadlines and check their work?

Until I read this, I had no idea that Microsoft was evil.

If we can't get the government to split them up, we must find a way to keep consumers from making computer/OS buying decisions that fit their needs.

There must be a way.

Tasty...

[zephc]

"'Proudly Serving My Corporate Masters'... it's a cookbook! Nooooo!"
----

Re:Employee of MS

[Water Paradox]

Major Burrito:

It amazes me that you could write so innocently on this topic. You unknowingly gave a revelatory insight into the way MS programmers think, and how they are able to justify the work they do.

Before you can understand anything I will write in this short essay, you must realize that MS programmers think fundamentally differently than most free software/open source programmers. And that way of thinking is clipped by a desire for money which does not exist in the Open Source environment.

In essence, as you so eloquently made clear, we open sourcers do not work for money. We work primarily for passion, with money as a secondary issue. MS employees are the opposite, they tend to work for money first, and passion second. Thus 'they were continually amazed at the amount of work that is poured into free software,' as you said. To Open Sourcers, this is not a source of amazement. This is simply a moment of recognizing the fact that others enjoy programming as much as I do. Lots of others.

Work For Money vs. Work For No Money? It's not quite that simple, but you can understand a lot if you use that as a reference point in building principles to understand what is happening. Here is why I prefer this as a reference point:

For the love of money is the root of all evil: which while some coveted after, they have erred from the faith, and pierced themselves through with many sorrows.

If you stand back from the whole MS/Open Source debate from any distance, this kind of generalization becomes possible, and necessary if you want to comprehend it in a meaningful way. There are many complicated issues stemming from this single duality, none of which I want to address here.

My point is that MS employees work within the "old" American Dream, where all you need to do is get a decent job making money, work at it for a number of years, and voila! You're retired, driving your RV around the country, untrammeled by the daily woes of the great masses.

This doesn't work for the artist. The artist doesn't want to live a life dreaming of the future. The artist LIVES in the future, and makes his own life beautiful each day. Thus, you'll never find an artist in an RV. He can't afford one, and thus has no desire for one. Instead, he creates something beautiful each day, and sleeps well that night.

Sleeping that well at night is a mystery to the man who seeks money. Artists have all kinds of problems we don't need to get into, so I'm not glorifying the art of being an artist, I'm only presenting it side-by-side with the typical MS programmer, who works for money, not for passion. I work for passion. I create an entirely different kind of product than my co-worker, also a programmer, who works for money. Sure, he has passion, but it is sublimated beneath his desire to fulfill his portion of the "American Dream." I chuckle wrily at his earnest efforts to get something THAT ALWAYS MOVES AWAY FROM HIM.

I say, Major Burrito, latch on to the American Dream which is not an illusion. Let Nikola Tesla be your role model, not Thomas Edison. Both were phenomenal inventors. But a close study of their two lives reveals that one worked for money and the other worked for passion. (Both were money hungry, but one more than the other). Same with Salieri and Mozart, Plato and Aristotle, Freud and Jung, and so many other great dualities.

The point I want to make is that the MS perspective is only half the spectrum. The other half is populated by people who wonder what MS would be like if it were programmed by people with REAL passion, not one sublimated by other desires.

This is an easy thing to see for most Open Source programmers. As for whether Open Source programmers have talent or not... we do it the hard way. -Water Paradox

Re:Employee of MS

[dasmegabyte]

Well, the best modellers in the world don't necesarily design for Revell, and the best mechanics aren't necessarily down at your local BF Goodrich. Programming is a skill, to be sure, but you don't have to put your skills to work for you, or necesarily charge people when you use them. I'm sure we all have skills or know people who do that are of a professional level, perhaps even a superb level, but don't have that particular job. How many of us slashdotters are accountants with hardware and networking skills, doctors with oratorial dictation skills, and so forth?

I may program now, and program well, for money. But I don't always want to be a snooty wage slave working for the corporate world, turning coding tricks for people richer than me. Someday, I want to teach (academia being a relatively level field)...but when I do turn in my ASP in a Nutshell book and swipe card, I'm sure as sin not turning in my programming skills. I'll probably just move them into another arena: freelance, shareware, open source free software. "Top tier engineers" aren't necesarily what free software needs -- an engineer once told me that you only have 8 years of programming time in the industry until you're technically just a product manager, telling younger programmers what to PEEK and where to POKE. Linux succeeds because the people who do the boring work(printer drivers, TCP/IP interfaces, and so on) are the ones who need it done...the incentive to do the work isn't "i need to get paid," but rather "i need to print something. It's survival-response programming, patch-the-inner-tube programming, and it's why Linux is often very terse in its interfaces...but still very efficient.

Douglas Coupland

[beavis_kc]

Microserfs by Douglas Coupland was a great book for the theme as well.

Employee of MS

[MajorBurrito]

I worked for MS as in intern a few summers ago, and I hung out with some the real high-level programmers (the ones who get to make REAL decisions) during my smoke breaks. They had an interesting perspective on free software.

Their most convincing argument is that programming is a job. It's work, and it can be hard work at times. But if all software is free, then who pays the programmers? It's pretty clear by this time that selling support contracts don't work. If a company can't pay its programmers, then who would work for them.

They were continually amazed at the amount of work that is poured into free software, and they wondered what Linux or *BSD would be like if there were some system for everyone who contributes to be compensated. I can recall one of the engineers saying something like, "We [MS] wouldn't have a chance if people with REAL talent [professional programmers] were contributing to the free software movement. Thank god the only people who really contribute are kiddies."

Now, I don't think everyone who contributes to free software is a kiddie, but it does bring up an interesting point: what would Linux be like today if it could attract top-tier engineers?