To mark the end of my third year on the Android team, here’s a TL;DR version of the last thousand days or so.

Do code reviews. You’ll occasionally butt heads, as there’s rarely a single “best” way to make even the simplest bug fix. But no matter what’s the seniority of your reviewer, you’ll always be better off at the end. I lost count of the number of times that I said to myself “Huh, I didn’t know that” after seeing a reviewer leaving his comments. Not to mention that you’ll have somebody else having at least some level of familiarity with your code if you ever get too swamped.

Every once in a while you’ll get out of your comfort zone working on a new feature or fixing a bug. At some point you know your reviewers, their style and their strengths. Don’t be tempted to add reviewers that will be inclined to rubber stamp such code. Seek out people who are deeply familiar and well versed in the specific area. You will be afraid that they’ll pick your code apart like a poorly constructed house of cards it is. Better now than after it ships. Such a reviewer knows how to do this better than you, and the result will be better for both you and your code base. It will just take longer. Don’t let your ego take a hit. It’s just code.

When you’re asked to do a review, do it quickly. Don’t drop everything and do it immediately, but do it the same day. The quicker you provide good and actionable feedback, the fresher it is on the side of the code author. Don’t let your reviewers rot. This also helps preventing unnecessary rebases. Not to mention spreading your strengths around, and learning from the strengths of others.

Don’t do gigantic code drops. If it’s a big feature, start on smaller steps towards the final goal. Mark unfinished places with TODOs so that the reviewer knows this is not the final thing. And make damn sure there’s not a single TODO left at the end.

Cross reference all code changes with bug tracker entries. Document all discussions, decisions and alternate solutions that didn’t work in the bug tracker. When somebody asks why things were done this way a year later, they’ll be thankful. In most cases, that somebody will be you.

Do code reviews. I might have mentioned it. But seriously. Don’t be that guy whose code ends up on The Daily WTF. By the way, if your team members start posting your code there, you might want to contact your internal security guy. Just saying.