Haskell's aeson library, which is probably the most popular way to use JSON in that language, doesn't require any of this complexity or typecasting ugliness. It can derive a typechecking parser for a particular JSON format from an ordinary Haskell data type. Your type becomes a JSON schema, and as long as the JSON you're parsing conforms to that schema, the parsing just works with a single function call.
The problem you're pointing out is not a problem with statically typed languages. It's a problem with bad languages.
It seems like a superficial tabs-versus-spaces kind of point, but when you see how the standard library is organized and how package names interact with actual programs, you grok why underscores make people wince; "foo_bar" should either be "foo/bar", or just plain "bar".
The import statement at the top of the file can clarify what the origin of a package is, but in the program body itself, the package name should make the library feel as natural as "fmt" or "io" or "math".
It's common at Google to have a few projects cooking that you move between. One reason for this (though I doubt it's the sole reason) probably has to do with the mandatory peer review process for all code, which can cause delays in getting your code submitted if your reviewer's schedule doesn't line up well with your own. Instead of introducing a bubble into your pipeline when that happens, it's nice to have a side project you can hack on for a little while until you get your code review feedback.
How are deadlines managed in that environment? Sprint ends or release dates or just "we will do it by Tuesday" all conspire against peer review delays.
Is the frustration level a constant problem if reviews can take ... X longer than thought?
Well, you can always assign a different reviewer if your initial choice is taking too long. I usually try to check with my teammates to see who has time for a review before sending them my code, at least if it's something that I want to get submitted quickly. That ensures that I pick someone who will look at it sooner rather than later. Sometimes the specifics of the process require someone who is not on your immediate team to give their approval, in which case delays are more likely.
I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.
I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.
No, not TBR. I was referring to the fact that you can +2 your own CL, which allows it to be merged. Officially this is an "emergency" feature, as you say, but a dirty secret is that it's used routinely. I encountered it in both Android and Chrome.
I've seen lots of self-+2s under the following circumstances:
1. You are the only engineer on your team, or all other engineers on your team are out for an extended period of time.
2. All other engineers have very different skillsets, and are not capable of doing effective review. Think Rails engineer attempting to review a touchpad firmware fix.
3. You have a hard deadline (e.g. product demo or factory build) and you're desperately trying to get as much working as you can. You may even be in a location where coordination is difficult and Internet access is poor.
For SWEs working on, say, web services, you probably have at least a medium-sized team (4+ engineers) and a week's slip is no big deal. But not all software is like that at Google.
I'm not actually sure this works in... well, not Android and Chrome. I can TBR, but as far as I know I can't self-LGTM (and certainly not self-Approve).
He's a Tech Lead Manager, or TLM, which means he's an engineer who also manages the team he's a part of. In some cases, dev teams have SRE counterparts who take the pager responsibilities, among other things. But not all services at Google have SRE support, and for those that don't, the developers themselves are usually on call. That includes the dev team's TL, or TLM, as the case may be.
That's a shame, do we know why? is it just not finished being implemented? I found a page[0] that said at some point they had stalled on refactoring something.
That's a shame and the first I've heard of the delay. For me and the software that I write, this is a must have feature and I was very much looking forward to its release.
I believe it's intentional (for privacy/usability reasons), so that it's always clear which account's emails you are reading and which you are replying to.
I don't think it's a technical issue.
In general Google tends to keep accounts siloed, if for no other reason than that different accounts is the solution recommended to people who want to silo things.
Not really, given that you can quite easily filter emails that you receive from your other address. I use exactly this workflow and it's much more useful than having them in separate inboxes (i.e. doesn't "defeat the purpose").
I tried it and found I constantly was sending email from the wrong account. While that's on me, it was evident I was never going to get it right either, so I went back to separate accounts.
To do the trick, you have to add the account as "not an alias" (you will have to add the gmail smpt and so) and later, select the reply "Reply from the same address to which the message was sent".
I did that. It was remembering to switch the account when composing new messages. I ended up sending work emails from my personal account on a few occasions.
Just in case you didn't see it, and weren't just talking about composing new emails, there is an option in the settings to send replies from the account that received the email.
Thanks. That was a very handy feature. Alas, it was when composing new emails. I'm sure with more diligence it'll come as second nature. But when rapid firing through emails I'd sometimes send from the wrong account and end up in confusing and embarrassing situations.
Gmail on mobile (both Android and iOS) both handle multiple Gmail accounts gracefully (personal, google apps, etc). To merge them seamlessly in the interface would be trivial.
To my understanding, the future of "enterprise support" for Android is that you'll be able to install multiple copies of the same app and one will be personal and the other work.
This is how BlackBerry 10 devices handle the difference between personal and work applications. Al though, it's just one application running two instances with app data in two different locations.
