Hardcore Software by Steven Sinofsky (Audio Edition)

Welcome to Chapter II. In short order I learn that Microsoft is way behind in the products I work on. BillG is really concerned about Steve Jobs NeXT computer. I move offices and find out I was part of a reorg.

This is a quick setup for a chapter about the creation of Microsoft Visual C++ 1.0.

Back to 007. Windows 3.0 Buzz

1990 to 1992: The big bet on Windows begins to pay off, but Microsoft struggles to win over developers who were enamored with object-oriented programming and C++ to more easily build GUI programs. Within Microsoft, differing cultures emerge between groups, and eventually define the company.

Microsoft was starting to lose its edge, even with Windows taking off.

The company got its start with languages and developer tools, but by the early 1990s tech enthusiasts and hobbyists were moving away from BASIC toward more advanced or professional languages and tools. Developers were being wooed by an exciting upstart, Borland International. Led by an energetic Frenchman, Philippe Kahn, Borland captured the hearts and minds of enthusiasts with a line of TurboTools that integrated a compiler, code editor, and debugger into one slick package. It was fast, really fast—fast the way that got under the skin of BillG. With support for both Pascal and C, and priced favorably, the products and the company became a favorite among independent developers. It also didn’t hurt that Borland expanded its product base to include a killer spreadsheet in Quattro Pro (get it, it came after Lotus 1-2-3) and Paradox, an industrial-strength database for MS-DOS.

Microsoft secured the professional end, particularly with Microsoft C 5.1, the product we were using for our ET++ experiments. The successor product, Microsoft C 6, re-upped the professional standard but was late (as everything was) and lacked the pizzazz of Borland. Microsoft responded to Borland with Quick C, a similarly integrated all-in-one product for MS-DOS. With C 6 a Windows version was added. Quick C was viewed as a defensive move. It was. We were focused on the high-end commercial developers, not the hobbyists or solo developers.

Being squeezed from the low end was one thing, but the high end was becoming problematic for Microsoft. Not only was the C 6 product late, but it was C and neither C++ nor object-oriented. This challenged Microsoft’s perceived leadership. In addition, Borland’s products performed better than the anticipated C 6. Internally, the teams, particularly Excel, began testing whether they could move to the Borland tools. This was especially noteworthy because it was coupled with a move away from Microsoft’s proprietary C-like language CSL.

As if this wasn’t enough, the growing importance of the graphical user interface would soon require a wholesale reinvention of tooling. Microsoft was way behind. Windows was our platform, but we lacked convincing and competitive tools. Squarely between Windows and OS/2, the Tools teams all but sat out developing new tools for GUI programming and focused simply on the programming language. The additional tools for developing the interface of menus and dialogs, as well as the complexities of making a GUI program, were left to the respective platform teams. These teams shipped tools in a software development kit (SDK), which was complete but not as polished a product as Borland sold.

This was my first experience with disruption, though that word was years away from business vocabulary. In 1990, we just called it competition. And losing.

While our marketing team talked all about revenue and market share, like any good business, in reality Tools was not really a business. An important lesson about Tools and platforms that I was learning in real-time was that a robust platform company invests (that is spends money on) Tools at an irrational level to support the platform. The reason Borland could have a Tools business was because it was spending much less than Microsoft, and so could be profitable. Microsoft was spending more money and making a worse product. In other words, I was part of an irrational investment that wasn’t paying off. We were a poor business, and we were failing at building tools professionals wanted to use. Losing control of the Tools was akin to losing control of the platform.

Apple invested heavily in tools for the Macintosh, just like a winning platform should. There was also a vibrant market for many different languages and tools for creating apps for the unique graphical platform. This was well known within Microsoft because so many of the Apps engineers got their start writing Mac software in college, including me. There was always a sense of envy regarding the elegance of building GUI applications with a GUI toolset on Macintosh—bootstrapping was when programming tools created themselves. Historically, programmers viewed bootstrapping as an important, if mostly symbolic, step in developing a platform. Microsoft was far from bootstrapped, as it was still using Xenix and OS/2 to develop for MS-DOS and Windows. Worse, most developers at Microsoft thought this was a superior way to build software. All that marketing we were doing explaining that a GUI was easier to use had the effect of telling programmers that GUI was how lesser programmers worked. Worse, that is what our own marketing team was telling us about our own customers.

Besides, even with those great tools and a lead of several years, Apple was still far behind in PC sales. Steve Jobs was no longer at Apple and his new company, NeXT, was top of mind for BillG and the industry. As successful as Windows was for Microsoft, there was a strong belief that no single system would dominate. NeXT was new. NeXT was led by Steve Jobs. And most of all, the product was clearly innovative and setting the bar by which BillG would judge our product and technology.

Steve Jobs at an event in San Francisco launching updated NeXT computers and tools. A key part of this presentation that caught Microsoft’s attention was the presence of Lotus CEO Jim Manzi describing how they built a unique new spreadsheet product on NeXT, called Improv. “We would not have been able to invent such a revolutionary new product on any other platform” definitely gets your attention.

Microsoft had to do something, something about Borland and NeXT.

Moving offices at Microsoft was a constant. It was time for our first move, to new buildings that were even bigger than the big double-X layouts. These were the new buildings for Apps: 16, 17, and 18. Rather than low slung grey these new buildings were 3 stories of glass and brick and featured their own courtyard and fountain, which would be the site of our future ship parties. The buildings had huge atriums of open space and skylights while still maintaining the sacred 9x12 foot single office with a door. The three buildings were connected by an enclosed tube system that looked like a Habitrail. The uniqueness of these tubes meant that they were frequently used for photo shoots and videos.

The night before a move (my first of a dozen I would experience), MSMOVE dropped off a stack of boxes, a roll of tape, and a move form. A paper form was used to draw placement of the huge oak desk, return, guest chair, and developer-issued folding table. The movers showed up at the end of the day, unplugged phones and computers, and put everything on carts and trucked them to the new office. Unpacking could happen 12 hours later. The MSPHONE person eventually showed up to make sure the newly hooked up phone worked with your assigned number.

This was going on every night in every building at Microsoft. It was like a giant nine-square puzzle, where at any given time an entire group existed in the moving trucks in the parking lot because there was never enough space for everyone, even with the new buildings.

My new office was right around the corner from a connecting tube and for the first few months I could hear the door slamming every time someone entered the tube. There was a design defect that turned the tube into a wind tunnel, making the door difficult to open while also forcefully closing it with high-speed wind. Eventually some vents were added solving this problem.

As with every hallway of developers, there was a deep sense of personalization that came with the private office space we were each allotted. Since most people were not yet grown-ups, there were no family photos, or traditional memorabilia. Rather, offices were filled with some form of personal collection representing youth. I saw a collection of vintage car license plates, a wall of album covers, and a beer can collection sitting on a custom shelf high up on the wall. And most every office featured a pyramid of used beverage containers, usually Mountain Dew or the ever-present Washington apple juice, and the occasional chocolate milk containers (the ones from elementary school).

Next to each door, there was a full-length window (a relite), about one foot wide, made with that type of institutional glass from high school with wires inside that gave a sense of involuntary confinement. While designed to let light in form outside, it often served as an outward-facing sign of personal expression. Usually the first thing decorated in a new office, relites were covered in stickers, signs, news articles, Dilbert comics, jokes, and bad code examples or bug burn down charts, all expected to be updated with some frequency.

Like the first day of high school, people wanted to stand out, but they didn’t want to stand out. I nervously attached a few items to my glass, mostly American tourist-trap kitsch from my recent cross-country drive: a Wall Drug sticker, a Corn Palace postcard from South Dakota, and a copy of Elvis Presley’s death certificate I had acquired in Memphis. Road and street signs were popular, and my “Slow Children At Play” road sign also followed me around for a decade.

I didn’t realize it but our ET++ team had just been reorganized. Not only did I move offices, but I found myself on a new and bigger team with a clarified mission.

On to 009: Password is ‘NeXTStep’

A continued thank you to subscribers for the comments and discussion we’re having. It is an amazing part of writing a book this way that we can share in additional memories and reflect on experiences we have all had. This section marks the end of “Chapter I” and so please feel free to drop me a line with feedback or thoughts on how things are going. By all means share this with friends as we’re about to start diving into product development—and I’ll be writing code finally.

Back to 006. Zero Defects

With spring 1990 approaching, the buzz for Windows 3.0 was becoming deafening within the halls of Microsoft. One of the most exciting things was seeing the visual appearance of the product. Windows 1.0 and 2.0 were, to put it kindly, garish, or at best excessively blocky and utilitarian. Much of this was out of necessity as computer monitors only displayed about the equivalent number of pixels of one app icon on today’s iPhone and only had access to 16 colors (or no colors at all). Windows 3.0 also added overlapping windows like on Macintosh which made a huge difference in how the product felt.

Windows 3.0 was the first integrated release of Windows, meaning sold along with MS-DOS on a new PC. The notion that Windows was an “operating environment” added on to MS-DOS was giving way to Windows the operating system. While seemingly arcane technical jargon, the change in vocabulary was also a change in how the product was sold to computer makers and how software developers should think about Windows. Windows coming with a new PC meant it was no longer a question developers would need to ponder when deciding how to write software. The landscape was changing from IBM-compatible PCs to Windows-compatible PCs. This was huge.

To emphasize this point, the company scheduled a major (for Microsoft) press event in New York in May 1990. What was months earlier a side project was now front and center for the whole industry. While Microsoft had previously held launch events at trade shows, this was one of the earliest examples (and certainly the most expensive) of a major event for a single Microsoft product.

This event was going to be monumental for the entire company, except perhaps for the people working on OS/2. We were all using OS/2 every day as a main development machine, and many people were working hard but struggling to get Word and Excel working on it. But it was also viewed with a good deal of skepticism internally. Much of this was because of the stories that made their way over to Apps from Systems about working with IBM and the disconnect between engineering cultures, but also our own experience in the poor quality and difficulty in using the product.

There were many stories of IBM’s dysfunction that were common knowledge. IBM used to measure their programmers on lines of code produced; more lines meant higher productivity. Except Microsoft believed fewer lines of code to create the same feature was better. IBM thought Microsoft engineers were less productive while Microsoft thought IBM engineers produced bloated code. Microsoft was young and confident. IBM was…experienced.

While IBM was a few decades into writing software, their experience was rooted in making highly custom and highly reliable mainframe software, over very long periods of time. The reality was Microsoft was at peak productivity for new lines of code being written for PCs, but we were still very early in figuring out a reproducible process for releasing products and of course we continued to have quality problems and scheduling missteps. BillG even noted our challenges in releasing software on time as he walked on stage at the event, saying that today Microsoft is announcing the completion of Windows 3.0 and had the product not been done hosting such a big event would have been a bit of an “extravagant way to announce a delay in the schedule.”

The deep tension between Microsoft and IBM was hardly visible to us and, frankly, the industry was geared toward a world with many competing computing platforms. Nearly every article about Windows viewed the product as a stepping stone to the more modern OS/2 that would shed its connection to 8-bit MS-DOS. No one was anticipating Windows 3.0 becoming a de facto standard, certainly no one at our daily lunch table. We increasingly knew Windows 3.0 was an exciting product, but we also knew that Microsoft had committed to a joint development project with IBM, a company perhaps 100 times the size of Microsoft. None of us really had a clue just how tense the relationship between Microsoft and IBM was becoming while we continued to find ways to absorb the complexities of OS/2, Macintosh, and now Windows 3.0.

