8 ms·

If it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too

If it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too.

jsemrau 9y ago
TIL.
xyzzyz 9y ago
It’s called “proto to proto” in google slang, and yes, googlers definitely complain that their jobs consist mostly of proto to proto work.
- oblio 9y ago
  "Protocol to protocol", I guess?
  - bhaavan 9y ago
    Protobuf to Protobuf.
  - dekhn 9y ago
    protocol buffer to protocol buffer. PBs are a foundational google tech, going back to pre-2000, that are used to store nearly all structured data at google. So, most applications are PB transformers (user request comes in, the user's proto is retrieved, the fields are accessed to produce a new record that is sent as a request to a backend, etc).
anonytrary 9y ago
Sounds lame.
- oblio 9y ago
  Sounds like real life. For every idea there's an awful lot of trench digging to do...
  - arbie 9y ago
    This. Even the coolest idea requires scaffolding. The larger/more novel the idea, the more (re)scaffolding needed.
    - anonytrary 9y ago
      Scaffolding sounds lame. I wonder how many engineers are treated this way at Google, implementing someone else's idea that is likely confined to the scope of the company. I mean, someone has to dig the trenches. "Working at Google" sounds overrated. I would hate to get employed at Google and then work on Google+ for ten years. Seriously? No one cares about Google+. You're a slave at Google, they are literally doing statistical experiments with your time. It is known, people turn down Google offers all the time to remain independent. Working for a big company doesn't give you a lot of freedom, unfortunately.
YeGoblynQueenne 9y ago
I don't know about google, but on my first proper job after graduating (the actual first lasted only two months) I was given a coding problem that involved writing a parser. After I got hired in the company I spent about seven months gluing APIs and adding one-liners etc, but in those seven months I once actually had to write a parser (for Tag-Length-Values). And in the seventh month, another engineer had a problem that was almost identical to my interview question- we were all gathered together around their monitor laughing about it. So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it. ... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.
- jjoonathan 9y ago
  I think the real value is in the ability to recognize the opportunity to apply an algorithm when it arises. You can't just look that up on stack overflow and the alternative is usually spending 10x as long to write a large logic hairball filled with bugs and missing edge cases. Apply another 10x multiplier for the maintenance. I've inherited enough of these (deeply nested code hairballs that can be replaced by a comparatively miniscule set of tree traversals or something) to change my view from "algo is just programmer status signalling" to "algo is a core competency that matters."
js8 9y ago
There is something wrong with our general approach to programming. Majority of "real" work is writing total functions (in the sense, non-recursive). Yet, we very much insist on using Turing-complete languages everywhere. I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion. This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things. This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled. (Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.) Interestingly, the interviews are very much based on TC language notions.

If it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too.

jsemrau 9y ago

TIL.

xyzzyz 9y ago

It’s called “proto to proto” in google slang, and yes, googlers definitely complain that their jobs consist mostly of proto to proto work.

oblio 9y ago
"Protocol to protocol", I guess?
- bhaavan 9y ago
  Protobuf to Protobuf.
- dekhn 9y ago
  protocol buffer to protocol buffer. PBs are a foundational google tech, going back to pre-2000, that are used to store nearly all structured data at google. So, most applications are PB transformers (user request comes in, the user's proto is retrieved, the fields are accessed to produce a new record that is sent as a request to a backend, etc).

anonytrary 9y ago

Sounds lame.

oblio 9y ago
Sounds like real life. For every idea there's an awful lot of trench digging to do...
- arbie 9y ago
  This. Even the coolest idea requires scaffolding. The larger/more novel the idea, the more (re)scaffolding needed.
  - anonytrary 9y ago
    Scaffolding sounds lame. I wonder how many engineers are treated this way at Google, implementing someone else's idea that is likely confined to the scope of the company. I mean, someone has to dig the trenches. "Working at Google" sounds overrated. I would hate to get employed at Google and then work on Google+ for ten years. Seriously? No one cares about Google+. You're a slave at Google, they are literally doing statistical experiments with your time. It is known, people turn down Google offers all the time to remain independent. Working for a big company doesn't give you a lot of freedom, unfortunately.

YeGoblynQueenne 9y ago

I don't know about google, but on my first proper job after graduating (the actual first lasted only two months) I was given a coding problem that involved writing a parser. After I got hired in the company I spent about seven months gluing APIs and adding one-liners etc, but in those seven months I once actually had to write a parser (for Tag-Length-Values). And in the seventh month, another engineer had a problem that was almost identical to my interview question- we were all gathered together around their monitor laughing about it. So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it. ... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.

jjoonathan 9y ago
I think the real value is in the ability to recognize the opportunity to apply an algorithm when it arises. You can't just look that up on stack overflow and the alternative is usually spending 10x as long to write a large logic hairball filled with bugs and missing edge cases. Apply another 10x multiplier for the maintenance. I've inherited enough of these (deeply nested code hairballs that can be replaced by a comparatively miniscule set of tree traversals or something) to change my view from "algo is just programmer status signalling" to "algo is a core competency that matters."

js8 9y ago

There is something wrong with our general approach to programming. Majority of "real" work is writing total functions (in the sense, non-recursive). Yet, we very much insist on using Turing-complete languages everywhere. I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion. This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things. This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled. (Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.) Interestingly, the interviews are very much based on TC language notions.