25 ms·

I've been at Google for 3 years and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc). I think it's fantastic. The whole

I've been at Google for 3 years and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc). I think it's fantastic. The whole 120% thing is up to the individual: there have been times I've made it a 120%, and there are times when it's been just "take a friday off to work on other stuff". You end up getting less of your "job" done but my managers have always been supportive. It's been great for sanity: some weeks/months feel just, like, meetings and chore work. It's great having that one day a week to work on a rockstar feature request in some fun project. It's also cool to work on your dream projects without the luck/physical move/whatever to get on the actual team. (you can effectively work on anything since no project is going to say no to free headcount) It's also nice because it spreads your professional network in the directions you choose to spread it, rather than the more organic spread that your normal job entails (assuming luck and available are big drivers of where and which projects you "end up" working, rather than 100% your choice). So, maybe I don't work on project X today, but I can 20% on it and build up those connections, and later in my career I have a much better shot getting on the project. That agency is a nice feeling. So, as far as the employee happiness goes, I think it's fantastic.

serial_dev 6y ago
What is the company size where you think a 20% policy like this matters? Does it only make sense for large companies like Google? Thank you for your take on these questions, your answer would be very much appreciated.
- seangrogg 6y ago
  Having formerly worked on 20% projects at Google and now working at a small company, I'd say that 20% time can be valuable at any size. For smaller companies it's easy to essentially always have feature work which means never really having time for code health; anything that wasn't done right the first time will be hard pressed to justify getting done ever unless it's either breaking something or preventing features. 20% time can allow engineers to do something about issues they see and care about which could improve things for everyone else in a way "one more feature" may not.
  - edoceo 6y ago
    We do something like this: Maintenance Monday. The dev team is just working on the bits of code they think need it, cleanup, test case, formatting, all those little things - that have no direct customer facing value. And then we do a Feature Friday so folks can work on the fun new stuff (of their choice). It's all company project related tho - sometimes loosely - we don't yet have a business case for AR/VR or using templates on a Remarkable 2 - but maybe - and they are used to spread knowledge around the team
    - cosmodisk 6y ago
      Where can I apply?
  - randmeerkat 6y ago
    I’m curious what motivated you to leave a big tech company for a small one?
  - lupire 6y ago
    That's not "20% time" that's "normal engineering not in crunch time".
- Spooky23 6y ago
  It definitely has more impact imo in organizations that tend to specialize and get too big to known everyone. I worked in a larger technology/shared services team where the execs set an expectation of “no email Friday” policy and encouraged peer learning and training on Friday afternoons. It wasn’t 100% effective, but helped establish a personal development culture, got SMEs talking outside their “turf” and sparked a few good projects and staff transitions. (We discovered we had a change management guy who was passionate about kubernetes)
- deklerk 6y ago
  I imagine it's not appropriate for startups, since they're burning money fast and mental health appppears to be less of a priority? I've not worked at one, so hard to say. Besides startups, I think it's fair play at companies of all sizes. Employees are the most important thing to companies, and the overhead of losing trained, context-carrying talent tends to be heavy. So, why not let them fulfill that scratch and keep them at your company. I've seen some companies allow 20% on any team within the company (rather than any project whatsoever): that could be a nice middleground for a company that is unsure about the whole thing.
  - kk__ 6y ago
    Twitch was basically a 20% project at justin.tv. Let smart people do what they want.
    - dontTango 6y ago
      At my last Engineering job, I would spend slow time working on job automation. That was until my boss flipped his shit one day and wanted me to memorize a bunch of shit in my down time. So instead of automating 6 figure Engineering jobs, I did what everyone else does on their slow Time. Facebook!
    - paulryanrogers 6y ago
      Survivorship bias could be at play. I'm a fan of 20% time. Though I think we'd need more data than some anecdotes to draw broad conclusions.
      - kergonath 6y ago
        It can be good for your engineers’ sanity even if it does not end up a unicorn, though.
    - kd5bjo 6y ago
      Not really; the consensus view within the company was that the justin.tv website wasn’t long-term sustainable and the company needed a narrower focus. There were three segments with sizeable viewer counts at the time: sports, video games, and social streams. The people streaming sports probably didn’t have the necessary permission from the copyright holders, so that was only possible through the DMCA safe-harbor provisions; obtaining the rights ourselves didn’t appear to be a viable option. The entire company basically split into two divisions: the social division turned into SocialCam, which had some moderate success, and the gaming division turned into Twitch.
