Leanpub Header

Skip to main content

The Effective Software Engineer (The Course)

Ethics, Flow, and Organizational Intelligence in Modern Software Development

The instructor has published 100% of this course.Last updated on 2026-08-24

What makes a software engineer truly effective? Beyond writing code, effectiveness comes from ethics, sustainable practices, collaboration, and the courage to adapt. The Effective Software Engineer guides you from clean coding habits to organizational empowerment, bridging the gap between developers and leaders.

Minimum price

$19.00

$29.00

You pay

Author earns

$

Also available for 1 course credit with a Learner Membership

PDF
EPUB
WEB
About

About

About the Course

Software engineering has no shortage of good ideas. The problem is that, over time, many of them become diluted.

Agile becomes ceremonies. Continuous Integration becomes a build server. TDD becomes testing after implementation. BDD becomes syntax. DevOps becomes a department. Architecture becomes a collection of technologies. Metrics intended to help teams learn become instruments of control.

This course, based on The Effective Software Engineer, goes back to the principles behind these ideas and explores how they fit together as a coherent approach to professional software development. The book itself was written to reconnect junior developers, experienced engineers, managers, and senior leadership with what some of our most effective engineering ideas were originally meant to achieve.

We begin with the foundations of Agile and professional ethics, then move through engineering disciplines such as Test-Driven Development, clean and changeable design, Continuous Integration and Continuous Delivery. From there, the course widens its perspective from the individual engineer to the team and ultimately the organization: flow, useful goals, curiosity, psychological safety, collaboration, DORA metrics, empowerment, organizational boundaries, and leadership.

The central idea is simple: Technical excellence is not an accident. It is created through disciplined practice and supported by the environment in which engineers work.

This is therefore not a course about learning another framework or following a prescribed process. It is about understanding why practices such as TDD, CI/CD, small increments, fast feedback, shared responsibility, psychological safety, and cross-functional collaboration work, and how they reinforce one another.

The goal is to help you recognize cargo-cult implementations, question practices that have lost their original purpose, and make better decisions about how software is designed, developed, delivered, and organized.

Whether you are a software engineer, technical lead, architect, engineering manager, or senior leader, the course invites you to look beyond tools and processes and ask a more fundamental question:

What kind of engineering system enables people to learn quickly, change software safely, deliver responsibly, and continuously become more effective?

Because great software is not controlled into existence. It emerges through curiosity, courage, and course correction.

Share this course

Instructor

About the Instructor

Stefan Ellersdorfer

Stefan Ellersdorfer has been a software developer since 2000 and an entrepreneur since 2010. He is a managing director of Smarter Software, a consulting agency based in Austria, where he focuses on building sustainable, high-quality software systems.

In The Effective Software Engineer, he brings together technical excellence - such as Test-Driven Development (TDD), Continuous Integration and Delivery (CI/CD) and clean design - with broader themes including ethics, psychological safety and organizational intelligence. His work emphasizes principles over rigid processes, advocating for adaptability, learning and long-term thinking in software development.

Stefan lives and works in Austria. Beyond his professional life, he is a musician and a father. These experiences have deeply influenced his perspective on practice, discipline, responsibility and collaboration - values that shape both his work and his writing.

Material

