Working at Microsoft – Day to Day Coding | Hacker News Reader

Working at Microsoft – Day to Day Coding

foredecker.wordpress.com

288 pointsthere164 comments

Reading this almost makes me want to cry.

It's still all to common these days to find developers with 4 year old machines, comprised of scavanged parts (from people leaving) running Windows XP.

A level of bureaucracy forcing you to maintain 3 tickets (at least) in 3 different systems to make even a typo fix in a production system with 3 day minimum turn around time.

Servers with less RAM and resources then your 4 year old desktop. Laptops? Too expensive so just use this 8 year old IBM one when we need after hours support. Source control? Use TFS which is the most god awful ticket manager/source control system the world has ever seen.

Private office? No, shared space, with people having loud meetings behind the developers at all hours of the work day. Corperate firewall blocking things like stackoverflow. A view from the office? No, other people can have that, you look at a concrete wall.

I guess the moral of this is work for a company that values developers. Keep that in mind while looking for a job if you are one.

What about new machines running Windows XP? That's just sad.

Most of my direct managers and indeed everyone else not in IT seems to have a new machine. The majority are running XP.

And for me, it hilighted some of what I've suspected for a while is wrong with Windows development.

I own a small company that handles a lot of end-users' various issues. Although I spend most of my time now coding, I spent more than my fair share of time working one-on-one with individuals and companies that were having problems with their systems. I still spend around 10 hours a week doing it.

My primary development machine is an aging laptop that can't even play YouTube videos any more without stuttering. I hate almost every minute of using it. It's slow, and limited, and it hangs.

So when I write something, I write it to work well on that laptop, because I know there are lots -- lots -- of people out there with similar old hardware, and to say they're frustrated with computers is an understatement.

How could a Windows developer possibly understand just how frustrating their product is when they spend all of their time using the most powerful hardware available?

How could they possibly understand that Windows file sharing in a mixed environment running SBS 2008 is still complete and miserable and utter garbage, when they're running on a network that hides those kinds of issues?

Their development process is great for their developers. No argument there, and I'm totally and unabashedly envious.

It's also terrible and completely wrong for most of their many users.

I don't think that's actually the problem. Windows (and many other MS groups) have quite excellent performance and integration testing. They generally do a good job of keeping performance under control. I think the biggest problem is how they approach performance as a test signoff criteria, usually, rather than as a budgeted line-item with goals for improvement.

As to situations like what you describe with file sharing in a certain environment that mostly comes down to insufficient beta testing and straight up prioritization/de-prioritization of certain issues.

Treating performance as a minimum bar that has to be met rather than a goal in and of itself sounds exactly like the kind of development process that would produce Windows -- which always feels sluggish if you're using anything other than the latest hardware.

I don't think Microsoft realizes how enormously performance contributes to user dissatisfaction with their OS.

As a web developer, I know that adding just a second to a page load massively diminishes perceived usefulness of a system; Google spends enormous amounts shaving tens of milliseconds off their page displays.

At the level of an operating system, that kind of user sensitivity to performance must be at least the same if not magnified. It seems like performance, especially on older hardware, should be far more of a priority for Microsoft than it apparently is.

To be fair, Windows 7 made some great strides, and ended up being faster than Vista on a lot of older hardware. However, that does tend to be the exception. The general perception of performance (at least in the areas of MS that I had contact with when I was working there) is that it's important to hold the line in performance, and it's not generally valuable to invest in actually improving performance over time. MS spends a lot of resources measuring performance very accurately, but not nearly enough resources in making appropriate architecture and design choices, or in making big performance improvement pushes.

My experience and observation is that performance improvements of substantial magnitude are often available for the taking in almost all software projects, but it requires a concerted effort to realize those improvements. MS instead spends its efforts on merely making sure that the software doesn't get slower by too much.

Consider that you can go to Bestbuy (or your local computer retailer or choice) and buy a $500 laptop capable of running Windows 7. A Mac is 2 to 5 times that. (Highest price PC at Bestbuy $1200, highest priced Mac ~$2200) (Macbook is $1000, pc is $300-$500).

I installed Windows 7 on 2 laptops of family members. These laptops were $300 from Walmart. Windows 7 runs just fine.

I installed Windows 7 on an Asus EEE pc. Runs about as well as Windows XP (only computer where I can tell it runs a littler slower).

Considering a ~$800 ipad that isn't a full computer...

I fail to grasp what kind of performance you expect to get out of Windows 7, while at the same time having a full featured OS at the same time running on _affordable_ hardware.

I can run a fully featured Linux system on a 800mhz laptop with 1gb of ram.

Microsoft has one of the largest and most comprehensive suites of test hardware available. They have rooms with hundreds of computers with varying levels of hardware performance that they test important builds on. They do their job, if the OEMs want to push out a crummy user experience, that's an issue on their testing end.

I'm just going to leave this here: http://www.pcmag.com/article2/0,2817,2361579,00.asp

> How could a Windows developer possibly understand just how frustrating their product is when they spend all of their time using the most powerful hardware available?

It is called the "Redmond reality distortion field"

http://www.stepto.com/Lists/Posts/Post.aspx?ID=486

And it affects every area of the company, not only developers.

Very very true.

The ideal situation would be a blazingly fast machine for compiling, linking, and running automated tests ... and commodity hardware for day-to-day tasks including browsing, email, word processing, spreadsheeting.

you seriously think devs will do a better job daily if they have a slower machine for day to day tasks?

This is an interesting question, because it implies that commodity hardware isn't good enough for day to day tasks.

If that's true, do you think the software developers have done a good job?

And if that's not true, then why shouldn't they use commodity hardware?

This is an 80/20 rule thing. The vast majority of PCs get refreshed in one way or another every 3-4 years.

So a company like Microsoft can invest in the 80% of the market that drives sales (ie. people who refresh computers) OR invest resources in solving problems for the 20% of people running old hardware with an old OS they bought a long time ago.

Should the state of the art be driven by the fact that your employer chooses to leave you with a laptop that cannot play YouTube video?

The very next thing my company is going to do after rolling out the product currently under development is start aggressively collecting and compiling statistics on all of our support issues, service calls, and our customers' systems.

Even accounting for business clients on hiring binges, I'm really, really certain that the vast majority of the PCs that we support are more than 4 years old.

I can see where you're going but it sounds to me like the entrepreneurial spirit in you has done what it tends to do in all of us: Look for a way to make lemons into lemonade.

But my perspective is that I would probably prefer not to have those particular lemons! My time is valuable to me, and so is my patience. And as a software developer, I spend far more time using other peoples software (IDE, DB clients, etc) than I do using my own.

The best way I can better my products, I think, is to devote as much time as possible to fixing bugs and adding features. Time spent waiting for my IDE to load is time spent not adding value.

