Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working at Microsoft – Day to Day Coding

foredecker.wordpress.com

Post reply on HN
Print view View original

91–100 of 171 posts

Re: Working at Microsoft – Day to Day Coding

#91

Post by boyter »

mfukar wrote: post #54
boyter wrote: post #9

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 yea…

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.

Re: Working at Microsoft – Day to Day Coding

#92

Post by InclinedPlane »

seldo wrote: post #82
InclinedPlane wrote: post #63

Earlier quoted context omitted.

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 shari…

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 sec…

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.

Re: Working at Microsoft – Day to Day Coding

#93

Post by iam »

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.

Re: Working at Microsoft – Day to Day Coding

#94

Post by robryan »

kenjackson wrote: post #16
johnbender wrote: post #14

Earlier quoted context omitted.

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.

Re: Working at Microsoft – Day to Day Coding

#95

Post by stevefarnworth »

thaumaturgy wrote: post #57
boyter wrote: post #9

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 yea…

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 developmen…

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.

Re: Working at Microsoft – Day to Day Coding

#96

Post by stuhacking »

nostrademons wrote: post #45
adbge wrote: post #30

Earlier quoted context omitted.

> 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.

Re: Working at Microsoft – Day to Day Coding

#97

Post by fierarul »

projectileboy wrote: post #60

The author seems to be pounding his chest about how efficient the MSFT code world is, but I was struck by how in efficient 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.

Re: Working at Microsoft – Day to Day Coding

#98

Post by JanezStupar »

tallanvor wrote: post #80
InclinedPlane wrote: post #69

Earlier quoted context omitted.

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 wit…

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 :)

Re: Working at Microsoft – Day to Day Coding

#99

Post by ot »

thaumaturgy wrote: post #57
boyter wrote: post #9

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 yea…

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 developmen…

> 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

Re: Working at Microsoft – Day to Day Coding

#100

Post by nostrademons »

stuhacking wrote: post #96
nostrademons wrote: post #45

Earlier quoted context omitted.

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?
Post reply on HN