Slashdot Mirror
Microsoft in the Mirror
Microsoft in the Mirror is written for a general audience, though some of the stories it contains are probably going to draw grins or nods only from readers interested in software and programming.
The collection of employee portraits -- first person, no last names -- starts with Carter's account of being hired (as an admin), then promoted over the course of years at the company to Editorial Assistant and eventually into management. Carter joined Microsoft when the company had a few hundred employees and called itself MicroSoft. Working in multiple divisions and levels of employeedom gave her a chance to see more of Microsoft than many employees see of the companies that employ them. (The book continues with a chapter apiece for the others; Carter's account is actually split into two, bookending the 18.)
Mirror is a breezy, personal self-portrait -- maybe too breezy and personal for some tastes; just a few pages into her text, Carter has already been through one boyfriend (her initial draw to Seattle), and a 9-year marriage (maybe I should be surprised that she mentioned it at all), and several job titles. Given the company's growth rate in its early years, perhaps this compression is necessary, but I would have enjoyed finding out more about the early days in detail, a Microsoft equivalent to the way Steven Levy describes an important stretch of computer culture in Hackers.
Though Carter's is a complete and interesting Microsoft experience (complete with sudden, transient wealth), most of the best content in this book comes from the other employees she prompted to share their stories. They speak with their own voices, in a range of prose styles and breadths; they range from chatty to Garrison Keillor-style droll, and though many of the employees' responses overlap (for instance, nearly all of them talk about their Microsoft stock options, either because those options made them rich, or because the shares and options they mishandled still haunt them), each one adds to the picture of Microsoft -- the corporation -- as a complex and demanding employer, and Microsoft -- the workplace -- as one where dress is casual, coworkers are (mostly) respectful and friendly toward each other, and office pranks are mostly good natured and elaborate.
(A few of the programmers profiled had their offices remodeled by
coworkers: Peter's floor was covered with sod, complete with
instructions to water it by activating the room's sprinkler head with a
helpfully supplied lighter, and Stewart arrived for his second day of
work to find his office occupied -- completely -- by an inflated pink
weather balloon.)
Carter (and her respondents) don't try to separate the personal from the
corporate: at a company where perqs like windowed offices for
programmers and well-stocked snack rooms for everyone are tradeoffs for
long days and nothing-is-impossible project schedules, that would be
impossible. This is refreshing at first, but after several chapters I
found some of the stories mixing in my head.
The first chapter I read was written by Yoshi, an ambitious and confident former Adobe employee, who engineered his way into a job at Microsoft when he saw Microsoft's development of TrueType looming ominously on Adobe's future -- and cutting the value of his company stock in half. So he jumped ship.
"I figured that if I took a project at Adobe that was directly relevant to MS, I would have a good chance of landing a job. So I did that, and we subscribed to the Seattle Times Sunday edition to start scoping out places to live."
Unlike some of the profiled employees, Yoshi didn't leap to Microsoft to enjoy intellectual freedom to explore abstract problems, or because the management and dress code was looser than elsewhere. Those things may be nice, but Yoshi did it for the money, including 3,000 shares of MSFT, with no apologies. His story, and tough-guy cynical attitude, also made me think of the contractor fired over a blog posting. He sums up his attitude like this:
"So I am a software mercenary. The old style of work and pensions in extinct. You get compensated if you work hard but it is merely a long contract. I am loyal as long as I am paid for my time and effort. I am a hired gun. I believe there is no dishonor to this view. In fact, I think it is more realistic and closer to how MS thinks of its people."
By contrast, Stewart's stretch at Microsoft
paints a far rosier picture of Microsoft's management as well as
the company in general. Stewart started out as a summer intern,
profiling the Xenix kernel ("hog heaven" for a college student), and
programmed in a string of other jobs throughout Microsoft, including a
mid-career stint on liason duty with IBM in Boca Raton, Florida.
Clashing corporate cultures in the shared office space meant that
"Microsoft employees racked up more security violations per day than an
IBM employee would have in a year because we didn't follow the dress
code and we didn't care about tailgating through the door." Microsoft is
thought of today as the stodgy company in some quarters; 'twasn't always
so, and the rest of Stewart's Boca Raton story makes this even
clearer.
Stewart's Microsoft story is also one of the more
challenging to Microsoft critics; he describes the Microsoft managers
under whom he worked as supportive, hands-off and efficient, and
Microsoft's coders as anything but sloppy or lazy. That "Microsoft
doesn't care about security" is a casualism that many outside Microsoft
have come to accept because of the confluence of Windows security
flaws, simple repetition of the allegation, and (as I see it)
envy. According to Stewart,
"One of the thing I liked at Microsoft was that most of the programmers there, in addition to being very bright, cared about writing quality, robust code. ... People cared about their code being as bug free as possible and were willing to sacrifice their weekends and social lives in order to write the best code they could. It was an attitude I saw throughout my twelve and a half years at Microsoft."
It's not surprising that people within the organization see Microsoft so differently; after all, the employees profiled come from different backgrounds and worked at different jobs within the company. More interesting to me is that in so many ways they agree with each other. Nearly all of them maintain that Microsoft is or was a rewarding place to work, and nearly all of them caution against something that may make recent CS graduates wince -- letting too much money go to your head. People who retired, or could have retired, in their mid-30s, really do have to ponder the problems that come with having too much money. (Mainly, that it can change your relationships to other people in unpleasant ways.)
The other employees profiled include Gerhardt (who arrived in Seattle on one week's notice from Germany, straight out of graduate school) and Ian, University of Waterloo graduate who was pushed to Microsoft in part by a Canadian recession. Work weeks of 120 hours, and sometimes only 80 (he "thought he was on vacation" when that happened) eventually led to chronic fatigue and insurance problems for Ian. In those days, he says, "Microsoft was still small enough that that once you were in, you were really in." Microsoft short circuited his insurance policy's depletion by giving him a job that he could do even while weakened, so he could remain covered by the company health plan while he recovered -- in other words, the sort of thing that a Big Faceless Corporation might not be expected to do.
Anne's is one of the shorter chapters, written with seeming restraint (and relief to be an ex-Microsoft employee) as she describes a work environment with mostly good relations between immediate coworkers and a fair amount of job satisfaction, but acrimony and bitterness between groups doing similar tasks, and "silly politics" surrounding the company's constant reorganizations that led to unnecessary stress.
Reading lightly, it's easy to get the impression that Microsoft hires only smart, competent people. Less-than-stellar managers and co-workers are mentioned in here, but mostly they're summed up with short, dismissive descriptions. I wonder whether this is more out of a good-natured desire to accentuate the positive or an illustration of our litigious society and fear of professional retribution. I would have enjoyed reading much more about what made them so awful, not out of shadenfreude, but out of simple curiosity, and to know how the vaunted Microsoft management machine dealt with them in the long term.
A three-part appendix rounds out the book. There's a short glossary of terms reflecting the book's general audience, defining abbreviations like DEC, HR and IT. A few Microsoft-specific ones are on the list too; can you guess what "calling in rich" means? A three-page timeline traces Microsoft's history from 1975 nearly up to the present day; since this book isn't about the details of Microsoft's history or its interaction with the U.S. federal court system, it's no crime that this timeline ends in 2002 and glosses over legal clashes. I'm most grateful for Carter's third appendix, which is a list of the prompts she sent to elicit the employee responses this book contains.
Since the computer industry in young (in all respects, but in particular the business of selling packaged, ready-to-run software), it's also changing rapidly. That means that even though the stories in Mirror reflect the recent past, they show how fast companies' relative fortunes shift and how quickly reputations change. A book like this -- mostly sympathetic to Microsoft, written by insiders -- doesn't pretend to be objective or to present a complete picture of the company, but it makes thought-provoking background reading if the word "Microsoft" makes you see red.
You can purchase Microsoft in the Mirror from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Despite Microsoft's vaunted hiring interviews and techniques, it sounds like they have exactly the same problems managing people and peer-groups as every other large company.
:-)
Perhaps geeks ain't so different after all
Simon
Physicists get Hadrons!
This book seems to let us see a side of the company I've often wondered about but rarely seen. Amid all the hype, lawsuits, and more, I've often wondered who the guys in the cubes are; what are they like, what do they think of their employer, how do they live.
This looks to provide a great picture of the people who make the corporate giant run. I'm not entirely anti-MS...they DO have some friendly, intelligent people working for them.
It's nice to see this side of things. Great looking book, good review.
Damon,
http://actionPlant.com
I've been an "I.T. guy" ever since my first job, and frankly, I banked on "PCs and DOS/Windows solutions" as the stuff one needed to keep up with to retain a decent job.
Somewhere along the way (I think roughly around the time Microsoft started pushing Active Directory integrated with Exchange 2000, but that's far from the ONLY factor), I started becoming disillusioned with the whole thing. I had always tinkered with Linux as a curiousity and fun "alternative OS" to use at home - but couldn't spark any interest in it where I worked.
I decided to "rock the boat" a little bit, building Linux-based thin clients PCs out of old, depreciated systems being taken out of service, and asking employees to try using them on a "trial" basis. I had few complaints, and got most of the ones I did have ironed out in short order. (Mostly, people whining about needing support for their scroll wheel mice, stuff like that.)
I think it threatened my co-workers though, who were die-hard "MS only!" people. My boss was "on the fence" about the whole project, basically not wanting to stop me from experimenting - yet uneasy about it disrupting his little "happy family" of I.T. employees.
Next thing I knew, I was let go. By this time, the job market was quickly drying up, and I spent a long time collecting unemployment checks, and trying to find another, similar job to no avail.
I finally found work with Apple Mac systems. Wow, what a difference! Problem is, it's a small mom and pop place that's hanging on by a shoestring. My hours got cut back to part-time recently, because he couldn't make ends meet otherwise. It's really disappointing more folks haven't yet discovered the things Apple has done/is doing with OS X.
But anyway, here in the present, I see the I.T. job market SLOWLY starting to open back up, but when I read the job descriptions, my stomach churns. I don't even want to apply for most of them! It just seems like signing up to administer hundreds (or thosands?) of users on Exchange email while helping develop roll-outs of the latest MS technologies is like signing one's death warrant.
This DRM garbage is just another nail in the coffin, the way I see it. I can just imagine the fun it'll be explaining to the higher-ups why everyone's locked out of hundreds of important documents because Joe Schmoe encrypted them and then got laid off/fired/took a vacation/whatever. It's already insane enough trying to keep up with all these security fixes (and fixes for broken fixes!), stop the floods of email from woms/virii, and all the other MS headaches.
Obviously, there are still plenty of I.T. folks out there happy and willing to take on these jobs, risks and all. But maybe all my experience has made me too jaded? I'm about to throw in the towel. I don't have nearly enough "real world experience" using the OS's I see as superior solutions (Solaris, Linux, BSD, etc.) to get a decent paying job supporting/administering them. I spent too much time in the MS camp for that. I think I can handle the Mac OS X support quite well, but nobody's hiring for that. MS's current offerings give me the creeps....
No, they're the guys who brought us NT.
Windows 9x always was a hack job.
"Sufferin' succotash."
Were these the guys that brought us Windows 95?
Yes, they did.
The problem appears to be in the Microsoft development model. I have seen numerous articles claiming that code written and checked by as few as 2 coders (and maybe not even marked as finalized) reaches production. The individual coders may be very hard-working, dedicated, and whatever else.
If the development model sucks, the final product will suck. It looks like this is a problem at the administrative level, not the programmer level. It appears that the Open Source community has figured this out, and I'd imagine Microsoft will follow suit in the near future if it wants to compete.
If you think the allegations of bad security of Microsoft are all about sloppy coding, then you haven't been paying attention. You can have the best checking for coding flaws, check the bounds of all input buffers and all that, and still have horrible security. The bad security of Microsoft products comes from decisions that are out of the coders' hands. The basic design decisions are where the flaws start - like choosing to make the running of attachments the default setting in an e-mail client - which is mainly a problem because the macro languages of content viewers like Word and Excel allow people to do things a macro language for an office tool should never be able to do - like open and write files to the disk in a manner outside the document's normal File/Save method. The decision not to sandbox the office tool macros is not a coder's fault. It's a very high level design decision, and one that's fed by marketting - it makes the tool more powerful at the expense of security.
The ugly truth about computer security is that it's a pain in the ass. It gets in the way of making programs be easy and intuitive. Microsoft consistently chooses to place the glitter and showoff factor at a higher priority than security. If something is insecure, but it makes the system seem nifty, they'll put it in.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I have worked with people who thought 80 hours a week made them better programmers, but from my perspective, they were so worn out that they got less done. Managers saw the long hours and were impressed by their dedication and loyalty, but all I saw was people spending hours on trivial problems because their brains were so fogged they were incapable of the five minutes of thought that would have pointed out a better solution.
I have no doubt all these Microsoft people thought they were hotshots, and thought all their coworkers were hotshots, but they define hotshot by long hours, and that only impresses clueless managers and other long hour hotshots.
When the only tool you have is a hammer, every problem looks like nails. Screwdrivers -- who needs 'em?
When the only capability you have is long hours of coding, every problem looks like a long slog of coding. Thinking and designing -- who needs it?
Infuriate left and right
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
That Microsoft is staffed by excellent developers and generally run by excellent managers is evident from books like Code Complete, which has some fun stories about the development of Excel.
.Net - but they are not abstract enough to build sophisticated applications on without large amounts of reinvention. This was explained to me by a project manager at a large bank in Brussels who had seen 150m Euro spent trying to build a web application using MS technology (MSQ, MTS, COM+, etc.)
The fact is that this does not appear to be enough to make really good software.
Microsoft's software has certain specific issues. First, it is too monolithic: it consists of large vertical packages. There are horizontal layers - like Win32 and
The second problem is that Microsoft make their software too complex. Complexity is fun for technicians and programmers and marketing people, but it's a serious handicap in real life: what succeeds is simplicity, but the kind of simplicity that comes from honest and determined removal of functionality. A good example: I plug a USB mouse into my Win2k system, and see 5 dialog boxes appear before it works. Indeed, I even get to confirm the download of a digitally signed driver. On another system (Linux), I plug it in, the mouse cursor appears, and it works.
Large, over complex pieces of software is a serious problem. Intelligence and hard work are effectively wasted, because they are spent managing the complexity that results, instead of creating real value (namely good abstracted horizontal layers and excellent designs).
The reason for these two issues comes, I believe, from the fact that the company is too large and wealthy, ironically. It can afford to throw unlimited numbers of the best developers at problems. It can afford to feel the pain of writing millions of lines of code when a hundred thousand would be possible.
The best software comes from small, starving teams, who have to scrape the last bit of ingenuity from their brains to turn that million-line problem into a 10k problem.
Software is my business, and this is my opinion based on 20 years of writing the damn stuff. Just my 2c.
Ps. "Code Complete" was the best book on programming ever written. It almost made me send my CV to Microsoft.
Ceci n'est pas une signature
I just love it when the mods god INSANE.
So Microsoft worked the guy so hard it damaged him, they they reclassified him so his insurance could continue? How nice of them! Of course, that was, more than likely, the cheap way out for Microsoft. After all, working you employees till the are badly damaged does not look good when presented to a jury and/or a judge.
"Work weeks of 120 hours, and sometimes only 80 (he "thought he was on vacation" when that happened) eventually led to chronic fatigue and insurance problems for Ian. In those days, he says, "Microsoft was still small enough that that once you were in, you were really in." Microsoft short circuited his insurance policy's depletion by giving him a job that he could do even while weakened, so he could remain covered by the company health plan while he recovered -- in other words, the sort of thing that a Big Faceless Corporation might not be expected to do."
I'm usually not pro-Microsoft. In fact, normally, I'm biased against them. But, it's good to occasionally be reminded of the way things are up there. Kinda brings me back to an almost neutral point. Sometimes I just get the wrong picture in my mind. It's nice to have that picture changed.
Stop the Slashdot effect! Don't read the articles!
Contrary to what seems to be popular belief in the unix world, "GUI" and "screen full of xterms" are not equivalent.
What nature? You mean the "make as much money as is possible for their shareholders at all costs" nature? Like every publically traded company on the planet?
You must mean because they are so SUCCESSFUL at it, that it warrants obsessing about them?
I would need a lot more than stock options and a relaxed atmosphere to work 80-120 hours a week. Thats seriously bad for your health. I could do that for a few months, if I was going to make a few hundred thousand in the end. I'd have to live in the office, so it had better have a health club with swimming pools and all the works, good food (not well stock snacks, I'm talking about a real kitchen with chefs and stuff) and I would definately take lots of breaks to visit the 'entertainment complex'. I work around 40 hours now, I'm getting burned out on that.
TallGreen CMS hosting
Never saw that error... rename never caused us issues in VSS. Moving files is done via share / delete, which retains the history.
The problem with VSS is:
- Doesn't work well over a WAN, have to purchase a 3rd party product like SourceOffSite. (Which, while pretty darn good, isn't keystroke compatible with VSS... which is annoying).
- Storage system is horrid... hundreds of thousands of little files, with little to no anti-corruption measures (such as storing CRCs of the revision or cross-linking things).
- Poor security, sure you can setup project security so that your developers can't delete things within the graphical interface, but then they can turn around and delete the entire VSS directory tree. (VSS requires that your developers have R/W access to the storage system.)
OTOH, the GUI is pretty and easy to use... a lot better then dealing with command line CVS commands. Makes a semi-decent versioning file system for cases where you're working on a multiple projects with multiple co-workers who are geographically seperated (when combined with SourceOffSite). WebDAV and the new CVS-replacement project look interesting, but I have yet to figure out how to do a simple setup.
Wolde you bothe eate your cake, and have your cake?
Anwyays, this was on the Excel team. And that could explain this other part:
From what I remember, at that time Excel and Word were pretty much the "elite" teams within MS. The design teams were extremely well respected and I think could get whatever they wanted in terms of resources they thought they needed to get their jobs done. For example, they were still using a Borland software development platform to develop Excel, at a time when Borland was a bitter enemy to MS overall.So Stewart's description may well be accurate for his experience, but it may not be the typical or even average case.
And of course, since then, I have to wonder if the quality has been maintained. Sure, the actual programmers really gave a damn about quality, and poured their heart and soul into the product, but they still lived a the mercy of -- what were they called -- the "program directors"? These were non-programmers whose job was to hand papers to the developers telling them what features to implement. Doesn't sound like the best long-term prospect for quality, does it? Furthermore, at the time I was there, they were just finishing up the OLE integration -- which my mentor on the Excel team described as "the worst thing that ever happend to Excel"...
"Orthodoxy is unconsciousness" - Orwell
It was clear that we were to ship ON TIME, this meant agressively dropping any and all features that got in the way. Even pretty key features could be dropped. "Shipping on time, shipping often" was the way to get more people to "throw their wallets at us". The quality of the software not central. I think this really makes a lot of business sense. But what I learned is, this perpective takes some of the joy out of creating software.
Deadlines are the only way anything ever gets finished.
Aim for the stars, and you might just get the moon. And while you still want the stars, most people will be happy with the moon.
The same thing applies to software development, writing, you name it...
Coming soon - pyrogyra
Yes.
The Linux GUI had a hell of lot more than a "screen full of xterms."
Window managers like FVWM were barely more than a basic menu system to launch applications from and some window management semantics. Decent copy & paste ? Nope. Integrated file management ? Nope. Common dialogs ? Nope. HCI guidelines ? Nope. Graphical configuration tools ? Nope. Drag & drop ? Nope.
The state of Linux "GUIs" (and I use the term loosely) in 1995 wasn't even competitive with Windows *3.0*, let alone Windows 95, OS/2 or MacOS.
The first WM+other stuff for Linux that could rightfully be called "GUIs" were probably KDE and GNOME, and early versions were pretty light-on in terms of functionality (in its defense, many of the deficincies were due to a lack of "KDE compliant" applications). That was ca. 1998.
Hell, I even remember the Windows 95 taskbar and right-click menu as being considered something that was copied from X window managers.
You remember wrong. IIRC FVWM95 was the first WM to try and clone the taskbar. Have a think about why it was called FVWM*95*.
The taskbar was, amazingly enough, a relatively unique idea. It sorta borrowed from NeXT and maybe even MacOS if you squinted right, but it was different enough to deserve being called "new".
From afar it looks like Microsoft has a lack of partitioning of functionality. Everything is embeded in everything else. It is so bad that ( According to Gates under oath at least --Gates would not lie to us would he? ) if you remove the media player you break the OS.
Open source has partioning of functionality forced on them. The code is written by volunteers all over the world. Functionaly has to be cleanly partitioned to make this work.
Religion is the main cause of atheism.