- oillio 6y ago
  I don't really understand the focus on the 20% thing. I have worked at different sized tech companies, from startup to medium sized, to giant. And I have worked in several capacities, from line engineer, to middle manager, to director. In my experience, it is impossible to measure an engineers performance with an error less than +/- 20%. I have worked on side projects that large and my manager never noticed until I demo'd the results. Generally, if your manager is not shit and not under unusual time pressure, they should have no problem with a project that doesn't significantly impact the primary work and has some chance of benefiting the company. Google is interesting as they have an explicit 20% policy, but in practice it doesn't really matter one way or another.
- fredophile 6y ago
  Where I work we don't get 20% but we do get 1 day a month (so about 5%). We're a lot smaller than Google. When I first started with the company I used the time to gain experience using the products we make. That gave me more insight into our user's perspectives and paid dividends in future tasks like bug fixing. Sometimes people use the time for small things that they want to add but aren't important enough to be scheduled. I work with people that are passionate about what we do so it's nice to be able to make improvements in the spots we care about. Sometimes people will use the time to throw together a proof of concept for a bigger feature. The real feature might take months to get working to the point where it is stable and polished enough for an end user but you can get a lot of management buy in if you have something tangible that can show people what the feature could do.
- Leherenn 6y ago
  We used to do it at my previous company, maybe 30-40 engineers, but only 10%. It didn't really work, in the sense that no project went anywhere. Based on the feedback here, it seems to work if you can contribute to external projects, where it's easier to add marginal value. In our case, everyone worked on the same project, so it was either develop some new features for the existing project, or create something brand new. We would develop some POC, and every time the answer by management was "that's cool, but we don't have the resources to polish it up/bring it to market and it's low priority". It was pretty depressing to me.
cbb330 6y ago
How do the teams working full time on a project onboard contributors who are doing it with their 20% time? Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
- teen 6y ago
  you only hire 1-2 for your team, and it's a longer term commitment
- pcl 6y ago
  I think it's incredibly healthy to encourage that sort of "visitor" committers in an enterprise codebase, for a couple of reasons. The problems of getting an existing employee up to speed with the codebase are a subset of what you need to do to get a new hire up and running. And so you really should have a decent story for this regardless. And culturally, it's super-valuable to have a certain percentage of visitors, since it helps break down the silos, one commit at a time. The counterpoints, of course, are that no team really wants to have to maintain a bunch of crap written by someone who's moved on after a quick stab at something, and it sorta sucks for the sustaining team if all the "rockstar feature requests" (as the GP put it so succinctly) are picked up by folks in their 20% time. The former can be mitigated with a good model for managing incoming pull requests, in my experience. The latter is a tougher nut to crack.
- singron 6y ago
  Particularly at Google, programming languages, code styles, common libraries, and tools are incredibly similar between teams. There are really low barriers to jumping into someone else's codebase. It's not uncommon to review changes to your team's codebase from people you have never met (on average, maybe weekly?). Anecdotally I also think a lot of code was generally really well documented. There is some effort to document things for a general Googler audience (i.e. you should understand most of the documentation on any given page without having to read all the other docs). All in all, once you have onboarded into the Google ecosystem, it's fairly painless to jump around the codebase.
