I don't really agree with any of these things. I'll go over them point by point and then add my reasons.
First is the issue of bureaucracy. This doesn't matter to me; it's hard to get individuals to do things, and it's hard to get big corporations to do things. If you want something done, do it yourself. Remember, the same bureaucracy that won't upgrade your Linux kernel is the same one that would be in charge of punishing you for doing it yourself. So don't fear the consequences of actions; if something feels right, just do it. (The one procedure that we can get our sysadmins to do here is to reboot a machine. So we have a "firewall rules" script, writable by developers, that is run from rc.local. If we really need some package installed, we do it from that script and then request a reboot. Against "change control policy"? Probably. Do I care? No.)
Next is having good projects. I suppose this matters for some people, but at the end of the day, I find pretty much everything programming-related interesting. If someone wants me to manually edit a billion records, or something, that's simply not going to happen, so nobody asks. You can't be afraid to push back if someone wants you to do something that you'll hate doing. Nobody wants you to hate your job, after all.
Performance reviews are always stupid. I've never seen the point of them. The people doing the reviews don't know how to program and don't take input from programmers, so the review boil down to random guessing. Which is fine, because a good review gets you no raise, and a bad review gets you no raise. It's just a big waste of time. (I get "meets expectations" every year, because they can only give out one "exceeds expectations". I mostly find it hilarious because I'm consistently in the top of the list of edits to our company-wide source repository. If being the top 10 in a 75,000 person organization is "meeting expectations", the expectations are a little high, I'd say. But that's OK, because management doesn't even know what edits or source control is.)
Strategic priorities are amusing. A bunch of people that know nothing about business or software will make lists of important-sounding things. The reason you are considered "top talent" is because you know this is bullshit. Ignore the todo list and work on what you think is important. (Same goes for the next point, being told how to do your job. If your management can't do the job, how can they check that you are doing it their way? They can't. So do things right.)
"Top talent likes top talent." That I can agree with. I know people can't be fired from big companies, but I wish they could be indefinitely suspended with pay. ("We'll pay you to STOP CHECKING IN CODE.") Then the three people with a clue wouldn't have to waste their time reverting the mistakes of the people trying hard for a good performance review.
The next three things boil down to how management works at big companies. If you are a really amazing programmer, they're not going to make you a manager. That's because they need programmers, not managers. So managers end up being blown-up programmers with enough people skills to get promoted. That means they make decisions with people skills rather than with programming skills. In order to get buy in, you have to "play the game", that is: don't treat it like your glibc mailing list, treat it like you're trying to get someone to date you. Be nice, say how your idea will unify teams, etc. People that can't understand details don't want them. Play to their people skills side, and everything will work our for the best. "I heard about this project and implemented it over the weekend" also works.
Anyway, I think the biggest problem is work environment and pay. I can get a 50% raise if I quit and go somewhere else. I can get a 2.5% raise and 20% bonus if I stay. The economics tell me to leave. You can't beat the economy. Same goes for work environment. I don't really believe that a top 5 corporation can't afford a 30" monitor for me. Stop lying and buy me the shit I need to get my job done. (The reason they don't want to buy people expensive equipment is because most people don't do any work. If those people see the three good programmers with bigger monitors, they'll want them too, just to feel good about their dick size. This goes back to the problem of not being able to do performance reviews properly.)
Honestly, this sounds horrifying. Yahoo (which everyone uses as a "poster child" of Silicon Valley company losing people) is orders of magnitude better than this in terms of projects, management, compensation and getting rid of bozos. E.g., your performance reviews (after which you get raises) are done by other programmers, your immediate manager (and his manager) are programmers, there is a career path for programmers (with compensation and responsibility to match management), etc...
You really should consider going elsewhere: I can show you places within a five mile radius of Downtown Mountain View (or SOMA, or The Mission in San Francisco, if you don't like suburbs) that not only do all that (that is the bare minimum) but also, e.g., write production code in Haskell (or whatever else that you're interested in).
I am supposed to start at Google on 1/3. Not 100% sure because I'm trying to extract more money (and don't really want to move to New York).
But the reality is: you can let your soul be crushed by evil, or you can like the likeable parts of your job and ignore the parts you don't like. It is sometimes fun to be smarter than everyone else, after all.
1) Don't prematurely optimize for salary, your market value increases vastly by having worked for Google. In addition, the bonus and RSUs have actual value, and you'll undoubtedly get raises if you think your initial offer was bad.
2) I'd hate New York also, but you're not moving there for the rest of your life. I know people who've moved from Mountain View or San Francisco offices to Seattle offices, and vice-versa while staying at Google. The Cambridge Office is quite nice as well.
I personally don't like Bay Area at all (San Francisco is disgusting, rest of Bay Area feels like you're stuck in a bad 70s movie), but there are only a few metropolitan area where software engineers are appreciated.
3) Just do it: I saw your comments on this site, I saw your Github repositories. You'll find actual culture fit at Google, something you won't be able to appreciate until you actually have it (or, on the flip side, as I found out myself -- until you've lost it and found it again).
Just don't use working at Google as an excuse to stop working on personal projects.
I don't really care if working for Google increases my market value, since I'm not sure I would want to leave Google once there. So it makes sense to me to get salary sorted out now, and then move to Google. If I passed the interview once I can probably do it again.
The reality is, if I didn't have to move, I would have accepted Google's offer instantly. But New York is expensive, and moving is a huge pain, and so the value isn't there to make me think, "yes, I must do this". I don't want to coordinate movers and look for apartments; I want to ride my bike and write software.
(Something that was strange about the Google negotiation process was that they only tried to match Amazon's Seattle offer; they never asked me what I wanted in order to move to New York. Take it or leave it, not negotiable. So if I can get what Google offered me from my current employer, it works out better for me in the short term.)
Edit: as it turns out, my current employer "can't" match my offer at Google. So, I'm moving to New York :)
Don't let anyone tell you that NYC is a bad place to work. You will have a much shorter commute, much more to explore in your city, and have a diversity of people around you here that aren't all in web companies. If you are dedicated and put effort into it, you can find a cheap place to live as well. The Google office here is also the real deal: plenty of big projects based in NY :)
"Top talent likes top talent." That I can agree with. I know people can't be fired from big companies, but I wish they could be indefinitely suspended with pay. ("We'll pay you to STOP CHECKING IN CODE.") Then the three people with a clue wouldn't have to waste their time reverting the mistakes of the people trying hard for a good performance review.
You hit the nail right on the head. I used to say this all the time when I was working for Oracle. There were plenty of people who weren't even contributing nothing - they were forcing the competent people to take time away from real work to fix the bugs these people caused. Negative value, indeed.
I'm guessing that you haven't worked at a place where it can take months to get a single line change implemented in production. This kills creators with the huge lag time between fix and implementation. I won't even go into meeting abuse.
Yeah, you've got to get those rules changed. It seems to be popular around here to call everything an "emergency fix".
(But the rules are changing. Right now, I only have to click one button to deploy to production, and it requires no manager sign-off. We hired a new CTO and that was the result :)
Obviously your employer sucks at bureaucracy. My employer has a "project and quality management system" (PQMS). Basically we have a group that sits around and thinks up more useless things that we could be documenting. Some documentation that they wanted last week is not good enough this week.
We have "phase reviews" before anything is released, no matter how minor. A "phase review" is essentially a long meeting with a dozen or more people (including one or more people from development) where the PQMS people bicker about the wording of something but no one cares that the thing does not work well. Then half a dozen people have to sign the documentation.
At the end of each sprint (we do something that we call Agile but is actually its antithesis) developers have to sign off on their peer reviews, which have been printed out. QA people have to create several documents (this seems to be QA's main function) and sign them and then everything is signed by multiple managers who know very little about what went on. We also have daily "stand-up" meetings that all development and QA people must attend. These meetings usually last 15-30 minutes but can last an hour or more. Before each sprint we have a "design review" meeting where people who know nothing about software development try to create user stories in our ticket system while everyone watches. A few days later we have a retrospective meeting and then we do sprint planning where we watch the same people who created the user stories try to enter sub-tasks for developers. Most of these meetings must be documented and of course people must sign the documents.
There is also a large repository of documents which supposedly describe every process that we use. These documents are of course inaccurate and rarely useful. A few of them are updated each week and everyone is required to read the updates.
No one, other than top executives who do not care, has any real power to dispute any new policies that PQMS creates. I should also mention that the people in the PQMS group have no understanding of software development.
BofA has all these dumb processes, and as a result, the stock market values the company at less than the total of its assets. CEOs do not make the connection between stupid policies and utter financial failure. "More policies," they say, until one day, the company is gone.
That's a big reason why I left a defense job I otherwise liked. Due to government regulations regarding contractors, every change had to be directly attributed to a request for functionality that the government generated or approved. It could take upwards of 2 months for a single one-line change, which was quite frustrating. There were spots in the code where the engineers KNEW things needed to be fixed but they weren't allowed to because they couldn't get the proper authorization.
An interesting side effect was that the group I was in made a point to use the best software engineering practices they knew (100% test coverage, all tests pass with each checkin, every checkin was code reviewed) because the engineers knew that, once code went out the door, it could be a long damned time before anyone touched it again.
I worked at a University where it would take a week to get production logs. If I couldn't find the source of the bug, I'd have to deploy a new version with a few more debugging statements, and wait another week to see the debugging in the next production logs. I eventually learned to put a hell of a lot of debugging statements in my code. I think about every other line was a debugging output statement.
"If you want something done, do it yourself. Remember, the same bureaucracy that won't upgrade your Linux kernel is the same one that would be in charge of punishing you for doing it yourself. So don't fear the consequences of actions; if something feels right, just do it."
That's a wonderful idea. It sounds like you're at a much more open "big company" than I am. You see, I don't even have the access to install stuff on a production box. I have to give it to an infrastructure team to install for me. And they aren't going to do anything without me going through a process that takes days of approvals and no less than 5 different documents. It doesn't matter how small the change is. If it needs to move fast, you need even more approvals, but the built-in rules of it taking so long are removed. Still need all of those documents though or they won't install it.
Most people in my ISD don't even have the ability to download. They don't have admin rights on their box. Most people are using 17" monitors. I was only too happy to get a 19". It was only a few years ago that they finally decided it was ok to give us internet access. Freaking internet access! This is my big corporate world experience.
I recently gave an estimate to someone which would take me 2 hours to do, and 4 to go through the change control process etc....
Of course that cant be taken at face value since im not allowed to estimate. My estimate is taken by a designer who produces several documents. They then budget for the following, designer, development lead, design lead, business analyst, tester, product owner, business tester.
I checked what my 2 hours work 4 hours testing etc... and its now an 80 hour effort. With 10 hours spent already producing the documentation and at least 3 levels of management discussing it.
For the record I implemented the change while giving the estimates and it ended up taking me an hour, but is still sitting in development.
Don't even get me started on how much time (weeks) effort (4 levels of management, weeks of meetings and at least 10 people involved) it took to get an additional 2 gig of RAM added to a production server which only had 2 gig to start with. I think the cost in man hours would have been at least $50,000 for a stick of ram which actually cost nothing as its already in the server and just needed to be enabled.
Oh on the Screen thing. I bought my own. 27" monitors can be had for $300 or less these days. Easier then trying to justify why a 24" would be advantageous to me and why dual 19" isn't as good.
Totally agree with your sentiment on bureaucracy. One of the first mantras I adopted at my "big company" was to get stuff done the best way you know how, and risk the slap on the wrist later. More than likely you have just taken the first step towards positive change in your company.
With regards to having interesting projects, I'd add that if you're in a big company, then in all likelihood there are tons of projects you will find interesting if you look hard enough (and if you're a tinkerer like a lot of you are here, this shouldn't be all that difficult). If you can honestly say you've rotated, shopped around, interviewed dozens of managers, and found nothing that can balance your compensation needs and your passions, then get out of dodge, stat. Otherwise, as my dad used to tell me, stick around until you run out of interesting/fun things to do.
First is the issue of bureaucracy. This doesn't matter to me; it's hard to get individuals to do things, and it's hard to get big corporations to do things. If you want something done, do it yourself. Remember, the same bureaucracy that won't upgrade your Linux kernel is the same one that would be in charge of punishing you for doing it yourself. So don't fear the consequences of actions; if something feels right, just do it. (The one procedure that we can get our sysadmins to do here is to reboot a machine. So we have a "firewall rules" script, writable by developers, that is run from rc.local. If we really need some package installed, we do it from that script and then request a reboot. Against "change control policy"? Probably. Do I care? No.)
Next is having good projects. I suppose this matters for some people, but at the end of the day, I find pretty much everything programming-related interesting. If someone wants me to manually edit a billion records, or something, that's simply not going to happen, so nobody asks. You can't be afraid to push back if someone wants you to do something that you'll hate doing. Nobody wants you to hate your job, after all.
Performance reviews are always stupid. I've never seen the point of them. The people doing the reviews don't know how to program and don't take input from programmers, so the review boil down to random guessing. Which is fine, because a good review gets you no raise, and a bad review gets you no raise. It's just a big waste of time. (I get "meets expectations" every year, because they can only give out one "exceeds expectations". I mostly find it hilarious because I'm consistently in the top of the list of edits to our company-wide source repository. If being the top 10 in a 75,000 person organization is "meeting expectations", the expectations are a little high, I'd say. But that's OK, because management doesn't even know what edits or source control is.)
Strategic priorities are amusing. A bunch of people that know nothing about business or software will make lists of important-sounding things. The reason you are considered "top talent" is because you know this is bullshit. Ignore the todo list and work on what you think is important. (Same goes for the next point, being told how to do your job. If your management can't do the job, how can they check that you are doing it their way? They can't. So do things right.)
"Top talent likes top talent." That I can agree with. I know people can't be fired from big companies, but I wish they could be indefinitely suspended with pay. ("We'll pay you to STOP CHECKING IN CODE.") Then the three people with a clue wouldn't have to waste their time reverting the mistakes of the people trying hard for a good performance review.
The next three things boil down to how management works at big companies. If you are a really amazing programmer, they're not going to make you a manager. That's because they need programmers, not managers. So managers end up being blown-up programmers with enough people skills to get promoted. That means they make decisions with people skills rather than with programming skills. In order to get buy in, you have to "play the game", that is: don't treat it like your glibc mailing list, treat it like you're trying to get someone to date you. Be nice, say how your idea will unify teams, etc. People that can't understand details don't want them. Play to their people skills side, and everything will work our for the best. "I heard about this project and implemented it over the weekend" also works.
Anyway, I think the biggest problem is work environment and pay. I can get a 50% raise if I quit and go somewhere else. I can get a 2.5% raise and 20% bonus if I stay. The economics tell me to leave. You can't beat the economy. Same goes for work environment. I don't really believe that a top 5 corporation can't afford a 30" monitor for me. Stop lying and buy me the shit I need to get my job done. (The reason they don't want to buy people expensive equipment is because most people don't do any work. If those people see the three good programmers with bigger monitors, they'll want them too, just to feel good about their dick size. This goes back to the problem of not being able to do performance reviews properly.)