ALT An image of a river flowing, with a first dam (upstream dependencies), a second one (your team) and a third one (downstream dependencies)

ALT Table of contents for The Software Engineer’s Guidebook (draft) Coming in fall 2023 – so, soon! Part 1: Developer Career Fundamentals 1. Career paths 2. Owning your career 3. Performance reviews 4. Promotions 5. Thriving in different environments Part 2: The competent software developer 6. Getting things done 7. Software development 8. Tools of the productive engineer Part 3: The well-rounded senior engineer 9. Getting things done 10. Collaboration and teamwork 11. Software engineering 12. Testing 13. Software architecture Part 4: The pragmatic tech lead 14. Project management 15. Shipping in production 16. Stakeholder management 17. Team structure 18. Team dynamics Part 5: Role-model staff and principal engineers 19. Understanding the business 20. Collaboration 21. Software engineering 22. Reliable software engineering 23. Software architecture Part 6: Conclusion 24. Lifelong learning Further reading Sign up at engguidebook.com or pragmaticengineer.com. to not miss it

ALT Be strategic on what work you pick up when writing code. By now, you should be one of the most experienced engineers on your team – and, possibly, across the several teams that you work with. You have several ways on how to be strategic about coding, such as: Pick up challenging work, and lead by example in how to solve them, balancing efficiency, quality and maintainability. Focus on pairing with fellow engineers, when those developers could benefit from this. An alternative approach is instead of you leading the charge: to pair with people, and help them grow as developers, and you nudge them. Be more involved in the early coding phase in a project: then slowly let others take over most of the coding. The early stage of a project is when making the right decisions is the most critical. Like setting up the architecture, putting the code structure in place, ensuring tests are written as agreed, and that monitoring and logging is done in-line with how the team agreed to do.

ALT If you work with a dedicated QA person/team: don’t just throw your work “over the wall.” An anti-pattern I’ve observed is how some engineering teams who work with QA folks tend to assume that testing, and quality assurance is purely the responsibility of the QA team. So they tend to just build things, then hand it over for testing – throwing it “over the wall” – not having thought much about edge cases, or how to test things, and not having done even simple, manual tests. Unsurprisingly, what happens in these cases is things take longer. QA finds obvious issues – ones that any engineer doing bare-bones testing on their work would have found –, and hands these back to engineers. Engineers fix these issues, then hand it over to QA, again. QA now finds the more nuanced bugs, which might have escaped the attention of engineers: and hands this back for fixing. Finally, after engineering resolved these, QA does another testing round – the third one! – and declares things as “works as expecte