- amf12 6y ago
joshuamorton 6y ago
Similar experience. I 20% on python...things. some python tooling, python3 was a major one, etc. I backed off recently just because most things I was involved in are wrapping up, but yeah, it was an active area for me. And also I am sort of 20%ing on my own project that is greenfield tooling with only dubious management support. It's given me exposure to lots of stuff, I've learned more about a favorite language, met some cool people, etc. Not to mention earned a handful of bonuses directly related to my 20% work. There's also now done tech debt reduction work that I've been tangential to that's clearly a value add, and it's primarily 20%ers.
ma2rten 6y ago
The myth that 20% time is dead was started by mchurch. He was at Google for six month and was let go. He then went on to bad mouth the company here and elsewhere online. 20% time at Google exists and managers are supposed to adjust the workload - it's not supposed to be 120% time. That said I think it would be hard (but not impossible) to a launch a 20% project to external users that doesn't have people working on it full-time.
- wpietri 6y ago
  And who was later banned at HN: https://news.ycombinator.com/item?id=10019003 https://news.ycombinator.com/item?id=10019003
  - grenoire 6y ago
    (I love dang.)
  - ikiris 6y ago
    Wow I had no idea that happened. Thanks for posting this for context.
  - nunez 6y ago
    Wow; good job, dang! mchurch is a poison to the tech community; sucks since he’s such a good writer :(
  - kortilla 6y ago
    Well Marissa Mayer also said 20% realistically didn’t exist at Google, and she’s the one he insulted to get banned.
  - fergie 6y ago
    It was a shame that he overstepped the mark that one time, because he had a lot of sensible and deeply insightful things to say. He is literally one of the best essayists in tech.
- deleted 6y ago
  [deleted]
alacombe 6y ago
> and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc). All Google related projects.
- forbiddenvoid 6y ago
  The point of 20% time is to work on things that help Google as a company. Not sure what your point is here. It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
  - alacombe 6y ago
    My compensation for 100% of my time, if my company want me to go above that, I expect to be paid for it. I guess you're just working for free then...
    - marksomnian 6y ago
      I really don't get what you're saying here. You get paid for 100% of your time, you just get to work on something beyond your direct responsibilities that still benefits Google for 20% of it. If you're alluding to "120% time", fair enough, but that's not what GP was referring to.
      - alacombe 6y ago
        > If you're alluding to "120% time", fair enough, but that's not what GP was referring to. From other comments, it's obvious that 1) Google expects you to do your 100%, and then a 20% on top of that of "Google related projects", most likely owned by Google, for free.
        wtracy 6y ago
        I've never ever heard of that actually becoming a requirement. What happens is that some managers really don't buy into the 20% concept, and don't provide time for it. Employees in those teams determined to do it anyway end up doing 120%. There is absolutely no requirement at Google to put in time on a 20% project. That said, what happens in practice is that 20% projects are the way that Google engineers are able to move across teams: You pick a team you want to join. You do something for that team as your 20% project with the goal of getting that manager to request your transfer to their team. So if you're desperate to get off your team without quitting Google, you could get backed into committing 120%.
swyx 6y ago
(OP here) i think thats great! :) i guess I was asking this because I've never worked at Google and wondered about any downsides - e.g. distraction (the 20% project would seem to be the "cool" project, which makes the 80% boring) or politics (could be anything from jockeying for position on a hot 20% project or something else I can't even imagine because humans are petty)
robswc 6y ago
Wondered if I could ask... is Google a relatively normal place to work? I currently do my own thing but I would love to work on projects that go far due to the amount of talent involved... but at the end of the day I'm just concerned with "office politics" I get the vibe that you have to "pick sides" which might just be an availability bias due to the news stories. I guess just relatively speaking, when talking with Amazon I get a different feeling. Recruiters probably aren't the best way to judge a company though, so figured I'd ask.
- esc_colon_q 6y ago
  It's fairly normal for a big company these days: extremely slow pace, red tape all over the place, your level matters more than your skill. It's an engineering-led culture so there's a lot of focus on code nitpicking and purity (arguments over whether mocks are evil, etc). Great place to work if you're high level (5+) and land on a good team with a good manager. Mind numbingly boring if not.
  - lupire 6y ago
    There's no argument over it Mocks are evil.
    - decentusername 6y ago
      This is a vast oversimplification of mocks. Mocks themselves aren't evil, they just enable subpar programming. I'd much rather spend 2 minutes making a functional test with a mock than 2 days rewriting a bunch of core functionality in the name of code purity.
    - esc_colon_q 6y ago
      Evil enough that new mocks should be banned by fiat and enforced by code that requires rarely granted permission to override against projects that are 5 years old and already have hundreds of them in place and do not have architectures that support better ways of testing? It might be a nice thing to avoid them, but you're always working with legacy code, and I've literally had "I need to add a button to accept new permissions" blow up into "I need to refactor our entire class structure across 200 files because I'm not allowed to add a new test that follows our old patterns nor commit this code without coverage, and oh yeah, nobody wants to review that CL in one go so I have to figure out how to break it into 20 bite sized changes. There goes my quarter...". That's just dumb, and that type of dumb is very fashionable at Google.
rossjudson 6y ago
I think of 20% time as error correction for management. Engineers can route 20% of their time to what they think is important, and not what management thinks. Nobody from management told me to rewrite the primitive array handling in the proto libraries for Java. It just irritated me that they didn't do what I thought they should, so I spent some time fixing it.
- mikelward 6y ago
  In my experience, 20% time is something that has management blessing. Otherwise it's just a risky side project where you're still accountable for 100% on your main assignment.
