Staff Engineer: Leadership Beyond the Management Track

The book explains different senior individual contributor roles, such as Tech Lead, Staff Engineer, and Software Architect. More importantly, it explains what is expected from these roles beyond technical expertise.

And that is probably the most valuable part.

At this level, engineering is no longer only about writing better code yourself. It is about creating leverage. You are expected to influence technical direction, improve collaboration, guide decisions, mentor others, and help the organization make better trade-offs.

In that sense, the book gives a useful map for engineers who want to grow without becoming managers. It also gives practical guidance on how to move toward these roles, what kind of work gets you there, and what expectations usually come with the title.

That said, I think the relevance depends heavily on context.

If you work in a smaller company, this book may not be that useful. Many smaller organizations simply do not have such a clearly defined individual contributor ladder. The same person may be developer, architect, tech lead, mentor, and delivery driver all at once — without anyone calling it “Staff Engineer.”

I also doubt the book is highly relevant if you or your company do not care much about titles. A lot of the book is about understanding the shape of these roles inside larger organizations. If your environment is more pragmatic and less title-driven, the value is more limited.

The second half of the book contains stories from people who took that career path. I skipped those completely. Maybe they are useful if you want personal career examples, but for me they were not worth the time.

TLDR;

The book is useful if you want to understand how senior technical roles work in larger companies and how to grow beyond the management track. It is less useful if you are mostly interested in better engineering practices, smaller-company realities, or hands-on technical leadership without the title system around it.

Thinking Fast and Slow

The key idea

The core thesis of the book is that our thinking can be described as two systems.

System 1 is fast, automatic, intuitive, and effortless. It helps us recognize patterns, react quickly, read emotions, and make instant judgments. But it also jumps to conclusions.

System 2 is slow, deliberate, analytical, and effortful. It helps us calculate, reason, compare options, and question assumptions. But it is also lazy.

Most of the time, System 1 creates an answer first, and System 2 only checks it if there is enough reason or energy to do so. That means we often feel rational while we are actually just justifying our first impression. And because System 1 is very good at creating coherent stories from incomplete information, wrong conclusions can still feel obviously true.

This is not just interesting psychology; it has very practical consequences for how we explain ideas, make decisions, give feedback, and collaborate as software engineers.

5 practical takeaways

1. Make the missing context visible

One of the strongest ideas in the book is: What you see is all there is.

People reason based on the information available to them, not based on all the information that would be relevant. And definitely not based on all the context you have in your head.

This matters a lot in collaboration. When people disagree with your proposal, they may not be irrational. They may simply see a different part of the problem.

So before arguing for a solution, make the context visible. What problem are we solving? What constraints do we have? What alternatives did we consider? What information influenced our conclusion?

Better context often creates better alignment.

2. Do not trust confidence too much

The book shows again and again that confidence can be misleading.

A conclusion can feel correct simply because the story in our head is coherent. But a coherent story is not the same as a true story.

This is important in discussions, planning, and architecture decisions. Someone may sound very confident and still be wrong. And that someone may be you.

A useful habit is to ask: What evidence would change my mind?

This moves the discussion away from confidence and toward verification.

3. Use framing consciously

Kahneman shows that the way information is framed influences how people judge it.

The same facts can lead to different reactions depending on how they are presented. That does not mean we should manipulate people. It means we should be responsible with framing.

In collaboration, this means we should be careful how we present problems, risks, and proposals.

“Refactoring this module will take two weeks.”

creates a different reaction than:

“Every new feature in this area currently takes longer because this module is hard to change. Spending two weeks on refactoring should reduce the cost of all future changes in this area.”

Same topic. Different frame. Different understanding.

Good communication is not only about being logically correct. It is also about helping others see the point clearly.

4. Make comparison easy

System 2 is slow, effortful, and lazy.

So if we want people to think carefully, we should not make the thinking unnecessarily hard.

