Live data from Hacker News

Resignation letter from Microsoft Employee

worldofsu.com

81–90 of 117 posts

Re: Resignation letter from Microsoft Employee

#81

Earlier quoted context omitted.

I'd be interested in the study data. The data I've seen suggest that great managers put most of their time into manageable employees, the ones I called swing performers above. It could be that some stars swing between good and great, while some median employees swing between poor and good. If there are stars who have a 10% swing based on management investment, then yes there's a better ROI working with them. I agree…

>Spending time identifying unmanageable poor performers does generate very high returns IF YOU FIRE THEM. In software, poor performers can actually have negative productivity: Their presence slows the rest of the team down. excellent advice. Before going into mission, platoon leader should better shoot all his bad soldiers, so they wouldn't slow the team down.

I don't know about shooting them, but removing them from the platoon might help.

Re: Resignation letter from Microsoft Employee

#82

Turns out that there’s a strong correlation between a student’s grade and their assessment of the professor’s abilities. Very interesting. I don’t listen too carefully when a poor performer tells me how awful their previous manager was. Wait, what? Are we confusing correlation with causation here? Let's say, for example, that a manager tends to give female employees poor ratings (or whatever BigCo calls a grade). Do…

Your "swing performers" theory also applies to teaching. In an online course I used to teach I found there were roughly three types of students: - People who already knew the subject and/or were capable self-learners, and who only needed me for some comments and the final assessment. - People who could benefit from my concentrated effort and actually learn during the course. - People who, for whatever reason, would not respond to efforts to help. Some of them were functionally illiterate, which is a real problem in online education. Of course, they should have been culled out by intake, but I digress...

I would spend the first third of each course identifying each group, and for the rest I would use my time more efficiently by engaging directly with those in the second group.

Now you have given me a name, I am going to call them "swing learners". Thanks!

Re: Resignation letter from Microsoft Employee

#83

Earlier quoted context omitted.

Unless you're at a non-profit, revenue/sales/profit are what drives the company. If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for. In one of my other comments from a different thread I made the point that a lot of developers don't realize that they should understand the business. When you do understand…

False dichotomy ($1B vs zero). Actually, in my experience, developers understand the business quite well. It's the other business functions which doesn't understand development. You WILL drive out (and keep out) good developers if you fail to treat developers as professionals whose inputs of how to develop software should be respected.

Yes, often businesses don't understand development... but...

Us dev's have it drilled into us time and time again that we are so special and can't possibly be expected to participate in the company as a whole (our time is too valuable! we can't stick to a schedule! they don't understand software!).

That's a load of bullshit, developers don't get to wall off their private kingdom of code, same as no one else gets to wall off their section of responsibility and dictate outwards from within. Please stop furthering the (on that note) false dichotomy that programmers are either: 1) mismanaged by egregiously incompetent tyrants 2) given free reign to dictate to the business

Software developers don't deserve any inherent respect. Their value added to the business does.

Re: Resignation letter from Microsoft Employee

#84
post #46

> Do you practice specific skills with repetition and intent? This troubles me a bit for coding, because: There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself - Turing http://libreamoi.com/index.php/why-is-programming-repetitive... -- However... there surely are skills in this process itself. What are they, and can they be prac…

There are a variety of problem-solving sites you can practice on, if that's the sort of thing you're looking for...

http://codekata.pragprog.com/2007/01/code_kata_backg.html#

http://projecteuler.net/

http://www.spoj.pl/tutorials/

http://programmingpraxis.com/

Re: Resignation letter from Microsoft Employee

#85

I didn't read the whole thing... After I realized how stuck on himself he was, I just skimmed it. Do quirky people really brag about how quirky they are? Do they write essays and call them farewell letters? I've never yet met a fun person who goes around telling people how much fun they are.

>I've never yet met a fun person who goes around telling people how much fun they are.

Hmmm, but I've met boring people who walk around complaining about how bored they are..

Re: Resignation letter from Microsoft Employee

#86

Earlier quoted context omitted.

I'd be interested in the study data. The data I've seen suggest that great managers put most of their time into manageable employees, the ones I called swing performers above. It could be that some stars swing between good and great, while some median employees swing between poor and good. If there are stars who have a 10% swing based on management investment, then yes there's a better ROI working with them. I agree…

>Spending time identifying unmanageable poor performers does generate very high returns IF YOU FIRE THEM. In software, poor performers can actually have negative productivity: Their presence slows the rest of the team down. excellent advice. Before going into mission, platoon leader should better shoot all his bad soldiers, so they wouldn't slow the team down.

Horrible comparison. First, it's not uncommon (historically) for bad soldiers to have been executed. In Russian history alone, I can find examples of that (Trotsky's decimation in the Red Army, based of course on the Roman practice).

Second, in this case the poor performers aren't executed. They're let go, usually after being put on a pip (which can be viewed as a notice to look for another job). They can improve their performance in another job (if someone is smart, but doesn't get these things done it's a wake up call for them to establish better discipline). Similarly, in the military poor soldiers aren't usually sent into front line battles (being delegated to secondary roles).

Re: Resignation letter from Microsoft Employee

#87
post #74
post #37

Earlier quoted context omitted.

Then how do we categorize a startup if not by age (Facebook is already 5 years old) and size (hundreds of employees, billions in stock)?

>hundreds of employees Thousands, even. 1400+, according to Wikipedia.

Surely 1400+ is only one thousand and so not "thousands"; whilst it is 14 hundreds and so is "hundreds".

Re: Resignation letter from Microsoft Employee

#88
post #61

Earlier quoted context omitted.

Do you honestly believe that devs at Microsoft sit around saying, "Hmm... how can we do nothing today?" What on earth gave you the idea I believed anything of the sort?

