Desi Programmer @ Work

Reflections on two years at Google

I recently completed my two years at Google. It’s been a great experience and I feel I’ve learnt a lot, both in terms of engineering as well as soft skills. I’m sharing some of my thoughts (in no particular order):

  • Having on-site food readily available saves lots of engineering time.
  • A team is a combination of people with different strengths and weaknesses. The best team is the one whose strengths are combined together and individual weaknesses are covered by other team members.
  • Be shameless about asking for help from others. People feel good about helping out others and sharing what they know. Show same level of generosity and enthusiasm when someone else reaches you out for help.
  • Email management is an art. It is tough but one must learn it. Unfortunately there are no courses for it. Asking people around for pro-tips regarding how they organize their inbox can be very useful when they have few hundred emails coming up in their inbox every day.
  • Having a strong grip over (English) language helps. Being able to easily keep your thoughts flowing helps you in all aspect.
  • A good bug-tracker alone can effectively help you organize almost all of your tasks.
  • Try to break down a feature request into many small tasks and open an entry in the bug tracker for each. Prioritize bugs assigned to you accordingly.
  • Keep good tracks of your notes on the bug; don't be shy putting small details on the bug tracker because it would not only help others in future but also you because in six months you will most likely forget 80% of the details.
  • Keep an eye on the progress of bugs of your team members to keep yourself aware of what's going on around.
  • Investing time in tweaking your shells scripts, config files and other hacking tools usually pays off. Don't overdo it, but don't underdo it either. Do share them with your team members as well as track them in a code repo.
  • No matter how much opinionated you are about Java, it is the main choice of language for large teams. Learn it's strengths well even if you don't like it.
  • Don’t repeat yourself, write tests. It does take time and resource investment to write tests but whether or not to write them shouldn’t be debated rather the argument should be around whether you want to have 90% test coverage or 99.99% test coverage of your code.
  • Writing helps a lot. Writing helps you generate ideas. Writing also helps you recall what you've done and sometimes keep you motivated by reminding you that you are making progress and doing a good job. Before I started writing this post, I had a feeling I haven't learned anything in the past one year.
  • The twice-a-year performance review to write self assessment and review peers forces you to write, which has a lot of benefits even though it is time consuming. Be concise and don’t pollute it to get the best out of it.
  • Specially learning diplomacy is not required when your disagreements are for the sake of betterment of product, end-users or overall well being of people around you. Your peers can easily sense whether you are coming from your ego or you genuinely care.
  • A small act of appreciation can turn acquaintances into friends who'd go out of their way to help you. Don't hesitate to go out of your way to appreciate people whenever they deserve it.
  • Best advice for climbing corporate ladder is written in Dale Carnegie's How to Win Friends & Influence People -- read it, again.
  • Be the person who'd everyone would want to refer to, both for competency as well as attitude.