Along with Windows 3.0, Microsoft demonstrated a new release of Excel for Windows, Excel 3.0, an updated Word version 1.1, and the first version of PowerPoint for Windows version 2.0. The PC software industry was a version number machine—literally everything was a 1.0 or a 5.0, or debating whether a product was a .1 or a .5. It was the source of marketing games such as “big upgrade in version 2.1” and notorious for cynicism such as “avoid a 1.0” or “wait for the ‘a’ release.” Microsoft was a varsity player in this world of confusing version numbers (and product names), and we were just getting started.

Those updates were just the software from Microsoft. The platform marketing team, which in the software industry had become known as evangelism, a term pioneered by Apple, had successfully wooed hundreds of independent software vendors to show off their latest products on Windows. The Windows 3.0 event included mentions of many of the biggest names of the day including Corel, Aldus, Iris (makers of what would eventually become Lotus Notes), and Crosstalk. Noticeably absent with Windows products were WordPerfect, Ashton-Tate, and Lotus, the leading applications for MS-DOS.

Also at the ready were hundreds of hardware companies ready to deliver a range of fully compatible computer systems, components, and peripherals. While often overlooked, the ability to have hardware and the required software to make printers, displays, and a host of accessories work with Windows was an achievement equal in magnitude to applications.

Windows 3.0 seemed to have everything that OS/2 did not. There were compatible PCs. There were new applications. There were supporting peripherals. It had the pricing and distribution too. The fact that it ran on as little as one megabyte of memory (though really two was better) and also ran all existing MS-DOS applications even better than they ran before made for an incredibly compelling launch.

Windows 3.0 represented a step-function change in the PC. The clunky world of obscure commands and text-based screens would give way to colorful overlapping windows and a mouse, something that Macintosh had for the past five years. While the PC was catching up in capabilities it was still outselling Macintosh by more than fifteen to one. What the PC lacked in ease of use and elegance, it more than made up for in lower cost hardware, a much broader base of support from software makers, and a wide array of peripherals.

The launch event was satellite broadcast to conference rooms around campus. For most of us, the idea of seeing Microsoft on a video stream like this was kind of crazy. While certainly the company was one of the biggest and brightest stars around, the world of technology and software was still a relative blip in the economy. Bill Gates was hardly a household name. About 15 percent of US households owned a personal computer in 1989, and worldwide about 17 million PC compatibles were sold (1989 was the first year more than one million Macintosh computers were sold—the Macintosh always had an outsized influence, and it’s worth noting that Word and Excel were selling to most of those Macintoshes, which was not the case for Microsoft apps on PC compatibles).

The trade press, which we devoured every week in tabloid sized print magazines at the library (senior executives were permitted to have their own subscriptions, but regular folks had to make their way to the library), covered every development of Windows and OS/2 as though both operating systems were inevitable.

Since we knew the Systems teams were hard at work at both, we had no other source of information to counter the narrative in the trade press. It is interesting to consider how much we were influenced by what we read in trade press when there was little else for us to go on. Little did we know that BillG, and the executive teams, were deep in an enormously complex “divorce.” The company was on the verge of moving away from a partnership with IBM and would go it alone with Windows. This would not happen quickly.

In fact, in the months leading up to the launch event, Microsoft and IBM famously issued a joint communication emphasizing that long term their collective efforts are squarely on OS/2 and urged independent developers to follow. When we read about this in the trade press it seemed exactly like what we were doing as Microsoft followed this advice too. Many of my friends were working super hard on OS/2 versions of Word and Excel. We were working hard to make ET++ work on OS/2 as well. At the same time, making applications work for Windows was ongoing, and going very well. The work on OS/2 was definitely not fake as many would say in the years to come, but it also wasn’t progressing. Everything was confusing and messy to those of us just doing our jobs.

Windows launched in May 1990 and sold four million copies in the first year. That was all the market proof the company needed to know that Windows was the future. The complex partnership yielding a complex OS/2 product was also looking less and less strategic. The fact that progress on the product was slow and the rapid sales of Windows were attracting all the interest of third-party developers, made the positives of OS/2 mostly theoretical. Who needs a better file system if all the interesting applications are on Windows?

In hindsight, that day in May was somewhat surreal. I had not yet even started to internalize the scale of Microsoft or its potential. To me the company still seemed so approachable. The Microsoft I knew was not much larger than my high school and I felt like I knew all the people in Apps. In reality, we were doubling in size every year.

A few weeks after Windows 3.0 launched, Microsoft closed the books on fiscal year 1990. It would be the first year the company would report sales over one billion dollars, $1.18 billion to be precise. That was almost double the revenue of either Lotus of WordPerfect, the two largest software companies. Microsoft became the first pure play PC software company with more than one billion dollars in sales.

The inevitability of Windows was starting to sink in over the summer. BillG always used to tell the interns, and by now we had perhaps 100 that summer, that he worried Seattle summers were so nice that people would not work. In fact, there was an incredible amount of energy that summer but we were in desperate need of strategic clarification. I needed it for my own job, the company needed it too. The industry, it seems, had already decided.

As far as reviews of the product, Byte magazine concluded “on both technical and strategic grounds, Windows 3.0 succeeds brilliantly. After years of twists and turns, Microsoft has finally nailed this product. Try it. You’ll like it.” Still, the technology enthusiasts were fretting about OS/2.

There was definitely a feeling that we were at some sort of new beginning with Windows 3.0, and at the end of the first era of the personal computer.

On to 008. Competing with Steve Jobs (the First Time) [Chapter II]

Go back to 005. Keeping Busy with Cross-Platform OOP

Thank you for reading along and the great comments! This post tells the story of my first memo, Zero Defects, and the impact it had on me and all of Apps. Microsoft was a company that wrote code but we also wrote memos, especially in Apps. Memos were often 20 or more pages long and printed for circulation via interoffice mail—we were building those tools after all! Also, this is my first performance review.

When it came time to write my first performance review, it simply read “attended ADC” and looking forward my only goal was to “make ET++ work.”

Still, I was nervous about writing mine. So, I shot off an email to Melissa Birch (MelissaB) asking for some tips. She was on the Word team, which was in the very final stages of shipping the original version of Word for Windows 1.0, code name Opus and another long and late project. She graduated from Brown University in 1987 (the same year I graduated Cornell). Melissa was tall, polite, and formal. We shared the East Coast rhythm and sensibilities. MelissaB was an astute engineer, tuned into the challenges of making projects work. I knew she could help.

Thanks to fellow Apps Tools developer Kirk Glerum (KirkG), I’d made my way through the gauntlet of a seemingly cliquey lunchroom of regular tables, seated at a table with MelissaB, KirkG, DuaneC, Jodi Green (JodiG), and many others on the Word dev team.

Kirk was a hacker’s hacker. He spelled his name Glærum (which wasn’t spelled that way by the facilities name-changers and was quite a trick to type on US English keyboards in MS-DOS) in reference to his family’s Nordic heritage. KirkG was as Northwest as one could get—he was the first to inform me that I was no longer allowed to use an umbrella. He grew up in Oregon. He attended the University of Washington and was a die-hard Husky fan right down to his purple Converse (when meeting people, where someone went to college was often the first fact Softies revealed since so many of us were straight from college). Most interesting was how he ordered a sandwich at the cafeteria. When asked what he would like, he always said, “Surprise me.” I could never have ordered like that. I later learned his business card listed his title as “Software Alchemist”—back then you could make up your job title and mine said “Computer Scientist” since I was convinced I would eventually go back to graduate school.

A New Yorker, JodiG joined Microsoft early on. It was immediately apparent that she was a manager because at lunch she was always asking other members of the team about their bugs and progress. She was another graduate of Brown. It was common for graduates of the same school to find each other at Microsoft, even if they weren’t classmates, because alma mater recruiting was something developers did, mostly because they knew the department, classes, and professors. I would soon be making recruiting trips to Cornell.

To help me with my review, MelissaB, over lunch, talked about the new mantra at Microsoft called Zero Defects. We would continue this discussion over a long email thread, as was all too common.

Zero Defects was a memo that was circulated by the leading development managers (the most senior engineering managers) in Apps and Languages. It was an effort to attempt to get a handle on product death marches and ever-increasing bug counts that were contributing to a broadening view of inevitability as products became more complex.

A key underlying argument put forth was that we were rewarding developers for checking in new code and declaring a feature done, even if it was not. Testers then found a lot of basic bugs. That meant they were preventing more interesting testing from taking place and that more code to fix those bugs was quickly written, delaying the new work, and testers would continue find even more bugs.

In any software project, adding or changing code had a good chance of introducing a bug approximately 10 percent of the time (a number floating around in academic circles for decades), whether it was fixing one line of code or adding whole new capabilities. The cycle of trying to complete a feature by finding bugs could never really end—this was called infinite bugs and was plaguing the development of Omega, Microsoft’s first Windows database, and to some degree Opus, Microsoft’s first Windows word processor, which began in 1984 but did not RTM until 1989.

RTM, release to manufacturing, was a phrase heard constantly. Everything was about getting to RTM. RTM was the ultimate goal. RTM was shipping. For the first decade or so of Microsoft, RTM literally meant to a factory, a Canyon Park facility about 10 miles north of Redmond where there was a shrink-wrap assembly line of boxes, manuals, and floppy disks. At the end of every product, at RTM, teams took a trip to Canyon Park and watched the first boxes roll off the line. We might have made software but we shipped it in boxes to retail stores.

The specification for Opus from BillG famously was “build the best word processor ever” and finish by October 1985, to align with the release of Windows. This was likely the first edict for Apps to align with a Systems schedule, a topic that emerged again and again. It was also as likely as two golf balls colliding mid-air.

Zero Defects was probably one of the most profound engineering documents I had ever read, and yet it was also common sense and blindingly simple. I remember one sentence well: “The hardest part is to decide that you want to write perfect code.” This was an impactful memo, in part because it was my first exposure to the collision between the idealized world of hacking and the pragmatic world of engineering products for millions. It was so practical and made so much sense, yet it was such a dramatic change from the hacker ethos that the most and fastest coding wins.

It might sound over the top to call a single memo that is literally about how to code without bugs as something “profound.” Certainly, for me it was profound because it was the first business memo I read that was also about why we are doing what we are doing, not just how. In a broader context, however, the memo was about the novel enterprise that was Microsoft at the time. Apps was building software for millions of people that were not trained computing professionals. That was new, for everyone. This memo was a realization that the company was at a crossroads and the old way—the way of hackers and hobbyists—was no longer acceptable.

This memo also marked a change in the entire Apps division, now numbering hundreds of people. With two big projects that were late and buggy, Omega and Opus, and several other challenging projects such as the recall of Macintosh Word for quality issues, Apps needed to do something different. No other company was building software at scale across so many categories and so many platforms as Microsoft Apps was doing. While all this was going on, Excel version 3.0, for both Windows and Macintosh, was under development and would soon ship merely 11 days late and with rock solid quality—a feat that would not be bested for a decade or more.

