Sure it may be a bit of propaganda, but Richard "foredecker" G. Russell's insider description [blog] of working conditions for Microsoft Windows team members offer some interesting insight.

In contrast with recent reports of competitor Apple, which cite incidents of employee interrogation, lack of privacy, and frequent visits from the "secrecy police", Microsoft sounds much more friendly and open (at least from a manager's perspective).  

According to Mr. Russell, almost everyone has their own office.  He describes:

Most people in Windows have a private office – with a door. Not just managers, not just developers – everyone. Even our intern has a private office. The only reason someone might share an office is because the building is crowded. Every so often we’ll move people around, one goal being to give everyone their own office, the other being to co-locate teams. I’m in one of our older buildings, but it is still in great shape. My building has slightly larger offices than newer buildings. Mine is 10×18, large enough for a good size desk, a eight foot white board, a comfy recliner, and a meeting table and chairs.

Systems undergo frequent upgrades with the average cycle lasting two years (pretty cutting edge in the IT world).  According to Mr. Russell, the average Windows team member's coding computer is (at least) "a quad core 64-bit system with 8 gigs of memory, fast hard drives, a gaming quality graphics adapter, and (two to four) large monitors."

He adds that managers and some engineers all have laptops too -- mostly Lenovo ThinkPads.

Developers frequently have two or three extra systems for testing purposes.  But the real meat of the team's work goes on in a lab with "a high fidelity KVM system" (KVM=Keyboard, Video, Mouse Switch system), with over 300 test clients.

His average day is pretty typical fare for anyone who's worked in the software industry -- writing code, compiling code, and unit testing.

Developers are free to edit their code in their editor of choice (not everyone uses Microsoft's Visual Studio) and can build/debug it either in the terminal or in using Visual Studio.

He states that the company isn't very strict when it comes to adhering to coding conventions.  He describes:

You may be amazed, or even find this heretical, but there is no common mandated coding style at Microsoft. There isn’t even one in Windows. Teams are free to code in their own style. By style here I mean typographic style – where curly braces go, tab indent size, where spaces go, comment format: things that have no semantic impact. There is no draconian common coding style mindlessly forced on everyone.

Certain teams, like the kernel and shell teams do adhere to a common coding standard, though, he acknowledges.  And some coding modifiers -- e.g. SAL annotations are non-negotiable.  For the most part, though style decisions are made on a per-team basis.  For Mr. Russell's team he allows his developers to pick their own styles for their projects.

He comments:

I’m sure some people will think this is awful. Some people find value in forcing people to code in exactly the same typographic style. Some organizations are maniacal about this. Usually, the people most vociferous about enforcing a common coding style want people to code their way. They don’t want to follow a standard, they want other people to follow theirs. I personally find this a massive bureaucratic distraction – it adds little value and goes a long way to really annoying developers.

Developers have access to the majority of the Windows source, with the exception of security and cryptography related items.  Reported non-security Windows bugs are in there in all their horror.

And each team decides its own code-review rules.  Most teams, like Mr. Russell's, use fully-automated systems that email code to reviewers to speed up the process.

Mr. Russell provides many other details about how the Windows team manages the highly branched Windows tree.  Building Windows code is a challenge, he says, as you have to make sure it runs properly on all forms of Windows (32-bit, 64-bit, etc.) and in a variety of environments.

He writes, "Windows is a colossal software product – it’s a gazillion lines of code. We manage all this code with a very sophisticated source code control system called source depot (or just SD)."

He concludes:

This all sounds great, but everthign (sic) isn’t unicorns and ponies every day: There are problems to be sure – somtimes (sic) the bug data base is slow, or source depot is down for maintenance, or a build is trash. But by and large these kind of problems are very much the exceptoin (sic) rather than the rule.

The day to day coding life of a Windows developer is work to be sure, but coding, testing, check-in and getting changes up to WinMAIN is pretty painless. There is a lot of automaton to help developers. The Windows engineering systems realy do run extrmely well and problems are rare. There are very few synchronous requirements and very little bureaucratic overhea (sic) imposed by the Windows organzation (sic).