Google Engineer Tips

    Hello!

    My name is Larisa. I work for Google and blog on larrr.com , where I originally published this article.

    Today I bring to your attention an article that was originally written exclusively for internal use by Google. I really liked it, so I contacted the author, with her permission I redid it a bit, and received permission from Google Press to publish. My translation.

    Just in case, this is not an official Google document, and Google is not responsible for its content. It is subjective, and written by an employee for employees.

    Tips for engineers

    April 15, 2013
    Edited May 21, 2014
    Translated August 31, 2015
    Gretta Bartels, Software Engineering Manager at Google


    Dear reader,

    In this document I described some principles that I rely on when working with my teams. There is nothing fundamentally new or revolutionary in them; all of these principles have long been known to each of us. But knowing and doing are two different things. Therefore, this document is also a reminder to me myself that my manager’s job is to follow these principles myself and remind others of them.

    One of my more experienced colleagues taught me that it is very important for a manager to be extremely predictable. The manager should have some set of simple rules that all his subordinates know about, and which they can follow even when the manager is not nearby. Therefore, my goal is for the programmers in my team to ask themselves the question “What would my manager say to this?” And answer themselves correctly. Then the team will be able to work almost independently, without my guidance. And I will sit at home and eat cakes :).

    Here is a list of my basic rules:

    1. Engage in work that is really important

    1a) Always ask yourself the question “Why are we doing this?”

    Whatever you do, everyone should always clearly know two things - 1) why are you doing this? 2) how do you understand that you have achieved the desired result? Even if it seems to you that you can answer yourself for the question “why?”, Do not stop at the first suitable answer, look deeper. Ask yourself this question over and over again until the answer is simple, obvious and at the same time quite ambitious.

    This is somewhat similar to the “ 5 why ” method , when the technician asks himself several times the question “why?”, Delving into the answer to find the cause of the problem. But in our case, I propose to use this method for any work, and not just to find the causes of problems.

    And here is an example from life. One of my teams is currently working on improving the quality of data for Google Maps (namely, we find and resolve internal inconsistencies in the data). In this case, the “why” chain may look something like this:

    We eliminate data inconsistencies
    -> so that we can integrate existing and new data easier and faster
    -> so that we can update the data faster
    -> in order to so that Google Maps is as accurate as possible
    -> so that the quality of Google Maps meets a very high standard and user requirements
    -> so that people actively use and trust Google Maps (and Google products in general)

    Looks pretty simple, right? But based on my experience, far from all engineers ask themselves these questions and see beyond the specific and isolated task they are working on.

    In fact, understanding “why?” Is very important for your work. Screaming is important, I would say.

    • Without this understanding, it is much more difficult to evaluate the results of one's work. And it’s much more difficult to adapt to the constantly changing project requirements, as a result of which you may need to prove to the management that what you are doing is really important.
    • In addition, this way you can find other people and teams who pursue the same fundamental goal. You can find support and allies, the importance of which is very difficult to overestimate.
    • Plus, you can better prioritize existing projects.

    By the way, there may be several answers to your “why?”. This is a good sign - your project is probably really important.

    And another important thing, especially for managers: using the “why” chain, you can not only better understand why you are doing something and how to do it better, but also see other strategic areas of development for your projects. Just go from the other end of the chain and ask yourself the question “how?”.
    1b) The most important thing is the result.

    As a manager, I evaluate my employees by the following parameters: Knowledge and Experience, Difficulty, Leadership and Results. Although all of them are important for professional development and career growth, one of the parameters is much more important than others. This is the Result.

    Most companies are not training and development sites for programmers. These are businesses that work, and precisely because of this, we can work in them. By the way, I personally really like this combination - business and technology. I like working on things that change the world. And many engineers with whom I spoke on this subject - too.

    Interestingly, the result does not follow from the rest of the parameters. You can be smart, experienced, knowledgeable charismatic manager or technical team of a team that works on an incredibly difficult and interesting task. A task that has no strategic importance whatsoever. On the other hand, it is hardly possible to create something worthwhile without knowledge, or without being a good leader.

    By the way, about the complexity. It happens that to achieve an important result, you do not need to do anything complicated. This is normal. Always look for and take simple and at the same time important projects when you have the opportunity.

    1c) Plans are useless, but important

    I believe in OKR (abbreviation Objectives and Key Results - goals and key results - a method used in modern management to manage projects. It allows you to synchronize team and individual goals and provide effective control over the implementation of tasks. Wiki .). I ask all engineers in their teams to write and evaluate them on a quarterly basis.

    Writing goals has many advantages. But I think the most important one is this: your time is limited, and you should occupy it with the things that will bring the most benefit. In addition, they can significantly improve the quality of planning. Without strategic planning, you can easily fall into two very common traps: overestimate how much you can make in a quarter, and drown in urgent matters instead of important ones. However, with planning you can also get into them, but it will be much easier for you to recognize them and get out of them.

    The situation when you do urgent things instead of doing important things is familiar to many. Here in this article, this topic is well disclosed. Read if you are interested.

    An even more interesting problem is the reassessment of their capabilities. As a manager, I regularly have to help engineers be more accurate in their assessments - in my experience, many people greatly overestimate the amount of work they can do in a given period of time. There were times when people set many goals, did each by 30-50%, but did not bring any goals to the planned result. It would be much better to make two or three goals 100%.

    Using written planning and evaluating their results after a quarter, many can significantly improve their skills in setting and achieving goals. Even without significantly changing their productivity, they begin to make more realistic forecasts and bring some really important things to the end. That is why I think OKR is incredibly important for my teams, and I hope that as many people as possible master this skill.

    2. Don’t waste time for free

    2a) Speed ​​up (aka How about a couple of tests?)

    During my studies at the university, as a test work, I had to write a Boggle game with a beautiful interface and support for remote games for several users. Naturally, I didn’t even lift a finger until the last day before the change. At 3 a.m., I found that my hastily written program contained a bug that crawled out at the very end of the game.

    So the rest of the night I spent playing my game, trying to repeat the bug and find its cause. Of course, that was at least stupid. I just had to set the game timer to 5 seconds and things would go much faster. In my defense, I want to say that it was in the morning, I really wanted to sleep, and not look for errors in my program. It would be even better to write a test, but then I didn’t even hear about the tests.

    Every time you repeat a piece of the program again and again, trying to find a mistake and fix it, do everything so that these repetitions are as short as possible. Most likely, this will seem superfluous to you, since you will be sure that you found the error the first time. But this happens very rarely. You will probably soon realize that this is not it, and you will have to repeat the process again. And then again.

    Therefore, when working on any project, try to make it as easy as possible to test it. Make it modular, make it so that any part of the program can be isolated and tested as simply as possible. Believe me, there will come a time when you will be glad you did it. And if you have problems with modularity and insulation, then this is a good reason to think about how good your design is in principle.

    A similar principle applies to working with people and products. When you are in a situation of uncertainty, think about how to conduct a quick and simple experiment that would give you at least some preliminary data.

    2b) Get rid of the problem once and for all (aka Automate)

    People should not spend time on things that are much better at computers. This is not even discussed.

    We all do programming to make life easier and automate what can be automated. It would seem that engineers would try to apply this principle to their maximum extent as well. But it turns out that not at all!

    Many times I saw people doing the same repetitive task manually from time to time instead of automating it. The main justification in this situation is “it takes only a few minutes, and the automation of the process takes a whole day”. Sometimes it’s even true, but not as often as it might seem.

    Automating the task:

    • Anyone will be able to cope with this task, even a person who has just started working in a team, or an automatic process. Handmade minutes will quickly gather in hours and even days - the task will start when you sleep, when you eat, and when you are sick.
      Automating a small task can open the door for more extensive optimization.
    • You may find situations that you did not even think about before you tried to automate the entire process.
    • By creating processes in order to automate them later, you will significantly improve your process design skills.

    2c) Develop

    Do not do the same thing for too long. After you have mastered some area, either automate it (see above), or train another engineer for this work and move on. Grow professionally, do not let yourself stagnate.

    Sometimes people do not do this because their work seems to them to be routine and they do not want to transfer this routine to others. But what may seem like a chore to you will be a great opportunity to learn something for another, perhaps less experienced, engineer. Even if this is not so, it most likely makes a lot more sense for the team when several people understand a particular task at once. Otherwise, it may become a narrow link.

    Sometimes people hold on to their tasks because it seems to them that it is too difficult to explain them to others, or because they believe that they cope with them better than anyone. If this is your case, then you should seriously think about creating good documentation.

    I constantly advise engineers in their teams to switch to new tasks and develop professionally.

    3. Do not work in a vacuum (aka Communicate with others)

    Try to describe the design of the systems you will work on in advance (aka write design docs). Send these documents to your colleagues and ask what they think. By doing this, you:

    • Streamline your own thought process.
    • Make sure that someone else is not involved in a similar project.
    • Improve your design using the helpful tips of your colleagues.
    • It’s much easier to find colleagues who agree to help you.
    • Show yourself as an active and responsible member of the team.

    Talk about your work (possible with slides). Invite others to share their work. Take an active interest in what others are doing in your and neighboring teams. You and your team will benefit from this.

    Many do not want to talk and write about their work until it is ready. Or they just don't like to write. These are rather weak excuses. If you do not want to write, or do not want to make a presentation right away for the whole team, then start small - just talk to one specific colleague, draw a sketchy design on the board. This will help you organize your thoughts, and it will be much easier to write a document or discuss it with the whole group.

    If you liked the article, then visit my blog. Perhaps there you will find even more interesting things for yourself. I already have nearly 300 articles on Google, career, self-development and productivity (some of them were once on Habré). I love to write, and I think I'm doing pretty well. At least sometimes.
    I would be glad if you like it!

    Also popular now: