4 ms·

> It's easy to move. There is no pay difference no matter what project you work on and internal mobility is encouraged and supported. People do what they want t

by asark 7y ago

> It's easy to move. There is no pay difference no matter what project you work on and internal mobility is encouraged and supported. People do what they want to do, and they tend to be extremely motivated as a result. It also helps remove bad managers: sinking ships get abandoned really, really fast. This is arguably the company's greatest weakness as well as it's hard to get people to work on something soul-consuming. But it's great for the employees and it's great for innovation. This is clearly both necessary if they want to retain their "all our people are among the best (and therefore have lots of options if they want to leave)" workforce and harmful to their projects. There's plain flakiness to their approach to things that's at this point a distinguishing characteristic of Google products. Even things that stick around long-term and don't get cancelled outright show heavy signs of no-one wanting to do the boring work, and no-one making them do it. Or of half-assing the boring work and then never fixing it.

lumost 7y ago
There is a really strong counter-argument to this that "the boring work" doesn't really matter in the long-run. I've seen many great projects sink over time because management over-indexes on easily understood, time consuming efforts, with only marginal customer impact. These efforts are easy to justify quarter on quarter - but are incredibly generic. Great big products tend to emerge from driving repeatable improvements in something everyone needs e.g. search, content, recommendations, servers, networks, data etc. and solving the hard problems that no one else has the dedication to solve.
- Moru 7y ago
  The problem arises when you as developer rely on this thing that Google invented but suddenly got bored of and shut down or changed a lot so your implementation has to be rewritten. Many have been hit by this over the years so are reluctant to try again.
  - WanderPanda 7y ago
    There are counterexamples, though: https://news.ycombinator.com/item?id=16347083 https://news.ycombinator.com/item?id=16347083
    - scarface74 7y ago
      As of last year, the last time I tried, the Google backed maps app still works on my first gen iPod Touch - last updated in 2009 and the first gen iPad.
  - jkoudys 7y ago
    I've been hit by this at least a half dozen times over my career. Apps scripts are probably the latest one causing me pain. I love being able to integrate with docs & sheets, but man if that ecma version isn't ancient af.
    - deathanatos 7y ago
      > man if that ecma version isn't ancient af. It is incredibly ancient. It's possible to use Babel w/ it though, and write reasonably modern JS. There's a CLI tool out there to upload something into an Apps Script … app? too; at one point, I had a project w/ a Makefile that would run the project through Babel and then upload it to Google. I didn't try all the features (and I didn't have any npm/package management), but things like format strings, for(… of …) loops, let/const, new Map() all worked. Babel is a wonderful, wonderful thing.
      - jkoudys 7y ago
        If it were simply ancient, that'd be one thing, but it's a weird hybrid of es3 with _some_ es5 features, and some es6 ones that often don't work the same. e.g. it has `const`, but no `let`, and it's not even block scoped so it's not that useful. Destructuring is there, but for arrays only and not object properties. I built my babel config to balance clean, new syntax with the least intrusive transforms possible. e.g. I have loose template literals on, since `\`hello ${world}!\`` is an easy transform (and still readable in the final source) as `'hello ' + world + '!'`. Generators, for .. of, and object rest/spread, are okay, but babel puts a ridiculous amount of helper functions at the top to support this. I suppose I could always configure each project with a shim file, but that's extra overhead I really could do without. block-scoping, arrow-functions, function-name, shorthand-properties, spread (for arrays and arguments), template-literals (loose, so `+` not `String#concat`), and exponentiation-operator I found give the most bang for your buck. `for .. of` is nice but if I can pass arrow functions into my `forEach` callbacks that's pretty clean too. Pretty great being able to say ``` rows.forEach(row => { const payload = row.map(([name, rank, serialNo]) => ({ name, rank, serialNo })); SomeApi.doThing({ onComplete() { foo(); }, payload, }); }); ``` in gapps. That said, it took a while to even figure out how much was possible, but yeah it's a big step up.
skybrian 7y ago
This is leaving out the effect of headcount restrictions, which is how management keeps overall control over what gets worked on. Sometimes there are legacy projects that have headcount but trouble filling it. But sadly, sometimes there are people who do want to work on some important maintenance project, but they can't get headcount. So, it may be easy to move, but only in certain directions where management wants people to move. (Or see if you can make a case for increased headcount somehow. Being good at persuasion or having a manager who trusts you can work.)

by asark 7y ago

lumost 7y ago

There is a really strong counter-argument to this that "the boring work" doesn't really matter in the long-run. I've seen many great projects sink over time because management over-indexes on easily understood, time consuming efforts, with only marginal customer impact. These efforts are easy to justify quarter on quarter - but are incredibly generic. Great big products tend to emerge from driving repeatable improvements in something everyone needs e.g. search, content, recommendations, servers, networks, data etc. and solving the hard problems that no one else has the dedication to solve.

Moru 7y ago
The problem arises when you as developer rely on this thing that Google invented but suddenly got bored of and shut down or changed a lot so your implementation has to be rewritten. Many have been hit by this over the years so are reluctant to try again.
- WanderPanda 7y ago
  There are counterexamples, though: https://news.ycombinator.com/item?id=16347083 https://news.ycombinator.com/item?id=16347083
  - scarface74 7y ago
    As of last year, the last time I tried, the Google backed maps app still works on my first gen iPod Touch - last updated in 2009 and the first gen iPad.
- jkoudys 7y ago
  I've been hit by this at least a half dozen times over my career. Apps scripts are probably the latest one causing me pain. I love being able to integrate with docs & sheets, but man if that ecma version isn't ancient af.
  - deathanatos 7y ago
    > man if that ecma version isn't ancient af. It is incredibly ancient. It's possible to use Babel w/ it though, and write reasonably modern JS. There's a CLI tool out there to upload something into an Apps Script … app? too; at one point, I had a project w/ a Makefile that would run the project through Babel and then upload it to Google. I didn't try all the features (and I didn't have any npm/package management), but things like format strings, for(… of …) loops, let/const, new Map() all worked. Babel is a wonderful, wonderful thing.
    - jkoudys 7y ago
      If it were simply ancient, that'd be one thing, but it's a weird hybrid of es3 with _some_ es5 features, and some es6 ones that often don't work the same. e.g. it has `const`, but no `let`, and it's not even block scoped so it's not that useful. Destructuring is there, but for arrays only and not object properties. I built my babel config to balance clean, new syntax with the least intrusive transforms possible. e.g. I have loose template literals on, since `\`hello ${world}!\`` is an easy transform (and still readable in the final source) as `'hello ' + world + '!'`. Generators, for .. of, and object rest/spread, are okay, but babel puts a ridiculous amount of helper functions at the top to support this. I suppose I could always configure each project with a shim file, but that's extra overhead I really could do without. block-scoping, arrow-functions, function-name, shorthand-properties, spread (for arrays and arguments), template-literals (loose, so `+` not `String#concat`), and exponentiation-operator I found give the most bang for your buck. `for .. of` is nice but if I can pass arrow functions into my `forEach` callbacks that's pretty clean too. Pretty great being able to say ``` rows.forEach(row => { const payload = row.map(([name, rank, serialNo]) => ({ name, rank, serialNo })); SomeApi.doThing({ onComplete() { foo(); }, payload, }); }); ``` in gapps. That said, it took a while to even figure out how much was possible, but yeah it's a big step up.

skybrian 7y ago

This is leaving out the effect of headcount restrictions, which is how management keeps overall control over what gets worked on. Sometimes there are legacy projects that have headcount but trouble filling it. But sadly, sometimes there are people who do want to work on some important maintenance project, but they can't get headcount. So, it may be easy to move, but only in certain directions where management wants people to move. (Or see if you can make a case for increased headcount somehow. Being good at persuasion or having a manager who trusts you can work.)