alarge's comments

I think the problem here is the implication of the term "politics". We've been conditioned (at least in the US) to think of politics as a tribalistic "us vs. them" activity where interactions have winners and losers.

The classic picture of "office politics" is about either damaging reputations with gossip or getting special treatment because of who you know instead of what you know.

But this depiction strikes me as less about that dirty version of politics and more about simply accepting that social grease is important in an organization. Teamwork is important. Crafting the message to the recipient is important. Inclusiveness and a shared sense of ownership is important. Culture is important.

I detest and refuse to engage in tribalism - workplace or otherwise. But I 100% believe in the stuff from the previous paragraph.

No, your manager doesn't decide your promotion. The difference between before and now is that before, your manager was expected to make the case for your promotion. Now, the manager is expected not to be an advocate, but to provide their balanced input (ready now, ready soon, not yet ready).

The promotion still goes to a promo committee - although now they try to locate it close enough to your org that they have heard of you, and can have a high-context reviewer (not your manager) at the table.

The carryover from the previous system (and the thing that these sorts of posts seem to miss) is that every level has explicit expectations about the sort of activities that a person at that level can be trusted to independently conduct. A decision on promotion is a decision on whether or not a person has adequately demonstrated that they can do the work of the next level. It isn't some sort of award for doing their current job well. When someone languishes for a long time at a level, it is usually because they aren't demonstrating those next-level signals.

The system can feel unfair - like a team that lacks adequate opportunities for someone to demonstrate next-level signals, or the insistence that work doesn't count until its production impact can be assessed (which may take years for some projects). But it is rarely as capricious as may sound.

Lest anyone draw the conclusion that this is a US thing, it certainly is not. I've lived in many places throughout the US and have never heard anyone say "three or two". Nor does "two or three" carry the connotation that two is likelier. A closer fit to that would be "a couple", which formally means two, but sometimes means "a small number".

This is so cool! And I'm dismayed that you have been subjected to the typical Hacker News cynicism.

By looking through some of your other project and interests, I can see that you likely have a healthy sense of your own capabilities and certainly don't need my validation or approbation. But I'm going to give it anyway.

Piffle on anyone who knocks you on tone! It is not trivial to make this level of technical information available in such an approachable fashion. When we first start our careers, detailed technical knowledge and the ability to solve low-level problems are super important. But the way you "crawl up the value chain" in software engineering is to become a "force multiplier" - someone who can make other people more productive. And the ability to communicate well (both what to communicate and how to communicate it) becomes a more and more important skill. This work clearly demonstrates your communication skills.

I hope you make software engineering your career choice. The field could use more people like you.

When I first entered this field in the 80s, there was a rivalry between vi users (as I was) and emacs users. There was so much about emacs that I couldn't stand, but I'll admit to quite a bit of envy as well.

Then, some time around 94 or so, I became aware of this vi clone called vim. My emacs envy could finally be put to rest because this vim could either do (or had on the roadmap to do) everything I had envied from looking over emacs users' shoulders! I became a rabid user and evangelist, immediately downloading each new version, reporting (and occasionally fixing) bugs. For a while when I was working at Sun in the late 90s, Bram and I had an ongoing email dialog.

My career path has never really allowed me to significantly work on open source, so I never really made the transition to a major contributor. Many years ago, vim hit peak feature set for me, so I didn't really need to track its development - the version bundled on my work desktop would always suffice and I'd download a new version at home whenever I changed out my home Windows PC. Other than that, I lost track of the community.

When I came to Google, I was tickled to find out that Bram worked here, though I never reached out to him personally. Before I knew it, he had retired, and I lost that chance.

For over 25 years, I have only ever used vim as my editor - at home or at work. It is the most dependable tool in my box, traveling with me through multiple employers and programming languages.

RIP Bram.

Roughly 10 years ago, I was working for a startup that offered a live conversational video service where you could also have hundreds (or eventually, thousands) of near-live watchers - with recording and later playback. The founder pitched the service to news orgs and celebrities. Anderson Cooper had a regular "show" there for a while, and we had a number of interviews with mostly 2nd-tier celebrities.