ffggvv 6y ago
thats great it exists for you but having worked there a while and known dozens of other googlers, ive never met anyone else who worked on one. so for a lot of people it doesnt exist.
watermelon59 6y ago
Do you have total freedom in how you use 20% time, or do you have to plan it out and tell your manager exactly what you're working on? My company tried doing the 20% thing but they put so much process around it that no one does it.

serial_dev 6y ago

What is the company size where you think a 20% policy like this matters? Does it only make sense for large companies like Google? Thank you for your take on these questions, your answer would be very much appreciated.

seangrogg 6y ago
Having formerly worked on 20% projects at Google and now working at a small company, I'd say that 20% time can be valuable at any size. For smaller companies it's easy to essentially always have feature work which means never really having time for code health; anything that wasn't done right the first time will be hard pressed to justify getting done ever unless it's either breaking something or preventing features. 20% time can allow engineers to do something about issues they see and care about which could improve things for everyone else in a way "one more feature" may not.
- edoceo 6y ago
  We do something like this: Maintenance Monday. The dev team is just working on the bits of code they think need it, cleanup, test case, formatting, all those little things - that have no direct customer facing value. And then we do a Feature Friday so folks can work on the fun new stuff (of their choice). It's all company project related tho - sometimes loosely - we don't yet have a business case for AR/VR or using templates on a Remarkable 2 - but maybe - and they are used to spread knowledge around the team
  - cosmodisk 6y ago
    Where can I apply?
- randmeerkat 6y ago
  I’m curious what motivated you to leave a big tech company for a small one?
- lupire 6y ago
  That's not "20% time" that's "normal engineering not in crunch time".
Spooky23 6y ago
It definitely has more impact imo in organizations that tend to specialize and get too big to known everyone. I worked in a larger technology/shared services team where the execs set an expectation of “no email Friday” policy and encouraged peer learning and training on Friday afternoons. It wasn’t 100% effective, but helped establish a personal development culture, got SMEs talking outside their “turf” and sparked a few good projects and staff transitions. (We discovered we had a change management guy who was passionate about kubernetes)
deklerk 6y ago
I imagine it's not appropriate for startups, since they're burning money fast and mental health appppears to be less of a priority? I've not worked at one, so hard to say. Besides startups, I think it's fair play at companies of all sizes. Employees are the most important thing to companies, and the overhead of losing trained, context-carrying talent tends to be heavy. So, why not let them fulfill that scratch and keep them at your company. I've seen some companies allow 20% on any team within the company (rather than any project whatsoever): that could be a nice middleground for a company that is unsure about the whole thing.
- kk__ 6y ago
  Twitch was basically a 20% project at justin.tv. Let smart people do what they want.
  - dontTango 6y ago
    At my last Engineering job, I would spend slow time working on job automation. That was until my boss flipped his shit one day and wanted me to memorize a bunch of shit in my down time. So instead of automating 6 figure Engineering jobs, I did what everyone else does on their slow Time. Facebook!
  - paulryanrogers 6y ago
    Survivorship bias could be at play. I'm a fan of 20% time. Though I think we'd need more data than some anecdotes to draw broad conclusions.
    - kergonath 6y ago
      It can be good for your engineers’ sanity even if it does not end up a unicorn, though.
  - kd5bjo 6y ago
    Not really; the consensus view within the company was that the justin.tv website wasn’t long-term sustainable and the company needed a narrower focus. There were three segments with sizeable viewer counts at the time: sports, video games, and social streams. The people streaming sports probably didn’t have the necessary permission from the copyright holders, so that was only possible through the DMCA safe-harbor provisions; obtaining the rights ourselves didn’t appear to be a viable option. The entire company basically split into two divisions: the social division turned into SocialCam, which had some moderate success, and the gaming division turned into Twitch.