Working with end-users all the time has changed my attitude about how valuable developer time is. It's not that I don't think developer time is valuable, it's that I've really seen, with my own eyes, just how many people are affected when developers value their own time more highly than they value their customers' time. All those little inefficiencies and minor bugs and other problems really add up quick.

I, personally, am far less inclined now to spend my coding time on new features, and more likely to spend it on refining what I already have -- and so far I've gotten really positive feedback from customers on that.

You choose were you want to work. Lots of places do this, my last few places in small firms bought me brand new computers when I started, and let 2 let me choose exactly what I wanted. It depends how important the company sees IT/how good a manager you have.

My manager is pretty good. The issue seems to be we are treated like a proper "development" shop, but not provided some of the basic tools due to strange funding decisions. Its not all bad, but there is enough smell there to take away a lot of the joy I usually get from code.

Don't sweat it. We all worked there for a couple years.

It's called "getting experience", and the key is to remember you're supposed to move on after you've built enough stuff to demonstrate your worth to the next place. This is what the beginning of everybody's development career looks like.

Grit your teeth and get through it. It gets good later on.

I guess thats where I am now. Three years and it might be time to look towards something else. Cheers for making me feel better about it though.

Avoid the Watercooler Gang

http://web.archive.org/web/20080502192810/http://www.gapingv...

Move on ASAP.

Still there. Contributing to OSS (golang) + studying theory I missed because I didn't do compsci at uni. Once I hit the 40/50 patch count and have good algo/os knowledge I reckon I should be better placed to be attractive job-wise. Several failed 'views have seriously hit my confidence, but I am working on fixing obvious areas of deficiency.

A lot of the problem is that the stuff you build can't necessarily happen at the place you're at - if all your place do is db frontends and your coworkers produce endless spaghetti, anything you produce is going to be subsumed by that.

Another issue which is rarely spoken about is the atmosphere of the development environment - if people are on edge/insecure/[deadsea-ers][1] things can get nasty quick, and there is nothing better at pulling down your confidence.

I have come to the conclusion that you have to build your own positive output because you love it, and let the career-enhancing aspects act as a side-effect. I adore this stuff, that's why I'm doing it.

It is often frustrating though - I am 29, 30 in September and it is difficult not to feel trapped. The negative aspects of the job make it harder to do the positive stuff necessary to get out - got to work hard to keep your head above the water.

[1]:http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

I'm hitting 29 in a few months and am more or less in the same boat. Keep fighting the good fight.

Amen brother. Drop me a mail if you want... always good to have solidarity in this kind of situation.

Definitely-expect one later tonight!

An assumption? We've been told pretty directly how complicated the process is (often with pride).

See the 14 steps which turn a 5 minute code change into a multi-man-month-mammoth: http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298...

Or the now infamous Windows Shutdown "crapfest": http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...

There's more. And I have no problem with the author stating how great coding is (because he has an office and a nice computer!). However, while your right hand is telling us how great it is and we shouldn't assume otherwise, your left hand is telling us how horrible it is.

Well, you are confusing "complicated" with "difficult". While this is true in general, automation reduces the difficulty of working with a complicated system.

