Freelancing and consulting. It's fun, pays decently well and is fully remote.
Left Google SRE because of how mentally draining it was, how draconian the IP clauses were (everything you create belongs to Google!), and how generally I didn't see a future for myself there.
Bottom line is that at least in California, employees theoretically have the right to IP developed in their own time on their own hardware, but in practice, there are numerous caveats, and litigation can be extremely risky.
One of the caveats is that the invention should not overlap with a company's "existing or anticipated line of business", and with the FAANGs being such behemoths, that can cover almost any form of software development.
Something that comes up in these discussions is the concept of “company time”.
Company resources is clear cut, but what is company time for a salaried employee? How does that change with being a remote employee?
I’ve moved to a strategic product role and honestly work less than an hour a day on average and seldom go into the office. If I decide to work on a side project does that restrict me from git commits between 8-5?
> Company resources is clear cut, but what is company time for a salaried employee?
Usually salary comes with an expectation of hours per week/month, and usually also comes with a software where you write down your hours, to track overtime, minus time, etc. So all the time you write down in that system, counts as companytime.
It depends what you do - I've always had to timesheet, but that's because I was working for clients, so we had to at the very least make sure we were estimating correctly, or, at my current job, that we're billing the hours I actually work.
It's not too onerous, since I only work for one client at a time, and time spent not at work is uncommon and usually in big chunks (e.g. an hour or two for a doctor's visit, days or weeks for vacation).
However, unlike many companies, they actually have a process where you can submit your "weekend projects" for Google to review and "gain back" explicit ownership of them.
Basically Google just checks to make sure it's not competing with anything Google's already doing, and then contractually assigns it back to you. (And anecdotally, if it does compete, you may be offered the opportunity to join said team, since it shows you're passionate about it.)
The assignment agreement took away all excitement I had coming to work for Google. It is so shitty. The two things I submitted to that process were rejected. I've kept on building stuff in my spare time (can't stop, won't stop), if they want to come after a side project that I made in my time, on my resources, with my ideas, and my code, that's their PR nightmare.
I cannot wait until I'm in a position to work on my own stuff full time.
It's also pretty easy to contribute to FOSS projects on your own time, as long as you're OK with Google being the owner of your contributions (I personally don't care since it's open source licensed anyway). https://opensource.google.com/docs/patching/ is an almost fully public version of the process Googlers have to follow to contribute stuff to open source projects.
Disclaimer: works at Google, maintains some FOSS code in my own time, both under my own copyright for some projects and under Google's copyright for others.
Have you encountered any project maintainers uneasy with the idea of Google "owning" that part of the source code? In practice it doesn't matter, but that part kind of confuses me.
This still kills the possibility of quickly collaborating with someone on a project in your free time. Any time you want to even start working on something together, you have to wait a couple of days for approval.
This simply doesn't work if you want to be active in a hackerspace or any other community where you iterate on projects quickly.
>This still kills the possibility of quickly collaborating with someone on a project in your free time. Any time you want to even start working on something together, you have to wait a couple of days for approval.
This depends on the project. If you and the project maintainer are ok with Google maintaining copyright over the code, there's a self-approval process that takes ~2 minutes.
And of course, that's only necessary if I'm working on the side project using company resources. If I'm not, I literally can't do the self-approval. There's only an issue if you want to maintain copyright should you want to monetize your product. Most hobby projects won't encounter those issues.
I heard from my Google friend that SRE besides the on-call stuff was procedural and had no deadlines. Could you elaborate on the mentally draining part?
At google there are SRE-SWEs and SRE-SysEng. An SRE-SWE has the same responsibilities as any SWE, but is expected to know SRE stuff. A SysEng is not expected to SWE as much, but they do both write software.
The main difference between SWE and SRE-SWE is that the latter pays better.
The message emitted as marketing to the outside world about SRE's is that they spend at least half their time writing code - improving monitoring, fault tolerance, recovery, etc. Because being called out of bed sucks.
If that's actually true is another question of course.
Left Google SRE because of how mentally draining it was, how draconian the IP clauses were (everything you create belongs to Google!), and how generally I didn't see a future for myself there.