From 5c86e06616e8285aff82be584a257fb4c97f5081 Mon Sep 17 00:00:00 2001 From: pathakanshu <229002110+pathakanshu@users.noreply.github.com> Date: Sun, 13 Sep 2026 16:47:38 -0400 Subject: [PATCH 1/6] chore: create SE3 and add frontmatter along with some structure --- blog/se3-fall2026/index.qmd | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 blog/se3-fall2026/index.qmd diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd new file mode 100644 index 0000000..6cbbe7a --- /dev/null +++ b/blog/se3-fall2026/index.qmd @@ -0,0 +1,32 @@ +--- +author: [Anshu Pathak, Aidana Kuat, Jake, Gregory M. Kapfhammer] +title: xyz +date: '2026-9-14' +date-format: long +categories: [post, professional development, software engineering] +description: xyz +toc: true +page-layout: full +--- + +## Aidana's Work + + + + + +## Jake's Work + + + + + + +::: {.callout-note appearance="minimal" title="Open-Source Tool for Software Engineers" collapse="false"} + +Our team built `xyz`, an abc. You can view the project +here: [xyz on GitHub](https://github.com/pathakanshu/). + +::: + +{{< include /_back-blog.qmd >}} From 72786e64213edd068c0632a7379fce8ec085d59d Mon Sep 17 00:00:00 2001 From: Jake-College Date: Sun, 13 Sep 2026 20:42:38 -0400 Subject: [PATCH 2/6] Jake's portion --- blog/se3-fall2026/index.qmd | 58 ++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd index 6cbbe7a..f3d1f3d 100644 --- a/blog/se3-fall2026/index.qmd +++ b/blog/se3-fall2026/index.qmd @@ -15,7 +15,63 @@ page-layout: full -## Jake's Work +# The Three Pillars of Social Interaction + +Collaboration is built on the “3 pillars” of social skills that serve as a foundation for healthy interaction. +- Humility + - You are not the center of the universe, are not omniscient, and can make mistakes. Be open to self improvement. +- Respect + - Care about the people you work with, treat them kindly and appreciate their contributions, abilities, and accomplishments. +- Trust + - Believe that others are competent and will do the right thing and have faith that they will be able to handle themselves. + +Performing a root-cause analysis on most social conflicts almost always reveals a lack of one of the three at the most basic level. + +## Why Do These Pillars Matter? + +Dealing with social problems can be difficult, but is incredibly useful when engaging in any work, as collaboration can lead to a more efficient workflow. Work groups will outlast any project, and can meet deadlines much faster than if each person would instead have done their own thing. + +Humility, Trust, and Respect in Practice + +Being a proper team member may sound incredibly difficult, but when put into practice, is incredibly easy if broken down to the simplest levels. + +- Relax /Lose your ego +- Give AND TAKE criticism +- Fail fast, iterate, and improve +- Learn proper patience +- Be open to influence + + + +# Blameless Post-Mortem Culture + +Understanding failures can be made easier by performing a root-cause analysis and writing a “postmortem” (as is called at Google and other companies). Ensure that the report isn’t a list of apologies or excuses, and addresses what exactly failed and what has been learned. +- A good postmortem should include: + - An event summary + - Timeline of the event + - The cause of the event + - Impact/damage assessment + - A list of action items and owners to fix the problem + - A set of action items to prevent the event from reoccurring + - Lessons learned + +## Being “Googley” + +“Googley” in this document is more so just a wide term for a set of attitudes and behaviors that represent strong leadership and exemplify humility, respect, and trust. +- Thrives in ambiguity + - Can deal with conflicting requests and directions even when the environment is constantly shifting. +- Values feedback + - Can receive and give feedback gracefully and understands the value of that feedback. +- Challenges the status quo + - Can set ambitious goals and pursue them even when there may be resistance or inertia from others +- Puts the user first + - Has empathy and respect for the users of products. +- Cares about the team + - Has empathy and respect for coworkers. + + +## TLDRs +Just be aware of the pros and cons of solo work, understand the time that you and your team spend communicating and in conflict. Working effectively with a team or large organization requires being aware of your and their preferred working styles. From da8af3dddd12f77827ef3bc6af6caca27e6e951f Mon Sep 17 00:00:00 2001 From: Aidana Kuat Adilbekyzy Date: Sun, 13 Sep 2026 23:14:13 -0400 Subject: [PATCH 3/6] Aidana's part completed --- blog/se3-fall2026/index.qmd | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd index f3d1f3d..2aaa3be 100644 --- a/blog/se3-fall2026/index.qmd +++ b/blog/se3-fall2026/index.qmd @@ -1,6 +1,6 @@ --- author: [Anshu Pathak, Aidana Kuat, Jake, Gregory M. Kapfhammer] -title: xyz +title: The Three Pillars of Social Interaction date: '2026-9-14' date-format: long categories: [post, professional development, software engineering] @@ -9,13 +9,27 @@ toc: true page-layout: full --- -## Aidana's Work +## Summary +This article explains why teamwork is one of the most important parts of software engineering. It shows that being a good programmer is not enough because engineers also need to communicate, share ideas, and work well with others. Many programmers are afraid to show unfinished work because they worry about being judged or making mistakes. However, hiding work can slow down progress and prevent people from getting useful feedback. The article also challenges the “Genius Myth,” which is the idea that successful software is usually created by one brilliant person working alone. In reality, most successful software is created by teams that not only share knowledge, review each other’s work, but also solve problems together. Getting feedback early and making sure that more than one person understands the project can make development safer and faster. Thus, the author's main idea is that strong collaboration and trust are just as important as technical skills when building successful software. +### Why Software Engineering Depends on Teamwork +Software engineering is not something that people usually do successfully alone. Even though some programmers are remembered as “geniuses,” most successful software is created by many people working together. This is what the article calls the Genius Myth. People often connect Linux with Linus Torvalds or Python with Guido van Rossum, but both projects became successful because many developers contributed ideas, features, testing, and improvements. The article explains that technical ability alone is not enough. Engineers also need communication, teamwork, and social skills if they wanna build comthing sustainable. This changes the way we should think about a good software engineer. Someone can be extremely good at programming but still create problems for the team if they refuse to communicate or cooperate. The article shows that the success of a project depends not only on individual talent, but also on how well people work together. +### Why Sharing Work Early Matters +Programmers should not hide their work until it feels perfect. Many developers feel uncomfortable showing unfinished code because they are worried that other people will notice mistakes or judge their abilities. This feeling is normal, but working in complete isolation can create bigger problems later. The article gives an example of someone spending months developing an idea alone, only to discover that another person solved the same problem faster by working with others. This shows why early feedback is so useful. A teammate may notice a mistake in a few minutes that you could spend days trying to solve by yourself. It is also possible to spend a long time building something before realizing that the original idea was wrong. +This idea is closely connected to shifting left. In software development, shifting left means moving important checks earlier in the development process instead of leaving them until the end. The article compares this to using a compiler. A programmer would not normally write 10,000 lines of code and compile everything only after finishing. Instead, they write a small part, compile it, fix any problems, and then continue. This creates a short feedback loop where mistakes can be found almost immediately. -# The Three Pillars of Social Interaction +### Building a Team That Can Succeed Together + +Working as a team also means that knowledge should not stay with only one person. Using the idea of the bus factor from the book, if only one engineer understands an important part of a project, the whole team may struggle if that person suddenly becomes unavailable. Someone could leave the company, move to another team, or simply be away for a long period of time. Because of this, teams need to make sure that important knowledge is shared. When people understand each other’s work, it becomes easier to continue the project and help someone who gets stuck. + +The article also shows that the work environment can influence how easily this knowledge is shared. In the past, engineers were often given private offices because people believed that programmers needed complete silence to concentrate. Although quiet time is important, being separated from the rest of the team can create another problem. If asking a simple question means leaving your office, finding another person, or interrupting them formally, people may decide not to ask at all. Small questions can then turn into larger problems because communication does not happen naturally. At the same time, putting everyone into one large open office is not necessarily better. Constant conversations, movement, and noise can interrupt engineers when they are trying to solve difficult problems. Programming often requires deep concentration, and even a small interruption can make someone lose their train of thought. Because of this, the article argues that neither complete isolation nor constant communication is ideal. A better environment allows both focus and easy communication. Engineers should be able to work without unnecessary interruptions, but asking a teammate for help should also feel normal and simple. Some teams create signals to show when a person should not be disturbed. For example, wearing headphones may mean that someone is concentrating and should only be interrupted for something important. This allows people to protect their focus without completely separating themselves from the team. + +The larger point is that good teamwork requires a balance. Engineers sometimes need to work independently, but they should never become disconnected from the people around them. A strong team creates an environment where people can concentrate on their own tasks while still feeling comfortable asking questions, sharing knowledge, and helping each other when necessary. + +### The Three Pillars of Social Interaction Collaboration is built on the “3 pillars” of social skills that serve as a foundation for healthy interaction. - Humility @@ -31,7 +45,7 @@ Performing a root-cause analysis on most social conflicts almost always reveals Dealing with social problems can be difficult, but is incredibly useful when engaging in any work, as collaboration can lead to a more efficient workflow. Work groups will outlast any project, and can meet deadlines much faster than if each person would instead have done their own thing. -Humility, Trust, and Respect in Practice +### Humility, Trust, and Respect in Practice Being a proper team member may sound incredibly difficult, but when put into practice, is incredibly easy if broken down to the simplest levels. @@ -43,7 +57,8 @@ Being a proper team member may sound incredibly difficult, but when put into pra -# Blameless Post-Mortem Culture + +### Blameless Post-Mortem Culture Understanding failures can be made easier by performing a root-cause analysis and writing a “postmortem” (as is called at Google and other companies). Ensure that the report isn’t a list of apologies or excuses, and addresses what exactly failed and what has been learned. - A good postmortem should include: @@ -55,7 +70,7 @@ Understanding failures can be made easier by performing a root-cause analysis an - A set of action items to prevent the event from reoccurring - Lessons learned -## Being “Googley” +### Being “Googley” “Googley” in this document is more so just a wide term for a set of attitudes and behaviors that represent strong leadership and exemplify humility, respect, and trust. - Thrives in ambiguity From d0c5e07e90a7121fcb415adcfd23faaf7bb0013c Mon Sep 17 00:00:00 2001 From: Aidana Kuat Adilbekyzy Date: Mon, 14 Sep 2026 09:24:15 -0400 Subject: [PATCH 4/6] Improve some mistakes and title --- blog/se3-fall2026/index.qmd | 24 +++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd index 2aaa3be..1803213 100644 --- a/blog/se3-fall2026/index.qmd +++ b/blog/se3-fall2026/index.qmd @@ -1,10 +1,10 @@ --- author: [Anshu Pathak, Aidana Kuat, Jake, Gregory M. Kapfhammer] -title: The Three Pillars of Social Interaction +title: Why Teamwork Matters in Software Engineering date: '2026-9-14' date-format: long categories: [post, professional development, software engineering] -description: xyz +description: This article explores why teamwork is essential in software engineering and how collaboration can improve the quality of a project. It discusses the importance of sharing work early, getting feedback, avoiding the “Genius Myth,” and creating a team environment where knowledge and responsibility are shared. toc: true page-layout: full --- @@ -13,21 +13,18 @@ page-layout: full This article explains why teamwork is one of the most important parts of software engineering. It shows that being a good programmer is not enough because engineers also need to communicate, share ideas, and work well with others. Many programmers are afraid to show unfinished work because they worry about being judged or making mistakes. However, hiding work can slow down progress and prevent people from getting useful feedback. The article also challenges the “Genius Myth,” which is the idea that successful software is usually created by one brilliant person working alone. In reality, most successful software is created by teams that not only share knowledge, review each other’s work, but also solve problems together. Getting feedback early and making sure that more than one person understands the project can make development safer and faster. Thus, the author's main idea is that strong collaboration and trust are just as important as technical skills when building successful software. ### Why Software Engineering Depends on Teamwork -Software engineering is not something that people usually do successfully alone. Even though some programmers are remembered as “geniuses,” most successful software is created by many people working together. This is what the article calls the Genius Myth. People often connect Linux with Linus Torvalds or Python with Guido van Rossum, but both projects became successful because many developers contributed ideas, features, testing, and improvements. The article explains that technical ability alone is not enough. Engineers also need communication, teamwork, and social skills if they wanna build comthing sustainable. This changes the way we should think about a good software engineer. Someone can be extremely good at programming but still create problems for the team if they refuse to communicate or cooperate. The article shows that the success of a project depends not only on individual talent, but also on how well people work together. +Software engineering is not something that people usually do successfully alone. Even though some programmers are remembered as “geniuses,” most successful software is created by many people working together. This is what the author calls the Genius Myth. People often connect Linux with Linus Torvalds or Python with Guido van Rossum, but both projects became successful because many developers contributed ideas, features, testing, and improvements. According to the author technical ability alone is not the most important part of creating a successful project; we should not give one person credit for the achievement of an entire team or community. Engineers also need communication, teamwork, and social skills to build successful software. This changes the way we should think about a good software engineer. Someone can be extremely good at programming but still create problems for the team if they refuse to communicate or cooperate. ### Why Sharing Work Early Matters +Programmers should avoid hiding their work until it feels perfect for them. Many developers often eel uncomfortable showing unfinished code because they are worried that other people will notice mistakes or judge their abilities. This feeling is normal, however working in complete isolation can create bigger problems later. The article provides an example of someone spending months developing an idea alone, only to discover that another person solved the same problem faster by working with others. Therefore, an early feedback is extremely important. A teammate may notice a mistake in a few minutes that you could spend days trying to solve by yourself. -Programmers should not hide their work until it feels perfect. Many developers feel uncomfortable showing unfinished code because they are worried that other people will notice mistakes or judge their abilities. This feeling is normal, but working in complete isolation can create bigger problems later. The article gives an example of someone spending months developing an idea alone, only to discover that another person solved the same problem faster by working with others. This shows why early feedback is so useful. A teammate may notice a mistake in a few minutes that you could spend days trying to solve by yourself. It is also possible to spend a long time building something before realizing that the original idea was wrong. - -This idea is closely connected to shifting left. In software development, shifting left means moving important checks earlier in the development process instead of leaving them until the end. The article compares this to using a compiler. A programmer would not normally write 10,000 lines of code and compile everything only after finishing. Instead, they write a small part, compile it, fix any problems, and then continue. This creates a short feedback loop where mistakes can be found almost immediately. +This idea is closely connected to shifting left. In software development, shifting left means moving important checks earlier in the development process instead of leaving them until the end. For instance, when using a compiler, a programmer would not normally write 10,000 lines of code and compile everything only after finishing. Instead, they would write a small part, compile it, fix any problems, and only then continue. This creates a short feedback loop where mistakes can be found almost immediately. ### Building a Team That Can Succeed Together Working as a team also means that knowledge should not stay with only one person. Using the idea of the bus factor from the book, if only one engineer understands an important part of a project, the whole team may struggle if that person suddenly becomes unavailable. Someone could leave the company, move to another team, or simply be away for a long period of time. Because of this, teams need to make sure that important knowledge is shared. When people understand each other’s work, it becomes easier to continue the project and help someone who gets stuck. -The article also shows that the work environment can influence how easily this knowledge is shared. In the past, engineers were often given private offices because people believed that programmers needed complete silence to concentrate. Although quiet time is important, being separated from the rest of the team can create another problem. If asking a simple question means leaving your office, finding another person, or interrupting them formally, people may decide not to ask at all. Small questions can then turn into larger problems because communication does not happen naturally. At the same time, putting everyone into one large open office is not necessarily better. Constant conversations, movement, and noise can interrupt engineers when they are trying to solve difficult problems. Programming often requires deep concentration, and even a small interruption can make someone lose their train of thought. Because of this, the article argues that neither complete isolation nor constant communication is ideal. A better environment allows both focus and easy communication. Engineers should be able to work without unnecessary interruptions, but asking a teammate for help should also feel normal and simple. Some teams create signals to show when a person should not be disturbed. For example, wearing headphones may mean that someone is concentrating and should only be interrupted for something important. This allows people to protect their focus without completely separating themselves from the team. - -The larger point is that good teamwork requires a balance. Engineers sometimes need to work independently, but they should never become disconnected from the people around them. A strong team creates an environment where people can concentrate on their own tasks while still feeling comfortable asking questions, sharing knowledge, and helping each other when necessary. +The article also shows that the work environment can influence how easily this knowledge is shared. In the past, engineers were often given private offices because people believed that programmers needed complete silence to concentrate. Although quiet time is important, being separated from the rest of the team can create another problem. If asking a simple question means leaving your office, finding another person, or interrupting them formally, people may decide not to ask at all. Small questions can then turn into larger problems because communication does not happen naturally. At the same time, putting everyone into one large open office is not necessarily better. Constant conversations and movements can interrupt engineers when they are trying to solve difficult problems. Because of this, the article argues that neither complete isolation nor constant communication is ideal. A better environment allows both focus and easy communication. Engineers should be able to work without unnecessary interruptions, but asking a teammate for help should also feel normal and simple. Some teams create signals to show when a person should not be disturbed. For example, wearing headphones may mean that someone is concentrating and should only be interrupted for something crucial. ### The Three Pillars of Social Interaction @@ -41,7 +38,7 @@ Collaboration is built on the “3 pillars” of social skills that serve as a f Performing a root-cause analysis on most social conflicts almost always reveals a lack of one of the three at the most basic level. -## Why Do These Pillars Matter? +### Why Do These Pillars Matter? Dealing with social problems can be difficult, but is incredibly useful when engaging in any work, as collaboration can lead to a more efficient workflow. Work groups will outlast any project, and can meet deadlines much faster than if each person would instead have done their own thing. @@ -55,9 +52,6 @@ Being a proper team member may sound incredibly difficult, but when put into pra - Learn proper patience - Be open to influence - - - ### Blameless Post-Mortem Culture Understanding failures can be made easier by performing a root-cause analysis and writing a “postmortem” (as is called at Google and other companies). Ensure that the report isn’t a list of apologies or excuses, and addresses what exactly failed and what has been learned. @@ -89,10 +83,6 @@ Understanding failures can be made easier by performing a root-cause analysis an Just be aware of the pros and cons of solo work, understand the time that you and your team spend communicating and in conflict. Working effectively with a team or large organization requires being aware of your and their preferred working styles. - - - - ::: {.callout-note appearance="minimal" title="Open-Source Tool for Software Engineers" collapse="false"} Our team built `xyz`, an abc. You can view the project From 2133f888a727595dd8313e62aba901c6f9277426 Mon Sep 17 00:00:00 2001 From: pathakanshu <229002110+pathakanshu@users.noreply.github.com> Date: Mon, 14 Sep 2026 09:58:40 -0400 Subject: [PATCH 5/6] chore: update link to CLI tool --- blog/se3-fall2026/index.qmd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd index 1803213..c511b15 100644 --- a/blog/se3-fall2026/index.qmd +++ b/blog/se3-fall2026/index.qmd @@ -85,8 +85,8 @@ Just be aware of the pros and cons of solo work, understand the time that you an ::: {.callout-note appearance="minimal" title="Open-Source Tool for Software Engineers" collapse="false"} -Our team built `xyz`, an abc. You can view the project -here: [xyz on GitHub](https://github.com/pathakanshu/). +Our team built `handoff`, a simple CLI for tracking project owners, backups, and runbooks. You can view the project +here: [handoff on GitHub](https://github.com/pathakanshu/handoff). ::: From b86e8344e660fe92c1ce164795d0e7c2621b3149 Mon Sep 17 00:00:00 2001 From: Aidana Kuat Adilbekyzy Date: Mon, 14 Sep 2026 11:52:33 -0400 Subject: [PATCH 6/6] Edit the description --- blog/se3-fall2026/index.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/se3-fall2026/index.qmd b/blog/se3-fall2026/index.qmd index c511b15..c8d5082 100644 --- a/blog/se3-fall2026/index.qmd +++ b/blog/se3-fall2026/index.qmd @@ -4,7 +4,7 @@ title: Why Teamwork Matters in Software Engineering date: '2026-9-14' date-format: long categories: [post, professional development, software engineering] -description: This article explores why teamwork is essential in software engineering and how collaboration can improve the quality of a project. It discusses the importance of sharing work early, getting feedback, avoiding the “Genius Myth,” and creating a team environment where knowledge and responsibility are shared. +description: How can we work better in software development teams? toc: true page-layout: full ---