- Don't give advice unless you really have to. This is easily the most important thing to remember and something I have to constantly work on. Most people just want someone to talk to and they usually already know what the right thing is to do. Offering advice is rarely considered helpful. Listen and support their decision. Most of the time the decision itself doesn't really matter as long as people move forward.
- Learn to look people in the eye when you talk to them. Many people find this challenging (myself included) and find themselves looking everywhere in the room except in the other person's eyes. From what I've read, this is more often true for guys. Especially for 1:1s, the best way to show that you're listening carefully and talking honestly to someone is to look at them when one of you is talking. In particular, never look at your phone or computer without first saying why you're doing this (e.g., "Just checking the time to make sure we're not running late since I know you've got lots to do").
- Take the personal issues seriously. Don't dismiss things if they're unrelated to the task at hand or seem minor. These things really matter to people and you should treat them as such. Acknowledge them, enforce that you think this is important and include these things in your decision making (although they don't necessarily have to be the deciding factors).
- Don't try to appear busier than you are. Yes you'll likely be busy and people will realize this. Resist any temptation to look like you're too busy to be approached (even if you really have a lot of stuff to do). Always err on the side of appearing less busy than you are to remain approachable. Avoid giving the impression that you're just trying to look busy so people will think you're important. Nothing good can come of this.
- Be modest. You're probably not as good of a leader as you think you are. Keep trying to evaluate your successes and failures. Downplay the successes and over-emphasize the failures to keep yourself grounded, fight complacency and highlight your efforts to improve.
- Wash your hands with soap every time. This may sound like a minor thing but getting the details right and taking every situation seriously is important. You should *always* (try to) conduct yourself in a way that you would like others to behave. Every situation is an opportunity to influence people's impression of you and the little things really matter.
Monday, August 20, 2012
Behaving Like a Leader
I've been an engineering manager at Google now for a couple of years and it's been quite an eye-opening experience for me. I won't say I've got a ton of advice to offer (see first bullet below) but here are a few things I've taken away from the people that I take as great leaders around me:
Monday, May 25, 2009
RIP Jay Bennett
Really sorry to hear about Jay Bennett's death. Bennett-era Wilco albums are among my most listened-to records. He'll be missed.
Sunday, April 19, 2009
HTML 5 on Mobile Browsers
Our most recent release of Gmail for the Android and iPhone browser tries to take advantage of some of the cool new HTML-5 capabilities that these browsers are supporting. In particular, both app-cache and the database are used heavily by our application. It's pretty amazing that these mobile browsers are pushing ahead as fast (or faster) than the desktop browsers. Just a year ago, writing anything for a mobile browser was slightly more painful than banging your head against the wall. Today, it's actually pretty reasonable.
See our first post here on the code.google.com blog: http://google-code-updates.blogspot.com/2009/04/html5-and-webkit-pave-way-for-mobile.html We plan to post regularly to this blog with details on how we worked with HTML-5, including details on new features, browser quirks, etc.
In my opinion it's great that mobile browsers are starting to do their part to make the web truly available to people on the go. Now if only carriers in Canada would provide reasonably priced data plans so people could actually take advantage of this. Ugh.
Tuesday, February 24, 2009
One New Thing Per Day(?)
I would like to learn one new random thing each day. They have those tear-away desk calendars but what I really want is a daily email that teaches me one thing I (likely) didn't know the day before. Anyone know if such a service exists? If not, anyone interested in building one of these? I wouldn't mind collaborating on this.
This reminds me of an old idea a friend and I started on called "Lore of Nations"... Won't mean anything to anyone but him and I, so you know how far this idea went.
Saturday, January 17, 2009
Javascript fun
Unlike most Googlers, I have very little experience with JavaScript. I've only recently started dabbling and it's quite an experience. Many, many articles have been written on all the cool/bizarre quirks of the language, so I won't repeat them here. Instead, I'll point out a couple of tiny things that I ran into recently that are kind of cool/bizarre.
!!boolean_var - This is really just syntactic sugar, but it is pretty nice. If you want boolean_var to be treated as a boolean, this will nicely cast it from any value (including undefined) to its boolean negation and back, so you're guaranteed that boolean_var is a boolean.
arguments fun - The javascript "arguments" object is quite handy, but it can be pretty tricky. Consider these two definitions of a simple function to add 2 or more values:
!!boolean_var - This is really just syntactic sugar, but it is pretty nice. If you want boolean_var to be treated as a boolean, this will nicely cast it from any value (including undefined) to its boolean negation and back, so you're guaranteed that boolean_var is a boolean.
arguments fun - The javascript "arguments" object is quite handy, but it can be pretty tricky. Consider these two definitions of a simple function to add 2 or more values:
>>> addAll = function(x, y) {
if (x != null && y != null) {
for (b = 1; b <>
x += arguments[b];
}
}
return x;
};
>>> addAll2 = function(x, y) {
if (x != null && y != null) {
for (y = 1; y <>
x += arguments[y];
}
}
return x;
};
>>> addAll(10, 2, 4, 6);
22
>>> addAll2(10, 2, 4, 6);
21
The first method works nicely but the second one fails. At first glance, it might appear the second method should work fine since "y" is not accessed after the null check, but notice that "y" and "arguments[1]" are aliased to the same variable, so using "y" as the loop iterator will mess things up. This is not a very common case, but if you're trying to optimize the javascript by avoiding unnecessary variable declarations, these details become quite important. Be careful out there!
22
>>> addAll2(10, 2, 4, 6);
21
The first method works nicely but the second one fails. At first glance, it might appear the second method should work fine since "y" is not accessed after the null check, but notice that "y" and "arguments[1]" are aliased to the same variable, so using "y" as the loop iterator will mess things up. This is not a very common case, but if you're trying to optimize the javascript by avoiding unnecessary variable declarations, these details become quite important. Be careful out there!
Wednesday, November 5, 2008
What if Obama is a flop?
Despite having not written for months, I didn't see how I could possibly let an event like this go by without comment. Far more significant than the Canadian election (even to us Canadians), last night's election says a lot about where the U.S.A. is at.
Of course, this is a very significant result. Despite a difference of only 0.1% of the popular vote, Americans actually did vote in favour of a minority for president. Unlike in Canada, where we picked the candidate that the rest of the world would look down on us for choosing, the U.S.A. picked the candidate that every other country wanted.
In a time like this, when everyone is happy and reflecting on the significance of the moment, I can't help but think of the worst-case outcome of this. What if 4 years from now the U.S.A. is still a disaster? Imagine that Obama floats through his presidency, without delivering on any of his promises, the country falls deeper into recession, the divide widens, etc. It certainly could happen. Specifically I'm thinking of a 2012 America where:
- Most citizens don't have free access to health care.
- They are still at war with (at least) three countries and losing many lives in the process.
- The sagging American economy has dragged down the entire world, such that new and emerging economies sink back to their old levels bringing many countries back to 3rd world status.
- More than 50% of Americans long for the days when a decisive Republican ran the country.
This could happen for a variety of reasons. Since every writer in the world is commenting on this election, the coming 100 days, the coming 4 years, etc. I won't comment on it here. Needless to say, despite every good intention and the rising hope of an entire nation (and arguably the world), it's entirely possible that nothing substantial gets accomplished and things operate pretty much as normal. I hope that's not the case, but it could be.
Despite the possible doom-and-gloom scenarios, this was, without a doubt, the right thing to do. This is the single biggest gift the U.S.A. has given itself and the rest of the world in my lifetime and regardless of what the next 4 years are like, I doubt anyone, from any country will be able to shake their heads and say "I told you so".
Of course, this is a very significant result. Despite a difference of only 0.1% of the popular vote, Americans actually did vote in favour of a minority for president. Unlike in Canada, where we picked the candidate that the rest of the world would look down on us for choosing, the U.S.A. picked the candidate that every other country wanted.
In a time like this, when everyone is happy and reflecting on the significance of the moment, I can't help but think of the worst-case outcome of this. What if 4 years from now the U.S.A. is still a disaster? Imagine that Obama floats through his presidency, without delivering on any of his promises, the country falls deeper into recession, the divide widens, etc. It certainly could happen. Specifically I'm thinking of a 2012 America where:
- Most citizens don't have free access to health care.
- They are still at war with (at least) three countries and losing many lives in the process.
- The sagging American economy has dragged down the entire world, such that new and emerging economies sink back to their old levels bringing many countries back to 3rd world status.
- More than 50% of Americans long for the days when a decisive Republican ran the country.
This could happen for a variety of reasons. Since every writer in the world is commenting on this election, the coming 100 days, the coming 4 years, etc. I won't comment on it here. Needless to say, despite every good intention and the rising hope of an entire nation (and arguably the world), it's entirely possible that nothing substantial gets accomplished and things operate pretty much as normal. I hope that's not the case, but it could be.
Despite the possible doom-and-gloom scenarios, this was, without a doubt, the right thing to do. This is the single biggest gift the U.S.A. has given itself and the rest of the world in my lifetime and regardless of what the next 4 years are like, I doubt anyone, from any country will be able to shake their heads and say "I told you so".
Sunday, June 8, 2008
On code reviews
One of the most valuable lessons I've learned from working at Google is the importance of code reviews. There was no mention of code reviews in school or at my previous employers, but now I can't imagine developing without it. Code reviews come in many forms but for my current project it comes down to one thing: Every piece of code must be okay'ed by at least one coder other than the code's writer before it gets checked in. That's it.
Here's a typical cycle:
1) Coder A writes code to add a small feature (or fixes a bug, or whatever).
2) Coder A shows diffs for this change to coder B (and possibly C, D, E, etc.)
3) Coder B reads through the code and notices some small logic bugs, a few style issues, and raises some other concerns.
4) Coder A fixes the issues that B brought up and responds to B's concerns.
5) Repeat 2-4 as many times as required.
6) Coder B is now happy and says so - in writing (e.g., via email)
7) Coder A checks in the change.
Sound painful? Sometimes it is. But the value added by this cycle is quite remarkable. It's extremely valuable to have people inspect the code before it gets in for many reasons, including:
1) Small logic bugs resulting from the same person staring at the same code for several minutes or hours are often caught quickly by a second set of eyes.
2) At least two people see every piece of code checked in, spreading the knowledge throughout the team and reducing the likelihood of ending up with code that only one person understands and/or can modify.
3) People are more cautious about what they check in. With code reviews, most developers do additional work to clean up, comment, and optimize their code before requesting a review in order to minimize the number of review iterations.
4) The blame can be shared among the team when things go wrong. This may seem like a small deal, but I think it's very important. No matter how careful people are, imperfect code will continue to get checked in. Without code reviews, it's easy to place the blame and this can cause animosity in the team. With code reviews, multiple people are involved in imperfect code getting checked in. This means that not only is it in everyone's best interest to make sure the best possible code gets checked in, but also mistakes become something that the team can improve on instead of just "coder A screwed up".
Code reviews add overhead, there's no question about it. But the value of code reviews is comparable to unit tests and other magic tools of software development productivity, so if you aren't using them, you should.
Here's a typical cycle:
1) Coder A writes code to add a small feature (or fixes a bug, or whatever).
2) Coder A shows diffs for this change to coder B (and possibly C, D, E, etc.)
3) Coder B reads through the code and notices some small logic bugs, a few style issues, and raises some other concerns.
4) Coder A fixes the issues that B brought up and responds to B's concerns.
5) Repeat 2-4 as many times as required.
6) Coder B is now happy and says so - in writing (e.g., via email)
7) Coder A checks in the change.
Sound painful? Sometimes it is. But the value added by this cycle is quite remarkable. It's extremely valuable to have people inspect the code before it gets in for many reasons, including:
1) Small logic bugs resulting from the same person staring at the same code for several minutes or hours are often caught quickly by a second set of eyes.
2) At least two people see every piece of code checked in, spreading the knowledge throughout the team and reducing the likelihood of ending up with code that only one person understands and/or can modify.
3) People are more cautious about what they check in. With code reviews, most developers do additional work to clean up, comment, and optimize their code before requesting a review in order to minimize the number of review iterations.
4) The blame can be shared among the team when things go wrong. This may seem like a small deal, but I think it's very important. No matter how careful people are, imperfect code will continue to get checked in. Without code reviews, it's easy to place the blame and this can cause animosity in the team. With code reviews, multiple people are involved in imperfect code getting checked in. This means that not only is it in everyone's best interest to make sure the best possible code gets checked in, but also mistakes become something that the team can improve on instead of just "coder A screwed up".
Code reviews add overhead, there's no question about it. But the value of code reviews is comparable to unit tests and other magic tools of software development productivity, so if you aren't using them, you should.
Subscribe to:
Posts (Atom)