Course Material

  • Welcome to The Effective Software Engineer

  • Preface

  • Acknowledgments

  • About the Author

  • Why I wrote this book

  • Navigation by Interest

  • Audience Groups Navigation

  • Thematic Coverage Across Chapters

  • Conceptual Timeline Through Chapters

  • Core Principles Across Chapters

  • Chapter 1 – Agile Software Development

  • Agile

  • A Brief History of Agile

  • Ticket or User Story?

  • What Real User Stories look like

  • A different problem of authentication

  • Different solutions to the known problem domain facing the User

  • Scope creep

  • Practices and values of Agile software development

  • Why “the Right Side” Still Matters

  • Understanding Agile Maturity: The Agile Fluency Model

  • What is the Agile Fluency Model?

  • Pre Agile

  • Focusing - a Shift in Team Culture

  • Investment

  • Benefits

  • Delivering

  • Investment

  • Benefits

  • Optimizing

  • Investment

  • Benefits

  • Strengthening Zone

  • Investments

  • Benefits

  • Why Fluency Matters

  • From Practice to Purpose

  • Conclusion

  • Exercise 1

  • From Estimation to Understanding: User Stories, and ATDD

  • Estimation Without Understanding

  • ATDD: Shifting from Guessing to Knowing

  • Example BDD style acceptance tests for core user story:

  • ATDD, and Estimation

  • Ethics and Responsibility

  • Exercise 2

  • Diagnosing Agile Dysfunctions

  • Top Management Dysfunctions

  • Middle Management Dysfunctions

  • Software Development Team Dysfunctions

  • Using This Diagnostic

  • Agile maturity checklist

  • Quiz 1

    3 attempts allowed

  • Chapter 2 – 79 years of software development

  • The Origins of Code

  • Cornerstones in the History of Software

  • What is Object Orientation?

  • The Illusion of Change in Software

  • What Did Change Then?

  • The Burden of Misinformation

  • A Call for Responsibility

  • The Forgotten Craft

  • Bridging the Knowledge Gap

  • Exercise 3

  • Dysfunction Maps: Staying Grounded in Software History

  • Top Management

  • Middle Management

  • Software Development Team

  • 1. Teach the Principles, Not Just the Tools

  • 2. Practice Professionalism through Process

  • 3. Cultivate Mentorship, and Historical Awareness

  • 4. Promote Critical Thinking in the AI Era

  • Exercise 4

  • Quiz 2

    3 attempts allowed

  • Chapter 3 – Ethics, practices, and good habits of programmers

  • The Programmer’s Oath (Robert C. Martin, 2015)

  • The Foundation of Good Code (Dave Farley’s Criteria)

  • The Code Works

  • Characteristics of Working Code

  • Benefits by Stakeholder

  • Sustainable Practices

  • The Code Is Easy to Change

  • Characteristics of Changeable Code

  • Benefits by Stakeholder

  • Connection to Theory of Constraints (TOC)

  • Exercise 5

  • Good Habits for Software Developers

  • Stakeholder Awareness

  • Code Style

  • Proficiency Levels

  • Execution Principles

  • Naming Guidelines

  • Team Collaboration, and Enforcement

  • Humility: The Unsung Virtue of Effective Developers

  • Exercise 6

  • The Relevance of Patterns, and Refactoring

  • Exercise 7

  • Technical debt

  • Exercise 8

  • Dysfunction Maps: Ethics, Craft, and Responsibility

  • Top Management

  • Middle Management

  • Software Development Team

  • The rational conclusion

  • Why Ethics Matters - A Personal Reflection

  • Ethical Responsibility Is Personal

  • Process vs. Principle: The Trunk-Based Development Paradox

  • The Real Root of Ethical Failure

  • The Way Forward: Mastery and Communication

  • Exercise 9

  • Clarifying SOLID: SRP, OCP, and DIP (the ones we argue about most)

  • SRP - Single Responsibility Principle

  • Smells that hint SRP is broken

  • How TDD helps

  • Refactoring moves

  • OCP - Open/Closed Principle

  • Smells that hint OCP is broken

  • Refactoring moves

  • DIP - Dependency Inversion Principle

  • Smells that hint DIP is broken

  • Refactoring moves

  • Choosing frameworks with awareness

  • How the three interact (and how tests keep you honest)

  • A tiny workflow to apply them together

  • Quick checklists

  • Final thought

  • Exercise 10

  • A Personal Success Story: How Practice Changed My Mindset and My Team

  • First, I had to change my own perspective.

  • TDD: From Practice to Habit

  • Architecture Principles and Object Orientation

  • Coupling and Cohesion: Old Wisdom, Fresh Understanding

  • Know What You Want

  • Bringing It All Together

  • Exercise 11

  • Quiz 3

    3 attempts allowed

  • Chapter 4 – Test driven development

  • The Mechanics of TDD

  • The Purpose of TDD

  • The Role of AI in TDD

  • AI in Software Development

  • Exercise 12

  • TDD, and Continuous Integration (CI)

  • Pair Programming vs. Asynchronous Code Review

  • Trunk-Based Development Changes Everything

  • The Common Model: Asynchronous, Half-Duplex Reviews

  • The Better Model: Pair Programming as Continuous Review

  • Why Pairing Wins (Always)

  • The Human Factor

  • But What About Parallelism?

  • Trunk-Based Development Needs Synchronous Thinking

  • Conclusion

  • Exercise 13

  • Dysfunction Maps: Practicing TDD in the Real World

  • Top Management

  • Middle Management

  • Software Development Team

  • Results of Test Driven Development

  • Training, and Mastery

  • Consequences of TDD

  • For Top Management

  • For Middle Management

  • For Software Teams

  • Exercise 14

  • Behavior Driven Development (BDD)

  • Explanation

  • The Four-Layer Test Architecture

  • What vs. How

  • Consequences

  • For Top Management

  • For Middle Management

  • For the Development Team

  • Exercise 15

  • Acceptance Test Driven Development (ATDD)

  • Explanation

  • Consequences

  • For Top Management

  • For Middle Management

  • For the Software Team

  • Exercise 16

  • Who Owns the Tests?

  • A Shared Responsibility, Not a Silo

  • Test Ownership Across Roles

  • Product Owners / Domain Experts

  • Developers

  • Testers / QA Engineers

  • Ownership by Layer (in 4-Layer Architecture)

  • Why Shared Ownership Matters

  • Exercise 17

  • Final Thought

  • Getting TDD Wrong: The Myth of “Just Write the Test First”

  • The Real Mechanics: Writing in the Test First

  • TDD as a Conversation, Not a Command

  • Why Algorithmic Problems Aren’t a Special Case

  • TDD Is About Clarity, Not Coverage

  • A More Accurate Practice

  • Summary: Don’t Write the Test First - Write with the Test

  • How to Structure a Test

  • Exercise 18

  • Executive Summaries & Cheat Sheets

  • For Managers: What To Know About TDD

  • For Developers: Daily Habit Checklist

  • Exercise 19

  • Quiz 4

    3 attempts allowed

  • Chapter 5 – Useful goals in software development teams

  • What is Value?

  • Three Primary Forms of Value

  • The Danger of Proxy Metrics

  • Exercise 20

  • Experimentation and Prototyping: The Right Way to Explore

  • The Role of Prototypes in Learning

  • The Myth of the Throwaway Prototype

  • A Prototype Is Still Software

  • Fail Fast ≠ Build Sloppy

  • A Prototype Is an Experiment in Value, Not an Experiment in Sloppiness

  • The Minimal Reliable Slice

  • In Short

  • Exercise 21

  • Work Breakdown & User Stories, Plan for Outcomes, Not Output

  • Value-Oriented Work Breakdown

  • Vertical vs. Horizontal Slices

  • Slicing Heuristics

  • Defining User Stories: Clarify the What, Delay the How

  • Exercise 22

  • Build the Right Thing

  • Executable Requirements

  • ATDD as Truth

  • Exercise 23

  • Flow Efficiency vs Resource Efficiency

  • How Process Hurts Flow

  • Adding People: Scale Decisions, Not Headcount

  • Flow Instead of Process: Optimize for Value, Not Activity

  • Exercise 24

  • Continuous Integration

  • Why CI Matters

  • CI as Architectural Pressure

  • Easy Changes: Optimize for Changeability

  • Organizational responsiveness

  • Exercise 25

  • Developer Morale: The Human Core of Software

  • Why Morale Matters

  • Sustainable Pace

  • Psychological Safety and Trust

  • Exercise 26

  • Dysfunction Maps: Useful Goals and Flow

  • Top Management

  • Middle Management

  • Software Development Team

  • Conclusion: Useful Goals Are User-Centric, Change-Ready, and Team-Aligned

  • Quiz 5

    3 attempts allowed

  • Chapter 6 – Curiosity as a Catalyst for Innovation

  • The Curiosity Deficit in Organizations

  • Exercise 27

  • Why Curiosity Matters in Tech

  • Curiosity in Tools and Frameworks

  • Exercise 28

  • Leadership Practices to Encourage Curiosity

  • Exercise 29

  • Practices, and Rituals to Support Curiosity

  • Exercise 30

  • Dysfunction Maps: Curiosity and Learning

  • Top Management

  • Middle Management

  • Software Development Team

  • WOOP

  • Following a Plan: From Rigidity to Adaptive Planning with WOOP

  • WOOP for Plan People on the Agile Fluency Journey

  • Exercise 31

  • Quiz 6

    3 attempts allowed

  • Chapter 7: Adaptive Intelligence, and the Courage to Change

  • Understanding AQ in a Technical Context

  • Exercise 32

  • Courage: The Enabler of Adaptation

  • Exercise 33

  • A Brief History and Importance of DORA

  • Exercise 34

  • Adaptive Intelligence Meets DORA, and XP: Embodied Agility vs. Dysfunction

  • Practices That Develop Adaptive Intelligence

  • Exercise 35

  • Adaptive Intelligence in Planning and Predictability

  • Exercise 36

  • Leading with AQ in Mind

  • Exercise 37

  • The Strategic Advantage of AQ

  • Quiz 7

    3 attempts allowed

  • Chapter 8: Psychological Safety as a Strategic Asset

  • Exercise 38

  • What Psychological Safety Is, and What It Isn’t

  • Exercise 39

  • The Cost of Silence

  • Exercise 40

  • Creating Psychological Safety in Tech Teams

  • Exercise 41

  • Team Rituals That Reinforce Safety

  • Exercise 42

  • Psychological Safety, and DORA Metrics

  • Exercise 43

  • Leading with Safety in Mind

  • Exercise 44

  • Psychological Safety and Legacy Systems

  • Have you ever thought about?

  • Exercise 45

  • Dysfunction Maps: Psychological Safety in Practice

  • Top Management

  • Middle Management

  • Software Development Team

  • Safety First - Not Last

  • Quiz 8

    3 attempts allowed

  • Chapter 9: Metrics That Matter: From DORA to Morale

  • The Power, and Limits of DORA Metrics

  • Exercise 46

  • Morale as an Early Indicator

  • Exercise 47

  • Triangulating Metrics, and Culture

  • Exercise 48

  • Anti-Patterns to Avoid

  • Exercise 49

  • Practices That Encourage Healthy Use of Metrics

  • Leading with Curiosity, Not Control

  • The Rugged Manifesto, and Sustainable Effectiveness

  • Exercise 50

  • Metrics as Mirrors, Not Weapons

  • Dysfunction Maps: Metrics and Morale

  • Top Management

  • Middle Management

  • Software Development Team

  • Quiz 9

    3 attempts allowed

  • Chapter 10: From Silos to Synergy: Leading Beyond Department Walls

  • The Hidden Cost of Silos

  • Exercise 51

  • Conway’s Law, and the Architecture of Communication

  • From Cross-Functional to Truly Integrated

  • Exercise 52

  • Team Topologies, and Stream-Aligned Teams

  • Exercise 53

  • Collaboration Rituals That Drive Synergy

  • Exercise 54

  • Leadership Practices for Integration

  • Exercise 55

  • Beyond Structure: Toward a Culture of We

  • Dysfunction Maps: Breaking Silos

  • Top Management

  • Middle Management

  • Software Development Team

  • Quiz 10

    3 attempts allowed

  • Chapter 11: Empowerment Is a Design Problem

  • Why Empowerment Fails

  • Exercise 56

  • Designing for Empowerment

  • Exercise 57

  • Practices That Enable Real Autonomy

  • Exercise 58

  • Leadership Behaviors That Support Empowerment

  • Exercise 59

  • Empowerment, and Organizational Effectiveness

  • Exercise 60

  • Empowerment Is a Loop, Not a Lever

  • Dysfunction Maps: Designing for Empowerment

  • Top Management

  • Middle Management

  • Software Development Team

  • Quiz 11

    3 attempts allowed

  • Chapter 12: Co-Located Teams Across Company Boundaries – Challenges, and Recommendations

  • The Illusion of Virtual Co-Location

  • Exercise 61

  • Language as a Barrier to Shared Understanding

  • Exercise 62

  • Strategic Work Requires Strategic Proximity

  • Exercise 63

  • The Role of Internal Ambassadors

  • Exercise 64

  • The True Cost of Misunderstanding

  • Exercise 65

  • Risk Assessment Matrix

  • Conclusion

  • Dysfunction Maps: Cross-Company Collaboration

  • Top Management

  • Middle Management

  • Software Development Team

  • Quiz 12

    3 attempts allowed

  • Chapter 13: Conclusion - Principles Over Process

  • What We’ve Learned

  • The Path Forward

  • Exercise 66

  • The Effective Engineer, the Empowered Team

  • Dysfunction Maps: Sustaining Principles

  • Top Management

  • Middle Management

  • Software Development Team

  • Quiz 13

    3 attempts allowed

  • References

  • Agile Foundations, and Values

  • Software Craftsmanship, and Professionalism

  • Testing, TDD, and BDD

  • Continuous Delivery, and DevOps

  • Design, and Architecture

  • Team Topologies, Flow, and Culture

  • Human Dynamics, Leadership, and Motivation

  • Other Notable Influences

  • Appendix A – Tools

  • Diagnosing Agile Dysfunctions from Chapter 1

  • Top Management Dysfunctions

  • Middle Management Dysfunctions

  • Software Development Team Dysfunctions

  • Agile maturity checklist

  • Dysfunction Maps: Staying Grounded in History from Chapter 2

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Ethics, Craft, and Responsibility from Chapter 3

  • Top Management

  • Middle Management

  • Software Development Team

  • Why pairing always wins from Chapter 4

  • 4 Layer test archictecture and owners from Chapter 4

  • Dysfunction Maps: Practicing TDD in the Real World from Chapter 4

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Useful Goals and Flow from Chapter 5

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Curiosity and Learning from Chapter 6

  • Top Management

  • Middle Management

  • Software Development Team

  • DORA vs. Traditional Metrics from Chapter 7

  • Embodied agile vs. agile dysfunctions from Chapter 7

  • Adaptive Intelligence, XP Principles & DORA Outcomes

  • Top Management Dysfunctions

  • Middle Management Dysfunctions

  • Team Dysfunctions

  • Dysfunction Maps: Psychological Safety in Practice from Chapter 8

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Metrics and Morale from Chapter 9

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Breaking Silos from Chapter 10

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Designing for Empowerment from Chapter 11

  • Top Management

  • Middle Management

  • Software Development Team

  • Chapter 12 - Risk Assessment Matrix for Outsourcing

  • Dysfunction Maps: Cross-Company Collaboration from Chapter 12

  • Top Management

  • Middle Management

  • Software Development Team

  • Dysfunction Maps: Sustaining Principles from Chapter 13

  • Top Management

  • Middle Management

  • Software Development Team

  • Appendix B – ATDD Example

  • Repository Root — Orientation

  • Domain Module — Business Rules First

  • Purpose

  • Location

  • Tests

  • Application Module — Delivery, Not Business Logic

  • Purpose

  • Location

  • Tests

  • Exercise 67

  • System Architecture

  • Acceptance Module — Executable Specifications

  • Layer 1 - The executable specification

  • Layer 2 - DSL - domain specific language

  • Layer 3 - The protocol drivers

  • Layer 4 - The system under test

  • Purpose

  • Location

  • AbstractAssetAcceptanceTest

  • Drivers extend DSL

  • Domain Driver and Test

  • Domain Driver

  • Domain Acceptance Test

  • Controller Driver and Test

  • Controller Driver

  • Controller Test

  • UI Driver and Test

  • UI Driver

  • UI Acceptance Test

  • DSL

  • Example

  • Exercise 68

  • UI Acceptance Module — End-to-End Confidence

  • Purpose

  • Location

  • Exercise 69

  • Frontend (ng-frontend) — Independent, Testable, Replaceable

  • Location

  • Continuous Integration Pipeline

  • Location

  • Commit Stage

  • Acceptance Stage

  • Exercise 70

  • Why These Artifacts Matter Together

  • Closing Note

  • Evidence-Driven Progress, Metrics, and Organizational Impact

  • Acceptance Tests as the Foundation of Meaningful Metrics

  • Exercise 71

  • Alignment with DORA Metrics

  • Lead Time for Changes

  • Deployment Frequency

  • Change Failure Rate

  • Mean Time to Restore (MTTR)

  • Exercise 72

  • Example: Acceptance-Test–Based Progress Report

  • Table: Acceptance Summary per Build

  • Transparency Without Blame — Reinforced by Evidence

  • Long-Term System Resilience

  • Exercise 73

  • Opportunities by Organizational Level

  • Software Development Teams

  • Middle Management

  • Top Management

  • No Heroes Required

  • Agile Development as Risk Management

  • Quality Enables Speed — Never the Other Way Around

  • The Habits That Actually Matter

  • Sustainability Over Heroics

  • Quiz 14

    3 attempts allowed

  • Appendix C - Glossary of Key Terms

  • Appendix D – FAQ and Role-Specific Guidance

  • Frequently Asked Questions – FAQ

  • For Managers

  • For Developers

  • Role-Specific Guidance (Appendix D)

  • Advice for New Managers

  • Advice for Senior Engineers

  • Diversity & Inclusion: The Foundation of Resilient Teams

  • Appendix E – Alignment Matrix

  • Behaviors, Principles, Value – Cheat sheet

  • Exercise 74

  • Detailed cheat sheets

  • Curiosity

  • Courage

  • Humility

  • Ethical Responsibility

  • Code That Works

  • Code That Is Easy to Change

  • Stakeholder Awareness

  • Continuous Integration (CI) & Trunk-Based Development

  • Test-Driven Development (TDD)

  • Shared Ownership

  • Psychological Safety

  • Flow Over Process

  • User-Centric Goal Setting

  • Adaptive Intelligence (AQ)

  • Empowerment & Autonomy

  • Cross-Functional Collaboration

  • Healthy Use of Metrics

  • Exercise 75

  • Quiz 15

    3 attempts allowed

  • Appendix F - How to break Learned Helplessness in Big, Mixed Teams

  • Shrink the surface of change

  • Exercise 76

  • Rebuild local agency (the antidote to helplessness)

  • Exercise 77

  • Use visible experiments instead of principles

  • Exercise 78

  • Normalize speaking up (micro safety rituals)

  • Exercise 79

  • Show progress with dual mirrors

  • Exercise 80

  • Anchor back to professional identity

  • How to break Learned Helplessness in Big, Mixed Teams

  • Exercise 81

  • Quiz 16

    3 attempts allowed

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub