the software engineer's guidebook review

Similar to an earlier post on Clean Code, this is another book overview! The Software Engineer’s Guidebook (shortened to SWEG below) is written by Gergely Orosz, author of The Pragmatic Engineer newsletter. Curious about his process? He shared his experience authoring the book!

With my education budget, I purchased a copy of SWEG! I’ve considered whether to steer my career into leadership or a more technical track. This book is well worth it, covering multiple aspects of both options. I’ll undoubtedly reference this for many years!

Below, we’ll review the book’s first two sections. They cover career fundamentals and building competence, which I chose to focus on because they are the most actionable sections. I also decided to present this part to my team.

Although I cover a lot from the book, I’ve added my own interpretations and content simplifications. What you see here is only brushing the surface.

If any of this interests you, please purchase a copy for yourself! 👌

In this overview, we’ll cover:

1. 🎬 The Presentation
2. 💡 My 3 Big Takeaways
3. 🔨 Career Fundamentals
4. 🔧 Building Competence

🎬 the presentation

I recorded a Loom presentation if you’d prefer to hear and/or visually see this information. It’s about 22 minutes long. Here is a link to the slides!

💡 my 3 big takeaways

1. No one will advocate for your career better than you. Take ownership!
2. Write it down. Yes, everything!
3. Each journey is entirely unique.

🫵 no one will advocate for your career better than you. take ownership!

When stated, it seems obvious. You are in control of your own career. In my Power of Career Change post, I talked about “ambiguous ambition,” where I didn’t have direction in my career path. I am happier actively making goals, completing activities toward those goals, and fulfilling a career trajectory.

I bring related topics to my one-on-one meetings. Here’s a terrific read in a collaboration post from High Growth Engineer on working with your manager(s).

📝 write it down. yes, everything!

Documenting accomplishments, challenges, and projects cannot be understated. Don’t forget to add peer feedback! You will better understand what you’re doing now and what’s next. This is also a solid tool when discussing your role. This could be a promotion conversation aid, a resume update reference, or proof if you are in a sticky situation.

Be consistent and store it on a personal device or account to retain access. I have a weekly reminder, tried a few templates, and currently use a Trello board adaptation. (Other options: Brag Document, Notion, spreadsheet(s), etc.)

🦋 each journey is entirely unique.

Through Meetup, I meet women from all over who reside in my state and work in tech. Their stories and tech roles are different, even if they have the same title! The best we can do is learn from other’s experiences and apply their lessons to our challenges.

Whatever advice, suggestions, and feedback you receive, you are responsible for discovering how and whether to apply it. Gergely did an excellent job clarifying that in this book. The information is a reference, not explicit instructions.

🔨 career fundamentals

The book starts with core aspects of career growth and ideas for reflection. We’ll touch on some concepts, but I encourage you to read it to understand them fully!

“Career paths are diverse, and there’s no simple way to define what a “good” career path looks like, as this varies from person to person. The best you can do is figure out which career path is interesting and achievable for you.”

→ I won’t touch on compensation, company tiers, performance reviews, promotions, and switching jobs here, but the book covers these in detail.

🏢 types of tech companies

There are several types of companies that hire technical workers.

• Big Tech - Large, publicly traded companies that are commonly known (think MAANG; Meta, Amazon, Apple, Netflix, Google, or other variations), with market caps in the billions of dollars. These companies impact hundreds of millions of customers and hire tens of thousands of Software Engineers.
• Medium to Large - Tech-first companies with Software Engineering at the heart of their business, like Atlassian, Dropbox, or Shopify, employ hundreds or thousands of engineers. Though they still offer wide-impact opportunities, their customer base tends to be smaller than Big Tech’s.
• Scaleups - Venture-funded companies are often later-stage startups with product-market fit investing in growth. They may intentionally take a loss or move fast under high pressure. Some examples are Airtable, Klarna, and Notion.
• Startups - Although venture-funded, startups depend on, and may secure, smaller funding rounds and seek product-market fit. They can be risky, less stable, and have poor work-life balance. However, engineers have freedom with work variety and growth due to a smaller headcount. An example is Airbnb (before graduating to a Scaleup).
• Traditional - Often non-tech companies with tech divisions supporting the core business. Think JP Morgan, Toyota, or Walmart. Tech may be considered costly with fewer staff+ paths, but it provides solid work-life balance and stability. Some keep tech front and center. Maybe they started as standouts and are now mature, reliable, and profitable with rigid organizational structures. They typically offer customer impact closer to Big Tech with more stability, work-life balance, and tenure. Examples are Broadcom, Cisco, Intel, and Nokia.
• Other - Examples are non-venture-funded (bootstrapped) companies, the public sector or government, nonprofits, consultancies/outsourcing/developer agencies, and academia or research labs.

With such variety, how do you know what’s right for you? That may take some thought. Narrow realistic options based on your circumstances. Talk with other engineers to learn about their experiences and ask questions!

👟 types of career paths

Once you find a role, how do you determine a path? Each is unique and could change over time, but how do you get there?

☝️ The Single-Track Career Path - In some cases, engineers move from an IC (Individual Contributor) role to management. They may remain long-term or later return to engineering if unsatisfied, possibly moving companies in the process.

✌️ The Dual-Track Career Path - This is the flexible path; it’s probably more applicable to most because of that flexibility!

Some engineers stick with IC, some follow the single-track path, and some switch between them.

⚖️ cost centers and profit centers

Some teams or projects are considered cost centers, while others are profit centers. Each has valuable experience, and working in both provides a more well-rounded engineering perspective.

📉 cost centers

Cost centers are needed for smooth operation, but they don’t typically generate business income. The challenges tend to be more interesting. Experienced engineers may join a cost center to build creative solutions for more significant problems. A downside is turnover. These teams are often targets when businesses need to reduce costs or engineers seeking career advancement could transfer to a profit center team.

💰 profit centers

Put simply, profit centers directly generate revenue for the business. Promotions can be more achievable in a profit center; it’s usually easier to reward profit! Performance reviews usually get better “scores” and bonuses, too. Engineers may join a profit center team to focus on growth or more straightforward challenges.

✨ career progress alternatives

There’s more to a career than finances and benefits, right? Absolutely! Here are a few to consider in your long-term career.

• Culture - Consider if you align with the mission and values of your company. Do you appreciate any societal contribution they provide?
• Flexibility - Do you have set or flexible hours? Is your role in-office, remote first, or hybrid? There may also be an on-call rotation to consider.
• Personal - You may prefer to “leave it at work.” You may have your own reasons for (dis)liking a company or a team. These are perfectly valid.
• Health - Consider actual or possible effects on your physical or mental health.
• Growth - Are there opportunities for growth or options to progress your skills and career? You don’t want to stagnate!
• People - This includes your relationship with your manager and peer dynamics.

🎯 owning your career

No one else will advocate as well as you can throughout your career.

🏹 you’re in charge

It’s up to you! Set goals, track goal efforts, and iterate. Managers don’t usually have enough bandwidth to grow individual careers. Here are some ways to take charge:

1. Tell your manager(s) and peers what you care about.
2. Share work you did that others may not notice.
3. Create opportunities for feedback from others.

🏆 be seen as someone who “gets things done”

The easiest way is actually to get stuff done! Ideally, your work is high-quality and completed reliably. Finish the work you commit to and overdeliver when you can.

Spend your efforts on impactful projects. How do you find these? Explore and ask questions to understand team and business priorities. Focus on these essential tasks.

Talk about things you complete! Don’t go overboard, but your manager should definitely hear about it. Share it if there is a measurable business impact, the work was unusually complex, or it took great effort.

✏️ keep a work log

Identify and stick to a solution and a cadence that works for you. What should you track? Significant code changes, code reviews, design docs, discussions, planning, helping others, postmortems, and anything else that takes time and has an impact.

A work log is powerful for identifying priorities and keeping them top of mind. You may feel empowered to say “no” or re-prioritize. Viewing completed work can bring a sense of accomplishment, too. It’s an incredible reference to quantify your impact.

💬 feedback

Give and receive feedback as often as possible!

So, if someone shares constructive feedback with you, remember it would’ve been easier for them to say nothing. Keep this in mind if your instinct is to react defensively.

Receiving:

• Hopefully, others will be respectful. Even if they’re not, there are useful nuggets.
• When you receive unclear or unsolicited feedback, ask for specific examples or clarify the impact to help uncover the useful nuggets.
• At times, you may need to seek out feedback actively.
• Regardless of whether you asked for it, you decide if you enact the advice.

Giving:

It’s helpful to consider your approach for positive and critical feedback.

• Positive: Call out good work when you really mean it. Share specifics about what you liked and why.
• Critical: Make it clear that you want to help and try to end positively. Focus on situational observations and impacts, clarify that it’s only an observation, and avoid telling them what to do. Deliver a critique in person (or via video) to reduce the chances of miscommunication.

🤝 ally with your manager

Your manager will impact your career. It’s a significant workplace relationship! One who believes in, advocates for, and supports your career goals can make a huge difference. How can you foster this relationship? It takes time.

Proactively share your log and accomplishments, ask for specific feedback, and discuss professional goals in regular one-on-ones. They have a lot on their plates!

Show reliability! Build trust by delivering what you agree on and providing updates when you don’t. You should be open, honest, and transparent to your comfort level. Hopefully, it will be mutual. Don’t forget to ask for help when needed!

This relationship isn’t only about you. Take time to understand their goals and challenges. You might help each other, or you may learn more about team nuances to identify opportunities in the future. Try to handle a task weighing on the team, especially if it helps you grow. Your manager is human; empathy can go a long way!

🐢 pace yourself

The “Stretching, Executing, Coast” method can help prevent burnout. These are states of being in your day-to-day. Navigate between them.

• Stretching can be hard but worth it! Initially, it is the most fun; you learn new things and grow quickly. You likely have fresh challenges to embrace!
  • Extended periods lead to burnout or a loss of motivation. Surround yourself with trusted people to help identify if you’re pushing too hard for too long.
• Executing is your “normal” way of working and getting things done well. When you have the capacity to go beyond, do so, but in ways that don’t overstretch you.
  • This is especially useful after a stretching period to avoid burnout.
• Coast when needed, but it should only be a few days. You may work at lower quality, not be proactive, and need task nudges in this state.
  • It could be a breather after a tough project, catching up, or a mental break due to personal circumstances or symptoms of low motivation. If this extends, consider what must change ahead of a difficult conversation!

🤔 owning your own career advice

• Take a long-term view. Careers are not straightforward!
• Find your own happiness. Don’t let promotions and titles define your self-worth.
• Resist envy and avoid comparing yourself with others. It’s all about demonstrating impact when opportunities are not evenly spread out.
• Play well with others. Don’t “elbow” people out of the way. You will only benefit by getting along well with others and helping each other.

🌱 thriving in different environments

There are different modes of work environments. Learning to work in each has a well-rounded result as companies and teams may shift over time.

First, we’ll compare product and platform teams. Rotating between these builds empathy for various “customers.”

• Product Teams build products for external customers through quick validation cycles.
  • Engineers are interested in the product and proactive with ideas and opinions. They are usually interested in the business, user behavior, and relevant data.
  • They are curious about the “why” and build relationships with non-engineers through strong communication.
  • End-to-end product feature ownership is common.
  • To thrive: seek feedback, embrace curiosity, learn about the business, and build relationships.
• Platform Teams build functionality to support business-facing internal customers. They are key in high-growth engineering organizations.
  • Engineers are focused on a technical mission often used by multiple teams.
  • They are often experienced engineers who seek complexity with wider impact.
  • Business impact can be harder to define. Frequently seen as a cost center, these teams are distant from external customers.
  • To thrive: build empathy for internal customers, talk to (and work with) engineers using your platform, and aim for some urgency.

Next, we’ll cover company modes: peacetime and wartime.

• Peacetime is a calm and steady state that focuses on expansion and reinforcing strengths. The company has a current market advantage!
  • Take your time, complete your work with high quality, and focus on longer-term initiatives that will benefit the business.
  • Avoid disputes and foster relationships.
  • Continue to learn and grow; avoid stagnation, but still pace yourself.
• Wartime occurs when the company’s existence is at stake! Competition may be fierce, the core market turbulent, or an imminent threat may exist.
  • Get things done quickly. Don’t focus on perfection.
  • Don’t take conflicts personally; the strained context usually causes them.
  • Prioritize business needs. Work like your job depends on it…it might!
  • Pace yourself to avoid burnout!

🔧 building competence

The following are essential things to master to be considered a reliable and “competent” developer from the book’s second part.

These things take time; keep pushing forward!

💪 getting things done

Competent engineers are good at breaking down work, providing realistic estimates, unblocking themselves, and delivering quality work.

How do they do this?

Focus on the single MOST important thing first, no exceptions. Learn to say “no.” Necessary things arise, but this adds up. It’s a balancing act. I like the offered tactic of, “Yes, I’d like to help, but…” to provide context for your “no.”

Unblocking yourself is a skill! Start to identify when you’re stuck, like spending more than 30-60 minutes without meaningful progress.

Leverage ideas to get unstuck:

• talk to a “rubber duck”
• draw it out
• read docs
• use an AI tool
• search online
• check forums
• take a break
• or start over

After a solid solo try, seek help! Asking for help is great, but come prepared to share what you’ve done to avoid wasting others’ time.

What if a person blocks you? This is more common at larger companies, and getting contact help is sensible. You may need to escalate delays, but handle this delicately to retain relationships!

Effectively breaking down work takes thought. Begin at a high level and identify “chunks” of work. Then, narrow “chunks” into straightforward tasks. If they’re unclear, break them down again. Don’t be afraid to add, remove, or change tasks.

Estimations are challenging. You will be asked. Use your (and peers’) experiences with the codebase, language, or similar work to provide estimates. When that’s not possible, prototype and timebox. You can also provide ideal and “worst case” options when there are unknowns, leaning toward the “worst case.”

Find mentors to help you grow. This is a group of people, not one person. You may look to more experienced engineers through a formal work program or informal, ad hoc one-on-one requests for help. Don’t forget about online mentors who share their experiences more publicly in blogs, podcasts, or books.

Retain a positive “goodwill balance” and help others, too. You’ll need help, and this balance level spans a spectrum. You will have a higher balance when you first start (as a junior or during onboarding). People want to help! But, as you take, be sure to give back with your expertise. Give thanks either privately or in a public team setting.

Take initiative when you can. Some of the most productive engineers take on work that wasn’t assigned! Talk with others to learn about projects and opportunities to volunteer. Try to document unclear things, take on investigations, research tools or frameworks your team uses, and talk with your manager about upcoming projects.

⌨️ coding

Practice. Practice more. You need to be proficient to translate your ideas into working code efficiently. Here are some ways to practice:

• Code regularly and ask for code reviews. These are invaluable!
• Read as much as you write. This helps avoid unusual habits, styles, and conventions. Check out open-source code for more reading opportunities!
• Code some more. Build a side project, complete tutorials with coding exercises, do coding challenges, or complete code katas.

👀 readable code

Crafting code that others can read (and maintain) is equally important as code that is correct. What readable code actually is may vary by team, company, and language. Ultimately, if you and others you work with can easily understand it, then it’s readable!

You can practice this by revisiting the code you drafted to improve it before asking for a code review. When you receive feedback in code reviews, try to implement and understand them. Coding is a social activity; pay attention to the questions reviewers ask and ask follow-up questions. They might hold clues to improving readability!