For instance, the build system is extremely "complicated". But all you really need to do is to make sure your code compiles, you pass all your local tests, and the BVTs, and you are good to go (oh, and a code review; anyone who objects to a code review is probably shouldn't be coding).

When, you, as a developer, satisfy those local conditions, the system automatically works at the global level.

Don't get me wrong, complexity is an evil that I'd rather avoid, but it is a necessary evil for creating systems that are useful in the real world; and it is an evil that can be tamed with automation.

[Full disclosure: as a former MSFT employee, my thoughts are heavily influenced by the company.]

> automation reduces the difficulty of working with a complicated system.

Effectively preventing it from ever being simplified. Like you said, complexity is evil and has to be addressed because no amount of automation will correct it.

This blog post is mainly about the tools developers use day-to-day while they're in coding mode. Tools and development processes do tend to be well thought out and efficient at MS.

That's not really related to the organizational dynamics that come into play for planning products and features. That tends to be complicated, involving a lot of people, meetings, and debate. (I'm not defending it, just saying that's how it is.) That 14 steps isn't about a code change; it's about the end-to-end design, implementation, and shipping of a feature, expressed in the most detailed, far-reaching way possible, to make a point about how things operate in a huge organization.

Both points of view are accurate, IMHO. When you're strictly coding, things are pretty efficient. Not too surprisingly, those were the times I enjoyed the most. But it's equally true that at MS, coding is only a small piece of a larger, somewhat slow-moving process. And sure, all that other overhead can get tedious, even exasperating at times. It's just a separate subject from what the OP is writing about here. The coding part is typically quite fun and autonomous.

I don't mean to drag this out, since I largely agree with what you are saying, and it's true that the OP seems to focus on that.

However, his intro blurb specifically says that we are wrong in assuming that writing software is a "soul-crushing bureaucratic exercise." Which, as you point out, the post never really says anything more about.

Remember, the intro blurb is discussion all the articles he intends to write on the subject. Together, they intend to show you how the intro is true. As it stands, he has two articles on the topic. Most people are only reading the one (the one which is linked). Even in that, the introduction is a common introduction for all the pieces (the two so far, so I imagine the others as well). That the original article focuses on coding doesn't mean he's ignoring other areas. Rather, that other areas simply haven't been written about.

I think you might be misinterpreting the first post you linked. He's not bragging about how complicated it is. He's also not complaining about how tricky it is. There are always things in the Windows org that could use improvement (otherwise, I'd be out of a job). However, the vast majority of processes exist to fulfill requirements that very few software projects have to deal with.

Consider that Windows ships in over a hundred languages to hundreds of millions of people. I'm not sure how many languages Linux ships in (I'd bet quite a few), but Linux contributors don't have to worry about getting arrested for drawing map lines wrong: http://blogs.msdn.com/b/alexbarn/archive/2004/08/20/217602.a...

Do we ship software without testing? No. Do we ship software that isn't globalized? No. Do we just hack something together, check it in, and call it a day? No. These aren't the kinds of practices that lead to a stable platform.

Mistakes get made (at all levels of the management chain), but they tend to be the exception in my experience.

Those blogs were posted in 2003 and 2006. We are in year 2011. 5 years in tech industry is like 20 years in other industries. Just sayin'

I've never read a post by Richard before, I don't want to seem like I'm giving him a hard time, and I'm a happy Windows user, so I'm a big fan of his work.

But this article isn't inspiring from a developer perspective. I've worked in a big IT department (300 people I think),as well as start-ups, so I'm not completely blind to the structures of different work environments.

When Richard first mentioned that everybody has an office, and that he was allowed to paint his, I thought about how uninspiring that is. Same with describing his hardware. Maybe it's just me, maybe it's Richard, but this article did very little to inspire me to go work for Microsoft.

I was hoping for some insight into code planning, the specific challenges faced by building the most popular (at least the most heavily used) desktop consumer operating system.

Richard makes it all sound very routine.

> Richard makes it all sound very routine.

To me, that is the most impressive part of all.

When the first few lines tell me about how surprised I will be, I expected to hear that people are encouraged to be creative, take risks, try working on project that might end up going nowhere -- in other words, that they promote a hacker culture.

Unfortunately, the things that the author focused on are not inspiring. Being able to paint your office? Great, but how about week-long hackathons where people can code on whatever they want?

Showing the three-level branch hierarchy of your repository doesn't seem to tell me a great story about what it's like to be a dev at MS. Not because there's anything wrong with the branch structure; if you work at a place where coders are given a lot of liberty and freedom, there should be more interesting things to talk about.

EDIT: he has another post which talks more about culture and projects here: http://foredecker.wordpress.com/2011/02/27/working-at-micros...

I have heard that people at MS do something called "app week". This appears to be a week between milestones where you take a week to build something that can be built in a week. Usually just tangentially related to their product. Maybe this author can talk about that at some point.

Again very dependent on the team. I've been in teams which specifically carved out time for this and also been in teams where prototyping/building crazy stuff was something you did all the time.

My team (XNA Game Studio) had App Week once or twice each year. By far my favorite time spent at Microsoft.

The XNA team is full of ex-game developers because working on platforms at Microsoft has much better "work life balance" than game studios. The stuff that I, and the other team members, created were always cool/fun/hilarious/weird/etc. It was like a week long game jam ending with a Friday afternoon "Think and Drink" where everyone showed off their creations and talked about the good, the bad, and the ugly of our own technology through their App Week experiences.

>> Great, but how about week-long hackathons where people can code on whatever they want? Showing the three-level branch hierarchy of your repository doesn't seem to tell me a great story about what it's like to be a dev at MS. Not because there's anything wrong with the branch structure; if you work at a place where coders are given a lot of liberty and freedom, there should be more interesting things to talk about.

I guess those can be counted as special cases and not pertaining to day-to-day working. The main point to gain from the post it seems is that its not a pain to work in such a complex environment. This is not some web or phone app, its a huge undertaking and how it works in a precise routine.

Microsoft treats developers very well. From offices, to hardware, to free gym memberships and health care coverage, to the idea that you're generally not expected to work more than 40 hours a week, it's all great. But that can't and doesn't replace the need for healthy corporate culture and good, intelligent, pragmatic leadership, a lot of which has increasingly been lacking at MS. You'll have a quad core desktop with 8 gigs of RAM, but that hardly helps you play the game of office politics that is often required to get bonuses or promotions (when the company bothers to provide them). It also doesn't help a corporate culture that is becoming increasingly bureaucratic and process oriented rather than results oriented.

A lot of talent is and has been evaporating up and out of Microsoft for just these reasons.

I was at Microsoft for two internships and two fulltime years. I never once had an office to myself, I always had to share. In fact, the new Studios buildings are almost entirely "6 packs" of cubicles.

As for hardware, if you really needed it we were able to get it, but there was a fair bit of scavenging for spare parts to power build/test machines. There was also a shortage of Xbox and especially Win Phone dev kits.

My day to day coding experience varied wildly by task. Some stuff had a 2 minute turnaround, most stuff 2 hours, and some stuff several days.

The politics, infighting, and Redmond isolationism are all very real, and very painful.

That said, the company is huge, so experiences differ broadly across the various orgs.

In the office I work out of only managers have private offices. There are also a few small offices with 2-4 people, but most work in groups of 6-10.

Dude... That is still better than work environment I had to endure - 50 developers in a single open area. If that weren't enough - someone decided to sit support for an entire team in the middle of this space, rationale being "that they would like to be close".

6-10 people in a room as long as they are developers is still awesome and productive environment.

Edit: I don't work for Microsoft - but wouldn't mind to :)

The thing here is not about if Microsoft let their developers use all the new shiny technology but the point to stress here is how much percentage everyday does a developer at MS actually codes, I bet it wont be more than 20%.

I am so sure of this because being at Amazon since April last year, I havent coded more then 700 lines of code, bulk of which was supporting new features in the already behemoth software.

I always wanted to work for a big company and I was super happy when I finally got a job offer but lately I have realized that the biggest downside of working for a big company is that you dont code, you just add features in to all the in use product, attend meeting and specific for Amazon, be on the pager 24X7.

For all you guys coming fresh out of colleges, head to bay area and join a start up, ditch these big companies.

That sucks for you. I've been working at Microsoft for about 4 years. First 2 years as a tester, and the latter 2 years as a dev (still a dev). When I was a tester, I coded 4 days a week with 1 day a week for other investigations (live site issues, meetings, etc.) As a dev, the ratio haven't changed. I still code at least 4 days a week (80% of the time) with 1 day a week for meetings, investigations, documentations, etc. We have a separate operations team that carries pagers. They will do their investigation before I get called. For past 6 months, I got called once. Just in case you are wondering, I work under the Windows Live org.

When I was a tester, I coded 4 days a week

I'm sorry, but what's the difference between a tester and a developer then?

I suspect the type of code you write. As a dev I'd expect you to write code that ships to customers. As a tester you write test code and harnesses. Stuff the customer never directly sees.

I think I can honestly say that at ever company I've run or been a manager of influence we've had more lines of test code than product code. Yet I'm still surprised when people say "testers code?"

That bad at Amazon? I've been at Google for a little over 2 years and have written about 160,000 lines of code for them. (And deleted about 30,000.)

Seems like a lot more than I expected, but just looking through my recent commit history, I wrote 830 lines of code just last week on my 20% project alone, so 1600 lines/week doesn't seem that unreasonable. And here I've been complaining about how I never have time to get any work done...

I just had my two year anniversary at Amazon. I've written many more than 700 lines but I bet less than 160K. And yes, deleting code is the best.

I don't know the GP but their post is believable. Some parts of Amazon are mired in cross-team dependencies. Worse, to get anything done in those situations, hacks have been piled on top of hacks for tragic years. The right solution may be waiting in the wings but all the dominoes have to fall first.

There is a lot of variety at Amazon. There are high-pressure, high-reward teams like Kindle. There is cutting edge stuff at AWS and elsewhere.

My team is a leaf far out on the dependency tree. Approximately, we have only end users. It's a great situation, even with a pager (shared between five people, so one week or less a month). Our pager, on the average, does not go off. We get to ship software every week and we're profitable.