This matters when we present options. Long verbal explanations are difficult to compare. People will often anchor on the first option, remember the most vivid argument, or simply follow the most confident person in the room.

A small decision table is often better:

• option
• benefit
• cost
• risk
• when it works
• when it fails

This does not make the decision automatic. But it makes careful thinking easier.

5. Slow down important decisions

Fast thinking is useful. We need intuition, experience, and quick judgment.

But the book is also a warning: intuition is not reliable everywhere.

For important decisions, we should deliberately slow down. Especially when the decision is expensive, risky, hard to reverse, or emotionally loaded.

Write the decision down. List alternatives. Separate facts from assumptions. Ask what could go wrong. Use an ADR when the decision matters.

Not because documents are magic.

But because writing forces System 2 to participate.

Conclusion

Do not believe everything you think. 😉

Radical Candor

Some time ago I started looking for material on how to become more effective inside an organization.

Technical skills alone are rarely enough.
At some point, the real challenges become communication, feedback, and collaboration.

That search eventually led me to Radical Candor.

What immediately caught my attention was the subtitle:

How to get what you want by saying what you mean.

That sounded exactly like the kind of practical advice I was looking for.

What I Took Away From the Book

While reading the book, I found several helpful ideas and practical hints.

Many concepts felt familiar because I had encountered similar ideas in the past, particularly in books by Tom DeMarco.
Still, it was useful to see these principles applied specifically to leadership and management.

The central idea of the book is simple but powerful:

Good leadership requires a balance between caring personally and challenging directly.

Managers should be honest and direct with feedback, while also showing genuine care for the people they work with.

That balance is what the author calls Radical Candor.

My Perspective

I am not a people manager myself.

My role is closer to that of a technical lead or staff engineer, so I skipped some sections that focus heavily on day-to-day management topics like hiring, performance reviews, or team administration.

However, many ideas in the book are still highly relevant even if you are not managing people directly.

In any technical role, you constantly interact with colleagues, give feedback on work, and discuss decisions.
Learning how to do that clearly and respectfully is an important skill.

Final Thoughts

Overall, I would say the book is definitely worth reading.

That said, it is probably most valuable for people managers or aspiring managers.

If you mainly work in technical roles, you will still find useful insights, but some parts of the book may feel less relevant.

Still, the core idea is simple and powerful:

Clear, honest communication combined with genuine care for people can dramatically improve how teams work together.

And that is a lesson that applies far beyond management.

At first I could not make much sense of the first part of the title, but I bought the book anyway. After reading the introduction it suddenly made perfect sense, because already there I learned:

In systems thinking, a system is more than just the sum of its parts.

A system is something that maintains its existence and functions as a whole through the interaction of its parts.

Your body is the perfect example. It consists of many different parts and organs, each acting separately yet all working together and each affecting the others.

The Art of Systems Thinking: Essential Skills for Creativity and Problem Solving

Once you start looking at the world through the lens of systems thinking, you begin to notice systems everywhere. We live in a world shaped by systems: political systems, economic systems, belief systems, organizations, teams - and of course software systems.

One quote from the book captures this shift in perspective very well:

If you cut a system in half, you do not get two smaller systems, but a damaged system that will probably not function.

This illustrates why traditional scientific analysis - breaking things into smaller pieces - only provides a limited understanding. Many important behaviors arise from the interactions between parts, not from the parts themselves.

To truly understand systems - whether a team, an organization, or a complex software system - we must respect this idea.

This is especially relevant in software engineering.

A team is more than a group of individuals. An architecture is more than a collection of modules. A development process is more than a sequence of activities.

What actually shapes the outcome are the connections and dependencies between the elements.

This book provides a framework for thinking about exactly that. It encourages you to step back from isolated incidents and ask a much more useful question:

What kind of system is producing these results?

Instead of focusing on individual mistakes or symptoms, systems thinking pushes us to examine the structure that creates the patterns we observe.

