The Software Engineer's Guidebook

These are my notes for the book The Software Engineer's Guidebook by Gergely Orosz.

Chapter 1 - Career Paths

There are many types or tiers of companies to work for, each with different expectations and requirements for success.

Understanding these differences can have an impact on compensation, the type of work you will be exposed to, and the trajectory of your career. Tech companies can be broadly classified into three tiers, with Tier 1 being the lowest and Tier 2 being at the top of the market.
As with company paths, there are also different types of software engineering career paths.

These paths vary by company, but typically there is a single career path where an engineer must move into management to progress, and a dual track where an engineer can choose between the managerial path or remain an individual contributor.
The idea of cost centers and profit centers - Profit centers bring in the money; as such, they are more stable. Cost centers do not generate revenue. Choosing between cost and profit centers requires balance, and working in both gives different perspectives.
A career is more than just jobs, promotions, and compensation. There are many other important intangibles that can contribute to a great career, including the quality of work, colleagues, team dynamics, company culture, personal motivations, among other things.

Chapter 2 - Owning Your Career

Your career is your responsibility, so own it. There are many ways to own your career: talk to your manager about your goals, share your work with colleagues, and create opportunities for feedback.
Make sure you get stuff done. Ensure that this stuff is impactful, and make sure people know that you get stuff done. Do impactful work and then make noise about it.
We suffer from recency bias - we only remember recent things. A great way to ensure we remember the work we do is to keep a work log and record key tasks each week.
Feedback is a gift, so give, ask for, and seek out feedback. Create opportunities to receive feedback through code reviews, design documents, and performance reviews. Make sure to acknowledge good work in specific terms.
Make your manager an ally by understanding their goals and making their job easier. Keep them informed about your current and ongoing work. Ensure that your one-on-one meetings with your manager are regular.
Remember, it's a marathon and not a sprint. Pace yourself during the different ups and downs of your career to avoid burnout.

Chapter 3 - Performance Reviews

Understand what is valued by the business and how you can add that value. This includes understanding how the promotion system works. There are many kinds of performance review processes, so identify which one applies at work and act accordingly.
Let your manager know that you want to be promoted. Share your goals with them and come to an agreement on goals and expectations.
Use your work log to record your wins and successes, and share them with your manager. Don't forget to include the work you do to help others.
Be honest with yourself and create a self-review. Determine if you are meeting expectations, falling short, or exceeding them. It is important to have established these expectations with your manager.
Remember that performance reviews are a snapshot of time. Play the long game and remember that individual reviews hold little significance in the context of a decade-old career.

Chapter 4 - Promotions

Understand how promotions work at your company. Find people who have been promoted in the past and analyse what they did to get promoted.
It's not enough to just do good work. You also need to collaborate with others and promote your work to create awareness. Focus on producing, organising, and publishing. Keep track of your achievements on a weekly, monthly, and quarterly basis.
Your manager is a valuable asset. Make sure to build a good relationship with them and keep them informed with updates and feedback.
Avoid being too focused on promotions and titles. This can be perceived negatively by your colleagues. Instead, prioritise learning and curiosity. Remember that many career investments pay off in the long run.
Don't let titles define your self-worth. Remember that work is more than just titles and progression.

Chapter 5 - Thriving in different Environments

Aim to be a product-minded engineer. Develop an interest in the product you are working on itself. Ask yourself, "How are product decisions being made?"
Companies go through different modes: peacetime and wartime. You should be able to identify when your company is in peacetime or wartime mode. These modes will influence the time pressure to deliver. You should learn how to thrive in both modes, and ideally, a company should not always be in peacetime or wartime mode. You should be adaptable to changes that happen when modes change.
Know the difference between startups and big tech companies and optimise for each of them differently, depending on the company. The key thing at the end of the day for both companies is to get things done.

Chapter 6 - Switching Jobs

We cannot control when opportunities arise, but we can control how we engage with them and how seriously we take them.
There is a balance between waiting for a promotion and getting a new role. However, pursuing more senior roles can be risky as tenure becomes more important. Consider what you will be leaving behind if you leave your current position.
Depending on the size of the company you are joining, onboarding can take different forms. At smaller companies, it is important to ship something into production in the first week, although this may be more challenging at larger companies.