ALT Typical Software Engineering Career Paths There are more typical, and less typical software engineering career paths. Here are some of the most common ones: 1. The lifelong software engineer 2. The software engineer turned specialist (e.g. specializing in native mobile or large-scale backend systems) 3. The software engineer alternating between generalist and specialist 4. The software engineer turned tech lead 5. The lifelong software engineer turned contractor/freelancer 6. The software engineer turned engineering manager 7. The software engineer turned founder 8. The software engineer turned non-software engineer (e.g. TPM, product manager, 9. The IC-lead/manager pendulum (alternating between leadership and individual contributor roles) 10. The non-linear career path (who said it needs to be linear?) Topics that will make it to The Software Engineer’s Guidebook. Sign up at engguidebook.com or pragmaticengineer.com. to not miss it!

ALT Grow roots At the Staff-level, you might no longer have a “home” team. Plenty of Staff+ engineers are folks who: Support multiple teams and are involved in several projects Are pulled into many additional activities - from strategy discussions, through recruitment, promotion committees, knowledge-sharing sessions, management meetings, and so on. Their “real” manager might be less clear: as they might technically report to one manager, but, in practice, work with several others A danger that happens with engineers who float around too much is that they fail to grow roots on any team and start to feel pulled in too many directions. Without having a sense of what team is their main one: none of them will feel like their priority. Combined with high demands from all teams and projects, this can lead to demotivation and burnout. Make sure you grow roots and have a “main” team at all times. Even if you are supporting multiple teams: make it clear which one your “primary” team and the project

ALT A type of architecture debt: dated languages or frameworks. Although more along the lines of tech debt, using languages or frameworks that are becoming dated - or could become not supported - can also qualify as architecture debt. When using languages or frameworks that are no longer actively supported or maintained, there could be risks with security or problems with interoperability. In some cases, the performance of these languages or frameworks could be significantly worse than modern alternatives. Changing a language or framework is a large enough task that it’s reasonable to consider if some of the architecture decisions should be revisited, as part of a rewrite. For example, when Khan Academy changed languages from Python 2 to Go, they also decided to break up their monolith to smaller services, as well as change from having REST API endpoints, moving to GraphQL. Note that using a more dated language or framework itself does not mean that there’s any kind of debt to be paid off.

ALT Personal connections tend to make everything easier at a company. The larger the company, the more this is true. Why is this? It’s because as a company grows, so does the amount of noise. And personal connections help cut through this noise. Here’s an example I’ve observed so many times: code reviews. At Uber, we had an internal open source model, where any engineering team could make pull requests to any part of the codebase. There were code owners: and if you created a pull request for a part of the codebase that was owned by another team, someone from that team would have to approve the change. My team owned quite a big mobile codebase that other teams frequently wanted to change, and so we got several such pull requests per week: to the point that it was pretty noisy.

ALT As a senior engineer or tech lead, you’ll most likely need to collaborate with a variety of people. Within larger organizations, here are the most common groups: Product. At many companies, product managers are embedded in most engineering teams. They tend to set the strategy of the team, and answer the question “what should be working on and why?” Other engineering teams. To ship projects, your team frequently will have systems it depends on, and teams that depend on your systems. Design and UX. For teams working with UI features, the design team is a key partner. Data science. For teams measuring the impact of their work, this is frequently done by data science folks helping design and run experiments. Customers. End-users using the systems, services, and features your team builds are some of the key stakeholders. It’s ideal if engineers have a direct line to at least some of the customers. Customer support.

ALT Capture current business needs and anticipate future ones Software architecture does not exist in isolation to the business. If we could produce architecture that is independent of the businesses’ needs, then we would have truly ‘best practices’ in architecture approaches: ones that could be blindly used, guaranteed to come with the best trade offs. But these don’t exist, because every organization has different current and future priorities and constraints. Good software architecture keeps the business requirements in mind, and translates them into architecture priorities and constraints. This is true for the current requirements, and the likely future evolution of the business - and the change of requirements. Capture the current business needs. Capture business requirements, as they relate to non-functional requirements like performance, reliability, scalability and others.

ALT How do you go about understanding the business? Build up a mental model on how the company works. How does it make money? What is its strategy? Use internal documents, talks, and other resources. Once you have a rough understanding, get feedback from people like product managers, your management chain, and business people. Fill the gaps in your understanding. Understand how your organization fits into the picture. Again, at first aim to fill out the gaps through your own research, and asking around. Then, ask your manager, your skip level, and perhaps even a level above to explain the strategy of the organization, how your org fits into the picture, and what the main priorities are. Talk with product managers, and ask them to teach you what they know about the business. Product managers tend to be on the hook to answer the questions “what should we build next?” and “what are the key performance indicators our group needs to optimize for?”

ALT Lead by example when you build software. You’re now a role model: expect that people will look to you how you write code, how you include tests, how you do code reviews - and respond to them - and how you roll out changes. The style and pace of your work are also things that people will pay attention to: do you put up daily, small and focused pull requests? Or do you sit on a massive change with 5,000 lines for two weeks, and then go back to fix issues introduced, even weeks later? Assuming you are hands-on, you can make a big difference to the team’s engineering culture just by doing exemplary work, where you don’t cut corners, and where you set the pace of development, just by doing it. I’ve observed the effect that a productive Staff software engineer has on the team, as less experienced engineers do code reviews - on code changes that are easy to understand, and the pull requests are clearly documented - and how these engineers start to “copy” things they see this Staff engineer do

ALT The four common archetypes of Staff-plus roles I encountered are: The Tech Lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities. The Architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership. The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to hotspot as guided by organizational leadership. The Right Hand extends an executive's attention, borrowing their scope and authority to operate particularly complex organizations.

ALT Here are the four archetypes I’ve observed as most common, amongst Staff+ engineers. 1. The Domain Expert. An experienced software engineer who is an expert in one or more domains, and their team and organization often rely on them for being a leader and goto person for this domain. 2. The Organizer. An experienced software engineer who takes on leading large and complex software engineering projects, which often means they need to coordinate multiple teams. 3. The Software Engineer++. An experienced software engineer who is a more effective software engineer than most, leads by example, and improves the software engineering skills of the team that works with them. This archetype is people who keep improving their craft, and become ridiculously efficient in building software. This means they are amazing at designing and building systems, writing easy to maintain code, debugging issues, shipping high-quality work, giving great feedback on code reviews, and mentoring engineers they work

ALT Partnering with product as a staff+ engineer Understand Get up-to-speed product vision, PRDs and other resources your product manager might have done. What are the metrics and measurements that the product cares about? What individuals and teams are the biggest stakeholders for the PM? Get a sense for the PM org dynamics. What is the hierarchy? How does it ovealp (or not) with engineering? Understand your PM more. What do they care about? What are they good at? What are they more passionate about? What are their career goals? What is their influence within the product, and within the team? Catch up Have 1:1s with the product manager. Ask about things like their priorities, the product direction of the team, how they work with other teams. Be curious! Consider regular catch-ups: especially if you don’t yet have a strong relationship with the PM. Share things happening on the engineering side of the world. Share details about team dynamics, as you see them.

ALT Internal politics for software engineers “Politics” has a bad rap amongst most software engineers. If an individual contributor is described as “political”, it almost certainly has a heavily negative meaning. It usually refers to how that person brings little to no contributions, but is seen as someone who works through others, sometimes manipulating them. What about when a software engineer is referred to as “influential” by their peers? This usually refers to how that person is seen to not only have strong technical skills, but is someone who is good at both gathering support for various initiatives: may that be their own ones, or ones for those on the team or in the organization. “Internal politics” and influence within the company are connected, even though we don’t like to refer to influence as politics. Influence is the “good type” of internal politics that I’d argue software engineers should learn to get to, if they want to support their team and eventually progress their own ca

ALT Perceptions which most people assume as “bad” politics are these: Caring about themselves only. If someone is perceived to only care about their career, their projects, their work: this person won’t be making friends. No one wants to work with people - or help them - who give nothing in return, unless it helps their personal goals. Elbowing others out of the way. Even worse than someone who only looks out for their own interests is someone who pushes others out of the way. For example, an engineer hogging a project and not letting others contribute - and clearly doing this to claim the impact of the project for their promotion - should not be surprised if their teammates talk about them in a negative association. Saying different things to different people. If an engineer is perceived as telling people what they want to hear - and telling completely different facts or opinions to different people - this can bite back when those people talk. This type of situation could come about from

ALT Healthy teams. What makes for a healthy team? Clarity. It’s clear why the team exists, what its goals are, and how they get there Execution. The team gets things done. Morale. This is generally good. No conflict. Lack of major confict between team members. Open communication and trust. Common reasons for unhealthy teams Unhealthy: opposite of healthy. It includes lack of clarity, poor execution, low morale, conflict, lack of trust on the team. Poor management. This could mean micromanaging, letting problems stir, inconsistent expectations, playing favorites, biases and many others. “Brilliant jerk”. A bad apple on the team that the manager avoids “upsetting” this experienced person. Lack of feedback. People are unaware how their behaviour negatively affects the team and don’t get this feedback. Lack of skills on the team. The team is missing skills/expertise to execute efficiently. Lack of direction or an ever-changing direction. Treading water: too much operational load. Low morale.

ALT Writing good commit messages and pull request summaries. Chances are, you will work in an environment where you submit code changes as pull requests, describing changes. Describing these changes in a clear and concise way will help getting better feedback - by making it easy for the reviewer to understand the “why” and the “what” of the change. Doing this will also stop you from making unnecessary changes, or things that don’t make logical sense. A few things to help with this: Aim to have small commits where possible. Try to break your changes into smaller steps: each doing one specific thing. Summarize the “why” and the “what” in the pull request. Write no more than a few sentences on why you are making the change - what is the need? - and give a short overview of what you changed. Use images, where UIs have been changed. A picture is, indeed, worth a thousand words. Attach an image of the “before” and “after” states. Mention edge cases covered, and ones not covered.

ALT Iterating quickly in your work environment. Know your tools! Learn your IDE (integrated development environment): get familiar with it, and its capabilities. Spend time on a deepdive. Does your IDE support things like finding within certain files, replacing in the current file, extracting methods, changing variable names, and so on? IDEs are very powerful: but only if you learn how to use them. Shortcuts. A nice to have: for things you frequently do, learn shortcuts your IDE might have. Like building your project, running tests, extracting. Working with version control/Git. You’ll most likely be using Git. Learn your version control tooling, the ideas behind Git: things like brancking, resolving conflicts, cherry picking. Regular expressions might be helpful especially when searching for certain files, or doing bulk editing/renaming.

ALT Automated tests Unit tests. The “baseline” of tests in most environments. Learn how to write expressive tests. Integration, screenshot and end-to-end tests. More complicated to write, and ones that test a broader range of functionality. These tests are usually more fragile as well. With backend, integration tests can be more relevant. For web and mobile, screenshot and end-to-end tests might be used more. Learn about these. Linters and static analyzers. Familarizing with these, and using the very least a linter. Load tests and performance tests. These can be more tricky to automate, but powerful in catching regressions. Continuous Integration and Continous Deployment Undestanding your CI/CD environment. What happens behind the scenes? Accessing CI/CD logs. What happens when checking in code? Running CI/CD commands locally to debug. How can you do this to reproduce and debug when the CI/CD fails? Setting up CI - if it’s not set up yet. Getting familiar with the tooling.

ALT “How can I get to the senior software engineer level ASAP?” This is a common question I get. The expectations of that of a senior software engineer are different across companies, as is the promotion process. However, there are activities that you can do which will help you grow as an engineer. These activities will often help make the case for a future senior engineer promotion, or serve as evidence that you are ready to operate at the senior level when interviewing for another job. Software engineering Educate yourself on engineering practices. Make an improvement to the engineering practices of your team. Something that will make people - including yourself - more productive. Code reviews. Participate in most code reviews on your team. If you don’t understand why a code change was done: ask, and educate yourself. Write a design document on a feature you’re building. Outline the problem, your approach, your architecture, testing considerations, rollout strategy, and so on.

ALT Getting things done Ship a small project to production, end to end, you driving all of this. From planning, through coding, to shipping. Get to the bottom of outages and things that go wrong. If there is an outage happening on either your team or a nearby team, understand what happened and why. Go oncall for your team. If your team has no oncall, volunteer to help out a team that does. Understand the business impact of all the projects you work on. Why are they important? Talk with people on your team, including the product manager or data scientists.