The behavior of a system is largely determined by how its components interact, not simply by the components themselves.

Many of the most interesting properties of a system belong to the whole, not to any individual part. When we take a system apart to analyze it, we often lose exactly the properties we were trying to understand.

Because the elements within a system influence each other, systems often resist attempts to change them. But when change finally happens, it can sometimes occur abruptly and dramatically.

A key shift in systems thinking is moving away from linear cause-and-effect reasoning. Instead of straight lines, systems are better understood as circles of influence.

The essence of systems are feedback loops, which we can split into two types:

• reinforcing feedback, which amplifies change and pushes the system further in the same direction
• balancing feedback, which counteracts change and stabilizes the system

All systems have a goal, a desired state where the system tends to settle or remain balanced.

Another important aspect of systems is delay. Cause and effect are often separated in time because feedback loops take time to complete. This is one reason why systems can behave in ways that appear confusing or counterintuitive.

Most systems contain certain points where small adjustments can lead to disproportionately large results. These leverage points are far more effective places for intervention than applying more effort everywhere.

Interestingly, some of the most powerful leverage points lie in mental models.

Mental models are the beliefs and assumptions we rely on to interpret the world. They shape how we understand cause and effect and how we decide to act.

In that sense, our mental models themselves form a kind of system. If these internal models are incomplete or flawed, we may unknowingly recreate the same systemic problems.

Learning can also be viewed through a systems perspective.

Learning follows a feedback pattern: we take action, observe the results, adjust our understanding, and act again. Over time this cycle moves us closer to our intended outcome.

Since the world is always richer than any single representation we hold, it is important to consider multiple perspectives. Broadening our viewpoints expands our mental models and improves our ability to understand the system.

The final part of the book demonstrates how systems can be visualized through diagrams and causal maps. Making relationships and feedback loops visible helps turn vague intuition into something that can be analyzed and discussed.

When you work in a great team, it’s one of the most enjoyable aspects of the job. But when teams don’t function well, the amount of friction can be enormous.

A key factor behind great teams is great technical leadership.

Good tech leads are not only strong in technical topics. More importantly, they need leadership skills.

In that regard, military teams and software teams are not so different. Both operate under pressure, must coordinate complex work, and rely heavily on trust and clear communication.

If you want to understand what truly matters in leadership, this book is an excellent resource.

That’s why I picked this book, and if you are a tech lead - or want to become one - I highly recommend reading it.

Extreme Ownership: How U.S. Navy SEALs Lead and Win

The book presents 12 principles to “lead and win.”

Each chapter follows the same structure:

A story from Navy SEAL operations in Iraq that sets the stage for the principle and helps build an intuitive understanding of why it matters.
If you are not interested in the military details, these sections can be read quickly.

The principle section then explains the core idea.

Finally, the business section shows how the principle applies in organizations and teams.

Here are the 12 leadership principles from the book.

1. Extreme Ownership

The leader must own everything in his or her world.

Leaders must take full responsibility for everything in their team’s results. There are no excuses and no blaming others. When leaders own failures, they can fix the real problems.

2. No Bad Teams, Only Bad Leaders

When it comes to standards, as a leader, it’s not what you preach, it’s what you tolerate.

Team performance reflects leadership quality. If a team fails, the leader must change the approach rather than blame individuals. Good leadership can turn around even poorly performing teams.

3. Believe

In order to convince and inspire others to follow and accomplish a mission a leader must be a true believer in the mission.

Leaders must truly believe in the mission. If they don’t, they cannot convincingly communicate it to the team. Understanding the “why” is essential to gain commitment.

4. Check the Ego

Ego prevents learning, collaboration, and effective decision-making. Leaders must stay humble and open to feedback. Mission success is more important than personal pride.

5. Cover and Move

Teams must support and protect each other to succeed. Success depends on collaboration between units rather than isolated efforts. The entire organization must work as one team.