Chapter 7 - Getting things done

Always make sure that your single most important task is completed. You may have to say no to some other tasks to give yourself more capacity to complete your key priority.
Sometimes you can be blocked due to a bug or by something you do not understand. Always make sure you can unblock yourself. This starts with identifying when you are blocked and getting the required support to get unblocked. Based on the blocker, you may want to escalate. This is especially true when you are blocked by code review from another team. Remember, escalations are delicate. Make sure you escalate without causing any conflicts.
The best way to get things done is to break down your work. When you break down your work, your priority should be on completing work that gets you closer to shipping something. That means focusing on the order of work that gets you closer to working functionality. Breaking down your work helps with estimation, which is a skill that takes practice.
Find a group of people who you can learn from as mentors. This may be a formal relationship with regular meetings or something more ad hoc like online communities, but make sure the mentors you pick are reliable.
Always ensure you have adequate goodwill within your team. When you help someone, your goodwill increases. When you ask for favors, it decreases. Always make sure to maintain a balance.

Chapter 8 - Coding

Writing code is one of the most important skills of a software engineer. It's a skill you want to master, and the only way to get better at coding is to practice frequently. Apply what you learn through consistent coding. Aim to code daily and always take the opportunity to have your code reviewed.
Ensure you read as much code as you write, especially code written by team members. This helps identify patterns and conventions specific to your codebase.
Strive for readability in your code. Code should be easily read by both you and your colleagues. What is considered readable might differ among teams, programming languages, and companies. Always ask yourself, can others understand the code you wrote?
Maintain high quality in your code. High-quality code uses the right level of abstraction, handles errors effectively and consistently, and takes into account unknown states.

Chapter 9 - Software Development

Master a language - Once you have a solid understanding of the fundamentals, try delving deeper to understand how things really work. This also applies to the main framework you use with a language - invest more time in understanding the framework.
Learn a second language. Gaining proficiency in another language can provide perspective about your primary language. You can compare strengths and weaknesses, and it makes learning additional languages easier.
Refactoring and debugging are important skills. Learn the tools that simplify these tasks and ensure you regularly practice these skills.
Strengthen your refactoring muscles - by refactoring code regularly - for every few tasks you complete, make it a point to do an important refactoring task.
Testing is very important - not just automated tests - but manual tests are also very important. They help catch edge cases and help us confirm our assumptions about how a piece of functionality is meant to work. Embrace a testing mindset.
Automated testing also assists with refactoring - when you have a strong suite of tests in place - you can more confidently carry out significant refactors as the underlying logic has been tested.

Chapter 10 - Tools of the productive software engineer

It is important to remain in the flow when working on code - we can ensure we stay in this state by having a rapid edit, compile/run, and output cycle. If it takes more than a few seconds to make edits & see how they look - you are most likely losing time on context switching.
Spend some time configuring your IDE and workflow by setting up shortcuts for frequent actions, configuring your theme & setting up code formatting and linting if needed. Make sure to use your team's linting and formatting config if one exists.
Get familiar with the frequently used tools of the trade - Git, SQL, The terminal, regular expressions, AI coding assistants.
If you have custom tools within your company to assist with development make sure you are familiar with the most important ones - make a list, figure out how to access them & how they work - create your own cheat sheet on how to use them effectively.
Consider having a personal productivity cheat sheet. Start with a blank document and add names of tools with short descriptions of what they do - links, commands & other notes.
Compare your output with your team members' work. This isn't about competition, but a way to assess your productivity, pace of iteration, and how you measure up against your colleagues. Track the frequency of teammates' pull requests, code pushes to production, and task completion. This can give you insight into your performance before receiving explicit feedback.
Understanding the existing code is key to improving your iteration speed. Dedicate time to comprehend how different modules interact and how the codebase functions.
Getting regular feedback is crucial. The fastest ways to develop as an engineer are by building and deploying problem-solving solutions, and receiving feedback. Evaluate if your solution functions as anticipated and whether it has any unexpected consequences.