oillio 6y ago
I don't really understand the focus on the 20% thing. I have worked at different sized tech companies, from startup to medium sized, to giant. And I have worked in several capacities, from line engineer, to middle manager, to director. In my experience, it is impossible to measure an engineers performance with an error less than +/- 20%. I have worked on side projects that large and my manager never noticed until I demo'd the results. Generally, if your manager is not shit and not under unusual time pressure, they should have no problem with a project that doesn't significantly impact the primary work and has some chance of benefiting the company. Google is interesting as they have an explicit 20% policy, but in practice it doesn't really matter one way or another.
fredophile 6y ago
Where I work we don't get 20% but we do get 1 day a month (so about 5%). We're a lot smaller than Google. When I first started with the company I used the time to gain experience using the products we make. That gave me more insight into our user's perspectives and paid dividends in future tasks like bug fixing. Sometimes people use the time for small things that they want to add but aren't important enough to be scheduled. I work with people that are passionate about what we do so it's nice to be able to make improvements in the spots we care about. Sometimes people will use the time to throw together a proof of concept for a bigger feature. The real feature might take months to get working to the point where it is stable and polished enough for an end user but you can get a lot of management buy in if you have something tangible that can show people what the feature could do.
Leherenn 6y ago
We used to do it at my previous company, maybe 30-40 engineers, but only 10%. It didn't really work, in the sense that no project went anywhere. Based on the feedback here, it seems to work if you can contribute to external projects, where it's easier to add marginal value. In our case, everyone worked on the same project, so it was either develop some new features for the existing project, or create something brand new. We would develop some POC, and every time the answer by management was "that's cool, but we don't have the resources to polish it up/bring it to market and it's low priority". It was pretty depressing to me.

cbb330 6y ago

How do the teams working full time on a project onboard contributors who are doing it with their 20% time? Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.

teen 6y ago
you only hire 1-2 for your team, and it's a longer term commitment
pcl 6y ago
I think it's incredibly healthy to encourage that sort of "visitor" committers in an enterprise codebase, for a couple of reasons. The problems of getting an existing employee up to speed with the codebase are a subset of what you need to do to get a new hire up and running. And so you really should have a decent story for this regardless. And culturally, it's super-valuable to have a certain percentage of visitors, since it helps break down the silos, one commit at a time. The counterpoints, of course, are that no team really wants to have to maintain a bunch of crap written by someone who's moved on after a quick stab at something, and it sorta sucks for the sustaining team if all the "rockstar feature requests" (as the GP put it so succinctly) are picked up by folks in their 20% time. The former can be mitigated with a good model for managing incoming pull requests, in my experience. The latter is a tougher nut to crack.
singron 6y ago
Particularly at Google, programming languages, code styles, common libraries, and tools are incredibly similar between teams. There are really low barriers to jumping into someone else's codebase. It's not uncommon to review changes to your team's codebase from people you have never met (on average, maybe weekly?). Anecdotally I also think a lot of code was generally really well documented. There is some effort to document things for a general Googler audience (i.e. you should understand most of the documentation on any given page without having to read all the other docs). All in all, once you have onboarded into the Google ecosystem, it's fairly painless to jump around the codebase.
amf12 6y ago

joshuamorton 6y ago

Similar experience. I 20% on python...things. some python tooling, python3 was a major one, etc. I backed off recently just because most things I was involved in are wrapping up, but yeah, it was an active area for me. And also I am sort of 20%ing on my own project that is greenfield tooling with only dubious management support. It's given me exposure to lots of stuff, I've learned more about a favorite language, met some cool people, etc. Not to mention earned a handful of bonuses directly related to my 20% work. There's also now done tech debt reduction work that I've been tangential to that's clearly a value add, and it's primarily 20%ers.

ma2rten 6y ago

The myth that 20% time is dead was started by mchurch. He was at Google for six month and was let go. He then went on to bad mouth the company here and elsewhere online. 20% time at Google exists and managers are supposed to adjust the workload - it's not supposed to be 120% time. That said I think it would be hard (but not impossible) to a launch a 20% project to external users that doesn't have people working on it full-time.

wpietri 6y ago
And who was later banned at HN: https://news.ycombinator.com/item?id=10019003 https://news.ycombinator.com/item?id=10019003
- grenoire 6y ago
  (I love dang.)
- ikiris 6y ago
  Wow I had no idea that happened. Thanks for posting this for context.