My experience at Amazon so far (since last June) is definitely better than pacifi30's. I've been writing a lot of software (for both existing and new projects), the dev infrastructure is great, dev tool teams are very responsive and always improving our workflow, and the end result (mobile in my case) is fulfilling.

I joined just a little after you and my experience has been very positive. Feel free to talk to me (danielsi@) anytime you want to talk about the dev process in the company or our teams.

I asked this in the comments section but it disappeared into thin air with no notification on what was happening(say, held for moderation etc).So I'll ask it here. Maybe an HN reader who works for MS might know the answer.

From the article,

"All managers have laptops. Most prety good ones."

Do developers (testers etc) have laptops (pretty good ones)? Or are they "management only" perks? (fwiw all the bodyshopping companies in India follow the "only suits have laptops" pattern)

Laptops are officially only for managers and Program managers. As a dev/test you can get a loaner for a presentation or find one, somehow.

"Laptops are officially only for managers and Program managers."

Heh! That's what I thought :-p Not surprised to hear MS works that way :-). Funny way to economise, making laptops status symbols. I think Google gives devs nice laptops and is probably better off for it.

It's not really a status symbol. PMs tend to be more mobile, presenting in meetings and such, and need laptops. Devs and testers get much better desktops.

"It's not really a status symbol."

A status symbol is, by definition, something only or mostly upper echelons of a hierarchy can get, with fig leaf justifications about why the folks on the lower rungs are "not worthy" of them. The surest way to make anything (a private office, a parking space, a laptop) a status symbol is to mandate that only people above a certain level in the hierarchy can get one.(Note that I am responding to a comment that states that laptops are only for managers and devs have to get "loaners". Other people at MS seem to disagree that this is the case)

"Devs and testers get much better desktops."

Good desktops aren't an excuse for not having good laptops.

The association of laptops with presentations and meetings conveys a lot about MS's approach to development. No wonder the place is infested with multiple layers of redundant management. I wonder how MS Research fares? Do Peyton Jones and co go laptopless too?

Everything done at MSFT is based upon dev-test-pm triads where all members of the team have equal say in the product and decisions. This is true from the individual contributor level up to the VP level (where it starts to break down). Dev's report to dev leads, test to test leads, and PMs to PM leads. All PMs, including individual contributors, get laptops. They are the same level as developers, and more importantly, in a completely different hierarchy.

I'm not going to lie and say devs don't want laptops - of course they do. Everyone wants a free laptop. But guess what? I'm a PM at MSFT, and you know what I want? A second desktop and better monitors. Are these a status symbols for devs? No. Resources are fairly assigned based on need, and everyone at the company realizes that.

I should also point out that most senior devs do have laptops in my experience. It's the really new, junior guys that don't get them right away. There are communal resources if a dev really needs portability for a few days.

"I'm a PM at MSFT, and you know what I want? A second desktop and better monitors."

If you want them to do your job and you are not getting them, that just illustrates the point better. Economizing on hardware (and paper towels, heh!) is really dumb for a software/tech company.

"I should also point out that most senior devs do have laptops in my experience. It's the really new, junior guys that don't get them right away."

So, in other words a laptop is a status symbol. Junior devs rank lower in the hierarchy though they use the same tools and work on the same codebases as senior devs.

So what you're saying is that where you work everybody has 2 desktops, 2 laptops and nobody would raise a brow if you wanted another?

In my book what Microsoft does is waaaaay beyond "trying to save on toilet paper". The last place I worked having a monitor bigger than 19" was a status simbol.

Excuse my patronizing - you are around/under 25 right? Because I have noticed that juniors tend to have this petty fascination with hardware that goes away with time (myself included).

"what you're saying is that where you work everybody has 2 desktops, 2 laptops and nobody would raise a brow if you wanted another?"

I work on a 3000 node super computing cluster doing heavy duty Machine Learning and signal processing and a lot of funky (and classified) hardware, and yes, no one would blink if I wanted two more machines (or a 100 more) - as a matter of fact we recently did a million$ + upgrade of the hardware on my say so, so yeah everyone on this project gets all the hardware they want ;-)

Looking around I see (my personal system, doing mostly rendering and reports) 7 quad core machines, three 27 in monitors, 2 laptops, both Thinkpads. I (literally) only have to ask to get more machines.

"Excuse my patronizing - you are around/under 25 right?"

Patronizing is always inexcusable and rude, and snark appropriate on reddit isnot so valued on HN, but I don't mind at all. When you say things like that you just make a fool of yourself in public, go right ahead. :-)

And as for my age, I am closer to 40 than 25, so perhaps you just need to try again? ;-)

EDIT: (btw "paper towels" != "toilet paper". You missed the reference This which wrt the benefits cuts in 2004which included stopping towel supply(later rescinded) - I confess I am only guessing the towels were paper. ;-)

from mini msft (I heard from a friend in MS, but mini is an online reference)

"Should have just done the towels and called it a day!" - Lisa Brummel, May 18th 2006.

You know, one moment of reflection: the circle is now complete. My second post to this blog was on July 6th, 2004. It was right after an impromptu employee meeting with Ballmer and Gates and as part of that, Mr. Ballmer justified the unfortunate recent benefit cuts, the main two points of ire being the towels and the ESPP revamp. Now, two years later, we're getting our towels back.

Has it always just been about the towels?

(Possible book title flashes through my mind.)

It's not like we're sweaty work-out animals always in need of a shower and fresh towel. No. What riled us was the bone-headed way the towel cut-back was handled, explained, and justified. It truly made us wonder just who are these people in charge and just who do they think they are leading? The towels became the symbol of poor leadership. That and the office-supply hide-and-seek.

Someone should send Ms. Brummel a golden towel award. I'd like my old ESPP back, too."

Just a slight correction: the towels mentioned here aren't paper towels, but real actual towels. Many MSFT buildings have showers stocked with towels. At one point, the towel service was discontinued as a cost-saving measure. Lots of employees took issue with this and wanted their towels back.

That sounds very cost ineffective. I'd be more productive with a personal helicopter with landing pads in various locations with an oncall pilot... but the productivity benefit is probably not worth the cost.

All organizations need to be cost efficient... unless you're a govt agency or contractor. In which case being cost INefficient is actually rational.

"That sounds very cost ineffective."

What specifically sounds "cost ineffective"?

3000 node clusters? That is a tiny cluster as clusters go. 7 quad core machines? Two ThinkPads? A million dollars on one-of-a-kind hardware?

You my friend, have zero clue in this. Since you have no idea what the specific cost benefit analysis on this project is that statement is built on nothing but your prejudices. I grant that it may "sound" ineffective to someone with no experience working on such projects. If I were to blather about whether a drug development proposal (something about which I know next to nothing) is "cost effective" without even looking at the financial documentation, I'd come close to what you are doing with that statement.