From my vantage point, Zero Defects, marked the start of Apps culture of shipping. A culture that included an organization structure to scale development teams, a process to plan and schedule products, techniques to maintain engineering throughput, along with methods for ascertaining quality through the entire development schedule. Excel 3.0 would be proof that projects could be on time and have superb quality. Apps would iterate and hone this process for years to come, but it is neat to have a sense for when it all began.

That is somewhat hindsight. The memo would have been more profound to me if I ever experienced a death march or worked on a large and complex shipping code base. I had no experience shipping a product, so what did I know? As MelissaB shared her perspective with me, I came to understand what ZD as we called it really meant. There was no system-wide integrity (in an engineering sense) and that the wrong people were writing too much code. Some developers wrote a lot of code to make it look like a feature worked, even if all the boundary conditions weren’t handled or if the code was fat (a Microsoft expression for verbose code that took too much memory or was too slow—a quick reminder that PaulA’s and BillG’s original Microsoft BASIC fit in four kilobytes of memory, or about two pages of this book). Worse, those developers received high praise for getting “so much done.” System-wide, the schedule was used not as a tool to get work done but more as a system to stretch goals without reflecting the complexity and interdependence of the work of the team.

Something MelissaB said to me during one of our lunches and many emails on the subject resonated for decades and proved to be a cornerstone, not only for me but for how the entire Apps division (and later Office then Windows) operated. Her reading of Zero Defects and her own observation was that everyone should be focused on clearly communicating what work they did and be measured by achieving that. No games. No stretch goals. No race to check off things that were not yet done. No doing the minimal work to make a feature demonstrable. Later, we came to call this promise and deliver.

Melissa also connected some dots for me and explained that the way groups were rewarding people who ultimately contributed more bugs than code was in practice rewarding some men and penalizing some women on the team. Teams that were small had few women. There was no hiding that fact. Melissa’s view was that the women were routinely delivering the code they said they would, when they said they would, and at the same time getting feedback about the need to do more. As potentially controversial as such a statement was, it was simple to demonstrate by looking through the schedules and at the RAID database. While Microsoft was just starting to appreciate how different developers worked, Melissa’s explanation of ZD in the context of specific people and their approaches to work (and rewards) made everything far more concrete. The specifics Melissa shared became a rallying cry for me later in my career as a manager and I would often share what she taught me.

Underlying this memo was the beginning of the idea of continuous quality. Every day the product should be shippable and of high quality. Work that was not yet completed was not part of the checked in (completed) code, but that code was kept in sync with the main product. This is something analogous to today’s continuous integration and continuous delivery, and it took decades for Microsoft to achieve this level of engineering, which began in a moment of crisis and self-reflection. Although this seems obvious today, software projects were not typically run in this fashion, certainly not PC software.

That’s the long way of explaining that MelissaB’s answer for my performance review question was to “make sure you put in that you will practice Zero Defects in everything you do.” That was a bit cynical, but it worked for us, and everyone. Those were performance reviews circa 1989.

With those goals in hand, we spent the fall of 1989 and winter of 1990 hacking away at ET++ and making it work on OS/2 and Windows. Little sample programs, like a calculator, worked. Along the way we found a lot of bugs in the new version of the Microsoft C compiler. And we continued to test out the programs we created on Windows 3.0.

In many ways, those early months were a second ADC or an ADC practicum. The opportunity to be on the ground floor of a new computer language was great, and the added challenge of trying to make it work on a bunch of operating systems that didn’t work only added to the fun and, also, the frustration. I guess I had not really considered that my job might be frustrating. It had not yet occurred to me how truly messy the company was.

Nevertheless, experiencing this while waiting for other groups to finish so we could collaborate seemed better than any alternative. Once performance reviews were complete and thinking about all my friends shipping Windows 3.0, Word 1.0, and Excel 3.0, left little doubt my project was busy work and it was dragging on.

Go on to 007. Windows 3.0 Buzz

Back to 004. Everything is Buggy

I finally have a project to work on. Unfortunately it feels a bit like make-work and I have no idea how it fits into the big picture of Microsoft. Actually, I’m not even sure what the big picture is as we’re all in the middle of the strategic shift to GUI and Microsoft has multiple operating systems we’re supposed to be supporting.

As part of the Apps Tools group, we were set up to provide the tools to make it easy to build apps that worked on any platform, regardless of the differences or details of each platform. Isolating app developers from platforms was our job. The industry called this cross-platform development.

Historically, such an approach was at the core of Microsoft from the beginning, simply because computing had always been heterogeneous. The makers of computer hardware customized the operating system, which in turn meant that apps needed to be modified to run on each different computer system. This was not any sort of evil plot, as some believed, but simply something that was in place because the hard part of making a computer system was the hardware. Hardware engineers, naturally, chose to modify the software if it meant making the hardware easy. In Microsoft’s earliest days, PaulA and BillG made the BASIC language for many different computers. Microsoft early apps, like the Multiplan spreadsheet, ran on many different personal computer systems at the time, a variety of 8-bit microprocessors and operating systems. Developers like JonDe and DuaneC were experts in the underlying technologies used to get Microsoft apps running on systems from DEC, Tandy, Zenith, Data General, and a host of other names from a bygone era, as well as IBM and then Hewlett-Packard, Compaq, and Dell. PCode and the virtual machine that DougK talked so poetically about in my summer training were in part about making it easier to run software on multiple platforms.

It was natural, therefore, that with Microsoft looking to grow the graphical interface apps business while also itself building multiple operating systems, there was a need for cross-platform tools that were more sophisticated than the 8-bit character mode tools that were already in place. Microsoft needed cross-platform tools just to be able to develop its own applications for its own operating systems. Let that sink in. It was common practice in the industry at the time for every major independent software vendor to also develop their own cross-platform toolset, designed to optimize for their own app and their own view of the platform landscape. Microsoft was unique in creating its own need for cross-platform tools, with multiple operating systems and its own applications.

Cross-platform product development was the elusive brass ring of development that accompanied each generation when there was no clear platform winner. From mainframes to minis to the increasingly popular Unix variants to microcomputers, and now the rising graphical interface. Each new platform promised to be the one to end all platforms, and it might have been, until the cycle repeated. Cross-platform tools are one of those developer problems that everyone believes they have an answer to, certainly early in software lifecycle.

This did not stop even Microsoft from getting caught up in building cross-platform tools. As platforms and applications mature, cross-platform becomes increasingly difficult and the customer experience decreasingly good. Microsoft was still in the early days of cross-platform so it was looking workable. Given the early success with BASIC and 8-bit character mode, it was no surprise that BillG thought the next generation of such work was trivial, a term he loved to toss around. The difficulty—the lack of a trivial solution—was that more and more work was shifting to operating systems away from apps. In other words, as Microsoft (with IBM, and Apple) invested more into making the operating system feature-rich, it made building cross-platform applications more difficult. In fact, that was the strategy, even if it pertained to its own operating system products.

Still, the industry believed the key to making cross-platform trivial was a programming technique, one that wasn’t too new dating back to the 1970s Xerox Palo Alto Research Center (PARC), called object-oriented programming, or OOP (sounds like oops). OOP was everywhere. A trip to the Tower Books on NE 8th Street in Bellevue, something I routinely did on Friday nights because it featured a necessarily deep section of programming and technology books, yielded new books every week with OO in the title. OOP promised to make programming an order of magnitude easier (another common phrase, meaning 10 times better or more, but with no specific units or ability to measure).

OOP was also deep in my own bones. My lab in graduate school was the Object-oriented Systems Lab. We spent the better part of a year recreating the original OOP platform from Xerox PARC, Smalltalk-80, so we could build our own OOP projects using that as a foundation. It is where I came to believe garbage collection was an important part of OOP. I came to Microsoft already an OOP zealot, which in part was why I was hired I was later told.

Aside from abstract computer science concepts, a new innovation for OOP was a new programming language pioneered at AT&T Labs, which, despite the breakup 10 years earlier, was still functioning and a leader in many fields of research, still winning prizes and medals. C++ was the OOP version of the widely used and taught C programming language. That meant it held the promise of not only making programming an order of magnitude easier, but also through its OOP techniques making it possible to be cross-platform, all while maintaining compatibility with the industry standard C language (the language used across Microsoft at the time). OOP as expressed in C++ would make not just cross-platform programming easier but make all programming easier.

Imagine that? No, really. Imagine that, because that’s all that could be done at the time, or ever.

The buzz around OOP reached epic, or comical, proportions even making its way into mainstream business press. The cover of BusinessWeek magazine featured a baby in diapers at a keyboard and monitor introducing OOP to readers as “a way to make computers a lot easier to use”. It was no longer just a magical tool that would make cross-platform programming trivial or a technology that computer scientists believed would lead to more robust and maintainable code. OOP was even going to make resulting applications easier to use.

Object-oriented programming and C++ represented my introduction to the hype cycle of the technology industry. In experiencing this now, I was fortunate in two ways. First, I was still early in career, so I was more mystified than cynical. Second, I was surrounded by already seasoned managers focused on “shipping” who helped our group to navigate the St. Elmo’s fire of OOP.

The industry would undergo a tectonic shift over a multiyear journey to demonstrate the utility of OOP when it comes to mass market software, especially for GUI platforms. Today, most anyone can build GUI applications, but early on the complexity made that extremely difficult. While we could not make it possible for an infant in diapers to program, we could make it much easier for the typical professional or college student. The degree to which OOP or other developments contributed to making it easier will always be the subject of debate, as programming tools and languages always seem to be. There is no doubt, however, that OOP is deeply rooted in the evolution of the graphical user interface, going all the way back to Xerox and forward to today’s smartphones.

Making progress in my new job, however, had one big problem: There was no C++ for the PC. In fact, there was barely C++ at all as it was primarily a research project at AT&T. The only tools around took C++ code and transformed it into C to then be compiled by a C compiler. Normally, one thinks of programming as typing in one language and then converting that into the raw numeric code for the PC, straight from English-like to binary numbers. C++ was so new that using it was akin to translating to German by going from English to French to German. C++ was first translated into C that Windows tools could understand, then finally translated into binary.

Like every other Microsoft project we were already late and behind schedule though I didn’t realize it or even really internalize it. But how could I have? I had no idea what product we were supposed to be building. All I knew was we were supposed to be working on cross-platform GUI and that meant OOP and C++. We did not, however, even have the software development tools to use the C++ language. There was a team in Languages working on a compiler, but first they were busy releasing the latest version of C, which was late and buggy and did not include C++ support.

ScottRa cleverly decided that we needed to keep busy. I was too young and naïve to really understand how deliberate this strategy was as Scott was essentially stalling while the company figured out larger strategic issues, such as Windows versus OS/2 versus Macintosh, and while the Languages group finished up C and could move full time to C++ tools.

Were we soldiers, doing battle and training, or were we the TVA just digging ditches to keep busy? I had no idea. Nevertheless, ScottRa devised a simple master plan. We learned the ropes of getting C++ code to work by being pioneers within Apps and using a crazy library of C++ code from researchers in Switzerland, ET++, and a commercial product Glockenspiel C++. The latter was a port of the AT&T C++ tools to OS/2 designed to work with Microsoft’s industry-leading C compiler, C version 5.1, that was already in market. ET++ was something called an application framework, not unlike parts of Smalltalk-80 with which I was very familiar—a framework was a collection of prewritten objects or code that helped programmers to write applications quickly because they could reuse previously written code. ET++ too was cross-platform, but it was just a research project at a university. ET++ was presented at a paper that came out when I was in graduate school and compared itself to MacApp, an application framework for the Macintosh that I was also quite familiar with from my MacMendeleev days. It was a given that we would someday build our own application framework. ScottRa told me it was just too soon.