6. Simple

And when things go wrong — and they inevitably do — complexity compounds issues that can spiral out of control into total disaster.

Plans must be simple and easy to understand. Complexity creates confusion and increases the risk of failure. Clear and straightforward plans improve execution.

7. Prioritize and Execute

“Relax, look around, make a call.”

When multiple problems arise, leaders must focus on the most critical one first. Solve issues step by step instead of becoming overwhelmed. Calm prioritization enables effective action in chaos.

8. Decentralized Command

Every tactical-level team leader must understand not just what to do but why they are doing it.

Decision-making authority should be pushed down to leaders closest to the problem. Everyone must understand the mission well enough to act independently. This creates speed, flexibility, and resilience.

9. Plan

Leaders must carefully plan missions and involve key team members in the process. Clear communication of the plan ensures everyone understands their role. Preparation reduces uncertainty and improves execution.

10. Leading Up and Down the Chain of Command

Leaders must manage relationships with both superiors and subordinates. If higher leadership doesn’t understand something, it’s the leader’s responsibility to explain it clearly. Ownership extends both upward and downward.

11. Decisiveness Amid Uncertainty

There is no 100 percent right solution. The picture is never complete.

Leaders must make decisions even when information is incomplete. Waiting for perfect certainty often leads to missed opportunities. Timely action is usually better than hesitation.

12. Discipline Equals Freedom

Discipline in planning, training, and execution creates freedom in operations. Consistent discipline reduces chaos and improves performance. The more disciplined the team, the more effectively it can operate.

Final Thoughts

While reading the book, I could immediately relate many of the principles to my daily work.

If you take a fresh look at how your team operates,
I’m pretty sure you’ll recognize some of the same patterns.

And that’s a good place to start improving.

We can use it as intelligent auto-completion, or ask it to implement entire features.

But to get good results, we need to engineer good prompts.

That’s why I picked up Prompt Engineering for LLMs. Here’s what I learned.

Prompt Engineering for LLMs: The Art and Science of Building Large Language Model-Based Applications

The book primarily targets developers who want to build LLM applications. Think of a chat application like ChatGPT or a coding assistant like Copilot.

But even if you do not plan to build such systems yourself, understanding how these applications are constructed gives you deep insight into how today’s LLMs and LLM-based products really work.

The book is divided into three parts.

Part 1 – Fundamentals

The first part covers the fundamentals of large language models.

It explains how they work, how they process data, what they can do, and just as importantly,what they cannot do. It also introduces the core architecture of LLM-based applications.

This section is especially helpful if you mainly use LLMs but want to understand what is happening behind the scenes. It builds the conceptual foundation you need before thinking about prompt engineering in a more systematic way.

Part 2 – Engineering Prompts

The second part focuses on prompt engineering itself.

Some of the concepts are useful for everyday users of LLM tools. But the primary audience here is developers who design and build LLM applications.

This section explains how to gather relevant content, how to structure and preprocess that content, and how to assemble effective prompts using different techniques. It moves from theory to applied engineering and shows how prompts are not just “questions,” but carefully constructed inputs that shape the model’s output.

Part 3 – Advanced Topics

The third part goes deeper into advanced topics.

It discusses integrating tool execution into prompts and building more capable LLM applications. It covers how to simulate reasoning, how to design conversational agents, and how to structure larger LLM workflows.

The book concludes with a discussion about evaluating the quality of LLM applications once you have built them - which is an important and often overlooked aspect.

Final Thoughts

If you simply want to use LLMs more effectively in your daily work, you probably do not need to spend the money. There are cheaper resources that teach basic prompt tips.

But if you want to deeply understand how LLM applications work internally - and eventually build your own - this is a solid book.

Beyond Vibe Coding cuts through the hype and draws a sharp line between short-term velocity and sustainable AI-assisted engineering.
It explains why prompting is really about expressing intent, why fundamentals still matter, and how juniors, mid-levels, and seniors must adapt differently in the AI era.