"I'd be more productive with a personal helicopter with landing pads in various locations with an oncall pilot"

In the right situation, expensing a personal helicopter would be trivial. What is "cost effective" depends on the derived benefit. Applies to startups too. The cost depends on the benefit derived not on what the raw materials cost.

So (fwiw, I could care less about convincing you) It is not really "cost ineffective". Machine/networking etc costs on this project are trivial compared to the total budget (spent on other resources) and (much) more importantly the derived benefit.

(just making up an example since I can't talk about what this project really does) If you were able to decrypt, and classify (in the Machine Learning sense) all enemy communication in real time, how much is that capability worth to a nation? Worth spending a few millions on? Not every project in the world has the financial structure of two guys in a garage coding up the next silly web app.

Iow you are talking about "unknown unknowns" with nothing to back up your conclusions. Amusing but not really relevant.

My personal setup is 3 24" monitors, 2 quad-core desktops, and a ThinkPad laptop, backed up by a few tens of thousands of machines sitting off in a datacenter somewhere. With what they're paying me, they could afford my total hardware setup with less than a month of salary, and it's saved me far more time than that. I use basically all of it - all 3 monitors are usually covered with windows, and it's not unusual to have 4-6 webservers running on my desktops.

I'm older than 25, though probably not as old as plinkplonk.

Exactly. Unless a company's in such bad shape that they have to nickel-and-dime on expenses, the value of productive (and happy!) employees far outweighs hardware costs.

See nobody is disputing what all of us claim here.

But it's the usual perception of majority of companies that engineering, product development,... are cost centers and cost centers need to be minimized to gain profit.

It's what you get when you let the beancounters run the business. But people bitching here that developers at MS don't have it well off - are being ignorant about majority of industry where developers are still being under-utilized to everyones dismay.

And Microsoft's care of intellectual workers is top tier. Even the ones that are not well off (sitting in a room with 10 other people) are better off than 90% of our industry.

Indeed some people get to have anything they want or need - good for them. Even better if it makes the end result better. It's good that they don't get into situation as I have in multiple occasions - running a top priority, code red development effort which if fails it will take the company down, and then when I needed a new virtual appliance I got informed that I cannot get is since the ESX is out of harddrives and that there will be no purchases since the budged has already been spent.

And this is the industry standard - not the "I run bazillion node supercluster".

Hell where I used to work - two of the interns went and bought 2 24" monitors each out of their own money to use them at work.

> It's the really new, junior guys that don't get them right away.

I've been at MSFT for 9 years and have yet to be issued a laptop. I've been MSFT for 9 years and have yet to actually need a laptop. :)

Sounds like the dev types get 3-4 monitors and very beefy PCs, and work 40 hour weeks.

Why would you want/need a laptop in that case? Multi-monitors with a laptop is asking for ergonomic-related health problems.

Laptops are, for the most part, neither necessary nor useful. Most developing/testing work is done in a single place, so I never really had a problem.

The number of hours of work-from-home that Google gets out of those laptops more than justifies their cost. Hell, I'm posting this from my work laptop, taking a break from writing out a whole bunch of use cases and product design decisions.

What do you do over at Google?

Very broadly, Search Features. I worked on the visual redesign that launched last May, and before that some of the search tools (particularly Wonder Wheel and Related Searches) and a bit on the move from having separate search properties (books.google.com, blogs.google.com, video.google.com, etc.) to a single search app. Then I spent about 6 months doing some infrastructure stuff with the webserver, and I'm now doing some feature work that's in the early stages of the project.

Cool. What tools do you use for daily design? I've been slowly moving from Photoshop to CSS, and want to start using stuff like Antetype early in the process. I've also figured out that Photoshop is good for finalizing a design that's been moved around, tested and iterated upon.

Facebook is laptop-only[0], though I've not yet started [1] I imagine they have something similar in mind.

[0] Plus an external monitor.

[1] And from what I've read on HN, I probably won't, as they're going out of business any day now :P

5-year Microsoftie here (mostly PM, some dev)

Sorry - I don't think that's true. When I was a dev I had a laptop. It is highly dependent on the team you work for. I know a lot of devs who have laptops. In fact, most things hardware related are highly related to the team you work for. Since MSFT works on such a variety of things, hardware needs tends to vary dramatically

9 year softie here (Shell Test in my early days, now doing Dev work)

Indeed everything is dependent on need. PMs always get laptops because they spend lots of time outside of their office. On my team, most dev leads are also issued laptops. Friends of mine in teams closer to laptop features (think Windows 7 touch input, for example) never have had problems getting a laptop. On my current team, it's not common for an IC dev to have a laptop. It's also not common to find an IC dev with a machine more than 8 months old. I haven't quite figured out what everyone else's fascination is with laptops. I bought one for my own personal use, brought it to work, and then stopped bringing it because it just sat on my desk doing nothing 95% of the time. The other 5% I've replaced with post-it notes which, I'm happy to say, are available to both PM and Dev.

It's very team dependent. Every dev in Bing has their own laptop. Of course most of us don't have our own office, it's more common to be doubled up.

I remember being at the MS Redmond campus for an MVP summit shortly before .NET was released (ca. 2000). Some of the devs in the VB.Net team would amble in to participate in discussions and whatnot (it was very informal). Most of them had laptops and did email and even coding while they were in the conference room.

Again, this was 10 years ago or so, but I'd expect that developers can still get a laptop if they want to.

Personally I've always preferred a desktop machine to code, because a laptop means I can take work home.

Depends on the team. I worked at a few different ones at MSFT, and generally the position was - two machines. Two desktops? Ok. Desktop + Laptop? Ok.

Most developers went for the desktop x2 plan. PM's almost always went desktop + laptop.

Again, this was for NEW machines. I had, at my peak, 6. 4 desktops and 2 laptops. Most of these were random old peices of hardware that were fit for recycling (but still fully functional!) that I used for whatever side projects I needed the hardware for.

Everyone always complains about their PC hardware - but not once did I see someone who actually needed a piece of hardware go without it. Monitor upgrades, for some reason, were much rarer and didn't make sense at all.

In the office I work out of, everyone has at least one laptop and a desktop. --Most people have at least 2 desktops, and of course there are plenty of servers as well (2 server rooms, in fact, one off-site).

I work in support, but I spend a lot of time looking at code and speaking with developers. My laptop is my primary machine, but I also have two desktops - quad core systems with 16GB RAM that I use to run VMs in Hyper-V (I have to use both Windows and Linux VMs). --Typically I'll have around 3 VMs running on each desktop, plus up to 3 more that I can switch on when needed. I also have access to a set of 3 servers (48GB RAM and about 9TB disk space) that I share with a team of 10 people for when we need to configure a larger cluster for problem reproduction and resolution. Developers tend to have similar setups here.