That meant, however, at least there was a project. We spent our days trying to get ET++ to work on OS/2, which basically no one else on earth was even thinking about. Days turned into weeks, and months.

I was glad to have a project to work on. Like so many new hires into big companies, though, I struggled to figure out how what I was doing fit into the big picture. Actually, I wasn’t quite sure of the big picture just yet.

On to 006. Zero Defects

Go back to 003. Klunder College

Subscribers, thank you so much for the kind words and most of all participation in the discussions. My heart warms each time someone shares their own story or memories from these times. In this section, I am transitioning out of Apps Development College to my full time role. Along the way I am learning the realities of PC software today—it is usually late, and usually buggy. I’m also starting to learn a bit about the two cultures at Microsoft, Apps and Systems. There will be a couple of short posts after this and then we’re off building products!

As the summer of 1989 turned to fall, the shipment of Windows 3.0 was looming. When not working on a Mac product or trying to get OS/2 stable for daily use, most of us in Apps were dealing with getting something to work on Windows and reporting bugs back to the Windows team.

Far away in Systems, Windows, what started as a side project was now a full team of people grinding away on a death march to get Windows 3.0 done. Typically, in those days, this period of heightened work hours and intense cycles of bug fixing marked the last months of any project. The cafeterias were not usually open for dinner ushering in a (mostly) Systems tradition of ship meals, featuring a buffet much fancier than the cafeteria offered. The idea of serving dinner as part of routine death marches became a decidedly Systems approach that was so formalized it became a budgeted line item (as I would later learn when I joined Windows). Windows 3 was still months from shipping, but the activity was going on around the clock.

Windows was in Systems, which was the big dog half of Microsoft. While the history of the company was in Languages where BASIC and other tools were made, the center, and at the time the economic engine of the company, was Systems where MS-DOS was made. MS-DOS was the brilliant product born out of a commitment to IBM to deliver a product that didn’t exist and wasn’t yet under development. It was subsequently acquired and modified to meet the deadline, with the twist that Microsoft was free to license the product to other computer companies.

In other words, while IBM was the first contract for MS-DOS it was not exclusive.

Out of that, the entire PC industry was created. And not for one second was that lost on the Systems people.

From those early first days, Microsoft felt like two different companies: Apps and Systems. A buzzword in modern business, these two cultures could not have been more different, at least that’s what I was led to believe by listening to stories at lunch. Even though the company was made up of only about 3,500 people, with half in Redmond, I had not yet met anyone in Systems. While I could have easily walked a few hundred feet over to one of the buildings they occupied, that wasn’t something that people did. Apps and Systems didn’t exactly intermingle.

The one thing we knew about Systems, despite the anonymity, was that as buggy and late as Apps products were, the Systems products, I was informed, were buggier and later. Windows 3.0 was coming down to the wire. There were no real secrets—many people had builds and were installing the product, and the weekly industry tabloids, InfoWorld and PC Week, were tracking the latest rumors, test releases, and gossip. The actual delivery date was not well known, not by the team or anyone else until very close to the announcement of that date.

From the time I arrived at Microsoft and installed that first build in ADC in the summer, the launch of Windows 3.0 was always real soon now, often abbreviated RSN in snarky email. That had no impact at all on the enthusiasm as the buzz that Windows 3.0 would be a breakthrough was pervasive through the hallways. The industry was equally anxious for what appeared to be a showdown across a plethora of operating systems including MS-DOS, Windows, OS/2, and Macintosh.  

In hindsight, it was easy to make fun of the fact that everything seemed late and hardly worked. The entire industry was like that. From the earliest days of PCs none of us knew anything else.

The expression vaporware was commonly used to refer to software that was well known and frequently discussed but not yet shipping. The phrase was used first as far back as 1983 by Esther Dyson in the industry thought-leading newsletter Release 1.0. In some sense, most everything was vapor. I remember sitting in my ADC office having just received a Goldman Sachs analyst report on Microsoft from the library. In the report was a table of all our company’s products under development and estimated ship dates. The dates were far in the future and all wrong by many months or even years.

In fairness, it was challenging to simply get a non-trivial product built, have it work on the wide variety of PC configurations that existed, and then ship it in dozens of languages. That’s because there was no internet, no diagnostics, or telemetry, and anything that went wrong simply crashed the whole computer, requiring a power cycle. And, most importantly, the field of software engineering was nascent to the point of not really having the institutional knowledge of building and testing software for mass distribution. Before the PC, there were many complex systems, but each one was custom and staffed by full-time people to keep it running. PCs were different. Everything was new. And that was before the complexity of coding for a graphical interface like Windows and Macintosh.

One of the biggest differences with PCs was that the PC operating system ran in such a way (called real mode compared to protected mode that would be introduced later in Windows and still later in Macintosh) that any bug in a program generally did one of two things, but probably both. First, for certain, whatever file was open and being edited probably became corrupt and data was lost. That was a heart-stopping given. Second, there was a good chance that the crashing program also caused the computer to crash, hang, or otherwise stop working. Thus, the cardinal rules of the early PC era were born: First, frequently save work and make backup copies, and second, if something goes wrong, reboot the machine.

I learned this firsthand too many times. In college when I operated computers in the lab, an entire shift could often be consumed by trying to help a classmate salvage the remains of a term paper off of a floppy after a crash. Those were the most horrific bugs because work was lost that people assumed they were saving. Such were early PCs (and Macs).

Because of this, it was extraordinarily super-human to even get programs working in the first place. By definition, a mistake in the code caused everything on the computer to stop working, including the tools being used to diagnose the bug. The best programmers, like Duane Campbell (DuaneC), ScottRa, and others, were able to figure out how to step through each instruction carefully and monitor whole blocks of memory for changes at the lower levels to figure out what was going on.

DuaneC was already a legendary programmer within the ranks, a tech lead as I would learn. He was a few years older but seemed more grown up simply because he was married and had a maturity level that most of us lacked. DuaneC had a slight Southern accent, having grown up in rural Tennessee, and a speaking tempo I was familiar with from the people I grew up with in Florida. He was a musician but also studied computer science at the University of Tennessee. He was one of the earliest members of the MS-DOS Applications team and a key contributor to Word. He was also one of the kindest and most thoughtful leaders I had ever worked with.

The most difficult bugs were those that crossed from the application into the operating system. That meant it took knowledge of not only your own code, but also code in MS-DOS and probably code from a video or print driver as well. Lunchtime discussions often dove deep into the details of bugs and the techniques used to find the mistake, and almost always the mistake was one of a small number of common flaws, such as forgetting to check for null pointers or using uninitialized variables.

The tools and techniques that were being developed across the engineers at Microsoft to build software at scale and to make reliable products proved to be a competitive advantage. That was an important fact. It was state of the art. The 1990s saw an incredible advance in building software at scale. And no company did that better than Microsoft. Microsoft’s ubiquity and scale did not allow for gloating or even acknowledging the progress, but it would have been deserved.

The world outside of Microsoft was different. Outside, the computing landscape was marked by a period of extreme heterogeneity. While IBM lorded over the PC, which dominated business, Compaq and Dell were becoming leaders in making PC clones and even racing ahead of IBM in areas like portables and using the new Intel chips. Apple Macintosh was not viewed as a viable alternative in business but captured the hearts and minds of students, educators, and creatives. While Microsoft was busy making MS-DOS and Windows 3.0, and was already shipping Windows 2 with Excel, it was also deep in a partnership with IBM to develop OS/2, a much more sophisticated and reliable (protected mode) operating system. From the outside, Microsoft looked confused or at least lacking a clear strategy. Caught in the middle were companies trying to bring software products to market. Which operating system would they come to rely on for their products? Some viewed the duality of Windows versus OS/2 as an elaborate scheme by Microsoft to distract potential future competitors. The age-old conspiracy theory, which lacked any foundation other than IBM’s poor execution, was that this was some sort of head-fake to distract developers with OS/2 while Microsoft could dominate Windows apps. The partnership with IBM was the highest priority, but it wasn’t working out well.

The ever-present industry trade magazines seemed not to miss a beat over the rift between Microsoft and IBM. The raging debate over the cost and benefits of moving to a 32-bit operating system, specifically OS/2, was front and center even though OS/2 for 16-bits had not taken off at all. This put Windows 3.0 at a perception disadvantage as it was a 16-bit operating system that could take advantage of 32-bit Intel processors. The industry disliked this lack of purity but loved the complexity of the debate. Something I learned early is just how much the PC era was marked by bringing complexity front-and-center to debates that had little to do with customers but served to keep analysts and pundits busy. Our job was to hide complexity, but it seemed others were constantly surfacing it. Though to be fair we did our share of talking complexity, not usually passing up a chance to demonstrate our nerd credentials.

More importantly for customers, there was the constant coverage of quality problems with software and hardware. If programs were not slow, they took too much memory, or hard drive space. At the same time, every week seemed to bring more news of faster processors hoping to finally make yesterday’s software fast enough to use. Except we were busy building more software, requiring even faster processors and more memory. We were under constant pressure to build software that ran on PCs customer had while also taking advantage of the latest processor and hardware. In hindsight, what saved us all was that at any given time the installed base of PCs (the number of existing PCs in use) was being dwarfed by the run rate of new PCs (PCs sold to new customers or to replace older slower PCs). The velocity of this dynamic was key to our ability to constantly ship software that outstripped the PCs people already owned.

The industry saying was something along the lines of “what Intel gives, Microsoft takes away” in reference to increasing hardware capabilities constantly outstripped by more demanding software.

The early and successful Microsoft strategy of developing applications that ran on multiple platforms, remained the cornerstone of the Apps strategy. Only now Apps was busy enough just developing for Microsoft’s own platforms consisting of the mature MS-DOS where Apps never gained a lead, the nascent Windows that few were buying (yet), the non-existent, mostly non-functional but strategically critical OS/2, and the monster money-maker Macintosh that was competing with all of those. As crazy as the strategy (or lack thereof) seemed to the press and Wall Street, it was even more taxing for us developers in Apps.

Cross-platform development was not only impractical but the answer to a question no single customer had on their own. Yet that did not stop the search for a magical solution, and thus my first real programming work. Microsoft, BillG in particular, always believed there was a software solution to any problem if enough “IQ” was applied (BillG used IQ as an expression of currency, such as “how much IQ is in that group” or “he brings a lot of IQ to the problem”). This optimism and faith in IQ was a gift to Microsoft, but also caused a lot of problems because not every problem required a high IQ solution and those with high IQ could not always apply it in a practical manner.

Finding such a magical solution was my first project and the first project of our new team.

On to 005. Keeping Busy with Cross-Platform OOP

Go back to 002. SteveSi