From the line I quoted from you. Clearly you seemed to be implying that working at a company like Microsoft meant that you would be a poor employee at a startup company. Of course you didn't elaborate as to why, so I did it for you.

It was a question. I didn't imply anything, I said straight out it was not meant to be disparaging. And it has nothing to do with sitting around twiddling thumbs at Microsoft, it has to do with cultural fit - the guy has not worked anywhere else, at all. So easy with the 'doing things for me', much as the thought is appreciated.

Re: Resignation letter from Microsoft Employee

#89
post #30

If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted. People tell me this isn’t true, that it’s all about the people you know and about “visibility.” I have no idea how to consistently deliver impactful business results without becoming visible as a side effect. I hate it when developers ask me how to become “more visible.” They hate it when I tell them to…

Unless you're at a non-profit, revenue/sales/profit are what drives the company. If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for. In one of my other comments from a different thread I made the point that a lot of developers don't realize that they should understand the business. When you do understand…

The sales guys would agree that reliability and scalability affect

1) The ability to take on new business (a big problem if you're kicking ass and growing fast.)

2) The cost of delivering service to those customers.

3) The ability to deliver new features because developers aren't spending their time fixing existing ones or helping operations fight fires caused by the existing ones.

Sales will agree about all of that. However, when it comes time to argue over priorities, they'll fight tooth and nail to get resources devoted to new development instead of scalability and reliability -- until stuff is broken, customers are angry, and their reputation is going into the toilet. At that point they'll rightly pin the blame on you, though. They want you to be responsible and do your job. They just won't reward you for it with "visibility."

Actually, the best way to get sales guys on the side of reliability and scalability is when they're told to stop selling a product because your systems or operations staff can barely support currently provisioned customers, but good luck making that happen without having a report of SLA penalties already paid and a convincing projection of large penalties in the future. Also, at that point, you'll already have signed or nearly-signed deals that haven't been deployed yet.

So if you just go along with the sales guys, they'll drive you into a freakin' ditch. The sales guys do not have a balanced view of the business any more than the developers do. Everybody has to contribute their piece of the picture and fight for the priorities that they understand.

When the engineers stop sticking up for what they understand better than anybody else, things get out of balance, your technical assets start to crumble, and eventually you're technically bankrupt. But throwing engineering priorities under the boat and doing anything necessary to please the sales guys in the short term can make you very popular. "Visibility" means making people who drive revenue happy, and abdicating your responsibility to deliver bad news is the easiest way to achieve it.

But the worst aspect of "visibility" is that from outside engineering, the applications that are chronically broken are perceived as the vital core of ongoing feature development, and the developers who work on those applications get the most visibility. If you asked a sales guy to write a list of the most valuable developers in the company, that's who they would name. Can you imagine a more perverse incentive?

Re: Resignation letter from Microsoft Employee

#90
post #30

If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted. People tell me this isn’t true, that it’s all about the people you know and about “visibility.” I have no idea how to consistently deliver impactful business results without becoming visible as a side effect. I hate it when developers ask me how to become “more visible.” They hate it when I tell them to…

Unless you're at a non-profit, revenue/sales/profit are what drives the company. If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for. In one of my other comments from a different thread I made the point that a lot of developers don't realize that they should understand the business. When you do understand…

For those of you who think and operate this way, I'm sorry, but this WILL catch up with you eventually. At my last job our sales pitch was "Yes". I won't use the word "literally" here as it would be an outright lie, but it was pretty close. Our sales guys went into meetings with the assumption that we could pull off whatever the clients wanted in nearly any time frame they wanted. This was all decided on at sales time without any consultation of the actual development team on capabilities, cost or how long it would take to actually implement. Management would tell the IT/IS department (yes, we had to do both) that it was a show of faith in the abilities of our team and that we should be proud of the fact that sales and management were so confident in us. You know what that is? BS. That is sales "selling" IT. It's complete and utter BS.

Sure, we met those deadlines, we implemented those features and we made small fortunes for the company. But at what cost? The infrastructure starts to resemble Jenga more and more, your spaghetti code becomes harder to maintain, you end up with magic strings, magic numbers, client specific cases and conditions and your start eating into your IT budget by having to hire more programmers to support all of your crappy implementations and more hardware to handle the un-optimized pile of crap you're running.

What's worse is the very people you rely on to keep this tower from falling over, your programmers who have become so familiar with all the undocumented edge cases of your system, are also the very people you're basically forcing out. You're forcing them out because they become tired of not innovating, not refactoring and not progressing the technology OR the business, but instead spending all their time stressing over not "crossing the wires" of this delicate catastrophe. And when you finally lose them as a developer, and you will, it costs you severely in down-time and loses in productivity while you get your other developers and new hires up to speed. But not only do they have to learn the business, they also have to learn all the edge cases that were only known to your senior employee who was finally fed up and quit. And guaranteed, something, somewhere will be forgotten, that wire will get crossed and you'll pay dearly.

And while I do agree that making money and growing the business is the end goal of the business, don't assume that your IT guy isn't concerned with that and just wants to write "pretty code". Often times your IT guys understand the business more than sales, middle management and sometimes upper management because they deal with the logic, the clients, the sales team, and everyone in between day in and day out. When they're pleading with you to say "no" to a customer or ask for an extension to implement feature "x" properly, maybe you should take heed a little more often. Because the duct taped feature "x" that won over client "A" today, could be the same feature that loses you client "b" and "c" tomorrow because the only developer that new their system well enough to keep them running walked out after being forced to write yet another band-aid.

Of course when he quits and everything falls apart, everyone will just assume he was an overpaid, crappy programmer and his buggy code is what was the ultimate cause.

Post reply on HN