From f0432854ddac61d451f1c2cf73ab2c2fa9ad0be4 Mon Sep 17 00:00:00 2001 From: coderpandaaa <153787230+coderpandaaa@users.noreply.github.com> Date: Sun, 30 Aug 2026 14:36:47 -0400 Subject: [PATCH 1/7] added preface overview and made folder --- blog/se1-fall2026/index.qmd | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 blog/se1-fall2026/index.qmd diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd new file mode 100644 index 00000000..8b2374bf --- /dev/null +++ b/blog/se1-fall2026/index.qmd @@ -0,0 +1,33 @@ +--- +author: [Dylan Headley, V, Ritesh Ojha, Anshu Pathak, Gregory M. Kapfhammer] +title: Software Engineering Beyond Programming +date: '2026-08-31' +date-format: long +categories: [post, professional development, software engineering] +description: What makes software engineering different from programming? +toc: true +page-layout: full +--- + +## Overview + +This blog post discusses the ["Preface"](https://abseil.io/resources/swe-book/html/pr01.html) in the +[Software Engineering at Google book](https://abseil.io/resources/swe-book)! + +The Preface of Software Engineering at Google introduces the question of what distinguishes software engineering from programming and computer science. The authors argue that software engineering is more than simply writing code. It includes the tools and processes an organization uses to build and maintain software over time. + +The central idea of the Preface is that software engineering can be viewed as “programming integrated over time.” Software must be able to adapt to changing requirements, continue to be maintained, and remain valuable throughout its life cycle. + +## Summary + + + +## Reflection + + + +## Action Items + + + +{{< include /_back-blog.qmd >}} From 4a0d7d290294d75553944e48c352020f7bcbf89b Mon Sep 17 00:00:00 2001 From: Tien DeLong-Headley Date: Sun, 30 Aug 2026 17:44:21 -0400 Subject: [PATCH 2/7] add: SE1 partial exec summary --- blog/se1-fall2026/index.qmd | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 8b2374bf..691316b3 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -14,13 +14,43 @@ page-layout: full This blog post discusses the ["Preface"](https://abseil.io/resources/swe-book/html/pr01.html) in the [Software Engineering at Google book](https://abseil.io/resources/swe-book)! -The Preface of Software Engineering at Google introduces the question of what distinguishes software engineering from programming and computer science. The authors argue that software engineering is more than simply writing code. It includes the tools and processes an organization uses to build and maintain software over time. +The preface of _Software Engineering at Google_ introduces two fundamental questions from which we derive our course name, "CMPSC 203: Software Engineering." -The central idea of the Preface is that software engineering can be viewed as “programming integrated over time.” Software must be able to adapt to changing requirements, continue to be maintained, and remain valuable throughout its life cycle. +The first looks to distinguish the difference between programming and software engineering as disciplines. The authors argue that software engineering is more than simply writing code; __it includes the tools and processes an organization uses to build and maintain software over time.__ The central idea of the preface is that software engineering can be viewed as **“programming integrated over time.”** Software engineering must be able to adapt to changing requirements, continue to be maintained, and remain valuable throughout its life cycle. + +The second aims to emphasize the difference in rigor between software engineering and more traditional engineering roles. Where mechanical and civic engineers build something physical, it is more often than not that software is regarded with less real-world consequence. But in the age of artificial intelligence and growing concerns of cybersecurity, _Software Engineering at Google_ believes that we as software engineers should strive to match the rigor of other fields. ## Summary +_Software Engineering at Google_ uses its preface to make its fundamental perspective on the discipline of software engineering clear: "as software becomes more integrated into our lives, we must adopt and rely on more rigorous engineering methods." But what do the authors mean by this? + +The difference between "programming" and "software engineering" is intent. Software engineering is the integration of programming over time because it relies on the intent of **sustainability**, as well as more **rigorous** methods to ensure the health of the project. + +### Disciplinary Rigor & Engineering for Sustainability + +This book is dedicated to teaching software engineers how to think more rigorously like other engineering disciplines to build something that is effective, and which lasts. + +There are three pairs of indicators that reveal the needs of a project to remain sustainable. + +- Time and Change: How will the **codebase** need to adapt to remain __relevant and healthy__? +- Scale and Growth: How will the **organization** responsible for the codebase need to adapt as it __evolves__? +- Trade-offs and Costs: How will the **organization** use the metrics of _Time and Change_ and _Scale and Growth_ to inform their engineering decisions? + +### Google's Software Engineering Landscape + +#### Culture + +#### Process + +#### Tools + +### What this Book Isn't + +The authors made it very clear what their intentions with _Software Engineering at Google_ were, but they also made it clear what they were **not**. This book is not: +- a guide to software design +- a comprehensive treatment of all the practical concerns that shape modern software development +As a result, it leaves out many important topics such as project management, API design, security hardening, internationalization, user interface frameworks, and other language-specific concerns. These omissions are not a statement that these issues are unimportant; rather, they reflect the book’s deliberate choice to focus on software engineering as a discipline rather than trying to cover every aspect of software development in depth. ## Reflection From 9ee7bc1da428351190616b1ca1b42360fbfa869e Mon Sep 17 00:00:00 2001 From: Rieger01 Date: Sun, 30 Aug 2026 18:50:49 -0400 Subject: [PATCH 3/7] Added Google's Perspective Section --- blog/se1-fall2026/index.qmd | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 691316b3..456eee46 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -1,5 +1,5 @@ --- -author: [Dylan Headley, V, Ritesh Ojha, Anshu Pathak, Gregory M. Kapfhammer] +author: [Dylan Headley, V Rieger, Ritesh Ojha, Anshu Pathak, Gregory M. Kapfhammer] title: Software Engineering Beyond Programming date: '2026-08-31' date-format: long @@ -20,6 +20,8 @@ The first looks to distinguish the difference between programming and software e The second aims to emphasize the difference in rigor between software engineering and more traditional engineering roles. Where mechanical and civic engineers build something physical, it is more often than not that software is regarded with less real-world consequence. But in the age of artificial intelligence and growing concerns of cybersecurity, _Software Engineering at Google_ believes that we as software engineers should strive to match the rigor of other fields. +--- + ## Summary _Software Engineering at Google_ uses its preface to make its fundamental perspective on the discipline of software engineering clear: "as software becomes more integrated into our lives, we must adopt and rely on more rigorous engineering methods." But what do the authors mean by this? @@ -37,12 +39,16 @@ There are three pairs of indicators that reveal the needs of a project to remain - Trade-offs and Costs: How will the **organization** use the metrics of _Time and Change_ and _Scale and Growth_ to inform their engineering decisions? ### Google's Software Engineering Landscape +Google focuses growth and sustainability in software engineering. They break this concept into three main points. #### Culture +How software is developed through teamwork and how this allows for growth. Some chapters in this section are “How to Work on Teams”, “Knowledge Sharing”, “Leading at Scale”, and “Measuring Engineering Productivity”. This section emphasizes the importance of working together to solve problems. Bringing different perspectives to the table can allow for better solutions and a more productive and healthier work environment. -#### Process +#### Processes +How Google has developed best practices for software engineers. They point out having an informed perspective due to Google’s large size. The chapter names include “Style Guides and Rules”, “Documentation”, “Testing Overview”, and “Deprecation”. This touches upon all different aspects of software engineering, from planning and creation to testing and deprecation. #### Tools +How to use tools to your advantage, whether they be your own or open source options. Some chapter names are “Version Control and Branch Management”, “Code Search”, “Dependency Management”, and “Large-Scale Changes”. Using a combination of your own tools and ones that already exist can be helpful in getting the wanted outcome by tailoring your tools to your needs but also not making extra work for yourself. ### What this Book Isn't @@ -52,6 +58,8 @@ The authors made it very clear what their intentions with _Software Engineering As a result, it leaves out many important topics such as project management, API design, security hardening, internationalization, user interface frameworks, and other language-specific concerns. These omissions are not a statement that these issues are unimportant; rather, they reflect the book’s deliberate choice to focus on software engineering as a discipline rather than trying to cover every aspect of software development in depth. +--- + ## Reflection From 7288f13e38636ddbd505fa9aebba7b5ef3fa5ee5 Mon Sep 17 00:00:00 2001 From: coderpandaaa <153787230+coderpandaaa@users.noreply.github.com> Date: Sun, 30 Aug 2026 18:53:19 -0400 Subject: [PATCH 4/7] changes --- blog/se1-fall2026/index.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 691316b3..132d09f2 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -1,5 +1,5 @@ --- -author: [Dylan Headley, V, Ritesh Ojha, Anshu Pathak, Gregory M. Kapfhammer] +author: [Dylan Headley, V Rieger, Ritesh Ojha, Anshu Pathak, Gregory M. Kapfhammer] title: Software Engineering Beyond Programming date: '2026-08-31' date-format: long From 1641e1151ea6955a3bfda1c99fa0cd05e22d8248 Mon Sep 17 00:00:00 2001 From: coderpandaaa <153787230+coderpandaaa@users.noreply.github.com> Date: Sun, 30 Aug 2026 19:49:03 -0400 Subject: [PATCH 5/7] added reflection --- blog/se1-fall2026/index.qmd | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 456eee46..493edaac 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -9,6 +9,8 @@ toc: true page-layout: full --- +--- + ## Overview This blog post discusses the ["Preface"](https://abseil.io/resources/swe-book/html/pr01.html) in the @@ -62,10 +64,11 @@ As a result, it leaves out many important topics such as project management, API ## Reflection +Our CLI tool reflects the Preface’s central idea that software engineering is not just writing code, but managing a system over time. By checking which dependencies are outdated and which versions are newer, the tool emphasizes the importance of continuous maintenance and adaptation. In a real project, dependencies change constantly, and failing to notice those updates can leave software vulnerable, inefficient, or incompatible with newer tools. Similarly, scanning for missing docstrings adds a more rigorous form of quality control. Documentation is not only for readability; it helps future developers understand the purpose and behavior of code, especially as a team and codebase grow. +This is a stronger example of software engineering because it goes beyond “does the code run?” and instead asks, “is the project healthy, maintainable, and sustainable?” The ability to target specific problems, outdated packages, missing docstrings, and project-level maintenance issues, makes the tool practical and actionable. It supports the Preface’s themes of Time and Change and Scale and Growth by showing that as projects expand, engineers need systematic ways to track complexity, change, and long-term health. In this way, bumpd is not just a utility; it is an example of the disciplined, evidence-based thinking that distinguishes programming from software engineering. -## Action Items - - +## Repository +Our team built bumpd, a command-line dependency and maintenance audit tool. You can view the project here: [bumpd on GitHub](https://github.com/pathakanshu/bumpd). {{< include /_back-blog.qmd >}} From f6329c291a6a18353147f8180ecd2bcead8b3a11 Mon Sep 17 00:00:00 2001 From: coderpandaaa <153787230+coderpandaaa@users.noreply.github.com> Date: Sun, 30 Aug 2026 19:55:32 -0400 Subject: [PATCH 6/7] changed reflection first line --- blog/se1-fall2026/index.qmd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 493edaac..9581bee6 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -64,9 +64,9 @@ As a result, it leaves out many important topics such as project management, API ## Reflection -Our CLI tool reflects the Preface’s central idea that software engineering is not just writing code, but managing a system over time. By checking which dependencies are outdated and which versions are newer, the tool emphasizes the importance of continuous maintenance and adaptation. In a real project, dependencies change constantly, and failing to notice those updates can leave software vulnerable, inefficient, or incompatible with newer tools. Similarly, scanning for missing docstrings adds a more rigorous form of quality control. Documentation is not only for readability; it helps future developers understand the purpose and behavior of code, especially as a team and codebase grow. +This distinction between programming and software engineering becomes concrete when we think about the kinds of tools teams need to maintain software over time. Our CLI tool reflects the Preface’s central idea that software engineering is not just writing code, but managing a system over time. By checking which dependencies are outdated and which versions are newer, the tool emphasizes the importance of continuous maintenance and adaptation. In a real project, dependencies change constantly, and failing to notice those updates can leave software vulnerable, inefficient, or incompatible with newer tools. Similarly, scanning for missing docstrings adds a more rigorous form of quality control. Documentation is not only for readability; it helps future developers understand the purpose and behavior of code, especially as a team and codebase grow. -This is a stronger example of software engineering because it goes beyond “does the code run?” and instead asks, “is the project healthy, maintainable, and sustainable?” The ability to target specific problems, outdated packages, missing docstrings, and project-level maintenance issues, makes the tool practical and actionable. It supports the Preface’s themes of Time and Change and Scale and Growth by showing that as projects expand, engineers need systematic ways to track complexity, change, and long-term health. In this way, bumpd is not just a utility; it is an example of the disciplined, evidence-based thinking that distinguishes programming from software engineering. +This is a stronger example of software engineering because it goes beyond “does the code run?” and instead asks whether the project is healthy, maintainable, and sustainable. By surfacing outdated packages, missing docstrings, and other maintenance issues, the tool makes project quality visible in a concrete and actionable way. It supports the Preface’s themes of Time and Change and Scale and Growth by showing that as projects expand, engineers need systematic ways to track complexity, change, and long-term health. In this way, bumpd is not simply a convenience tool; it reflects the disciplined, evidence-based thinking that distinguishes programming from software engineering. ## Repository Our team built bumpd, a command-line dependency and maintenance audit tool. You can view the project here: [bumpd on GitHub](https://github.com/pathakanshu/bumpd). From 03c505b487bec01511eb4291f1214695133d6a11 Mon Sep 17 00:00:00 2001 From: coderpandaaa <153787230+coderpandaaa@users.noreply.github.com> Date: Sun, 30 Aug 2026 21:56:34 -0400 Subject: [PATCH 7/7] fix: contents of qmd file --- blog/se1-fall2026/index.qmd | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/blog/se1-fall2026/index.qmd b/blog/se1-fall2026/index.qmd index 9581bee6..a3e10993 100644 --- a/blog/se1-fall2026/index.qmd +++ b/blog/se1-fall2026/index.qmd @@ -11,7 +11,7 @@ page-layout: full --- -## Overview +## Overview This blog post discusses the ["Preface"](https://abseil.io/resources/swe-book/html/pr01.html) in the [Software Engineering at Google book](https://abseil.io/resources/swe-book)! @@ -30,7 +30,8 @@ _Software Engineering at Google_ uses its preface to make its fundamental perspe The difference between "programming" and "software engineering" is intent. Software engineering is the integration of programming over time because it relies on the intent of **sustainability**, as well as more **rigorous** methods to ensure the health of the project. -### Disciplinary Rigor & Engineering for Sustainability + +### Disciplinary Rigor & Engineering for Sustainability This book is dedicated to teaching software engineers how to think more rigorously like other engineering disciplines to build something that is effective, and which lasts. @@ -40,19 +41,20 @@ There are three pairs of indicators that reveal the needs of a project to remain - Scale and Growth: How will the **organization** responsible for the codebase need to adapt as it __evolves__? - Trade-offs and Costs: How will the **organization** use the metrics of _Time and Change_ and _Scale and Growth_ to inform their engineering decisions? -### Google's Software Engineering Landscape + +### Google's Software Engineering Landscape Google focuses growth and sustainability in software engineering. They break this concept into three main points. -#### Culture +- #### Culture How software is developed through teamwork and how this allows for growth. Some chapters in this section are “How to Work on Teams”, “Knowledge Sharing”, “Leading at Scale”, and “Measuring Engineering Productivity”. This section emphasizes the importance of working together to solve problems. Bringing different perspectives to the table can allow for better solutions and a more productive and healthier work environment. -#### Processes +- #### Processes How Google has developed best practices for software engineers. They point out having an informed perspective due to Google’s large size. The chapter names include “Style Guides and Rules”, “Documentation”, “Testing Overview”, and “Deprecation”. This touches upon all different aspects of software engineering, from planning and creation to testing and deprecation. -#### Tools +- #### Tools How to use tools to your advantage, whether they be your own or open source options. Some chapter names are “Version Control and Branch Management”, “Code Search”, “Dependency Management”, and “Large-Scale Changes”. Using a combination of your own tools and ones that already exist can be helpful in getting the wanted outcome by tailoring your tools to your needs but also not making extra work for yourself. -### What this Book Isn't +### What this book isn't ? The authors made it very clear what their intentions with _Software Engineering at Google_ were, but they also made it clear what they were **not**. This book is not: - a guide to software design @@ -68,6 +70,8 @@ This distinction between programming and software engineering becomes concrete w This is a stronger example of software engineering because it goes beyond “does the code run?” and instead asks whether the project is healthy, maintainable, and sustainable. By surfacing outdated packages, missing docstrings, and other maintenance issues, the tool makes project quality visible in a concrete and actionable way. It supports the Preface’s themes of Time and Change and Scale and Growth by showing that as projects expand, engineers need systematic ways to track complexity, change, and long-term health. In this way, bumpd is not simply a convenience tool; it reflects the disciplined, evidence-based thinking that distinguishes programming from software engineering. +--- + ## Repository Our team built bumpd, a command-line dependency and maintenance audit tool. You can view the project here: [bumpd on GitHub](https://github.com/pathakanshu/bumpd).