ADC, Apps Developer College, was more a curriculum than a college, run by Dan Newell (DanN) and Doug Klunder (DougK). It was called Klunder College because Doug created it. ADC was basically a couple of three-ring binders of assorted documentation and memos and a bunch of self-paced coding exercises that constituted a new and unique approach to on-boarding at Microsoft at a time when most everyone who programmed was self-taught. The idea of a programming orientation or bootcamp seemed unnecessary, perhaps even insulting. I would take away much more than I could really understand at such an early juncture in my career as I immersed myself in my first lessons in culture.

Most teaching was done during a meeting with Dan, and usually by stopping by or hovering at his office. Even though we had offices, there was a constant roaming of the hallways and stopping by unscheduled to see people. This, I would soon learn, was the Microsoft management and learning culture—self-sufficient, informal, and interrupt-driven (a specific computer term that became one of my first Microsoft-isms—“What’s the best way to meet them? … Oh, they are interrupt-driven.”) It was a big change from the structure of universities but also consistent with how most everyone there had learned PC programming in the early days.

DanN’s office was filled with vinyl records, a stacked stereo system, and a few early ’80s music posters. He was an experienced Microsoft SDE and was half the leadership of ADC. A few doors down was DougK. In contrast to Dan’s office, Doug’s office was completely spartan, as though he had only recently moved in. Doug looked like a member of the Doobie Brothers, with a long beard, flannel shirt, cords, and no shoes. He was exactly what my mother had warned me about.

Doug was a programming legend at Microsoft. After graduation from MIT he joined Microsoft as the first college hire and subsequently an informal leader in the quest to hire directly from college, especially in Apps. He was one of the earliest Apps SDEs and had written much of the code in an early spreadsheet for MS-DOS that Microsoft released as Multiplan but called Electronic Paper, or EP, while under development.

Dan told me that BillG decided the company’s future was on graphical user interface (GUI) like OS/2 and Macintosh so the company chose not to bring an updated MS-DOS (CUI, or character user interface) spreadsheet to market. Doug was so frustrated by this decision that he quit Microsoft and went off to work on a farm in California. Doug’s innovative work was critical to Mac Excel 1.0, which ultimately shipped for the original Macintosh. Later, he returned to help finish Mac Excel 1.0 and contribute broadly to Apps in the transition to GUI. Doug was the ideal person to indoctrinate us into the ways of Microsoft Apps.

My first day had been a success, or at least not a failure.

After a few weeks of ADC, I finally received an email from ScottRa. He suggested we meet the next day first thing. “How about 11 a.m.?”

Microsoft SDEs bordered on nocturnal in those days. This was consistent with how college programmers coped with the scarcity of computers. It was always best to work late at night when fewer people were trying to get to terminals and, if on a shared mainframe, slowing it down. Everyone was working nights at the office back then. There was no way to even do email from home and certainly not any coding. The old Xenix email system made it easy to see if a person was logged on, and rumor was that BillG was always checking in on key people to see if they were connected. These were all traits of the original hacker ethos that had worried my mother.

When asked if Microsoft had “flex time” (an ’80s buzzword) by prospective college hires, we always said, “Yes. You can choose to work whichever 80 hours of the week you want to work.” That was, essentially, true for the ’90s. Our views later matured as did the company, much to the chagrin of new old-timers like me. Mostly we were in our 20s and loved what we were doing.

Scott explained what was in store for me for the next few months. Before programming anything I needed to learn the unique dialect Microsoft used. While I knew the programming language, Microsoft had a unique style called Hungarian, named for Charles Simonyi (CharlesS), one of the rarified level 14 architects in the company and the only one in Apps. CharlesS was recruited by BillG from Xerox PARC where he had built the first GUI word processor. Hungarian was the secret handshake used between programmers at Microsoft and it was unlike anything I’d ever seen. In college programming or in books, one might use a name in code such as FormatLine. In Hungarian, we used names like FFormatLineFspec, which were chosen to make code more manageable for large teams.

I also needed to learn the tools used to build Excel and Word. There was a proprietary programming language called CSL, also named after CharlesS. This language, based on C, had a virtual machine, which made it easier to run on other operating systems (in theory) and also had a good debugger—attributes that were lacking in the relatively immature C product from Microsoft. I also learned RAID, the database tool that the product groups used to track bugs in products (get it, complete with backronym of Reporting and Incidents Database). And, most importantly, I learned SLM, pronounced slime, the source code tracking tool (like GitHub much later). Through this I used shipping code and coded up features and fixed bugs as exercises, never checking them into production. It sounded pretty cool. It was pretty cool.

I loved talking with Doug. He was not like anyone I had spent a lot of time with—he was truly the hippie/hacker Time described. As I got to know him, I learned of some of his relatively extreme perspectives. He was obsessed with privacy. He didn’t have a driver’s license, bank account, telephone, or anything, but still lived among us. I often saw him outside of work. We lived in the same neighborhood (Capitol Hill, soon the heart of grunge music) where he always paid cash at one of the restaurants in the neighborhood. This dedication to privacy proved even more ironic, and prescient, as he went on to build Microsoft Money, which he used to track his cash transactions. In his post-Microsoft career, Doug became an attorney and, admirably, went on to work for the ACLU on issues such as privacy. He was ahead of his time.

Importantly, for my own future, Doug instilled in me a sense of principled product development. Throughout my time at ADC Doug shared his account of the decisions around building Mac Excel instead of a new MS-DOS spreadsheet, including a famous Red Lion Inn offsite where the strategic decision was made to bet on the graphical interface. BillG insisted on prioritizing GUI over CUI even with a potentially killer MS-DOS spreadsheet close to complete, causing DougK to ultimately quit out of principle. Doug’s principled lessons followed me through my career.

Doug was an incredible programmer, the first of many amazing ones I met. He had a full map of an entire body of product code in his head and a deep understanding of the data structures and code paths—more than encyclopedic but organic as though his brain had merged with the code. In hindsight, I came to understand that great programmers have the same relationship to code and products as great writers do to words and complete works, or filmmakers do to camera shots and complete films. Every line of code, every data structure, was not only deliberate but deeply related to the other choices one makes.

One issue we spent an enormous amount of time discussing was memory management, which was an acute problem in PCs those days—how to fit more information in less space. This was not simply about data but also the amount of code in an application—how to do more with less. Doug recounted how he had developed minimal recalc for Excel (originally for the unreleased spreadsheet product), which was a way of only recalculating the cells in a spreadsheet that needed to be calculated when something changed. Previously every change in a spreadsheet recalculated the entire sheet, which was slow and memory intensive. It is difficult to overstate the brilliance in Doug’s approaches. It would be equally fair to say that Doug wrote code only Doug could understand, very much how great products were built then.

Many of the conventions or techniques used in Apps were pioneered by Doug and taught or, more correctly, transfused to us in ADC. Even though software products were often late (very late) and quality was spotty (very spotty), that was only in hindsight. In general, Microsoft’s Apps, particularly MS-DOS Word and Excel, were generally among the most robust and highest quality. DougK and DanN instilled several key lessons about being an Apps software design engineer:

* Scheduling and estimating work. Individuals needed to be really good at scheduling their own work and coming up with estimates that were not only precise to the day but accurate as well.

* Bulletproof code. Developers were responsible for building code beyond their features, including the code that ran in “debug mode” that was constantly checking the integrity of the data structures and ensuring that assumptions made by programmers were validated. During any code review in ADC, the code was sent back if it was not fully defined by what were called debug ASSERTs, or code that was run to verify the values of variables and integrity of data structures while running a special build of the product for this purpose.

* Self-documenting code. Schools taught that good code had comments or annotations that were not code but English that explained the code. Doug hated comments and insisted that code should be the ultimate comment itself. This was a bit ironic because he was known for developing some insanely efficient code that was also difficult to read and would have benefitted from comments. His view was that comments were always out of date and far less precise than the code itself. I really had to unlearn commenting, a practice I had embraced.

* Performance in speed and minimal memory. CPUs were slow and memory was extremely scarce, so there was a big focus on writing efficient code. This was rooted in BillG and was an important part of Microsoft’s early developer culture and key contributor to success. Code written this way was hardcore.

During ADC, I built a memory allocator, code that handled requests from a program to provide memory to store data and later free memory. Early programs, especially written in C or CSL, were notorious for mismanaging memory, which caused program crashes and in turn crashed the entire computer along with it.

Doug had developed a set of ideas for building a bulletproof memory allocator, one that tracked allocations and reallocations and made sure memory was properly initialized before it was used in the code. These were super common bugs in PC software.

It was a huge learning experience. But I had also been working on modern, automatic memory allocation called garbage collection (GC) in graduate school. After a few days of hacking away on my memory allocator project for Doug, I worked up the guts to approach him and ask why Microsoft did not use GC.

It didn’t go so well. Doug literally laughed at me. Still, after I persisted, he suggested I go meet Jon DeVaan (JonDe) on the Excel team who could go through every bug in Excel (it was up to version 2.x and ran on Windows) and explain how many came from bad memory management code. Doug knew that his memory allocator, also my programming exercise, was a significant barrier to creating memory allocation bugs in the first place. He wanted me to see for myself.

JonDe didn’t laugh at me like Doug had, rather he listened then indulged me by going through 30 minutes of RAID searches looking at memory management bugs to see if GC fixed them. GC prevented perhaps eight of 7,500 in Excel. That made for a convincing argument that GC was not remotely worth the tradeoff in memory and performance. GC would eventually become standard practice on the web and on Apple’s iPhone, but I was a decade too optimistic.

JonDe was among the best Microsoft had ever produced, in addition to being one of the best engineering managers to have ever worked at the company. We worked together for the remainder of my time at Microsoft, each with unique strengths, making each other better at what we did.

I spent an inordinate amount of time installing Microsoft products and using them. I developed my own method for using a network boot disk and getting a “clean” PC up and running. This skill seemed to be both a necessity and something each person reinvented on his or her own. PCs still barely worked.

One product I spent a lot of time on that was still under development, Windows 3.0, a year away from finishing but was already the buzz of the developers running it. At the time, the mainstream SDE machine was running OS/2 because it was able to use more memory and handle more programs gracefully, but it also had a lot of limitations, such as a lack of apps and the inability to print. There was always much cafeteria discussion about how lame OS/2 was, wondering what was going on over in Systems with our partnership with IBM.

Windows 2.x was already in market and had some early pioneers supporting it, including Ray Ozzie at Lotus, who had developed the innovative Notes product. The biggest supporter of Windows 2.x was Excel, which was also developing version 3 of Excel to be on both Windows and Mac (and OS/2) at the same time, using an innovative cross-platform layer of software.

Back then, buyers did not get a PC with Windows. PCs came with MS-DOS. Using Excel meant buying Excel, and it came with Windows. According to branding and packaging, Windows was an operating environment, or more like an app on top of MS-DOS. This became the subject of antitrust consternation years later. As innovative and successful as Excel was on the Mac, Excel on Windows was not competitive with the MS-DOS Lotus 1-2-3. Microsoft’s older CP/M and later MS-DOS spreadsheet Multiplan was a distant number two.

Windows 3 was a bit of a skunkworks project and was a bet on a new architecture called protected mode, which enabled multiple programs to operate at the same time and share a larger amount of memory. In many ways this was also what OS/2 was supposed to do, but OS/2 had much grander visions as well as a difficult engineering partner in IBM (or IBM might say it was Microsoft that was the difficult partner). Windows 3 was beginning to look more like an operating system and less like an add-on to MS-DOS. It was interesting to install and play around with, which all of us did. Actively under development were versions of Word and Excel and several other products. We spent the summer trying everything.

DanN shared with me what he was most excited about—one of the key “secrets” of Windows 3, which was how the product enabled protected mode but could also remain compatible with old MS-DOS programs. David Weise (DavidW) and Murray Sargent (MurrayS) had invented some novel uses of the Intel chipset that even Intel did not anticipate, which enabled these efforts. One programming trick called PrestoChangeoSelector was a key “hack” they developed and later became an absurd symbol of “secret” application programmable interfaces (APIs) in Windows (absurd, because it was supposedly secret, when in fact it was right there to see). Dan told this story with great Microsoft pride, as the development of Windows 3 and these techniques represented much of what Microsoft did so well in those days. Hack.

I admired Dan. What Doug brought to ADC in insights for coding, Dan brought in big picture about how products were built and team dynamics. Dan knew everyone at the company and was definitely a cool kid. Because of Dan I got to meet quite a few of the senior people across both Apps and Systems. Systems was pretty okay to Apps people and vice versa, but there was clearly both an organizational and cultural divide between the two—a theme that I would experience for many years to come and also be the subject of many “battles”.

A few months in, Scott came by and said he was anxious for me to join the team. My time in ADC was abbreviated so I could get cracking on our project. Unbeknownst to me, I was joining a newly formed “tiger team” created to build an entirely new product to streamline building applications.

Object-oriented, GUI, and Microsoft’s next killer product (killer was Microsoft jargon), plus Scott told me our project was “super important to BillG.”

On to 004. Everything is Buggy

If you missed the first post, start with 001. Becoming a Microsoftie (Chapter I). A Prologue has been added offering just a bit about my own history with computing. There is also a Roadmap/Table of Contents. If you need an overview and guide to subscriptions with discount codes, see Introducing "Hardcore Software".

Back to 001. Becoming a Microsoftie [Chapter I]

When I first arrived in Redmond, I lived about three blocks from campus, in company-provided temporary housing at an apartment complex called Bellevue Meadows, a block from the Residence Inn I had almost burned down during my interview. It was still light out at 9 p.m. on my first night (welcome to the Northwest), so I walked over to campus to check it out.

Microsoft’s three-year-old campus was made up of the original X-wing buildings, 1 through 6, and the recently completed double X-wing 8 and and 9. There was no building 7. Nobody knew exactly why, though there were a bunch of theories tossed around over the years. Sending a new person to meet up at building 7 was an ongoing prank. The real buildings surrounded a fountain and the small-but-infamous Lake Bill (which, looking back, is much smaller than I recalled from that first night). There was a basketball court near the lake, which always seemed to be in use. The buildings, connected by tree-lined sidewalks, were known for their design, which was meant to maximize the number of private offices with windows.

In a nod to Microsoft’s culture of self-reliance, the next day, my first day, after a two-hour orientation session (that felt like forever), I and about 20 other college hires were left to fend for ourselves. While I had been told how to set up direct deposit (paychecks were still hand delivered for many) and learned some details about my healthcare plan, I literally had no idea where to go. Fortunately, a more studious fellow new hire noticed, buried in the paperwork, that there was a map and an old-style printout with name (Steve Sinofsky), telephone extension (x67768), manager (Scott Randell, listed as SCOTTRA), and an email ID and password (yes, printed). The floor plan and numbering system made MIT’s infinite corridor look understandable.

As I flipped through the paperwork, I noticed my assigned email name was STEVESI on the printout, which immediately irked me as I was steven in all my previous systems (all lower case because of Unix). Obviously, I was not going to complain.

As I came to understand it, SteveSi was officially, and forever, my new name. Email names were how people wrote and spoke about others. Where a previous generation might have used only a last name out of casual respect or mister in person, Microsoft used email from BillG to SteveB on down. Aside from the free drinks, private offices, and khakis with button-downs, email names remained one of the iconic cultural identifiers of those days (and still used among alumni.) Given names no longer mattered at Microsoft. I was SteveSi. Cris Wittress was CrisWit—I finally got what she meant.

Before I started, Steven Schwartz had landed the name StevenS, a fact for which I was always jealous. After he left I even tried to secure the name, but there was a no-recycle policy. A coworker named Bill Gallagher was given BillGa, and for years he got crazy mail intended for (the real) BillG. As the company grew, it began to wrestle with the complexities of people getting married (or divorced) and how to deal with email name changes—much trickier than they’d imagine. Ultimately, in the late 1990s with the move to Microsoft’s email product, we finally moved to friendly names like [email protected].

There was a list of email aliases (an early Unix-ism) to get help, like benefits, sickday, vacation, supply (office supplies), recept1 (recept2, recept3, etc. for the receptionists), stock (stock option sales), espp (employee stock purchase plan), payroll (for help with direct deposit), and, best of all, pcrepair, which could help with computer hardware. Perhaps that was second best, as I soon discovered library, which mailed the Microsoft librarians any topic to research or a request to send copies of articles or locate any book needed for work. There was an actual library filling most of one arm of an X in building 4, where I spent a lot of time as well. Everything was an email away.

Microsoft made about 35 different products back then, and I had personal experience with almost none of them. Importantly, by the mid-1980s, Microsoft moved beyond being a single-product company. It had substantial businesses in each of the major categories of the day: languages, operating systems, and applications. No single product represented more than half the company revenue. This early diversity was critical to Microsoft’s growth. In many ways, early software companies emulated record or book publishing by having many licensed titles for sale, and while early Microsoft followed this model it was now building most software in house.

The Systems group was the big group and was made up of the grown-ups. It felt to me the most like my summer aerospace job because there were people who were married (gasp!), and some even had children. This was the group that made MS-DOS, which was the single biggest moneymaker. They were also making OS/2, which was a massive joint project with IBM. There was a much smaller side project called Windows that was increasingly interesting. Unique to the Systems group was a much larger number of people who had joined Microsoft with years of prior work experience. There were people from IBM, DEC, ATT, HP, and a host of other computer companies from a previous era. Dave Cutler (DaveC), a legend with over 25 years of experience, had recently joined from DEC along with many of those colleagues. This made sense since building an operating system was something done at other big companies.

Languages was the history of the company and the oldest group. This was the group that made BASIC, as well as programming languages and tools from C to Pascal, Fortran, and, importantly, Assembler. The Languages products were for MS-DOS, Xenix (the commercial version of Unix, the ancestor of today’s Linux), and an expansion to OS/2 (an ill-fated joint development between Microsoft and IBM).

I thought many of the people I met in Languages seemed old. Some owned houses and had new cars. Some had been at Microsoft more than five years already.

Apps was the colloquial term for Applications, which is how the computer industry viewed programs used by end-users, versus the Operating System, which was required by the machine, or Languages used by developers. The Apps group was less tenured as it was both a newer business for Microsoft and seemed to have more college hires. Apps was almost a sleeper business even back then. Most of the products it made were for the Macintosh, like Word, Excel, and File, all of which were on the first or second version. Apps for MS-DOS were almost as numerous, but all were a distant number two in the market relative to software giants Lotus, WordPerfect, Ashton-Tate, and Software Publishing that I had used in my summer job during college.

I walked over to building 5 to find the private, interior office in which I’d begin my career. It had no exterior window but had one to the hallway. As I searched for my office, I passed the kitchen and saw the giant glass-door refrigerators filled with cans of every variety of Coke and Pepsi products like a convenience store.

It would be decades before I paid for a beverage.

Just across from the kitchen was the mail and copy room. This room had everything one could imagine needing for work. It was like a CompUSA and Office Depot all in one. Along with a big laser printer (and a copy machine), there were 5.25-inch and 3.5-inch floppy disks by the case, notebooks of every size writing paper (not computers which hardly existed in portable form at this time), printer paper, pens, tape (transparent and masking), thumb tacks, and more. There were boxes of colored pencils (legend had it that BillG used those to annotate code with different colors, but I later learned that was a myth). There were rulers for scanning across lines of code in landscape. Best of all were the staplers with the Microsoft logo on them. This was like a gift shop, and anyone visiting left with a box of floppies and one of those staplers.

After a few wrong turns, I finally saw the engraved door placard (think Mad Men) that read STEVE SINOFSKY. Not Steven. I was peeved. While I did not meet him for a few years, Steve Ballmer (SteveB) had something to do with this, I’m certain.

Later that morning, I met a fellow college hire named Antoine Leblond, a French-Canadian who was in a far worse position than me, as the powers had reduced him to TonyL. That only lasted until his then-girlfriend visited and, as an even more ardent Québécois, Lucie Robitaille somehow managed to get it changed to a cool alias: Antoine.

Offices back then were furnished in what could be described as Native Northwest. Think a solid wood oak 60-by-30-inch deep desk with a 24-inch typing return and a swivel chair with matching oak arms. There was a matching 60-inch high solid oak bookcase. A whiteboard and cork board were attached to the white walls. A 12-button analog phone in corporate brown was on the return, featuring my personal phone number, 206-936-7768 or x67768. The furniture reminded me of the make it as indestructible as possible stuff that filled the freshman University Halls at Cornell. Even if I was motivated to rearrange the layout of my nine-by-twelve-foot space, I could not because everything was so heavy. The setup was also horribly non-ergonomic by today’s standards. Still, by any measure of an entry-level office, it was amazing.

My bookshelf was pre-populated with, I later learned, standard-issue books for every new software design engineer hire. There was an Intel 286 and 386 reference along with a Motorola 68000 reference—everyone in software engineering understood machine architecture and instruction sets. A phone-book-size MS-DOS encyclopedia weighed down the shelf. There was also a dictionary and thesaurus, and a copy of the same Microsoft Press desk calendar featuring important milestones in computing and an MS-DOS technical reference card in the back that CrisWit had sent as a recruiting gift.

Importantly, there were two seminal works on programming, Fred Brooks’s The Mythical Man-Month and Programming Pearls by Jon Bentley. The former, I learned, was the most epic of all Microsoft struggles, which was trying to release products on time—by the summer of 1989 Windows was on the second version, having shipped 1.0 almost two years after public announcement. The latter book represented the hardcore ethos of Microsoft software engineering, which was tight code—what code could be written to solve the problem with the most clarity and fewest lines, least amount of memory, and fewest CPU cycles.

There was also a copy of The Hacker’s Dictionary by Guy L. Steele, a famous computer scientist partly responsible for the programming language Scheme used and developed at MIT. The book was a 1980s version of what was often called computerese though Microsoft had its own unique language. One other book seemed rather strange to me, Stewart Brand’s The Whole Earth Catalog, which seemed useful if I was intent upon producing my own energy or building a yurt, but definitely represented the tail end of the hippie culture of computing from which we all originated.

There was a Compaq PC and a terminal in the office. The Compaq was an Intel 386 chip running at 33 MHz with an extended memory card and hard drive. The terminal was hardwired to Xenix servers via a different network and where the email system was hosted. It was Xenix email, which itself was just a port of Unix mail. I was right at home shelling out to “vi” to edit mail as I had been doing since college. (vi as in visual editor abbreviated.) There was also an HP-16C Computer Scientist calculator, for handling all the hexadecimal and binary conversions I would need to do, but I already owned one.