The "individual offices" aspect is interesting. Back in the 1980s and early 1990s, when Microsoft went from success to success and the corporate culture got really established, software engineering research showed that developers were more effective with individual offices and big monitors.

By 2005/2006, when I was looking at corporate culture at MS, things had changed: with the advent of pair programming and agile methods, many designers and developers are more effective in shared spaces -- and many prefer those environments. NOT cubicle farms, which are the worst of all world, and NOT large badly-designed open-spaces ... but there are plenty of other good options.

However, "individual offices" for devs is now such a status symbol for the teams that still have them, that people at the management level are very unwilling to change. One designer I know spent literally a year trying to get permission to get his 12-person team into an open space. In the end he gave up and eventually left the company.

>with the advent of pair programming and agile methods, many designers and developers are more effective in shared spaces

I'd be interested in seeing a source for this. I personally believe any creative endeavor is better performed in isolation.

The great thing about offices is that you can go sit in someone else's half the day if you need to collaborate on something.

I just started a post-doc position, and for the first time in my career have my own office, and quite a nice one, at that. It is absolutely fabulous. Besides the obvious benefits, the biggest unexpected positive aspect of having my own office is that I can have a discussion with a student or co-worker without worrying about disturbing those around me.

"Most people in Windows have a private office – with a door"

At my office we've made an effort to keep our workspace communal to the point of removing the 12" dividers that were included with our work tables. This, as you might guess, does result in some distraction but in fostering the relationships at the office people are more apt to like being there.

I'm curious how other large companies and startups handle this.

[UPDATE] Its important to note that we let people work from home whenever they like. So, in the case where they really need to focus, they have the freedom to do so.

I've worked in both environments. Honestly, the best environment, IMO, is working from home -- office is second. Shared office spaces are a distant fourth.

I'm the type of person who needs a lot of solitude at some times, and at other times, I love to blast music, pace, juggle, and gorge on chips.

When I need the solitude, when I'm in the zone, I don't want you taking a call from your gf, or deciding with some other guys in the office where to eat lunch.

Likewise, I may need to spend 12 hours doing nothing that looks productive. Just kind of thinking as I listen to music and do something mindless like pay bills. I feel like at even the most liberal of open floor plan offices I've felt inhibited if I spent a day or two doing what looks like screwing around. And don't get me started on pair programming.

I've done it both ways and had different experiences depending on the job.

Right now I work about 85% from home. I enjoy going to my (shared) office, but I tend to spend way to much time helping my officemates on their problems when I'm there (can be good or bad).

At the startup where I used to work, we had a shared open space. I was doing some coding, but mostly running long simulations, so I had a lot of down time. In that case, distractions were not an issue.

My job before that I had my own office, name on the door, view, etc. BUT my project members were on a different floor, which I couldn't actually go to (defense company). That was the main instance when I wish I had a shared office.

I guess I am lucky, I can spend some time looking like I am screwing around or doing mundane tasks so long as I get my work done on time.

This is the exact opposite to me. I spend my full day working, hit (or better) all deadlines, come in about 2 hours early and I still get grief from the big boss for leaving on-time!

Do your developers have to do any creative work, requiring deep thought, or are they just code monkeys?

If the former, do you provide a way for them to get away from the distraction when they need to think deeply?

We allow them to work from home whenever they like, hence the desire to provide a place they want to show up at.

I think this is key. This is what we did in grad school and it worked great. You worked at home most of the time and came to the office to chalk talk or do work where you don't mind interruptions.

That tends to work great when everyone is a five minute bike ride to the office/lab. It's a tougher proposition when a non-trivial number of members of the team are 30 minute auto commutes from the office.

This is what my and my cofounder do with coworking, spend a fair bit of time working from home but it is good to get into a communal space every now and then. Even if the productivity is lower, being around those your working with leads to things that wouldn't have been thought up or noticed otherwise. The same with others not working on the same thing as you, even now and then things come up and tend to kickstart something or give new insights.

I work in an open space. The office has some secluded spots with couches that people can go to with their laptops to work without distraction. They can also attempt to steal an unused meeting room if they need complete isolation.

I'm a bit confused by this post. The author seems to celebrate a private office. I strongly prefer open work spaces that you share with others, as do many companies I've worked with/seen. Care to share your opinion? I'm curious...

The idea is that developers should have a quiet, distraction-free space to do their coding. With open spaces and cubicles you hear other people's conversations and you cannot reach the deep focused attention that you need to produce good, bug-free code.

A decent semi-open setup has you not seeing much other than your monitor, and not hearing anything because you have good (company paid for) headphones on. And like others have said, If I can always WFH when I feel it is necessary.

I shared an office in one situation, worked in an open space in another, and had a private office in a third. Private office was by far the best situation. Being able to grab complete silence when necessary was amazing. Private offices end up being the best about 90% of the time. When you do need to collaborate, conference rooms are available and using laptops isn't hard. Most offices can also support about 2-3 other co-developers with ease.

If I had a choice I would choose a private office every time.

"The author seems to celebrate a private office. Care to share your opinion? I'm curious..."

From experience, my most preferred to least preferred office options are

(1) Work from home (2) private soundproof office with a door (3) shared sound proof office (2 or 3 people in a medium/large room) with a door(4) open work spaces with a maximum of 5-8 people (5) standard cube (6) crowded and noisy "open work spaces" where you can't hear yourself think / get interrupted all the time, especially the "agile" version with enforced pairing and the "buzz of conversation" and so on.

The best options give you silence. The least inundate you in noise.

I'm right there with you. The informal collaboration possible in an open space is so much more productive for me.

Why do you imagine that informal collaboration isn't possible with offices? It happens all the time. Maybe you're just being prejudiced against a situation you have no experience with?

Because I've worked in both environments. I say informal because in open spaces you get involved in conversations and collaborative efforts that normally you have to go out of your way to be involved in. Here's a good example.

I was having a conversation with a dev about building an iPad app in my spare time and another dev sitting near by jumped in and argued that I should focus my efforts on the Mac App Store since it would be new and relatively easier to get noticed. 3 months later and I have an app selling well enough to quit my job if I really wanted to. This golden little side comment would not have happened if we all had offices.

Ideally, I'd like both: an open space to collaborate in, and a quiet place tucked away from interruptions and distractions to code in.

This. People get hung up on this type of debate when there's a perfectly obvious hybrid solution.

Different strokes for different folks. And not only that, sometimes people vary in their preferences depending on the context. I like working alone at night most of the time but sometimes a busy coffee shop really does the trick.

In my experience open spaces are preferred by those who are less competent and want to bother me all day with questions.

You never ask people questions when coding?