- nunez 6y ago
  Wow; good job, dang! mchurch is a poison to the tech community; sucks since he’s such a good writer :(
- kortilla 6y ago
  Well Marissa Mayer also said 20% realistically didn’t exist at Google, and she’s the one he insulted to get banned.
- fergie 6y ago
  It was a shame that he overstepped the mark that one time, because he had a lot of sensible and deeply insightful things to say. He is literally one of the best essayists in tech.
deleted 6y ago
[deleted]

alacombe 6y ago

> and have 20%ed the entire time I've been there on: grpc-go, Drive, and Go tools (gopls, etc). All Google related projects.

forbiddenvoid 6y ago
The point of 20% time is to work on things that help Google as a company. Not sure what your point is here. It's not intended to just be using 20% of your work time to work on whatever the heck you want to.
- alacombe 6y ago
  My compensation for 100% of my time, if my company want me to go above that, I expect to be paid for it. I guess you're just working for free then...
  - marksomnian 6y ago
    I really don't get what you're saying here. You get paid for 100% of your time, you just get to work on something beyond your direct responsibilities that still benefits Google for 20% of it. If you're alluding to "120% time", fair enough, but that's not what GP was referring to.
    - alacombe 6y ago
      > If you're alluding to "120% time", fair enough, but that's not what GP was referring to. From other comments, it's obvious that 1) Google expects you to do your 100%, and then a 20% on top of that of "Google related projects", most likely owned by Google, for free.
      - wtracy 6y ago
        I've never ever heard of that actually becoming a requirement. What happens is that some managers really don't buy into the 20% concept, and don't provide time for it. Employees in those teams determined to do it anyway end up doing 120%. There is absolutely no requirement at Google to put in time on a 20% project. That said, what happens in practice is that 20% projects are the way that Google engineers are able to move across teams: You pick a team you want to join. You do something for that team as your 20% project with the goal of getting that manager to request your transfer to their team. So if you're desperate to get off your team without quitting Google, you could get backed into committing 120%.

swyx 6y ago

(OP here) i think thats great! :) i guess I was asking this because I've never worked at Google and wondered about any downsides - e.g. distraction (the 20% project would seem to be the "cool" project, which makes the 80% boring) or politics (could be anything from jockeying for position on a hot 20% project or something else I can't even imagine because humans are petty)

robswc 6y ago

Wondered if I could ask... is Google a relatively normal place to work? I currently do my own thing but I would love to work on projects that go far due to the amount of talent involved... but at the end of the day I'm just concerned with "office politics" I get the vibe that you have to "pick sides" which might just be an availability bias due to the news stories. I guess just relatively speaking, when talking with Amazon I get a different feeling. Recruiters probably aren't the best way to judge a company though, so figured I'd ask.

esc_colon_q 6y ago
It's fairly normal for a big company these days: extremely slow pace, red tape all over the place, your level matters more than your skill. It's an engineering-led culture so there's a lot of focus on code nitpicking and purity (arguments over whether mocks are evil, etc). Great place to work if you're high level (5+) and land on a good team with a good manager. Mind numbingly boring if not.
- lupire 6y ago
  There's no argument over it Mocks are evil.
  - decentusername 6y ago
    This is a vast oversimplification of mocks. Mocks themselves aren't evil, they just enable subpar programming. I'd much rather spend 2 minutes making a functional test with a mock than 2 days rewriting a bunch of core functionality in the name of code purity.
  - esc_colon_q 6y ago
    Evil enough that new mocks should be banned by fiat and enforced by code that requires rarely granted permission to override against projects that are 5 years old and already have hundreds of them in place and do not have architectures that support better ways of testing? It might be a nice thing to avoid them, but you're always working with legacy code, and I've literally had "I need to add a button to accept new permissions" blow up into "I need to refactor our entire class structure across 200 files because I'm not allowed to add a new test that follows our old patterns nor commit this code without coverage, and oh yeah, nobody wants to review that CL in one go so I have to figure out how to break it into 20 bite sized changes. There goes my quarter...". That's just dumb, and that type of dumb is very fashionable at Google.

rossjudson 6y ago

I think of 20% time as error correction for management. Engineers can route 20% of their time to what they think is important, and not what management thinks. Nobody from management told me to rewrite the primitive array handling in the proto libraries for Java. It just irritated me that they didn't do what I thought they should, so I spent some time fixing it.

mikelward 6y ago
In my experience, 20% time is something that has management blessing. Otherwise it's just a risky side project where you're still accountable for 100% on your main assignment.

ffggvv 6y ago

thats great it exists for you but having worked there a while and known dozens of other googlers, ive never met anyone else who worked on one. so for a lot of people it doesnt exist.

watermelon59 6y ago

Do you have total freedom in how you use 20% time, or do you have to plan it out and tell your manager exactly what you're working on? My company tried doing the 20% thing but they put so much process around it that no one does it.