I signed on and changed my password to one I used for the next 10 years or so until password policies came into vogue. I fired off emails to some old lab mates who were the only other people I knew using email. I didn’t hear back right away, which was weird. That was when I learned outbound mail was batched and sent/received twice a day. I was told Gordon Letwin (GordonL), the legendary MS-DOS and OS/2 engineer, was not in favor of being connected to ARPANET or BITNET due to security concerns (he was certainly ahead of his time) so this was the compromise. Emphasizing this, our first business cards had only phone and fax numbers and TELEX numbers (!). By special request, a UUNET address could be added. UUNET was one of the first commercial internet provider of email addresses. That summer, mine was still uunet!uw-beaver!microsoft!stevesi. Don’t ask. Microsoft used email for everything inside the company, but externally email was not yet a thing.

Turning on the PC, I was immediately greeted with a hung machine (back then we called them machines, not devices) unable to make it through the boot sequence. I received my first lesson in corpnet, or the corporate network. The network was reliable, but the software on the PCs was not. Hangs were frequent and the only fix was a power cycle. I was only familiar with Novell Netware and had not yet experienced a product in the same space that Microsoft had just released, LanManager, a.k.a. LanMan. I wasn’t alone. Almost no one had bought the product because it mostly didn’t work.

This brought my first experience with emailing helpdesk. By email, they asked me if I was an SDE. I wasn’t sure, and then I realized my title was software design engineer. The next mail said they were on the way.

A nice man with a pushcart filled with tools and gear to keep PCs running and connected showed up. He pulled a 5.25-inch floppy out of a plastic disk holder and began the process of a network boot, which was a fancy way of using a floppy disk to boot a computer and connect to the network. After a minute or so of grinding floppy noise, I saw the magic “C:>” prompt.

The tech began some magic incantations that were new to me, like NET USE to connect to a shared network drive. Then he began to install OS/2 1.1 and then applications, but there weren’t many. I asked where the printer was and he laughed. I learned OS/2 didn’t really print yet, and to do so I best to use MS-DOS and those apps, which he then set up (also using some new magic like mapping LPT1 to the nearby printer in the copy room).

Once my computer was set up, I still wasn’t sure what to do with my day, but it was lunchtime. I was never really good at lunch or spontaneously meeting new people, so I began to get stressed. I finally resigned myself to passing on lunch and futzing in my office. Then I heard a knock on my door.

“Hi, my name is Andy Craze . . . AndrewCr.”

We were both new, though Andy had started the week before, and we were both joining Apps (the team would soon move to Development Tools in my first of many re-orgs). As recent grads do, we exchanged where we were from, college, and major information. Andy was from Cleveland. Went to Stanford. Studied computer science. He also informed me he was a huge Grateful Dead fan. He was outgoing and suggested we get lunch.

What I didn’t know, until Andy explained it, was that we weren’t technically working at our actual jobs yet, or even sitting with our teams. Instead, we were in Apps Developer College (ADC). ADC was where new Apps SDEs learned how to be Apps SDEs. We would be there for an indeterminate amount of time while we learned the ropes—meaning learned the tools and techniques of the Apps division. If those few sentences sounded like a bunch of jargon, that’s essentially what every conversation sounded like.

Unlike today’s start-ups in Silicon Valley, lunch was not free but marginally subsidized by Microsoft and operated by an institutional food company. We went to the pizza station and I ordered by the slice.

I sustained myself on pizza for a decade.

On to 003. Klunder College

Subscribers head over to substack.com by clicking on the title of this email and join in the comments and discussions. If you received this from a friend, please consider subscribing.

Welcome. This is the first serialized section (yay!) The book is broken into 15 chapters and an epilogue. Each chapter has a number of sections, which are the posts you’ll receive in email. Occasionally I will add some context or an update at the top of a post like this. The Roadmap will maintain links to posts and will be an easy way to track the whole work. There will be additional posts and ask-me-anything threads (a Substack feature) which will also be mailed out and listed in the roadmap. The first posts are about what it was like starting as a new hire and a bit of an introduction to me.

PCs and software barely work, but the ascent of the IBM PC powered by Intel processors and Windows is underway. It is the start of the modern PC era as PC sales (from all manufacturers for the year) exceeded 20 million units worldwide, which is about half the worldwide sales of all personal computers to date including those from Apple, Tandy, Atari, and more. Looming, however, is platform competitor NeXT, the new computer company started by Steve Jobs. The dramatic extent to which that company will alter the technology landscape is decades from revealing itself. While Apple’s Macintosh is a competitor, it is also the foundation for Microsoft’s Applications business. The group I was hired into was squarely in the middle of both the new and old Steve Jobs platforms.

The whiteboard in my graduate school lab read, “Steven, Bill Gates called. Call him back.”

It was super weird to see that written because Microsoft wasn’t on our collective academic radar and most people didn’t know who Bill Gates was. Someone was clearly playing a joke on me. My college friend Brent grew up in the Seattle area and I had mentioned to him that I was interviewing at Microsoft, so it was probably him.

Later that day, I got home to find my PhoneMate microcassette answering machine flashing. There were two messages recorded. The first one was left earlier that morning as I started walking to the Lederle Graduate Research Center at UMass-Amherst where I was a second-year PhD student in computer science. A somewhat squeaky and distracted voice said, “Steven, um, this is Bill Gates calling. Can you call me back at . . . um . . . 206-882-8080?” The second message had been recorded later in the day. “Steven, yeah, this is Bill Gates calling again. I guess I called you at your lab like your message said, but you weren’t there either. When you get a chance call me back.” My outgoing message at home gave the number of the lab since that was the only other place, basically, that I spent time.

Brent’s ploy seemed rather elaborate. He kept it going for a couple of days as I kept getting voicemail messages claiming to be Gates. I did nothing.

As an undergrad I had written a program called MacMendeleev (after the father of the periodic table). I had been dying to write a Mac program after the incredible Super Bowl launch advertisement. MacMendeleev was the result of landing in an encouraging chemistry lab (thanks, Professor Clardy). As much as computer science classes made me finally feel like I was in the right place in life (thanks, Professor Teitelbaum), my chemistry classes were the exact opposite (B+ fall of freshman year was the highest grade I’d receive in chemistry in four years). The Mac was not a business computer, especially according to the advertisements by IBM, and they weren’t used in my classes. There wasn’t dBase II yet, as I had used earlier on my Osborne, and I wasn’t going to use Microsoft BASIC to write something from scratch. The Mac was, however, focused on education. The one thing I loved in chemistry was the periodic table. I dreamed up the idea of an interactive periodic table that could chart or graph the elements according to different properties to see what exhibited periodicity. I got some help from my lab mate, Tom Ball (a future Microsoftie), to help me with the graphics.

Surprisingly, MacMendeleev achieved a small amount of success. We signed up with the ever-present photocopy store Kinko’s that maintained an in-store kiosk that made copies of library programs. It was a software vending machine. The program was used in a few classes, and we made enough money on it to fund a cruise on Cayuga Lake.

The program also scored me an invitation to the 1988 Association of Computing Machinery regional gathering on Computers in Education. The conference loaned me a Mac to use, instead of the luggable PC I started using that I had acquired from my summers at Martin Marietta. The PC ran MS-DOS (Microsoft Disk Operating System), the software required for a PC to run and provide capabilities for other companies to write programs. It was the defining product for Microsoft in the 1980s and became the business engine that powered the company prior to Windows and Office.

I had never been to a conference and was not sure why I was there or what was going on, but I found myself sitting at a table talking about the periodic table, doing my first demos and booth duty. Apparently, I impressed the organizers enough to win an award. My prize was a just-released Color Macintosh. It was a huge score.

A representative for Microsoft approached me after my win, offering me some software, and asked me what I wanted…BASIC? I was heads down building Smalltalk on Unix, using TeX for papers, and using all GNU tools, but we agreed on a copy of Microsoft Word. I was excited but thought it was weird because everyone used WordPerfect on PCs and MacWrite on Macintosh, and I used LaTeX.

My first year of college I worked the night shift at a public computer lab filled with all sorts of new computers. There were PCs people could use (mostly grad students) for word processing and spreadsheets using WordPerfect and Lotus 1-2-3, an odd Apple Lisa the predecessor to Macintosh, several highly advanced computer graphics workstations used by physics students, in addition to the mainframe terminals, punch card readers, and refrigerator-size line printers I maintained. By early 1984, the first public Macintosh computers arrived, and I spent my Friday night shift helping people recover documents after the notoriously flaky MacWrite crashed and ate them.

Later, when I was applying for jobs (with the resume of a student who never really had a job), on a whim, I applied to Microsoft using the address on the Microsoft Word box I’d received. It was 16011 NE 36th Way, Redmond, WA 98052. I also sent my resume to Apple Computer. Like everyone I ever knew, I never heard back. They were like that back then (and still are, I am told). I think about a year later I got a postcard with a yellow Post Office sticker forwarded from Amherst to my current address letting me know my resume was on file.

I was fairly certain I was going to work in government service, as it was a popular trajectory for engineering graduates, especially those like me with some Russian language skills. There were multiple trips taken to undisclosed locations in the metropolitan DC area talking to the high-tech parts of three-letter agencies.

But then, two days after mailing it, a Microsoft recruiter named Cris Wittress called about having me come out to interview. She overnighted a plane ticket and a hotel booking. I was off.

The taxi ride to the hotel had a cutting edge feel to it. I was used to seeing important technical companies on Boston’s Route 128, like DEC, Data General, Apollo, and Banyan, but in Seattle, the names were all different: Apple, MicroRim, Egghead, Tektronix, and more (and oddly a McDonnell Douglas Aerospace building right next to Microsoft).

I stayed in the new Residence Inn, which was only a few minutes from the Microsoft campus, as it was called. It was a dreary February. I didn’t have a car and couldn’t figure out where anything was, but there was a Houlihan’s next-door so I had potato skins and fried cheese, as if I was still in high school. I got back to the room and decided to try out the fake log in the fireplace. Apparently, there was a chimney door or something, as I quickly set off the smoke alarm and caused a minor incident.

First thing in the morning, I put on my blue Brooks Brothers suit and headed over to building 1. I signed in in the lobby and was promptly greeted by Cris Wittress, who introduced herself as “Cris Wit” as though it were a nickname. The first sign of cool: She had an office. Come to think of it, everyone had an office—with a door. Fancy.

Cris briskly walked me through the day, describing the people I was going to meet and explaining that they were going to ask me technical questions and that was my interview. In one-hour slots, back-to-back, I met with a phenomenal loop of people who asked me coding questions, grilled me on architecture, and challenged my core assumptions. There was a fancy lunch and a fancy dinner that were typical of job interviews in the go-go 1980’s. Not so typical were the offers of beer at lunch and sake at dinner (at Benihana!) Most everyone on my interview loop was a recent graduate of Waterloo or Toronto. Along with the elite schools in the US these two schools were well represented in the Microsoft ranks.

I flew home the next morning. Cris called right away to tell me I had a job offer and sent me a rush version followed by a formal letter. The offer arrived overnight via Mailgram, an expensive, old-fashioned telegram (except it could be a full page). Mailgrams were used by big business before the internet, when the fax machine dominated offices (but students did not have one).

