An engineer who worked at Google for 14 years talks about '21 lessons that successful people are aware of outside of code'
Adi Osmani , a software engineer at Google who works on Google Cloud and Gemini, shared 21 lessons he learned during his 14 years at the company on his blog. While Osmani initially thought his job was to write good code, the longer he worked there, the more he realized that successful engineers aren't necessarily the best programmers. He also said that those who can navigate the interpersonal relationships, internal politics, alignment, and ambiguity surrounding code thrive.
AddyOsmani.com - 21 Lessons From 14 Years at Google
1. Focus on user problems
While it's natural to become obsessed with new technology and start looking for ways to use it, Osmani says value creators think in reverse: 'They should dig deeper into the problem by reading support tickets, talking to users, and seeing where users get stuck, and then use that understanding to create solutions.'
◆2: Consensus building over correctness
Even if you keep winning technical arguments within your company, 'quiet resentment' can build up, and this can manifest as resistance when development begins. Osmani says, 'The purpose of the discussion is not to be right, but to align understanding of the problem, to create space for others to speak, and to question one's own convictions.'
◆3: First, put it out. You can't fix a blank page.
'No matter how much perfectionism you have and how much discussion you have, it's hard to find the right answer without experiencing reality,' Osmani points out. He says that learning is quicker when you first let users try out the product, even if it's just in the bare minimum, and see their reactions, in the order of 'make it first, get it right, then make it better.'
◆4: Code is easier to understand than beautiful
Well-written code may seem like a sign of competence, but it can also be a risk in production. Since code is also a 'memo' that others will read when troubleshooting late-night issues, Osmani says you should prioritize writing in a way that others can understand over the beauty of your code.
◆5: New technology is “debt”
Osmani sees the decision to adopt new technology within the 'framework for innovation' and suggests that every time you deviate from the norm, you will pay the costs later. He doesn't see the introduction of new technology as a problem, but rather that if you do introduce it, you should limit it to areas where you can expect a return, and stick to safe, proven choices elsewhere.
◆6: People communicate results
In large organizations, decisions are often made based solely on summaries from meetings you don't attend. If there's no one to explain your accomplishments in your absence, your influence becomes a secondary consideration. It's important to make it clear to others how your accomplishments are connected to your value.
◆7: The best code is not to write
'Although deleting unnecessary code can improve a system more than adding code to add functionality, deleting code is often not highly evaluated,' Osmani points out. Before creating something, you should thoroughly consider what would happen if you did nothing.
◆8: With a large number of users, bugs become features
As the number of users increases, even unexpected behaviors become 'specifications,' and even bugs can have dependencies on other elements. In this case, compatibility support becomes 'value' that goes beyond 'maintenance,' so deprecation of features should be designed as a 'transition.'
◆9: The cause of slowness is misrecognition
While delays are often blamed on execution or technology, Osmani points out that in reality, 'it's often caused by mismatches in direction, division of roles, and priorities with other people.' He says that the more experienced engineers are, the more time they spend on 'aligning understanding' rather than 'writing code quickly' because that's the bottleneck.
◆10: Focus on your hands
Since organizational restructuring and policy changes are outside of your control, worrying about them will only increase your anxiety. 'You should focus on your sphere of influence, break down the uncertainty, and identify actions you can take right now,' says Osmani.
◆11: The price of convenience is paid in trouble-shooting
Osmani points out that convenient mechanisms (abstraction) are a gamble that 'do not require understanding the underlying mechanisms.' While you do not normally have to be aware of the internals, when a failure or unexpected behavior occurs, the complexity hidden by the abstraction comes to the surface, and you often find yourself alone in the middle of the night trying to figure out the cause. Therefore, while mastering convenient mechanisms, it is important to also understand the failure patterns and how they can break down at the lower levels.
◆12: Write to solidify your understanding
Osmani says that while writing documents, presenting them, explaining them in reviews, and organizing and talking to AI, 'the parts that I can't explain well are the parts that I don't understand yet.'
◆13: Make work that supports others visible
While document preparation, support for new employees on their launch, and coordination between teams are important, they are prone to burnout if they are not aware of it. They recommend visualizing these tasks by dividing them into time slots, rotating them, or turning them into deliverables.
◆14: Behind the continued victory in arguments lies the 'accumulation of resistance'
Osmani points out that the people who always win arguments are those who know something is wrong, and that in many cases, they stop arguing because they have given up, not because they have been persuaded. In this case, objections tend to erupt not during the meeting but at the implementation stage, so it is necessary to take time to incorporate feedback and sometimes change your mind.
◆15: Indicators are easily distorted
Osmani pointed out that the metrics he showed are easily optimized, and that 'if you only focus on lines of code or development speed, it will be distorted.' He said that speed metrics should be paired with quality and risk metrics, and that you should judge based on trends rather than treating numerical standards as absolute.
◆16: 'Not knowing' creates peace of mind
When experienced people acknowledge uncertainty, others are more likely to ask questions and their assumptions are challenged. Conversely, in a culture of 'pretending to understand,' problems tend to hide and explode.
◆17: Personal connections are a long-term asset
Osmani reflected, 'It was a mistake to focus only on work and neglect networking,' and said that those who invest in relationships with others will reap the benefits in the long run, such as quicker access to opportunities and recommendations. He said that we should approach it with curiosity and generosity, not calculation.
◆18: Performance improvements come more from 'reducing' than from 'adding'
When system performance degrades, it's tempting to add countermeasures, but Osmani points out that it's often more effective to ask, 'What processes don't need to be calculated in the first place?' He said the fastest code is 'code that doesn't execute.'
◆19: Processes exist to reduce uncertainty
Osmani states that 'good processes and rules make coordination easier and reduce the cost of failure, while bad processes and rules tend to be mere tokenism for the sake of assigning blame,' and that processes that cannot be explained in a way that mitigates risk or clarifies them are merely a burden. He also points out that if you spend more time recording than doing the work itself, 'something is fundamentally wrong.'
◆20: Time becomes the most important resource
While it's natural to trade time for money early in your career, at some point you'll realize that time is a non-renewable resource, and you need to be intentional about what you're trading for before you burn out in pursuit of promotions and compensation.
◆21: Growth is cumulative
Osmani argues that expertise comes from deliberate practice, there are no shortcuts, and learning is built up by increasing options. He says that actions like 'writing for clarity,' 'creating reusable parts,' and 'documenting experience' will have long-term benefits.
Osmani concluded by saying, 'The 21 lessons are based on curiosity, humility, and focusing on users and teammates.' He said that an engineer's career is long enough to allow them to recover even if they fail, and that those who are respected are not 'those who did everything right,' but 'those who learned from what went wrong, shared their experiences, and continued to return to the field.'
Related Posts:
in Note, Web Service, Posted by log1b_ok