I can get the free PDF version https://abseil.io/resources/swe-book
Ch1. What Is Software Engineering?
Three difference between programming and software engineering are time, scale, and the trade-off at play. As software engineers, we are asked to make moer complex decisions with higher-stake outcomes, often based on imprecise estimates of time and growth.
Programming tasks(development), software engineering tasks(development, modification, maintenance). The addition of time adds an important new dimension to programming.
Time and Change
The life span of software is not one day. it’s not programming assignment or startup development. A transition happens: A program must begin to react to chaning externalities.
Hyrum’s Law
If you are maintaining a project that is used by other engineers, the most important lesson about “it works” versus “it is maintainable”
Why Not Just Aim for “Nothing Changes”?
“For most projects, over a long enough time period, everything underneath them might need to be changed.”
Security problems are disclosed. Your project uses some library. and it depends on risk of containing critical bugs and security vulnerabilities.
Efficiency improvements further complicate the picture.
Upgrading to newer hardware can be diminished. No mistakes were made, but the passage of time still made change valuable. Change is not inherently good. We shouldn’t change just for the sake of change. But we do need to be capable of change
Scale and Efficiency
Site Reliability Engineering (SRE) book. Human costs are not the only finite resource that needs to scale. If the compute cost for your test cluster grows superlinearly, consuming more compute resources per person each quarter, you’re on an unsustainable path and need to make changes soon.
“How long does it take to do a full build?”, “How long does it take to pull a fresh copy of the reposi‐ tory?”, or “How much will it cost to upgrade to a new language version?” aren’t actively monitored and change at a slow pace. They can easily become like the meta‐ phorical boiled frog;
Everything your organization relies upon to produce and maintain code should be scalable in terms of overall cost and resource consumption. In particular, everything your organization must do repeatedly should be scalable in terms of human effort.
Ch2. Culture
Ch5. How to Lead a Team
The Tech Lead
The tech lead (TL) of a team—who will often report to the manager of that team—is responsible for (surprise!) the technical aspects of the product, including technology decisions and choices, architecture, priorities, velocity, and general project manage‐ ment (although on larger teams they might have program managers helping out with this). The TL will usually work hand in hand with the engineering manager to ensure that the team is adequately staffed for their product and that engineers are set to work on tasks that best match their skill sets and skill levels. Most TLs are also individual contributors, which often forces them to choose between doing something quickly themselves or delegating it to a team member to do (sometimes) more slowly. The latter is most often the correct decision for the TL as they grow the size and capability of their team.
Moving from indivisual contributor role to a Leadership Role
You might find yourself sucked into helping your team resolve conficts, make decisions, and coordinate people. Maybe you never intended to beomce a ‘leader’, but somehow it happended anyway.
Antipattern: Hire Pushovers
You should strive to hire people who are smarter than you.
Antipattern: Ignore low performers
The benefit of dealing with a low performer as quickly as possible is that you can put yourself in the position of helping them up or out.
Antipattern: Treat your team like children
If I treat team members like kinds - people tend to act the way I treat them.