It happened fast. The offer was to work in the Applications Tools group. It was for $37,500 and had 1,500 non-qualified stock options, plus moving expenses. I called my uncle, who worked in investment banking on Wall Street, to ask what a stock option was. He told me and said mine were probably going to be worthless, but someday maybe they’d be worth $10,000.

Still undecided but leaning toward government work, one evening, late, I got a call at home.

“Hello, Steven . . . finally great to get a hold of you. My name is David Pritchard and I work in college recruiting at Microsoft. Bill Gates has been trying to get a hold of you, but it has been difficult. Can we set up a time tomorrow for you two to talk?”

David was one of Cris’s managers and leader of the college recruiting program (the success of that program is substantially owed to his early efforts).

Oops, I guess that really was Bill Gates before and not a prank.

When Bill and I finally spoke, the conversation was awkward, since neither of us were exactly good at chit-chat stuff.

“Hi, Steve, this is Bill Gates.”

“Hello. Thank you for calling, and so sorry for the confusion. I thought a friend of mine . . . ”

“So, David gave me this list of like ten people and I’m supposed to call all of them and convince them to work at Microsoft. You should come work at Microsoft. Do you have any questions?” (I always thought this was the best part of the call—him telling me he was just cranking through a list. Transparency.)

“I’m definitely excited and thinking about it. I don’t really have any questions.”

“Well, why haven’t you accepted yet? You have a good offer.”

“I’m considering other things. I have been really interested in government service.”

“Government? That’s for when you’re old and stupid.”

(No, really, he said that.)

“At Microsoft we have amazing things going on in multimedia. Have you seen all the things we are doing with CD-ROMs and video? We are going to make a whole encyclopedia on a CD-ROM, 650 megabytes with videos, maps, quizzes, and more.”

“I haven’t. I use a Macintosh and workstations. I used MS-DOS at my summer job and Windows 1.0, but it was pretty slow.”

“Well, Microsoft makes more money on Macintoshes than Apple does because of our apps—our word prosser [sic], Word, is super good. OS/2 runs in protect mode, which the Mac does not do. Do you have any more questions?”

“Not really.”

“I’m glad we got to talk. The offer is super good. Bye.”

After some failed negotiations on my part for more salary, I accepted and joined the Applications Tools group with Scott Randall as my manager. My start date was set for July 10, 1989.

The Seattle Times wrote an article in 1989 called “Inside Microsoft – A ‘velvet sweatshop’ or a high-tech heaven?” Cris mailed it to me, along with a flurry of fancy Airborne Express overnight envelopes I would receive over the coming weeks containing items meant to woo me including the Annual Report, a Microsoft Press Desk Calendar (with an ASCII table in the back), issues of The Seattle Weekly (to remind me of the cool music scene), and glossy data sheets on Microsoft products. The Times story chronicled the long hours people worked, including evenings and weekends. It talked about former employees referring to themselves as “recovering” Microsoft workers, but it also painted the picture of a creative, challenging, prankster-geek culture. The contrast and the controversy didn’t bother me.

What could be so bad about hard work that came with a private office, free Coke or Pepsi, and Lipton Soup?

Whatever was going on there, it was working well.

Microsoft finished fiscal 1989 as I was crossing the country to start my job. Despite a global recession and a market crash leaving company stock close to its IPO pricing three years earlier, it closed the books with more than $800 million in revenue (1989 dollars) and a market capitalization of about $3 billion. The company was already doing business in 50 or so countries with dozens of sales offices around the world—a testimony to the growth mindset of Bill Gates. The company had approximately 3,000 global employees. I was the latest of about 1,200 hired in research and development, mostly in Redmond, Washington. The Apps division was a still in the low hundreds of engineering hires, most from college, and most of those experienced on Macintosh.

When I joined Microsoft, I knew little about the company and even less about the corporate world in general. I was a kid fresh out of school, impatient and gung-ho to be a part of my new world, but equally inexperienced and a bit overconfident about what I was in for.

In the computer world Microsoft was well known but it wasn’t IBM or RadioShack. But most people I knew, including my family, were extremely fuzzy on what I was going to do and where I was going to do it. My grandfather was the only person in my family to have ever been to Seattle, and that was by stow-away train rides during the depression. I spent most family gatherings explaining what software was and that Seattle was not just a forest.

On to 002. SteveSi

In 1982, Time magazine named the personal computer Machine of the Year, marking the first time a non-human was awarded Man of the Year. It was a fascinating read, but like many nerdy kids across the country at the time, I’d already become captivated by computers.

My best friend Dave Crotty and our other best friend, Neal Fordham (collectively, the three of us were known as the boys), spent the previous year making mixtapes of ’80s punk and new wave on Dave’s father’s Bang & Olufsen component system.

When Dave’s brother Kevin got an Atari 800 computer, my curiosity piqued. I was mesmerized by this new machine—not by the video games I could play on it but by the presence of BASIC, the first programming language experienced by most everyone in the early days of personal computing. BASIC was thanks in no small part to Bill Gates and Paul Allen and their start-up originally known as Micro-Soft.

I gave up Space Invaders for rows of numbered lines. The timing turned out to be great.

Our family business was a retail store in Orlando, Florida. My Saturdays were spent calculating sales tax, doing inventory, and making change while chatting with customers.

Dave’s Atari gave me an opportunity to create my first program:

10 PRINT "Amount of sale?”20 INPUT sale30 LET tax = sale*.0440 PRINT "Merchandise: ", sale50 PRINT "Tax: ", tax60 PRINT "Total: ", sale+tax70 GOTO 10

As the family business evolved, my father, David, realized that turning it into a wholesaler was a great opportunity for the family. He decided to buy a computer to run it. I have no idea where the motivation for this came from and certainly knew the expense was significant ($1,800 then or about $5,000 in 2020 dollars). While our family had been early adopters (to some degree) of many modern household items—we had a fancy 35mm camera, a microwave, a Betamax, and even a big-screen TV—a computer, however, was puzzling. It was also an enormous privilege. Rather than a “toy” computer, of which the Apple ][, Atari, and the new Commodore 64K (64K!) were viewed at the time by those who claimed to know, my father invested in a business computer. He went to a computer store, staffed by people in suits and ties, and bought one of the earliest Osborne I computers.

The Osborne was a remarkable machine at the time and in the history of the personal computer. A nearly 30-pound “portable” (it didn’t even have a battery as portable meant you could relocate it) described as “the size of a sewing machine,” it had a 5-inch CRT screen that wasn’t large enough for a full 80 characters across, so using the CTRL key and arrows that panned the screen would allow someone to see the rest of it. It came with two 90K 5.25-inch floppy drives and 64K of memory. It ran the CP/M operating system (Control Program/Monitor), which at the time was vying to become the de facto standard.

It came with a bundle of “free” business software, including the WordStar word processor, the SuperCalc spreadsheet, a copy of the remarkable VisiCalc on the Apple ][, and two (!) different BASIC languages, MBASIC, which I later learned was Microsoft BASIC, and a faster variant, CBASIC. Notably, a “database” called dBase II was promised but did not arrive until later (“real soon,” the dealer told us).

Magazines were the early fountain of knowledge about the new computer because computers were not connected to anything else or any other computers. The monthly Portable Companion, the first issue, free with the computer, was filled with tips and tricks for using the Osborne and the bundled software. I dutifully filled out reader response cards and soon had a library of code samples I could type in and printer configuration codes. I read Dr. Dobb’s and BYTE at B. Dalton Bookseller in the mall instead of playing games.

I set up the computer in the tiny extra room that served as the TV room for my sister and me, much to her chagrin. The noise created by the combination of typing on the full travel keyboard and the constant grinding and clacking of the floppy disk drives, not to mention the loud beep at power-on and whirring fan, took a toll on my younger sister, Jill. Through our lightly constructed 1970s Florida ranch house, I heard her repeatedly whine, “Stop clicking . . . stop beeping.”

I was undeterred.

My father and I spoke twice about the computer. The first time was when we bought the computer for the business and I was left to figure out how to “put it to work,” whatever that meant in 1981. Second, after a few months, when I was not making enough progress, he basically said he was firing me and he was going to hire a professional, whatever that meant. But that second conversation lit a fire under me.

I spent a month or two using CBASIC to build an inventory program for the wholesaler. I had no idea how a database worked, what a database table was, or anything like that. There were enough example programs for managing “lists” in CBASIC for me to figure out how to modify them.

Probably just in time for my father’s loss of patience with me, I was rescued by the delivery of disks and manual for dBase II. After a few hours of using it and going through the typewritten photocopied documentation that came with it, a whole new world opened up for me. I immediately began building an entire system for the business.

A tribute to the power of dBase II more than to any skill I had, it took only a few weeks to get accounts, inventory, payables, and invoicing up and running. My father was relieved. I began the job of manually inputting the names and addresses of hundreds of customers and thousands of products.

To store all the data that did not fit on a 90K floppy, I spent weeks evaluating a 10-megabyte hard drive to add to the second Osborne bought for the business (one remained at home for me to program and the other ran the business). The 10-megabyte drive was the size of our Betamax and sounded like a small aircraft, but it dramatically changed how the business could be run. Imagine something like 100 floppies running all at once. It was magic. And it was fast!

Along with dBase II, the “300 baud modem” that promised to unlock the world of connecting to other computers over telephone lines was also delayed. When it finally arrived, I added a new sound to the clicking and clacking, the audible modem handshake that later came to symbolize “online.”

At first, there wasn’t much to dial-up except expensive per-minute professional services that were out of my price range and required a credit card I did not have. After a lucky meeting at the local CP/M User Group (CPMUG, as it was called) where I was the youngest by at least 10 years and the only person there not (yet) working at Martin Marietta or Kennedy Space Center, I learned about FIDONet.

I was finally online. And then I was online all the time (using the second home phone line I received for my Bar Mitzvah).

That connected me to user groups, forums, and others writing and exchanging programs. I felt like I was on a new learning curve as every night led to another discovery. Sometimes I learned the arcane aspects of CP/M, such as how to edit the OS code to disable the File Delete command (to make using the computer safer for my father) or to customize WordStar for our printer so it would print “double wide” characters for fancy headings. Other times, I learned some sophisticated dBase II constructs like keeping multiple tables connected and in sync for reporting. It was also in an online forum that I learned about the IBM PC and how it was going to be the winner between it, CP/M, TRS-80, and Apple Computer, the other ever-present computer systems.

So much was changing in such a short amount of time. That year fewer than two million PCs built by dozens of companies were sold, each computer running different and incompatible software, as if early automobiles needed different roads for each car maker. A year earlier, IBM introduced the IBM PC and was welcomed to the PC Revolution by five-year-old Apple Computer in a full-page advertisement in the Wall Street Journal.

It was early in the PC Revolution.

Cornell University’s computer science program, one of the first in the country, started in 1965, the year I was born. As 1982 wound down, I was admitted to Cornell.

Prompted by that Time article, my mother, Marsha, told me that computers were a fine hobby, but she reminded me that I wanted to be a doctor. I received a good talking to once she read the descriptions of “hacker” culture—flannel shirts, no shoes, and working late at night in the solitary computer room of the nation’s colleges. It all sounded too close to late-night beeping and clicking. She wanted assurance that I was attending Cornell to study something more in line with what was expected, what I wanted. She was concerned that I might become a “hacker.”

Too late.

On to 001. Becoming a Microsoftie (Chapter I)