When the service started, they made the decision to not actually delete any content (delete just set a flag which disabled the content but didn't actually remove it).

Fast forward a year or so, and it became clear that a real delete was needed. So they had a junior engineer write up a sort of delayed sweep - delete all the videos with the delete flag set. But then, for some reason, they decided put the implementation behind a delay. Something like "actually delete all soft-deleted videos, but don't start doing it until 30 days from now". However, unbeknownst to the team, there was a bug in the implementation that deleted everything, regardless of whether the 'delete' flag was set.

So one night, roughly a month later, all the content started disappearing from the site. One guy heroically tried to stop the process, but I think he was too late. The engineering director happened to be on a vacation down in South America somewhere and I think the founder fired him in a fit of pique. I managed to reclaim a small bit of content (basically the videos that were cached on the actual recording servers before they were uploaded to S3).

You can imagine the technical over-reaction:

  * Delete switched back to a soft delete
  * Turned on S3 object versioning
  * Started redundantly copying content onto a totally different hosting service

This was fine (hah!) until we had to start taking down the inevitable child porn that always shows up on services like this - I got stuck with writing the takedown code and it took me forever to track down all the various tendrils of stuff.

As you might expect, we lost a ton of users over mass content deletion and the service never really rebounded. The company held on for a couple more years, pivoting a couple of times, but eventually folded.

When I started college, all of our classes would assign a temporary (semester-long) account on one of the various Vax 11/780s supplied by the computing center.

Talk wasn't available yet (pretty sure we were on 4.1 BSD), so we'd use write(1) to communicate to each other (e.g., to figure out where someone was sitting in the lab). To block someone from writing to you (often desired, because write(1) would just spew over whatever you were currently looking at), you'd use the "mesg" command, which our University set as default to 'y'. I figured out that running 'mesg y' effectively just gave open write permission to your tty.

With that knowledge in hand, I started a practical joke where I'd remap someone's keys by redirecting an stty command to their tty, e.g.:

  % stty erase e > /dev/tty03

which would make 'e' the backspace key for the duration of their terminal session. Much hilarity ensued.

There is no way that New York style pizza can be compared to Focaccia. They have almost nothing in common. Now that Chicago thing, maybe. But as far as I'm concerned, that's not pizza.

I don't think this is a "SV techbro" thing. In the 80s (when I was in college), "hacker" had a connotation of someone who built cool things in software, usually outside the "normal" approach. It was sort of the opposite of what eventually became software engineering - quick and dirty "tricks" that explored the edges of operating system. We looked up to hackers as repositories of esoteric knowledge. Long hair and hiking boots were common.

Certainly, some of what they hacked on might be related to security. Or maybe they wrote little games. Or threw together a curses-based interface to the Unix shell. Or some other cool utility.

As I recall, there was a concerted attempt to distinguish between people who exploited security vulnerabilities (aka "crackers") from people who could quickly build these useful things ("hackers").

I feel like the modern use of hacker (ala "hackathon") is actually pretty well in line with the usage I grew up with.

Atherton is a bit of a weird case and seems to derive its land values almost exclusively from lot size (and maybe inertia?). The peninsula in general tends towards low density and high property values and Atherton is just really on one end of the spectrum. However, it doesn't have something like walking distance to downtown Palo Alto or the views of Saratoga, Los Altos Hills, or Belmont. It has... big lots. With big houses. I honestly have no idea why it is so coveted.

The philosophy at Google is that the hiring bar is high enough that anyone who passes it should theoretically be able to fill any open position at their level. This is somewhat less true for higher levels, but it is also much harder to pass the bar at those levels. There are typically a lot of unfilled positions, because there just aren't enough people who pass the hiring bar (so there is plenty of demand for people).

You don't really expect any new hire SWE to be able to do the job on day 1 - Google has so much bespoke internal technology that it takes months to become productive. So the fit conversations aren't really just another round of interviews - they are more of a "mutual fit" assessment (interests and background). Often it's more of a sales pitch ("here's why you should join our team").

I'll take a slightly more nuanced position than a peer poster and say this is "mostly wrong" and somewhat backwards.

(I've been out of this area for a few years, so my perspective might be a little dated, but I doubt it has changed that much)

Pilots aren't simply "selected". You have to get through multiple gates to become a pilot in the USAF. Most of those gates involve demonstrating some degree of devotion and/or skill at flying (for example, having a private pilot's license before competing for a pilot slot is a really good idea).

Having said this, pilots for the most part either end up in combat roles (e.g., fighters, etc.) or in leadership roles (as in, you have a whole crew you for which you are responsible). Furthermore, pilots are officers and all officers are expected to be effective leaders. So sure, leadership qualities are one of the things you look for - because you look for them in all your officer candidates. Now, you may not agree with the personality traits identified as leadership traits. In general, it is true that the military tends to favor personality traits over management skills (the argument being that management skills can be learned, but some innate personality traits cannot). They judge that things like "likeability" and "ability to get others to trust and follow you" matter.

And here comes the backwards part. General officers are selected for their perceived ability to understand the mission of the USAF and move it forwards. This requires leadership skills and so is biased towards those with those skills. But there is also a general belief that the people who have most directly been involved in executing that mission are the people who are best positioned to lead that mission. In this case, being a "rated" officer (this used to be pilot/navigator/missile launch officer, but now seems to include a couple of other designations) actually dramatically improves your chances to make O6+ (Colonel -> 4-star General). So it isn't that you are selected to be a pilot because they think you'd be a good General - they think you'd be a good General because you've been a pilot.

A final note - while all officer candidates are selected based on leadership skills, there are other factors that are also considered. For example, if you are competing for a technical slot, having a STEM degree is generally a requirement. But traditionally, the rated slots didn't have any particular educational requirements (other than a 4-year university degree). As a result, pilot candidates generally just have two things in common:

   * Those personality traits
   * A demonstrated commitment to become a pilot

Given this, I can see why the original comment was made. But to actually become a pilot, you have to demonstrate the ability to fly. The training is both rigorous and very expensive, and I'd seriously doubt they'd keep the system as is if it routinely produced "awful" pilots.

I'm obviously not Doreen, but I was a military brat and military myself and can relate some of what I saw. First off, there's a sense of impermanence to everything. Your best friend is often someone you will only know for ~3 years of your life. You have to meet people and become friendly with them quickly or you will have no social contacts outside your family.

If you were a military spouse, you may have had a job, but rarely a career. You move at the whim of your spouse's job (every few years) to places you don't control. You generally don't get to pick your neighbors or even your friends - you just adapt to the situation that constantly changes.

Spouses of military members that go on unaccompanied tours have it even worse. They are at home alone, often for months at a time. My anecdotal observations of Navy spouses, for example, was that cheating was a standard practice - not because the marriage was necessarily bad, but because they were so lonely. This is based on limited exposure (I was Air Force, both as a brat and active duty), so may not be as universally true as I observed.

This can all sound horrible, but it really wasn't. Just different. Different enough that sometimes it is hard to explain.

The issue isn't whether or not your character encoding is always a multiple of 8 bits. It is whether or not you can use standard (octet-focused) parsing functions to deal with those strings. This is what makes utf-8 "special". No byte of a utf-8 multibyte sequence will ever have a value < 127. So for most "syntactic" parsing problems, you can use standard C functions to deal with utf-8 strings - something that is not true with most other multibyte character encodings.

The comment about the 90's is simply not true. I've been a successful (e.g., getting paid) developer since the 80s and have never been in the Microsoft stack. With the exception of a small bit of VMS-hosted development in the 80s, everything I have done in my career has been hosted on some sort of Unix. And I'm not some outlier. Sun Microsystems dominated the 90s for problems of just about any scale beyond the small workgroup.

I make this point because many of us (both engineers and customers alike) pushed back hard against Microsoft. They actively fought against open standards and interoperability. We literally thought of them as the evil empire. Even as late as the mid 2000s, when I was at Yahoo and there was talk of a Microsoft acquisition, I would have quit rather than work at Microsoft.

Economics aside, changing that toxic culture is what I appreciate most about Nadella's time as CEO. He has (it appears) made Microsoft into a citizen.

You've already been voted down, so not sure how much I'd add to this, but...

Wanting to have an office outside the home doesn't mean you are trying to escape - it means you are trying to establish the conditions for maximizing your productivity. Where you can work uninterrupted for long stretches of time - and even when you are interrupted, it is likely less of a context switch than the various daily interactions, temptations, and chores that happen while at home.

On a tangential note - my major complaint about the currently popular "open office plan" setup is that it has flipped the productivity curve for me. I go into the office for all the team interactions. When I need to get work done, I work from home (and hope for a day of minimal interruptions).

Chiming in here to agree with the others. In particular, finding simple, understandable solutions to complex problems is highly valued at Google. Complex solutions are an anti-pattern.

And the comment about readability and testability is so far different from my experience that I have to wonder where the poster is getting their information. Google code reviews have to be among the most nit-picky I've ever seen in a 30+ year career, with serious attention to detail all the way down to punctuation in comments.

I also had a cat that went absolutely bananas for (especially ripe) cantaloupe. She could smell it across the house, would aggressively beg for it, and would purr the whole time she was eating it.

Not sure I understand your point here. You need to use your password manager credentials to autofill also (at least for 1Password). The only reason to copy/paste is if you don't think your password manager will put the right info into the right boxes.