Beyond Vibe Coding: From Coder to AI-Era Developer

AI tools are now part of everyday development.
The real question is not whether we use them - but how.

How do we integrate AI without sacrificing quality, maintainability, and engineering discipline?

Beyond Vibe Coding: From Coder to AI-Era Developer attempts to answer exactly that.

The book introduces a useful distinction:

• Vibe coding optimizes for short-term speed.
• AI-assisted engineering optimizes for sustained velocity and reliability.

AI can accelerate you - but only if it is embedded in real engineering practices.

Programming With Intent

The central shift the author proposes is subtle but important:
AI development is not about generating code - it’s about expressing intent clearly.

Prompting, in this view, is less about clever tricks and more about communication discipline:

• Provide context
• Be specific
• Avoid overloading
• Refine iteratively

Treat AI like a junior developer. Give direction. Review the results. Iterate.

The book introduces techniques such as role prompting and chain-of-thought reasoning, but the deeper takeaway is this: effective prompting requires structured thinking.

The 70% Problem

One of the strongest ideas in the book is the “70% problem.”

AI can reliably scaffold a feature, generate boilerplate, or get a system mostly running.
But the final 30% - domain-specific decisions, edge cases, architectural trade-offs - remain human territory.

AI handles accidental complexity well.
Engineers still own essential complexity.

That distinction matters.

• You must understand the generated code
• You must review and test it
• You must debug it when it breaks
• You must not merge what you cannot explain

The last 30% is where real engineering begins. For juniors especially, skipping that part risks long-term skill atrophy.

Practical Guidelines

The book reinforces pragmatic, almost conservative engineering habits:

• One task per session to avoid context confusion
• Keep prompts concise and focused
• Treat AI output like code from a junior developer
• Don’t merge what you don’t understand
• Provide coding standards and architectural rules explicitly
• Share effective prompts within the team
• Reflect and iterate regularly

In short: AI does not replace engineering practices - it amplifies them.

Adapting to the AI Era

The book makes one thing clear: AI does not level the playing field.
It changes how each experience level creates value.

For seniors, AI is leverage.

• Act as architect and editor-in-chief
• Use AI to accelerate large refactorings and strategic improvements - without losing control
• Continue cultivating domain mastery and long-term foresight

Experience becomes more valuable, not less.
AI amplifies judgment.

Mid-level engineers are encouraged to grow beyond feature implementation.

• Build deeper domain expertise
• Take ownership of code review and quality assurance
• Develop systems thinking, architecture, and design skills

The shift is subtle but important: move from writing code to understanding systems.

For juniors, AI is an accelerator - but only if fundamentals are solid.

• Learn the fundamentals - don’t skip the “why”
• Practice problem-solving and debugging without the AI safety net
• Build an eye for maintainability
• Develop prompting and tooling skills deliberately

AI can speed up progress.
It cannot replace foundational understanding.

Final Thoughts

If you are new to AI-assisted development, this book provides a structured and grounded starting point.
It helps you avoid common mistakes and establish sustainable workflows from the beginning.

If you have already experimented extensively with vibe coding and developed your own patterns, you may find fewer surprises. The book consolidates solid ideas rather than introducing radically new ones.

Still, it offers an important reminder:

While tools evolve, software engineering fundamentals still apply.

Pull Requests (PRs) were invented for Open Source projects. They allow “untrusted contributors” to suggest changes and ask “trusted committers” to pull them in. Committers review these requests on their own schedule, leave comments, demand changes, or simply reject the “pull request” altogether. For this reason, PRs work extremely well in Open Source.

Work in commercial teams is fundamentally different. Team members collaborate long-term, share goals, and trust each other. Changes are not “suggested” but planned - it’s rarely a question of whether but how something gets done.