✅ writing quality code

Like all of the other advice in this section, this comes with practice. Some things to work on include using the correct levels of abstraction, handling errors well, and being wary of “unknown” states. In any case, you may have to experience these things to learn to do them well.

😎 software development

Wouldn’t you know it? As you go along, there are also software development-specific things you can work on!

👌 become proficient in a language

Learn the fundamentals and work to understand advanced features. You can consult docs, find a good reference, look at code examples, study a book, or watch videos. Then go deeper! Learn about what happens “behind the scenes.” It’s recommended to go deeper before going more broad.

Master the “main” framework you use with a language. You can follow the same approach as learning a new language. Open-source frameworks have the added benefit of a visible codebase to see “under the hood.”

Once you have a good handle on one language, learn a second. It doesn’t have to be done arbitrarily; seek out helpful opportunities! AI as a tool can aid you to learn faster, too. Doing this helps you better compare language strengths and weaknesses and, hopefully, keeps you from repeatedly using the same language.

🐞 debugging

Get to know your IDE. Some of them have really powerful runtime debugging tools! You should also watch more experienced developers debug, perhaps during a paired debugging session.

Although it sounds counterintuitive, learning to debug without tools can be helpful. There’s the well-known console.log method, but you can also use paper to draw/write it out or write unit tests to help pinpoint issues.

♻️ refactoring

This also takes practice! Make this an everyday habit and work on it, starting with your own. After you write code, revisit it and see what you can improve. Some IDEs have refactoring capabilities. Look at yours and give it a shot if yours has this ability. Code reviews can give you more ideas for refactoring. It’s a good idea to give them a shot!

Reading through code should provide new insights: you can deepen your knowledge of the codebase and begin to spot inconsistencies. Make notes as you go along and seek feedback to see if a refactor is worthwhile before diving in. For an easier start, you could look at refactoring tests and the helpers for those tests. It will deepen your codebase understanding; ideally, others will be able to better understand.

🧪 testing

Speaking of tests, competent software developers ensure their code works, plain and simple. Before requesting a code review, they test the code. Preferably, your team will use automated testing to make this more seamless. In any case, reliable developers care deeply about edge cases and work to cover their work as much as possible.

🧰 tools of the productive software engineer

We’ve covered a lot already, but there are a few more things to consider.

• Your local development environment. Get to know it well and become more efficient. Learn the ins and outs of your IDE or coding text editor of choice, like refactoring, compiling, running the project, hot reloading, debugging, running and debugging tests, or creating a PR. Configure your workflow, learn shortcuts, and set up formatting and linting, if needed. The smoother this is, the less context-switching you’ll have to do.
• Frequently used tools. Get to know these and practice using them:
  • Git - branching, rebasing, resolving conflicts and merging, cherry-picking
  • Command line/terminal - often within many IDEs; start using it for tasks!
  • Regular expressions - learn some; it can be useful
  • SQL - learn the basics
  • AI - give it a whirl to boost your productivity; there are inline coding assistants and generative AI chat interfaces to “talk through” concepts
  • Company-specific developer tools
  • A “productivity cheat sheet” - create your own doc full of references!
• Learn to iterate quickly. Here are some ideas:
  • Read existing code to understand what it does. Ask someone to walk through the structure, draw it out, share your code map, and create a cheat sheet to help you learn it.
  • Make small code changes when possible.
  • Learn how to debug the CI/CD for your project(s).
  • Learn how to access production logs and dashboards.
  • Run and write automated tests and checks.
  • Don’t just wait for code reviews; ask for them!
  • Get frequent feedback by building things!
  • You can compare team member outputs but only to gauge iteration speed. Because career trajectories vary, don’t generally compare yourself to others.

I hope that this information is concise and digestible while also being helpful!

The book was excellent, filled with ample stories, examples, and actionable advice I didn’t cover that can be used at any career level in the current tech environment.

Get yourself a copy, too, to reference as you navigate your career!