niquet / swe-notes

Notes on software engineering inspired by the book "The Software Engineer's Guidebook" by Gergely Orosz

Notes on Software Engineering

This repository contains my personal notes on various software engineering related topics. The notes are based on 'The Software Engineer's Guidebook' by Gergely Orosz, with additional practical notes on tools, languages, computer science concepts, and other topics.

I recommend reading Gergely Orosz's book, whether you're just starting out or a seasoned engineer. You can find the book at https://www.engguidebook.com/. I also recommend diving deep into software engineering concepts or topics that interest you as quickly as possible.

Getting Started

I have divided my notes into four main categories:

• Career skills - everything you need to steer your career in the right direction,
• Soft skills - everything apart from the development tools that you should know,
• Hard skills - everything around the development tools that will help you become a better software engineer,
• and computer science and software engineering concepts - theory that you can brush up on.

Usage

Contribute

Career Skills

Soft Skills

Getting Things Done

• Get things done, reliably ↔️ Good at breaking down work + Realistic in your estimates + Autonomous in unblocking yourself + Delivering quality work

Focus on The #1 Priority

• Focus on the most important piece of work ➡️ Identify the most important task (your #1 priority) on your list (i.e., If you could only do one thing this week, what would it be?)
• Always get your #1 priority done ➡️ Always deliver your most important task on time, which may require you to turn down other tasks, skip meetings, and put other things on hold
• Learn to say "no" ➡️ If you are at risk of not completing the #1 priority, decline incoming requests to protect your time (e.g., by saying "Yes, I'd love to help, BUT ..." or "Thank you for thinking of me, BUT...")

Unblock Yourself

• Unblock yourself ➡️ When you run into blockers like bugs, missing information, or waiting for code reviews, there are two parts to unblocking yourself: knowing when you are blocked and trying different approaches to unblock yourself
• Rule of thumb: If you cannot make meaningful progress for more than 30 minutes to an hour, admit that you are blocked
• Different approaches for unblocking yourself:
  • Seek help from someone on what to try
  • Do rubber-ducking: Verbalizing a problem sometimes triggers a chain of thoughts that lead to a solution
  • Draw it on paper: Visualizing a problem might give you ideas for what else to try
  • Read documentation and references: You might be using a language feature, framework, or library in a way that it wasn't designed for, or you could be neglecting features already available to solve the problem
  • Use an AI tool: Input the problem and the things you have already and take a look at the suggestions
  • Search online for a similar problem: Describe your problem in various ways as others might have used different terms for the same issue
  • Post a question on a related forum or Q&A site: Explain the problem you have on for example an internal Q&A site or Stackoverflow (additionally, explaining the problem might give you ideas for other solutions to try)
  • Take a break: Go for a walk or switch to an unrelated task and you might see the problem from a new perspective or notice something you missed earlier, when coming bacck to the problem later
  • Start from sratch, or undo all changes: Go back to the last point where eveything worked and restart by making smaller changes, one at a time
• Get support ➡️ Blockers that exist because of a lack of knowledge (e.g., because you haven't seen the problem before) or because you don't have access to the right people are best resolved by reaching out to others who can share the knowledge you don't have
• Easiest way to get support is to let your team know: "Hey, I'm stuck on this issue. Can anyone give me a hand, maybe collaborate with me on this?"
• Learn how to escalate ➡️ If you know what to do, but you are blocked because you are waiting for someone or something, you may need to escalate by asking someone higher or elsewhere in the chain of command to use the authority of their position to communicate your message
• Aim not to harm personal relationships when you escalate ➡️ When considering whether to escalate beyond your team, discuss it with your manager and teammates first
  • What's the norm in your workplace?
  • Do people go straight to their manager, who sets their priorities?
  • Are engineers more autonomous, prefer to handle things themselves, and know when to get their manager involved?
• A holistic approach to escalating:
  1. Explain: Explain why help is needed and provide context for its importance
  2. Ask: Ask why nothing is happening, chances are they have other priorities on top of their mind
  3. Warn:

Break Down the Work

Estimate the Duration of Work

Seek Out Mentors

Keep Your "Goodwill Balance" Topped Up

Take the Initiative