I am not opposed to all questions. I am opposed to the questions that are typically asked by those who prefer open spaces. I am also not opposed to basic questions asked by those who are new to the field, but I am often asked basic questions by those with 3+ years of experience.

Read a book.

It's possible we just know different people who prefer open spaces, but the questions I'm frequently asked are more specific variations on "How does Google's serving and indexing pipeline work?" and "What are the best practices for building JavaScript-heavy webapps in an environment where latency matters?"

There are obviously no books about those topics (well, there are some about the latter, but they're all wrong, and we have experimental data to prove it). And even if they were, they'd be out of date before they were published. Google's indexing system changed completely when Caffeine was launched last year - the only way to get information about it is to ask the people who're responsible for developing it. And the ecosystem surrounding the web is continually changing, and we keep running new experiments to keep up with it, because things that we were absolutely certain were true 5 years ago no longer are.

Most companies are nothing like Google.

> What are the best practices for building JavaScript-heavy webapps in an environment where latency matters?

Well, what are they?

At the moment, confidential. Google derives a competitive advantage from being fast.

I've toyed with the idea of getting permission to release some of the results we've discovered, in maybe a blog series like what Crockford did for JavaScript at Yahoo. Google also derives a strategic advantage from the rest of the web being fast, and IMHO the benefits of making everyone else fast outweigh the benefits of being faster than everyone else. But I've already got a 20% project that takes up like 50% of my time, so I don't have time to organize something like that. Maybe later.

My favorite argument comes from http://www.joelonsoftware.com/articles/fog0000000068.html : "Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds)."

If a question isn't an emergency, I queue it up by sending email. If it is, I ask in person, fully realizing I'm fucking up their day and hoping that doing so really is in the best interest of the company. I also only check my email a couple of times per day and wear heavy closed headphones for coding, because those elusive moments of flow are about half of what I live for.

"fucking up their day"

This is interesting--I would never feel this strongly about being interrupted unless someone was being overtly rude or annoying. I want to be productive, but I don't feel obligated to plow forward relentlessly hour after hour. If someone breaks my flow to ask a reasonable question, I don't think of it as a big deal. I think true flow is a lot less fragile than many give it credit for. It doesn't vanish anytime a pin drops nearby.

I think there's something to be said for the benefits of a less serious and more relaxed mindset. Working steadily, but not getting all caught up in "how productive am I?" like you're an assembly line robot. Coding is as much an art as a job and often you can be more productive by playing ping pong and chatting for 6 hours then having an insight that saves you 100 hours in the long run because your mind makes a lateral leap about the architecture that almost definitely wouldn't have happened if you had just sat at your desk typing all day.

I still see the benefits of private offices because it can be very beneficial to have the option of silence and intense focus when that is what you need to get over a hump, but it also seems like a lot of programmers are missing the great potential rewards of real creative collaboration--probably because they are used to collaborating in an uptight business-guy kind of way. Instead, they should take a cue from other creative people like artists, poets, and musicians, and allow their minds be free a good portion time through relaxation, speaking freely, and gasp having plenty of thoroughly unproductive fun. The gains in inspiration will easily outweigh the lack of perspiration, and life will become more enjoyable to boot. Isn't that ultimately the point of all this toil anyway?

I'll admit to sometimes getting annoyed when I'm interrupted and lose my train of thought. I like to code, damnit, it's hard when something keeps me from coding. :-/

But I've also found that my stress level just dropped so much when I acknowledged that I get nothing done during business hours, and so ought to just go in and accept the fact that my job is to help other people get things done. I can still fit in 2-3 hours after dinner, once everyone's gone home, and I found when I was doing my startup that 3 hours is about the maximum time per sitting that one can spend doing high-level intellectually creative work without getting totally burnt out. The unfortunate part is that it time-shifts my day (I go in to work around 1:00 PM and work till 9 or 10 at night), which means I only see the sun for half the day. But with enough practice (obviously failing now, since it's almost 3:00 AM), maybe I could swing my sleep schedule around and just have the mornings off to do whatever I want, then go to sleep as soon as I get home from work.

For me it really depends on what the question is - if I was in the middle of coding and someone asked me a coding related question (especially about whatever we were working on) then that really wouldn't require a context switch.

However, if someone non-technical comes and asks me something (which usually requires a lot of parsing) then that will require a context switch and I will loose a chunk of productivity.

Some of it for me is pure selfishness. I just care a lot more overall about having an interesting day than being productive. An interesting day includes work and solving problems, but it also includes conversation on both technical and random human topics, connecting with people on a deeper than working level, and just plain screwing around. Luckily this all tends to balance out (at least), because maintaining high spirits and an active imagination gives a boost to productivity that's at least as strong as having a private office and slogging away in it stoically every day for 10 hours.

I don't mean to sound like I'm chaining myself to the oars, and it's all a matter of degree. Talking design or shooting the breeze with the other guys is great and all, but sometimes I already know what I need to build if only everyone would just let me keep it in my head long enough to get anywhere on it. I find Joel's "15 minutes" optimistic. When a dozen people need immediate answers about stuff I haven't thought about since last year, and I try and fail a dozen times to actually write some code only to go home exhausted without a single commit to my name, it's utterly demoralizing. I go out of my way to respect others' time in the zone as an overreaction to how rarely mine is.

A poll about preferred work environments: http://news.ycombinator.com/item?id=2270424

I've done both and much prefer offices. It's much easier to collaborate in an office than it is to drown out distracting noise from a shared workspace. Offices don't keep you from being able to swing by someone's desk or have someone drop by yours, unless you shut your door for a reason.

My current area at work is open and I have to on occasion bring ear plugs to keep the noise down to a level where I can concentrate. There are group meetings, conference calls on speakerphone, and loud personal conversations happening all the time. IMO, if it comes to needing ear plugs then the one purported benefit of working in an open area is lost since you can't really be sharing/collaborative if you've closed yourself off.

It's all explained in the book Peopleware, along with years of data to back the conclusions.

I've worked at startups with open plans for the past 12 years. At every one, it starts out ok when there are less than 10 people. As soon as there's about 20, almost all of the important programming work is done after hours when all the loud people are no longer there. The only thing that gets done during the day (programming wise) is putting out fires. I've come to the conclusion that half the reason startups require "insane hours" is because during the day, the programmers are distracted and only working at 20% capacity.

Open office spaces are great! For socializing, that is. If you actually want to get work done, peace and quiet is a must.

I'm startled to see actual use of Visual Studio. When I was there a few years ago, literally every dev I met shunned it in favor of vim (or rarely emacs) and build.exe and windbg, despite pleas from DevDiv for any feedback.

4 PMs to 5 devs seems like overkill. why do this?

Not sure why, but from what I hear from friends at MSFT, an approximately equal number of devs, qas, and pms is very standard.

I've heard the ratio is dev::test::pm ~= 4::4::1

  My paint job is well done and tasefull and failities didn’t fuss at me about it.

  They key point is tha tthis is up tot the team (or team’s) that own the code.

  This all sounds great, but everthign isn’t unicorns and ponies every day: 
  There are problems to be sure – somtimes the bug data base is slow,

Would have been cool if he had spell-checked this before posting it.

I'm not sure what is the more naff joke; to go with 'And this is why Windows needs a native spellchecker' or 'Obvious over-reliance on static language compilers'. I'll go with neither, as it's a good read.

If anyone still wants to read this, the page has been taken down for some reason but I pulled the cached copy from google before they lost it: http://opensource.osu.edu/~jfriedly/mirrors/working-at-micro...

Nothing about his description really does it for me except the prospect of being able to play Skyrim on my work machine when it comes out.

I don't like open spaces, but being all alone in an office seems pretty horrible as well: Wouldn't you rather work from home, then? Ah, you say, but then people can't knock on your door to ask questions. Which, again, seems like it's making things worse, I don't want to sit in a closet waiting for people to knock on my door...

Around here we work on laptops, coding questions are handled via irc, most of the devs (not that many, <10 total) share a room but there's plenty of space for going elsewhere to get privacy when the hack is strong.

edit: laptops with monitor/keyboard at workstations, that is. I don't want to imply that everyone is hunched over a laptop all the time.

Using whatever editor or CLI you want sounds like a nice touch, might not be so expected in such a big company.

Does this extend to browsers? Is it open to use Firefox or Opera or Chrome as your main personal web browser, or is there a corporate mandate to use Internet Explorer on every desktop within Microsoft?

(I know the OP on wordpress may not read this here, but any other input is welcome)

There's no mandate (that I know of), but there is a strong culture of dogfooding that tends to push one to using IE. There's also many intranet sites that won't work without ActiveX.

But certainly no one's dropped by my office to ask me to stop using my alternate browser (I tend to separate my usage by my usage patterns. Work stuff on IE, personal stuff on the non-IE browser).

It's typical for Microsofties to use IE, search on Bing, etc. simply for dogfooding purposes, but it's not a specific requirement.

It does draw some raised eyebrows if you show up at the office with, say, a personal laptop that's a MacBook and a paired iPhone, but it's at the level of good-natured ribbing rather than actual managerial disapproval or job problems. I would usually say "Yes, but I convinced a family member to buy an XBox 360, so my corporate loyalty karma evens out!"

Everyone certainly does not get their own office. The way it works is that people are given offices sorted by their seniority (years at Microsoft, not your pay grade). So it goes:

* 2 people in a non-windowed office

* 1 person in a non-windowed office

* 1 person in a windowed office

* 1 person in a corner windowed office.. etc

and people just starting out do end up getting paired up with someone else.

Entirely depends on team and building. I wasn't doubled up until my 3rd year at MSFT. Even then, it was due to cramped space (bldg 9).

If developers always have the fastest machines available, how will they test or care about speed? I hope they have automated benchmarks of common tasks at least.

(Although it is obviously good to have things compile as fast as possible.)

In the case of Windows im sure they have a large test suite which runs benchmarks over tasks to weed out the non performant areas. Not only that in the later builds im sure its tested on thousands of systems to ensure that this code is weeded out in most cases.

Honestly, giving your developers a slow machine to "encourage" them to write faster code is a fallacy. The average user is not running multiple databases, multiple IDE's, debuggers, editors, multiple browsers, help documents and all the other programs they require to get stuff done. By all means make the test machine match what the users have but invest (yes it is an investment) in a fast machine for your developers.

If nothing else it will make them feel appreciated which will return more then the $1000 odd it will cost to spec their machine up from your users base model.

you need the fastest dev box to compile as fast as possible and run unit tests and bvt tests quickly. It's a true pain having to wait 20 or 30 minutes for something to compile and test just to keep working.

Performance tests are done separately on machines on a lab and there's lot of them, with components on and off,different configurations etc. In some cases you can simulate slowness like latency or less bandwidth ,as in a client with a 14.4k modem connection, with things like wansim. That allows to automate as much as possible.

I was an intern at msft. they have thousands of machines--consumer grade--constantly running tests.

It sounds like a startup situation :)

When you've got enough experience - sitting in your little silent dungeon - you'll find yourself longing for those hectic environments again...

The author seems to be pounding his chest about how efficient the MSFT code world is, but I was struck by how inefficient it all seemed. Is that just me?

If you think about the human and technical scale of what they are doing there, it seems pretty efficient to me.

I have interned at Microsoft. No intern has a private office. In fact, many interns do not work in offices at all.

Team/building dependent. On my team, the vast majority of interns get a private office. When they get doubled, they get doubled into a window office.

I turned down Microsoft when they recruited me in college. Wow, what a great decision.

Now, I run a software firm where no one has an office, everyone pairs (including owners and interns), we have a /slightly/ better ratio than 1 test per 100 SLOC, etc.

> we have a /slightly/ better ratio than 1 test per 100 SLOC, etc.

Has TDD really resulted in this becoming a status symbol? :P

Problem is that all status symbols in the programming world are meaningless, so in the absence of any useful metrics, we latch onto useless ones.

Tests/LOC at least measures something, even if it is imperfect. It's probably better than measuring LOC themselves, which are often a long term cost for the company, not a benefit.

but, Tests/LLOC seems to state even less than LLOC. LLOC gives an indication of the complexity of the application (or a component).

All Tests/LLOC seems to state is that some lines of code exist and potentially, some test cases are testing them.

It's also a measure of test granularity, i.e. for a module of given complexity, how many test cases cover it?

We can see what it measures. I'm just saying that it's a pretty nebulous metric when used out of context. Taking 2 numbers and condensing them into 1 (à la Megapixels) is an exercise in marketing.

This is why code coverage numbers are a much better metric.

Wow, I got blasted on this comment. So, there was a reason why I didn't start spouting our exact LOT/LOC ratio: I have no idea what it is. No one at our office does. That's not the important part. My point is that, on average, one test per 100 LOC is almost definitely not covering much of the logic. I mean... if you have one happy-path test and one expected failing test per block of code, you have one testing context per 200 lines. Two hundred lines!

I'm not understanding this comment. Which part of this post made you think that your decision was great? The fact that you started a software firm? the fact that no one has an office at your firm?

The fact that there is a culture; not cabins,

Can't tell if trolling or not...

Is it just me or he needed to use some Spell. Check? Oh he was on Windows, as buggy as it gets (code or writing).

As much as this comment nosedived at the end, I have to agree that his typos and misspellings detracted from the article for me. A basic proofread would have prevented this from feeling like it wasn't too well thought out...

Reply on news.ycombinator.com