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 “do great work.” They think I’m mocking them.
You can think this way if your idea of "what the business needs most" is "what currently has the sales guys in a tizzy." Forget about everything else. Oh, and if your code only works for current customers, and has to have a bunch of tweaks and fixes applied for each new customer, then people will think your code is what allows them to sell to new customers. No kidding. If you write code that doesn't handle cases A, B, and C, then later you get credit for adding "support" for A, B, and C and making it possible to sell to customers X, Y, and Z. That's "visibility," because people from sales and marketing will mention your name appreciatively at high levels.
And for God's sake don't do any work on scaling or reliability, because a salesman never calls up your boss's boss and says, "It's been a long time since the scalability of your systems scotched a deal. I just want to say that's awesome and thank you." Wait until it breaks, make everyone thinks it's impossible, and then fix it.
EDIT: In a healthy organization, none of this will affect who gets promoted, but in an organization where people worry about "visibility," this is what they're talking about.
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 it and the salesperson is in a tizzy about the "wrong thing", you can point out, "actually, that's not the real revenue driver. XYZ is. Why does the customer think ABC is? I'll tell you why, it's because DEF. But by doing XYZ we can deliver ABC in six months time."
I think you'll find when you can talk at the level of business a lot of things become clearer for you and the sales team.
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?
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.
I've heard developers tell me, in all seriousness, MS should dump Windows and start shipping a real OS like Linux. False dichotomy? I don't know, but I think you'd find the business would probably lose a fair bit of money doing that.
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.
It's amazing that you get so defensive over "learn the business". I never said to be a meek dev. In fact I clearly state that you should attempt to change minds with principled arguments that have the business in mind.
But based on my experience, that's not what I've seen. I've seen devs fight to do a completely rewrite that management won't fund because everyone wants to continue to use the old LOB solution. The devs argue about how the old system is a rats nest and uses archaic technology. But the business says that its doing the job, why do you want us to switch to something that lacks the features we need, just because it uses REST rather than SOAP (whatever that means).
And I've been brought in to consult on many of these disputes and probably 8 out of 10 times the "ugly" code is perfectly serviceable. What I've often done is shown how one can incrementally improve and rearchitect the existing code with no downtime... and probably more than half the time this ticks off the architect. His big dream was to do this monster rewrite that I've just shown is completely unnecessary.
At the end of the day maybe I've hurt morale of the dev team, but janitors don't get paid to not clean bathrooms (not that we're janitors, nor is there anything wrong with being a janitor, but you get the point).
I apologize for being overly defensive, but I've unfortunately lived through all of what I was saying. I do agree with your Janitor analogy in that at the end of the day you're paid to do a job. However the problem often lies in situations where developers are hired for their expertise, but they aren't allowed to utilize it to do the job properly and instead are just asked to get it done.
I guess if I hired engineers who were capable of doing a complete re-architecture of a system, but forced them to put in "ugly" code that is perfectly serviceable - I wouldn't expect them to be around very long. I don't speak for everyone, but I do strongly believe that those that do this for a job and paycheck will be fine, if not happy, working on ugly code to keep things going. Those that do this for the love it, whom in my opinion are often better programmers, won't. At least, not for very long.
Still, there is definitely merit to your statements, especially when it comes to devs dreaming of re-architecture and instead having to settle for a small change. I appreciate the follow up.
Thank you for your follow up. Clearly your experience is far outside my world. I've never heard of an outside consultant being brought in to second guess the company's "architect".
It seems like you mostly move among bad developers. I don't think your experience is relevant to most of the developers reading HN.
Obviously, a full rewrite not a good idea in most cases as Spolsky eloquently argued.
PS: I didn't detect any "defensiveness" (you know, the catchall passive-aggressive term that is used to use to imply that the other side has a weak hand without backing it up) in the post you were responding to. It rang true to me.
I don't think I move among bad developers, per se, but when I consulted I generally worked at places that weren't software companies. HN is filled with developers who plan to build companies (or work for companies) whose core business is to build software and either sell or have that software be the key part of a service. A lot of the places I did consulting for, if all of their in-house software stopped working, they could probably still do business, but a lot less efficiently. Most companies are not "about" the software just like they're not about the desks in the office.
And actually... quite often I wasn't brought in to second guess the architect. Many times I was brought in at the request of the architect. But yes, most of the time you're brought in because they lose faith in the architect or team. If you see me stop by to do a simple audit of your code, you should probably get your resume ready -- well not really, as I don't do any consulting any more.
Right. The time to worry about IT quality is after the duct-taped fraud of a product has collapsed and exposed millions of credit card numbers and personal information. Lawsuits, legal penalties, and potentially criminal charges are generally not good for the business.
Or maybe the gradual weight of technical debt simply slows you down so much that smarter, tech-focused competitors steal all your business.
That's just scare-mongering from IT guys, until it actually happens to your company (and you can always just blame them anyway).
> 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.
And that's an excellent reason not to tie a given salesman's compensation directly to sales value, but to time-averaged client profitability.
If you skin your client and sell them more than they need or something impossible to pull off, then retire and leave a mess for legal to sort out, you are not exactly a good salesman.
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 we discount their negative assessment of the manager? If there's a poor relationship between an employee and a manager, I'm not surprised when there is negative performance and a negative assessment.
Aren't we extremely interested in negative performers? We need to triage. Some employees are stars and will be stars no matter how you manage them. Ignore them, keep the kitchen stocked with whatever they drink. Some employees are poor performers no matter what you do. Identify them and fire them immediately, or better still leak their résumé to competitors, you get a 2-for-1.
The area of management opportunity are the "swing performers," those whose performance can be influenced by management practice. Some of the negative performers will be irredeemable, but some will be swing performers and it's worth listening to disgruntled poor performers if you can find a way to filter for swing performers in the hope that you can identify opportunities to turn them into good performers.
>Turns out that there’s a strong correlation between a student’s grade and their assessment of the professor’s abilities.
One possible explanation is that the student's evaluation of the prof is based on how well he understands the course material (since the prof's job is to induce that understanding) - which, of course, also impacts the student's grade.
>Turns out that there’s a strong correlation between a student’s grade and their assessment of the professor’s abilities.
In my experience with classmates, it initially might also look like this correlation is true, however I think the hypothesis is a bit more involved.
In one case, one class was taught with quite easy grading policies and many people ended up getting good grades - yet the smart students were unhappy with the professor and lack of challenge. In another cases, I've seen quite difficult abstract math classes and smart students would complain about the teacher as well - because of personal incompatibility - the teacher's style just didn't click with the student. And also, many times weak students would express a lot of respect and positive rating of a professor even though the teaching was over the top of their heads.
Yet obviously there were the lazy/less smart types who would just reduce the challenge to complaining about the prof - yet they are probably likely to complain about people in different situations (i.e. job)
Interesting data point for you. First, Break All The Rules found that average managers put most of their time into their worst performers. Great ones put most of their time into their star performers. The reason? Both groups can improve, and a 10% improvement in a star is worth a lot more than a 10% improvement in a dud.
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 with the idea that it's a poor idea to spend most of your time with your worst performers. The problem with the worst employees is that many of them are irredeemable, so you can't get 10% improvement out of them, except possibly by micromanaging them to the point where you're doing their work)--and that doesn't scale. They're unmanageable in a negative sense, and thus you need proportionally more investment to get poorer returns.
One strong exception to a dictum against spending time with worst performers: 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.
>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).
>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).
I can only say - Kirk Douglas, "Paths of Glory". It said all about bad performers and management.
>Similarly, in the military poor soldiers aren't usually sent into front line battles (being delegated to secondary roles).
nice, correctly incentivising, performance management system - if you shown yourself a bad soldier then you don't get to go to dangerous mission(s). I bet you'd be a respected 4-star general ...
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!
I read the whole thing, and thought it was valuable. For example, little snippets like: "Turns out that there’s a strong correlation between a student’s grade and their assessment of the professor’s abilities." were new ideas to me. I guess some of this comes from the management and leadership books he's read.
I didn't think he talks particularly much about himself or how quirky he is either.
Also interesting that this is the second person at Microsoft I've read about this week complaining about benefits being reduced. Michael Kaplan (interesting blog on internationalization issues at Microsoft besides) says "Microsoft, multi-billion dollar company that it may be, has no spine whatsoever to speak of.":
A while back I did a lit review on the correlation between grades and teacher evaluations. I remember being surprised at how little of a correlation economists found between the two variables. Based on my memory, things like teacher personality, teacher nationality, grade variance, and class size matter a lot. Didn't pg have an essay about how "Turns out" is a euphemism for I'm too lazy to provide evidence?
I'm surprised that's what you took away from it. I thought they were good anecdotes about corporate culture and life at microsoft, as well as what we should aspire to, from someone who has seen a lot of people come and go. Each paragraph (and sometimes sentence?) stands fairly well on its own...
Still, even if he's stuck on himself, it is _his_ farewell letter after all
He lost me at the bit about it being impossible not to get promoted just by doing good work. Doesn't work that that in any organization, because to be a manager you have to want to be a manager, and you have to want it more than you want to be "just" a programmer, and you have to think being a manager is better than being a programmer.
Getting a promotion is a full-time job in itself. No time left for coding...
There's ways to be promoted without being a manager. If that isn't the case in your organization (even if you _do_ want to be a manager), leave.
Ideally, there should be two ladders: technical and management. Every management rank should have an equivalent technical rank, with salary to match (fellow being equivalent to a VP, CTO being equivalent to CEO). That's the case at Microsoft, Google, Facebook, Yahoo and many other technology companies (as opposed to enterprises that merely _use_ technology or sales/marketing companies masquerading as technology companies). Technical talent should be appreciated; at the mean time, being a manager is quite different from being an IC and requires a different skill-set -- one shouldn't become a manager only if they want a raise.
There're more than a few people where I work whose full time job seems to be inserting themselves into existing projects as middlemen for the purpose of taking credit. They're transparent too when it comes to taking blame... I don't want to be a manager (been there, done that) but if I did, I wouldn't have time to do actual work.
This was the best thing I've read all week, full of nuggets of wisdom. Who cares whether he calls himself fun or quirky or whatever else? You could get about 80% of what you need to know about life and work from that one collection of paragraphs, which mean's it's pretty worthwhile read as far as I'm concerned.
However... there surely are skills in this process itself. What are they, and can they be practiced?
Concrete example: if you keep repeating code, you could (variously) write a function for it; a framework for it; a language macro; use an IDE that automates it; write a vim/emacs macro; etc
So perhaps one specific skill is to learn how to automate things with a concrete tool, and practice automating tasks (eg. writing a few vim macros as practice, to learn the syntax, API, pitfalls, conventions etc).
( EDIT: or, more generally, practice using your tools )
Deeper skills are recognizing repetition (and regularity in general), defining it clearly enough to know what an automation would need to do; and know how to verify that you're correct. Implementing it is a final step. Another skill is in assessing whether such precise analysis is worth it, given insufficient data to 100% nail the task; that the task may change (esp with new data); and of course that to estimate how much effort is involved in doing it "properly", verses a "good enough" solution, verses not automating at all.
But how does one practice those tasks with "repetition and intent"? They aren't like piano scales - each problem is unique and unknown. hmmm.
I worked with Philip some, he's a really smart, interesting guy - I was definitely bummed when I heard he was leaving. His internal blog at MS had a lot of great advice for younger developers and managers, I managed to save it off before he left and the IT folks ate it
It took all my discipline NOT to write an angry resignation letter. In the end, I didn't write any at all. No good can come from them unless they are the most vapid and empty of sentiments.
Microsoft employees can be broadly classified in two current states of mind: people who can't wait to leave and people who can't imagine leaving. I almost never encountered someone that was in-between these extremes. As such, you pretty much can't write a resignation letter that expresses meaningful sentiment that doesn't offend one of these large groups.
I worked with Philip a bit last year. He's (well, was) probably one of my favorite MSFT employees - I don't think I've seen anyone else with such energy. Big loss for MSFT, great win for FB.
He had me until: "What’s your final level at Microsoft? Please don’t say CEO or Technical Fellow – I can almost guarantee you it’s not." He may be right, but there are some ambitious employees at Microsoft who truly do want to be CEO. If that's what they want, I hope they continue to bust their ass of to achieve it.
I really don't like when critics put a cap on someone's future.
Undoubtedly you are correct, someone else will eventually be CEO, thus his statement is categorically false. However he is being over the top to make a point, some people think it while knowing they don't work hard enough/care enough to get there. He is saying people need to stop lying to themselves and realistically view their future with the company.
"Practice articulating positions you disagree with faithfully and persuasively. Unless you can do this, you’re implicitly assuming that people who disagree with you are idiots. Smart people understand why smart people disagree."
Two things struck me, one kind of minor - a Pentium 66? In 1997 my desktop machine at my new startup job was a Pentium Pro 200. It replaced the SGI Indy R4400 200 from my previous startup job. No offices with doors, though, of course.
The other thing was, and I don't mean these questions in a derogatory way, how do you start working for Microsoft in 1997, of all years. And how do you stay there for 12 years running? What kind of startup employee will you be when the only professional environment you have known is Microsoft? I'm not suggesting that there aren't perfectly excellent, sensible answers to all of these, and obviously his new employer thinks so. I just can't personally conceive what they are.
Facebook, behemoth that it is, is still a startup. We get a little carried away calling every little personal website project a startup and perhaps that's just right for the forum. But don't get tunnel vision. Facebook is a startup.
If you have more money privately invested than money earned, you're probably a startup. If you're searching for a repeatable, scalable business model, you're probably a startup.
Or, your business might be a failure, yet past the point of being a startup. Clearly Facebook does not qualify as a failure, but they are not a startup in my estimation. They're an established business.
It is pretty arbitrary and Facebook is a late-stage startup but hundreds of employees, sky-high valuation and five years of age are not unheard of and still within 'startup' range, to me. Mushy factors include things like culture, innovation, risk. I'd say 'run by founder' also adds startup points.
I would suggest stock value more than 50x peak profit probably works. A 5 year old billion dollar company that is never made more than 1 million a year is probably still a startup. A 3 year old 10 million dollar company that made 500k last year is probably not.
Only if it's valued more than past revenues would suggest. IMO, Tesla Motors is still a startup Google is not. What separates them has more to do with the stability that comes from profit than it does an IPO or company culture.
"What kind of startup employee will you be when the only professional environment you have known is Microsoft?"
What do you think they do at MS and what do you think they do at startup companies? Ex-MS people have done places like Zillow, Valve, Fog Creek. And thousands have joined relatively large companies in their early phases, such as Google and Facebook.
Do you honestly believe that devs at Microsoft sit around saying, "Hmm... how can we do nothing today?"
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.
Good ideas are a dime a dozen. Great ideas are usually laughed at. Neither sees the light of day without you taking action.
While there were good stories and takeaways from his post, I keep hearing this same mantra coming across so many would-be entrepreneur stories. Why do people doubt themselves so much and not listen to their own ideas?
The issue isn't confidence, it's motivation. Ideas are a dime and dozen. Execution on good ideas is what matters. Personally, it seems so blidingly obvious that I wouldn't even think to say it, but clearly for a lot people this seems controversial.
It is hard to believe that someone that managed so many is focusing in his parting words on (1) telling people that got bad reviews that they aren't as good as they think they are, and (2) telling them to aim their sites lower (since not everyone can be president). That's not the kind of manager I'd want. There is nothing wrong with confidence and ambition; just redirect it towards taking risks to accomplish tasks that no one thought could be done.
Those people complaining, btw, probably have valid complaints, regardless of what they've output. Often people that have low output are a sign of poor hiring and/or management. Why didn't he focus on suggesting changes to remedy this?
In addition, he was ditching on the Litebulb mailing list, rather than suggesting an alternative. What if he were to suggest that MS had 20% time to work on Litebulb requests?
Compared to the EA breakup letter the other day, this was a lot more fun to read. What a surprising change to read a resignation letter that wasn't all FU & drama.
I liked this because he explains really well on how employees may be misjudging a manager's negative attitude on them because they don't understand the requirements of the business (or productization, for that matter).
It often happens that you need to do something negative such as giving bad review, not approving some large piece of code which the employee thinks is beautifully written. Or even just fire someone.
I've been on both sides, and now on the management side I see that employees usually don't realize the truth, and consequently have hard time getting a lesson out of the incident.
"Practice articulating positions you disagree with faithfully and persuasively. Unless you can do this, you’re implicitly assuming that people who disagree with you are idiots. Smart people understand why smart people disagree."
This should be taught to everyone from a young age.
"Individuals are the sole cause of anything that’s ever happened."
The most inspiring quote in the article. Reminds me of the Margaret Mead quote I have hanging in my room somewhere: "Never doubt that a small group of thoughtful, committed people can change the world. Indeed, it is the only thing that ever has."
Meta-summary: Here is a list of platitudes which, if you completely internalize and act on them, will lead you to be successful enough to leave and get a job at Facebook.
Doesn't it show what's wrong with an organization when people's heads have this much politics and organizational complexity in them? His advice is to ship good software to get ahead, but his thought process is all about everything else.
Once, at a Pizza Hut counter, I noticed that all the pens meant for signing credit card receipts had little flowers attached to their tops. Stuck together in a cup, the bunch of pens looked like a bouquet. I asked the cashier whether this was a new Pizza Hut policy. She said no – she had done it on her own. What would you pay to have her in your company?
Maybe he missed the point? People typically attach things to the end of pens to stop them from getting stolen. Not to make bouquets.
Having a hard time reconciling the dismissive attitude toward soda theft and the celebratory attitude toward punishment for cattle theft, otherwise awesome essay.
So this guy sounds like some office granny scolding the interns over trifles of etiquette. He summed up his 12 years of working at Microsoft with a bunch of smarmy anecdotes typical of office gossip & politics. Not a single mention about software or technology in general. No penetrating insights about the industry, products, the future.
I wonder about Microsoft's financial future if this is what their corporate culture has been reduced to. Everyone is so high on themselves and on playing Soap Opera over in Redmond that nothing truly new gets shipped.
Does the "TL;DR" sentiment really belong at HN at all? I'd like to think this community is above that. The whole thrust of the site is about/for people who aren't interested in taking the easy way out.
It's like one of those "you know you're a bad programmer if.." quizzes. It doesn't say anything you don't already know, & it's just playing on peoples insecurities.
You can think this way if your idea of "what the business needs most" is "what currently has the sales guys in a tizzy." Forget about everything else. Oh, and if your code only works for current customers, and has to have a bunch of tweaks and fixes applied for each new customer, then people will think your code is what allows them to sell to new customers. No kidding. If you write code that doesn't handle cases A, B, and C, then later you get credit for adding "support" for A, B, and C and making it possible to sell to customers X, Y, and Z. That's "visibility," because people from sales and marketing will mention your name appreciatively at high levels.
And for God's sake don't do any work on scaling or reliability, because a salesman never calls up your boss's boss and says, "It's been a long time since the scalability of your systems scotched a deal. I just want to say that's awesome and thank you." Wait until it breaks, make everyone thinks it's impossible, and then fix it.
EDIT: In a healthy organization, none of this will affect who gets promoted, but in an organization where people worry about "visibility," this is what they're talking about.