A Decade at Google
wp.sigmod.org
wp.sigmod.org
You do not reach [work life] balance by reducing work. You reach balance by finding a passion that draws you out of work.
Or find something you like to do with your kids.
Regularly scheduled hobbies are the easiest to pull off. If you just try to find a spare hour, you never will.
Being upfront about it like that got me a lot of credit somehow. It was never a problem.
Also, when they were around 12, I was a partner in a consulting firm. So I could make my own hours. That definitely helped out during those years.
That said, I've definitely worked at companies that want to have their cake (in by 8:30 or 9) and eat it to (leave no earlier than 5:30-6 with expectations of frequent late nights and weekends with 2 weeks vacation). I've simply lost all tolerance for that, and always wonder how others manage it in stricter environments.
The first few months there wasn't time for any of that anyway and then as I began to have time I took out the few items that I really wanted to use, but all the while I didn't have a constant pile of fun things around the house making me feel bad because I didn't have time to play with them.
Depending on the circumstances you will have different amounts of time, but most importantly is realizing that you will have less time and taking steps to adjust to your new role.
The next phase, when they are a little older, you can share your hobbies with them. Kids love to do fun things like hiking and camping and building stuff and playing games. That is awesome.
So I guess from my perspective, I would say your passions and hobbies and interests can be molded by having children, and become something you share and develop together as a family. From an outside perspective, we probably devote too much time to this sport (I would have thought so a few years ago), but it's something we all enjoy and have found ways to participate in together.
Not really; a side effect of finding a passion that draws you out of work is that you reduce work but simply reducing work is not the same thing.
But many self improvement advisors across a host of problems from overeating to addiction agree that the way to kick a habit is to crowd it out of your life. You don't have time to eat a cheesecake because you're going for a run or to a volunteer event or to the park with your kids.
In the U.S., while I think it's true that people tend to work closer to 50 hours, we pay lip service to the "40 hour work week".
In our industry where it tends to be an option for us, "find a new job" might make sense.
He says he's from outside CA.
If I'm not directly competing and stealing clients I think that chances are low that they will try to claim ownership.
I was under the impression that their policy was 'you can do research anywhere in Google' and that there was no separate staffed labs doing more academic research. You may get research in the V8 team, or the systems team or whatever, but they were doing research as part of product teams. At least that's what I was told when I applied.
Anyway, it's pretty easy to verify: http://research.google.com/
And the guy's profile: http://research.google.com/pubs/author1112.html
Edit: Don't know why I'm getting voted down. The OP was questioning whether there's a research group at Google, in the comment section for an article by somebody who's worked in that department for ten years. If that's not a definitive answer to the question, I don't really know what the OP is expecting.
It sounded like an innocent question to me and it was one I also had. While there is a research site it still wasn't entirely obvious to me how it worked. You're probably getting downvoted for the lying bit and being condescending.
Google Research used to be pretty separate. That is, it was a separate product area from other product areas. It is no longer. This is an organizational issue however, and while it would seem like it mattered, it did not. It only changed who was the SVP overseeing it at some super high level. The VP was the same for many many years, and the person really in charge.
But this is irrelevant to the second part of your question, where you mention: "and that there was no separate staffed labs doing more academic research."
They do not do "more academic research", so in that sense, your recruiter was right.
Research at Google is not about academic vs industrial. The practical difference between the research scientist and SWE ladders is that in research scientist, publishing is valued as well. Outside of research, it's certainly nice, but not really part of the job description.
However, unlike most other places, publishing alone is not the goal. If all you ever did was research and publish, you'd be fired :)
Google expects research scientists to do real coding, real work, and be as good of SWE's as their SWE's.
It is a very hybrid approach, and different from most other places.
So I found this: https://static.googleusercontent.com/media/research.google.c...
If anyone has other interesting resources about the general employee structure at Google/other big companies, please reply :)
For a perspective/survey check this out: http://www.dis.uniroma1.it/~degiacom/didattica/semingsoft/ma...
"My coding activities were always productive. They either launched a new project or a major change in direction of a project. They also enabled me to have discussions with my team members at a completely different level of detail (to everyone’s enjoyment)."
This can be great. It sounds like it went well. However, I have personally seen a downside, some potential risks, when the boss "keeps coding".
Here's why - if the boss is coding but staying off the critical path, this means that the often detailed, difficult implementation work will be delegated to developers who report to the boss. The old adage that genius is 1% inspiration, 99% perspiration? Well, the critical path is the perspiration part. Deadlines, estimates, glaring errors that shouldn't have happened and need to be fixed late at night or over the weekend… these are all part of the critical path. While coding can keep a boss closer to a technical team, it can also create a dangerous illusion, that the boss is still "technical" but insulated from the truly difficult aspects of a technical role. There is a big, big difference between coding on your own research project and coding under deadline pressure for a system that needs to work. This is only a risk, not a certainty, as a good manager will recognize this.
Perhaps a greater risk, though, is that if the boss gets to play around with new technology and launch projects for the rest of the team to finish off, there's a risk that the boss is pretty much eating the frosting of the team's dessert but making everyone else eat their vegetables, so to speak. If you're a manager who codes, keep in mind that autonomy and innovation may be key to the motivation and job satisfaction of the people working for you. This can lead to a very damaging management anti-pattern, where a manager who "keeps coding" essentially uses managerial authority to intercept and filter projects, make the key technical decisions, do the interesting bits that would lead to interesting conference talks, and then delegate the work of actually finishing the product to the team. This may deprive senior level developers the autonomy that they really were supposed to have on projects.
Once again, I want to emphasize that this isn't necessarily what happened here, in fact, it sounds like it wasn't. But the passage made me a bit nervous, since I consider this to be something of a management anti-pattern.
Instead of a boss who is part-time manager, have we tried managing 3/4 of the year then doing a "developer rotation"? How does that work?
http://webcache.googleusercontent.com/search?q=cache:WpRJJJ-...
The normal cached version still tries to download images and whatnot from the original server.
Hmm.. humans are inspecting the query stream?
There's lots more data over here: http://www.google.com/trends
(I don't believe the author was referring to this, I think he meant something far less interesting.)
This is the worst advice ever, esp. if you don't know how to code and don't have code readability for the language being used in the code review. Learn from code reviews, see what other people are saying, but don't comment on a fix unless you found something glaringly obvious.
It seems that his intended audience is expected to know how to code.
Nonetheless, I commented on LOTS of code reviews when I joined, but almost always with questions asking (usually) 'why is this done this way?' or (rarely) 'could this by done this other way?'. It helps that our code review tool lets you mark comments as 'no action required'. This allows the first form to be a genuine question without judgement. I would usually learn something, and sometimes the original author would revisit a decision and improve the code. I reserve the second form for when I'm pretty sure I think what I'm suggesting is an improvement.
In my experience this allowed me to provide feedback without perceived ego or offense[1], but also accelerated the rate at which I came up to speed on both the language and the details of the project I'd joined. Despite being a few years in now and fairly familiar with our project, I try (although sometimes fail) to maintain this style today.
[0]: My father got me my first development job as a subcontractor building terminal emulation software for the Pennsylvania Turnpike Commission at 16. I'd learned C a few years beforehand on QNX. A number of other jobs from the same folks followed over the years while I finished up high school and undergrad.
[1]: Usually, anyway. There are some people who take ANY comment, question, or critique as an accusation. Thankfully I've encountered only one of these people at Google.