PRs were not made for this. They optimize for control and gatekeeping, while commercial teams optimize for flow and delivery speed without sacrificing quality.

Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.

Kief Morris, Why your team doesn’t need to use pull requests

Motivation

Many great articles and YouTube videos already discuss this topic - see the references - including well-known voices like Dave Farley, author of “Continuous Delivery”.

This article provides a concise overview of the real-world consequences of PRs for commercial teams, written for managers and team leads.

Setting the Stage

Before getting into the arguments, let’s clarify a few facts.

Git ≠ PR

Git doesn’t require Pull Requests. It’s a version control system that works perfectly well without them.

Code Review ≠ PR

Code reviews are valuable for code quality, knowledge sharing, and finding bugs. PRs are not required to practice code reviews.

Working incrementally

Developers rarely complete a feature in a single commit. Bug fixes might fit in one, but most features need multiple commits to be completed.

How Pull Requests work

Pull Requests always require a branch. A PR can contain one or many commits. It is a “gated submission”: changes are integrated into mainline only after all gates have passed - usually automated tests and code review. A developer cannot start a second PR on the same branch; further changes will update the existing PR.

The Arguments

Passing gates takes time

Running build pipelines takes time. The larger the codebase, the longer it takes. Reviews take time as well. A PR may wait hours or even days for review. If reviews are expected immediately, context switching creates new problems (see “reviewing code immediately”).

Continuing on the same task during PR verification is difficult

Feature work usually requires several changes. While one PR is under review, continuing the same story requires creating a new branch from the first one. This adds effort and becomes messy if the first PR fails validation.

Bigger PRs

To avoid this overhead, developers tend to group several changes together and open one PR when the story is finished. As a result, a single PR often contains multiple logical changes.

Longer-living branches

Producing more changes takes more time, which means feature branches live longer.

Delayed Feedback

The longer branches live, the longer feedback gets delayed - from tests, from teammates reviewing the design, and from product owners or users who can only verify that the right feature was built after integration.

Higher reluctance to apply global refactorings

The longer branches live, the higher the reluctance to apply refactorings that span multiple files or affect public APIs because developers fear the effort of complex merges. Skipping refactoring means not paying back technical debt, which means lowering code quality.

Bigger integration chunks

The bigger the PR, the bigger the chunk of code changes that is integrated at once into mainline.

Higher merge complexity

The bigger the chunks that get integrated, the higher the risk of complex merges. Complex merges cause more effort.

Higher risk of bugs

The more complex the merge, the higher the risk of mistakes and regressions, reducing product quality.

Harder to analyze build failures

The bigger the chunks that get integrated, the harder it is to figure out which change actually caused the issue when the build fails which increases the effort required to finish the feature.

Higher reluctance to reject changes

Bigger PRs also raise the mental barrier for reviewers to reject changes and demand rework. In the end, it’s one team aiming for the same goal - and it’s hard to tell a teammate to throw away a week’s work.

Reduced need to work incrementally

It is common sense in the software industry that working incrementally leads to less waste and better results.

But when accepting bigger PRs, developers lose both the incentive and the skill to work in small increments. Over time, this leads to even larger PRs.

Harder reviews

Reviewing large, multi-purpose changes takes longer and increases cognitive load. Feedback becomes shallow, resulting in a higher risk of technical debt or even new bugs.

Higher barrier for minor cleanups (Boy Scout Rule)

When integrating small improvements requires the overhead of a PR, developers skip them. Over time, this lowers code quality.

But what about …

… working in isolation?

Feature branches may feel productive because they isolate work, but that’s a local optimization. It benefits an individual’s focus at the expense of team flow.

… running CI builds on feature branches?

Running pipelines on branches is possible if the build farm scales, but it provides partial feedback at best. It shows whether a branch works in isolation - not whether it integrates with everyone else’s changes. By definition, that’s not Continuous Integration.

… reviewing code immediately?

Immediate reviews reduce PR delay but force frequent context switches for reviewers. Each context switch costs time (~ 15 minutes) and mental focus. More PRs mean more context switches, lowering overall team productivity.

… short-lived branches?

Short-lived branches reduce some problems but don’t resolve the fundamental ones. Each PR still acts as a gatekeeper, breaking the flow. More PRs simply multiply the overhead.

Continuous Integration

Continuous Integration (CI) is the alternative that optimizes for flow and productivity.

By default, there are no feature branches. All developers commit directly to mainline and every commit triggers the build pipeline. Tests run after each commit, and code reviews happen asynchronously. No gatekeeping!

The key point is that integration does not mean release. That’s why changes are integrated even before a feature is completed. Still, every change getting integrated must meet production quality.

Builds can fail - that’s normal. When mainline breaks, fixing it becomes the top priority (“green-to-green” principle). Because integrations are small, fixes are quick and rollbacks low-risk.

Even if the latest commit is broken, the last green build is always releasable. Release branches can be created from there if needed.

CI enforces small, incremental changes, solving all the problems introduced by PR-based workflows. It aligns developer behavior with team performance rather than individual convenience.

Are branches and PRs entirely bad?

Of course not - they have legitimate uses.

Prototypes

When exploring a problem using a prototype, it’s fine to work on a branch. The branch helps manage work-in-progress, but its purpose is learning, not integration. Once a solution is known, development restarts cleanly on mainline.

Integrating Dependencies

External dependencies come from outside the team and are therefore trusted less. Using a gated submission for validation before integration is often appropriate.

But why does everyone else do PRs then?

Many teams adopted PRs because they are the default in popular tools like GitHub and GitLab. Others assume it’s the standard way to use Git. Few stop to question whether a model designed for untrusted collaboration fits a trusted commercial team.

Conclusion

The key question is: what do you want to optimize for?

If your goal is control, use PRs. If your goal is flow and productivity, adopt Continuous Integration.

References

• Are Pull Requests Holding Back Your Team?
• You Might Be Better Off Without Pull Requests
• On the Evilness of Feature Branching
• Why Pull Requests Are A BAD IDEA
• Why CI is BETTER Than Feature Branching
• I’ve Found Something BETTER Than Pull Requests
• Git Flow Is A Bad Idea
• The Dark Side of Pull Requests
• The Death of Continuous Integration
• Continuous Integration - Flow Beats Control!
• DORA
• Accelerate
• Continuous Delivery

The Mythical Man-Month

In his book, Frederick P. Brooks analyzes how software engineering worked back in 1975 — with a strong focus on productivity and complexity. As an engineering manager, he was deeply concerned with one central question: Why is software development so difficult, and why do so many projects fail?

What’s fascinating is that — even though our industry has changed massively over the past 50 years — many of his observations are still true today.

Here are a few examples of his most striking claims:

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

A small sharp team is best - as few minds as possible.

The second is the most dangerous system a person ever designs; the general tendency is to over-design it.

The manager of a project needs to establish a philosophy and set aside resources for the building of common tools, and at the same time to recognize the need for personalized tools.

And of course, the classic Brooks’s Law:

Adding manpower to a late software project makes it later.

Instead of imagining that our main task as programmers is to instruct a computer what to do, let us concentrate instead on explaining to human beings what we want a computer to do.

Donald Knuth

Code Is For Humans - A Guide To Human-Centric Software Engineering

As the subtitle indicates, this book puts the human at the center of software engineering. It argues that our real challenge is not just to make computers do the right thing, but to make the code clear and manageable for the people who work with it.

A major theme is complexity, especially the cognitive load our design decisions can create or reduce. Jackson shows how choices in architecture, naming, and structure can either help developers reason about a system or make it harder to understand.

The book examines complexity from different angles, always with the same focus: its impact on people.

If you’ve read other books on software engineering and design, this one offers a valuable and different perspective. It’s definitely worth reading.