From 7167a6f33acb607974eeec0a2c331c5fb7c73472 Mon Sep 17 00:00:00 2001
From: Sean Massa <endangeredmassa@gmail.com>
Date: Fri, 29 Sep 2023 21:51:31 -0500
Subject: [PATCH] add more old articles

---
 README.md                                     |   9 ++
 app/article-data.js                           |  30 ++++
 app/components/article-card.gjs               |   2 +-
 app/components/article-header.gjs             |   2 +-
 .../articles/conventional-comments.md         |  77 +++++++++++
 .../articles/detangling-the-code-review.md    | 111 +++++++++++++++
 .../articles/detangling-the-manager.md        |  96 +++++++++++++
 .../articles/detangling-the-standup.md        | 130 ++++++++++++++++++
 app/templates/articles/theme-pact.md          | 111 +++++++++++++++
 9 files changed, 566 insertions(+), 2 deletions(-)
 create mode 100644 app/templates/articles/conventional-comments.md
 create mode 100644 app/templates/articles/detangling-the-code-review.md
 create mode 100644 app/templates/articles/detangling-the-manager.md
 create mode 100644 app/templates/articles/detangling-the-standup.md
 create mode 100644 app/templates/articles/theme-pact.md

diff --git a/README.md b/README.md
index 18ffdaa..458f959 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,11 @@
 # ember-blog
 
+## To Do
+
+- ensure articles are sorted by date
+- scroll to top on link clicking
+- manually check links
+- add redirects for old slug to new slug
+- 404 protection: https://remysharp.com/2023/09/26/no-more-404
+- allow `published: false`
+
diff --git a/app/article-data.js b/app/article-data.js
index 362598e..6616755 100644
--- a/app/article-data.js
+++ b/app/article-data.js
@@ -11,6 +11,36 @@ let articles =
     "title": "An Incremental Approach to Linting to Your Projects",
     "date": "2017-08-08",
     "description": "I have gone through the process of adding linting to existing, large projects a couple of times. I've learned some lessons about how to approach this so that it's not disruptive to the team doing other work. Follow these steps to get robust linting into your project without pulling team velocity to a halt!"
+  },
+  {
+    "slug": "detangling-the-manager",
+    "title": "Detangling the Manager: Supervisor, Team Lead, Mentor",
+    "date": "2021-11-18",
+    "description": "The term Manager means a lot of different things to different companies. It can include Project Manager, Product Manager, Technical Lead, Team Lead, Mentor, Coach, Supervisor, as well as Individual Contributor. Most often, in my experience, a manager is responsible for at least these roles: Supervisor, Mentor, and Team Lead.<br><br>There is great value in having those roles played by separate people."
+  },
+  {
+    "slug": "detangling-the-standup",
+    "title": "Detangling the Standup: Status Reports, Team Planning, Context Sharing, and Community Building",
+    "date": "2022-01-04",
+    "description": "Standups are often applied without understanding the problem they are solving. This leads to:<br><br>1. Not clearly solving a specific problem<br>2. Not solving a problem with the best solution<br>3. A daily interruption to deep work<br><br>What follows is a pragmatic and ideal approach to resolving this situation. The pragmatic approach is to understand so you can excel within that system. The ideal solution tries to change the system to better serve the team."
+  },
+  {
+    "slug": "detangling-the-code-review",
+    "title": "Detangling the Code Review: Questions, Preferences, Suggestions, Conventions, Requirements",
+    "date": "2022-03-14",
+    "description": "Teams can have more effective code reviews if they default to approval and have a framework for delivering and managing feedback."
+  },
+  {
+    "slug": "conventional-comments",
+    "title": "Conventional Comments: Streamlining Feedback",
+    "date": "2022-03-15",
+    "description": "How I use Conventional Comments to make it clear (1) what kind of comment it is, (2) what specifically I want, and (3) how important it is that my comment is resolved."
+  },
+  {
+    "slug": "theme-pact",
+    "title": "Theme Pact: Goal Setting Framework with no Goals",
+    "date": "2023-02-02",
+    "description": "Pulling from several sources, my framework for goal setting includes:<br><ul><li><b>Theme:</b> a guiding light, a default decision</li><li><b>PACT Goals:</b> specific personal outputs I commit to</li><li><b>Habits:</b> systems for making sure I achieve those outputs</li></ul>"
   }
 ]
 export default articles;
diff --git a/app/components/article-card.gjs b/app/components/article-card.gjs
index ddab956..ee65ecf 100644
--- a/app/components/article-card.gjs
+++ b/app/components/article-card.gjs
@@ -7,7 +7,7 @@ import { LinkTo } from '@ember/routing';
       @model={{@article}}>
         {{@article.title}}
     </LinkTo>
-    <p class="meta"><i>{{@article.description}}</i></p>
+    <p class="meta"><i>{{{@article.description}}}</i></p>
     <p class="meta">{{@article.date}}</p>
   </div>
 </template>
diff --git a/app/components/article-header.gjs b/app/components/article-header.gjs
index 3206992..043c9e7 100644
--- a/app/components/article-header.gjs
+++ b/app/components/article-header.gjs
@@ -5,7 +5,7 @@ import { LinkTo } from '@ember/routing';
     <div class="post-link">
       {{@article.title}}
     </div>
-    <p class="meta"><i>{{@article.description}}</i></p>
+    <p class="meta"><i>{{{@article.description}}}</i></p>
     <p class="meta">{{@article.date}}</p>
   </div>
 </template>
diff --git a/app/templates/articles/conventional-comments.md b/app/templates/articles/conventional-comments.md
new file mode 100644
index 0000000..c5a6016
--- /dev/null
+++ b/app/templates/articles/conventional-comments.md
@@ -0,0 +1,77 @@
+<ArticleHeader @article={{this.model}} />
+
+The idea behind [Conventional Comments](https://conventionalcomments.org/) on Code Reviews is that structure can convey a lot meaning quickly.
+
+This process helps convey understanding of:
+
+- what change is suggested
+- why it matters
+- how important it is to change now
+
+You can use the process [as documented by the author](https://conventionalcomments.org/), but I like using the following the following customized version.
+
+## Streamlined Conventional Comments
+
+All comments must be resolved before merging, but resolution can look different for different kinds of comments.
+
+All comments are also non-blocking unless otherwise specified.
+
+### Format
+
+```jsx
+<label> ([blocking-status]): <subject>
+
+[details]
+```
+
+- label: this is a single label that signifies what kind of comment (see above) is being left:
+    - question
+    - suggestion
+    - convention
+    - requirement
+- blocking-status (optional)
+    - (blank): does not block merging
+    - non-blocking: does not block merging
+    - soft-blocking: does not block merging, but the comment should be resolved in a follow-up code change
+    - blocking: blocks merging
+- subject: brief and explicit description, no need for padded language
+- details (optional): the context, reasoning, and conversational messaging
+
+## Examples
+
+> **question (non-blocking):** Were you able to find a case when `paging.next` doesn't exist?
+> 
+> When I tested analyzing temporary failures, the URL for next always seemed to exist and be the same across all subsequent polls. I ended up having to check whether `items.length === 0` (`events.length === 0`) instead to break out of the loop.
+
+> **suggestion (non-blocking):** extract functions
+> 
+> In the model hooks especially, I suggest extracting functions aggressively. This makes it easier to see each concept that happens as the result of a hook.
+> 
+> What do you think about something like this?
+> 
+> ```
+> beforeCreate: async function(model, options) {
+>     ensureEmailMxDomain(model);
+>     ensureLatLong(model);
+> }
+> ```
+
+> **convention (blocking):** use `last_email_interaction_at`
+> 
+> Our convention for database column names says that dates should end in `_at`.
+> 
+> I marked this as “blocking” because migrations are expensive and risky in this database. We should minimize the number of migrations where possible.
+
+> **requirement (blocking):** invert conditional `if (found)` should be `if (!found)`
+> 
+> It looks like the code and test are accidentally checking that the file was found, but I think here we expect the file to not be found.
+
+# Takeaways
+
+This structure makes it clear to others what needs to be done. It's also a good forcing function for the author to consider the feedback they provide more carefully.
+
+The best part is that readers don't have to know about the structure to understand feedback written in this style.
+
+# Related Topics
+
+See [Detangling the Code Review](./detangling-the-code-review) for details about different kinds of feedback.
diff --git a/app/templates/articles/detangling-the-code-review.md b/app/templates/articles/detangling-the-code-review.md
new file mode 100644
index 0000000..23f084f
--- /dev/null
+++ b/app/templates/articles/detangling-the-code-review.md
@@ -0,0 +1,111 @@
+<ArticleHeader @article={{this.model}} />
+
+# Responsibility
+
+As a team member, you have the following responsibilities to your teammates regard code reviews:
+
+- respond to code review requests within half a business day with your review or a note about needing more time
+- review code with compassion and respect
+- review code thoroughly, thinking through possible impacts and edge cases
+- after approving code, you take on a share of the responsibility for that code operating correctly in production
+
+As a code change author requesting review, you have the following responsibilities:
+
+- drive progress on the code review being merged
+- find appropriate reviewers for your code change
+- make your code easy to review
+    - submit smaller code changes, when possible
+    - write detailed descriptions of why your changes were made in review requests
+- respond quickly to feedback
+
+# Understanding Code Review Comments
+
+**Your goal is to approve the code change if at all possible.** This builds momentum, shows progress, and even in cases where the author needs to make a change, allows their original contribution to be impactful.
+
+There are different types of Code Reviews comments:
+
+- **Questions** are simply that, questions about the code change. They can vary in severity.
+- **Preferences** are personal, non-functional tweaks to the code.
+- **Suggestions** are alternate, functional ways to fulfill the requirements. Ideally they come with some reasoning or pros/cons.
+- **Conventions** are project- or team-based rules to follow. They work best if they are automatically enforceable. That way, no human has to comment about these issues.
+- **Requirements** are what needs to be done for the code to accomplish its purpose. The code change must meet its requirements.
+
+**Question Comments**
+
+Sometimes you need more context. Question Comments are a great place to ask for more information because others may have the same question and/or the answer may add context that other reviewers can use.
+
+When asking questions, make it clear how important it is to get an answer. You may have a mild curiosity or a serious concern.
+
+*Blocking?* If you need to know the answer because you consider the code change to meet the requirements, block merging. Otherwise, do not block merging.
+
+**Preference Comments**
+
+There’s a time and place for discussing preferences in a codebase, but that’s not during Code Review. When reviewing code, focus on correctness instead.
+
+When you want to discuss code preferences, bring it up during existing team meetings or schedule a new meeting to discuss this.
+
+All of these are preferences, not facts about what’s best, in most programming languages:
+
+- where to put optional spaces before/after other syntax
+- indentation value (tabs/2-space/4-space)
+- anything else that’s not pointing out a failure to meet a Convention or Requirement
+
+*Blocking?* If you insist on commenting with a preference, it should never block merging the code change.
+
+**Suggestion Comments**
+
+When the code change meets the requirements, but it could do so *better* in some way, you can comment with a suggestion. If the code change meets the requirements in theory, but in practice there will still be significant problems, then it’s still a Requirements Comment.
+
+All Suggestion Comments should clearly describe what the suggested code change is, why it’s better, and why it might be worse.
+
+This is the fuzziest type of comment because complexity and human judgement creep in. You could suggest a code change because the original code would be slow (for a certain definition) and the suggested change is faster. But maybe that code is only ever run on a handful of items in a place where some delay would be fine, anyway. Is it worth making the code faster? Is the faster code harder to read? Maybe we’re not making the right tradeoff in this case.
+
+Be mindful of the pros and cons of each approach when making Suggestion Comments.
+
+*Blocking?* If the suggestion is an alternative approach that is debatably better, do not block merging. If the suggested code change is significantly better (in your opinion), recommend that they adopt it now or submit a new code change immediately after.
+
+**Convention Comments**
+
+There are authoring rules that programmers should follow when working in a given codebase that are based on (1) what currently exists in that codebase and (2) agreed-upon rules of the team that owns that codebase.
+
+As many of these as possible should be automatically enforced in the CI test suite. These tests should be runnable in local development environments as well. Ideally, these are also checked in real-time in the dev’s editor. Linting is the most common example of automating this, but it can include performance tests, generative tests, and more.
+
+Not all conventions will be automatable. These are often related to naming variables and functions.
+
+Code Review should only include comments on conventions when they are not automatable. Even then, they should never be blocking comments. Conventions can always be cleaned up immediately after merging a code change that breaks them without affecting the functionality of the system.
+
+Preferences can become Conventions after discussing the issue with the team. These are best batched into infrequent discussions to avoid Convention thrashing.
+
+*Blocking?* If you are commenting about a failure to meet a Convention, it should rarely block merging the code change. You can recommended they submit a new code change immediately after to remedy the convention violation.
+
+**Requirements Comments**
+
+There are absolute requirements for a given task for which a code change is made. The code change must fulfill those requirements without introducing new bugs.
+
+If the code change meets the requirements in theory, but in practice there will still be significant problems, then you should still consider your comment to be a Requirements Comment.
+
+*Blocking?* Failure to meet requirements or introducing new bugs are the only guaranteed way to block a code change from being merged.
+
+**Flexibility**
+
+This structure gives you a shared set of language and expectations to make code review a more efficient process.
+
+However, there is room for flexibility. When the site is down, feel free to toss these ideas out the window. When you have a good reason to deviate from this, just explain way.
+
+# Takeaways
+
+This model gives you the tools to consume and express code review comments more effectively.
+
+The type of comment (Question, Preference, Convention, Suggestion, or Requirement) should lead to whether or not resolution of that comment should block merging the code change:
+
+- Question: non-blocking or blocking; depends on context
+- Preference: non-blocking; don’t comment with this unless you can’t help yourself
+- Suggestion: non-blocking or soft-blocking
+- Convention: soft-blocking
+- Requirement: blocking
+
+# Related Topics
+
+However feedback on code changes is provided, they should be communicated with compassion. You should consider how your comments will be received based on team context and experience level of the author. Dr. McKayla goes into much more detail on [compassionate code review](https://www.michaelagreiler.com/respectful-constructive-code-review-feedback/).
+
+See [Conventional Commits](./conventional-commits) for details about how I use this model to write code review comments.
diff --git a/app/templates/articles/detangling-the-manager.md b/app/templates/articles/detangling-the-manager.md
new file mode 100644
index 0000000..1763455
--- /dev/null
+++ b/app/templates/articles/detangling-the-manager.md
@@ -0,0 +1,96 @@
+<ArticleHeader @article={{this.model}} />
+
+<b>Main Idea (tl;dr)</b>
+
+The core argument follows. The most important parts are bold.
+
+1. **Manager (title) is usually some combination of (roles) Supervisor, Team Lead, and Mentor.**
+2. These roles cannot be played well together because they have conflicting incentives:
+    * **Supervisor: benefit the company**
+    * **Team Lead: benefit the team**
+    * **Mentor: benefit the individual**
+3. **There's a critical conflict between Supervisor and Mentor that makes it really tough to tell your Manager you need help doing your job.**
+4. Ideal Solution: Make sure all roles are:
+    * played at all
+    * played well
+    * played by separate people
+5. Pragmatic Solution: As the Manager, be mindful:
+    * that you should be playing each role
+    * of when you are playing a specific role
+    * to assess yourself in each role
+
+*Note that everything I say here has been exhaustively experienced, internalized, and formalized with [Trek Glowacki](https://twitter.com/trek/).*
+
+---
+
+# **Conflicting Roles and Incentives**
+
+The term Manager means a lot of different things to different companies. It can include Project Manager, Product Manager, Technical Lead, Team Lead, Mentor, Coach, Supervisor, as well as Individual Contributor. Most often, in my experience, a manager is responsible for at least these roles: Supervisor, Mentor, and Team Lead.
+
+**Supervisor Manager:** They are most concerned with ensuring the cost of employees is justified by their output. They are incentivized to benefit the company.
+
+**Team Lead Manager:** They are most concerned with the performance of the team as a whole. They provide team vision and quality. They are incentivized to benefit the team.
+
+**Mentor Manager:** They are most concerned with helping team members become better versions of themselves, in a professional context. They are incentivized to benefit the individual.
+
+For each type of manager, they play their secondary roles to a lesser degree, sometimes being absent entirely. There are managers that can play all three roles reasonably well, but they seem very rare.
+
+The Mentor role is most often absent and most often needed. It also exposes the strongest conflict between these three roles. Mentor directly conflicts with Supervisor: When you feel like you are not doing a good job, you should be able to talk to a Mentor about it, but a Supervisor may judge you for it, affecting your opportunities and compensation.
+
+# **Ideal Solution: Separate Roles for Separate People**
+
+I think the clearest solution is to split the roles, but that option isn't possible for every organization. Either your company is too small or too rigid in organizational structure. If you can't split up the roles, see the next section on a Pragmatic Solution. If you can split the roles, read on!
+
+Manager is not a role. It's a position in a hierarchy, a title. Instead of having titled managers, make sure you have people playing the different necessary roles. I've found the following breakdown to be effective.
+
+**Department Head as Supervisor:** A Department Head is a good place to have someone playing the Supervisor role. That means you will have no other supervisors in the department. For this to be successful, the person playing this role has to do a good job setting expectations across the department. This can be done through progression and review systems. It's not easy, but it's also the most important role to split out from the product team's day-to-day work because of the detrimental nature of the conflict between this and other roles.
+
+**Team Member as Team Lead:** Teams should not grow so large that the person playing the Team Lead role has to focus 100% of their time on that role's responsibilities. That leaves time for them to contribute to the team's work on the product itself. I've found that a 50-50 split between Team Lead and Individual Contributor roles often works well, but it will ebb and flow throughout a project or team's lifespan.
+
+**Company Member as Mentor:** Anyone in the company with the understanding of their mentee's role can play the Mentor role. This could be a more senior engineer in another team or your current team's project manager. This does not need to be kept within a team boundary. This can be a 100% focus role, but that will be rare until a company is quite large. This is more likely a 25-50% role for someone playing a different role.
+
+For those playing multiple roles, expectations should be set appropriately. It's all too easy to expect an Individual Contributor to perform similarly to others on a team even though they are also a mentor or a team lead.
+
+This works! The role conflict melts away, leading to a happier, more productive department.
+
+# **Pragmatic Solution: Strategies for Playing Conflicting Roles**
+
+Companies aren't always large or flexible enough to split up the Manager's roles into multiple people.
+
+The core strategy to resolve the internal conflict is to try to only wear one role's hat at a time. While doing this, you still have to acknowledge the conflict between the roles you play. You also need to acknowledge this to your teammates.
+
+**Act as Different People:** In 1:1s, you are sometimes playing the Mentor or the Supervisor role. If possible, schedule separate meetings per role you are playing. For example, this could be a performance review meeting as a Mentor and a compensation adjustment meeting as a Supervisor.
+
+**Develop a Leadership Voice:** In product management, project management, and status meetings, you are often playing the Team Lead role, but sometimes also the Individual Contributor role. Make sure that your suggestions are made as one or the other. For example, you might share a project management decision from your work with the department head and other Team Leads. You may suggest a fellow engineer explore a different technical approach to their work. One is broadcasting a decision, the other is suggesting an option.
+
+**Stay Self-aware:** In other ad-hoc interactions, you may be playing any of these roles. Recognize that your suggestions can come across as commands. Be explicit with teammates about which roles you are playing when.
+
+## Performance Assessment **of Your Many Hats**
+
+If your company doesn't have clear expectations per role, you should write them out for yourself.
+
+Given your roles' expectations, do a self review as each one:
+
+- Supervisor
+- Team Lead
+- Mentor
+
+Then, ask each Team Member to review your performance of each role they interact with:
+
+- Supervisor
+- Team Lead
+- Mentor
+
+Performance Review itself is a topic for another day. The import part here is that each role is reviewed separately.
+
+# Continued Learning
+
+For me:
+
+- @[endangeredmassa](https://twitter.com/endangeredmassa)
+
+For you:
+
+- [https://wherewithall.com/](https://wherewithall.com/)
+- [https://lethain.com/](https://lethain.com/)
+- [https://docondev.com/](https://docondev.com/)
diff --git a/app/templates/articles/detangling-the-standup.md b/app/templates/articles/detangling-the-standup.md
new file mode 100644
index 0000000..6c82c75
--- /dev/null
+++ b/app/templates/articles/detangling-the-standup.md
@@ -0,0 +1,130 @@
+<ArticleHeader @article={{this.model}} />
+
+Standups are often applied without understanding the problem they are solving. Broken down by potential problem being solved, this becomes more obvious:
+
+| Problem | One Solution | Typically Called |
+| --- | --- | --- |
+| unclear project or task status | Status Report meetings | Standup |
+| inefficient team collaboration | Team Planning meetings | Standup |
+| unclear team problems and/or solutions | Context Sharing meetings | Standup |
+| team member silos or other lacks of communication | Community Building meetings | Standup |
+
+Because of this, we have new problems:
+
+1. Not clearly solving a specific problem
+2. Not solving a problem with the best solution
+3. A daily interruption to deep work
+
+What follows is a pragmatic and ideal approach to resolving this situation. The pragmatic approach is to understand so you can excel within that system. The ideal solution tries to change the system to better serve the team.
+
+Note that the value of each process will vary by team composition and project management strategies.
+
+- Remote (similar time zones) vs. Remote (various time zones) vs in-person
+- Cross-functional vs function-specific
+- More vs. less experienced
+- Kanban vs. Sprint vs. Project vs. Waterfall styles
+
+# Pragmatic Approach
+
+Figure out what kind of standup you have will help you understand its purpose. That will help you accept the value it provides, even if it’s not for you.
+
+You can then try to fulfill that purpose to the best of your ability.
+
+**Status Report “Standups”**
+
+Individual contributions to these meetings focus on what was done, what’s on track (or not), and what’s up next. They are generally less useful to the individual contributors on a team.
+
+These contributions are most useful to the team lead and/or stakeholders to understand the status of the project.
+
+> Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. I should finish it this morning. Today, I’ll finish that story and pick up the next one.
+
+
+
+**Context Sharing “Standups”**
+
+Individual contributions to these meetings focus on what was done, how, and/or why. They include specifics.
+
+These contributions are generally more useful to the individual contributors on a team. They are less useful to the team lead.
+
+> Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. Turns out, the documentation was wrong about how to differentiate between bad credentials and bad integration.
+> 
+> In my debugging, I built up a wrapper component that smooths over the confusing parts and more clearly validates inputs based on our needs. Make sure you use it in our other apps if you need to implement Google sign in.
+
+
+**Community Building “Standups”**
+
+Individual contributions to these meetings pay lip service to the premise of a “Standup”, but spend a non-trivial amount of time on socializing.
+
+These contributions may feel like a waste of time, but are likely useful to all team members. This kind of meeting can build the team community.
+
+> Yesterday I was working on the “Sign In With Google” story and I’ll keep working on it today.
+> 
+> Last night I took my kids to a trampoline park for the first time. It was bonkers, but a lot of fun. I ended up jumping just as much as the kids.
+
+**Team Planning “Standups”**
+
+Individual contributions to these meetings focus on what needs to be done, especially before/after/together with other team members today or in the very near future.
+
+These contributions are generally more useful to the individual contributors on a team, but the team lead needs to know as well.
+
+> Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. I’m still not sure what the problem is. Can someone pair with me on this today, ideally this morning?
+
+
+# Ideal Approach
+
+The best approach to tackling the Standup confusion is to make a list of these kinds of problems, decide if your team has any of those problems (solved for, or not), then ensure you have good solutions for the problems your team has.
+
+For example, say your team has a Status Report “Standup”. You would break out the problems:
+
+| Potential Problem | We Have Problem? | Current Solution |
+| --- | --- | --- |
+| unclear project or task status | yes | Status Report “Standup” |
+| unclear team problems and/or solutions | no | N/A |
+| team member silos or other lacks of communication | yes | MISSING |
+| inefficient team collaboration | no | N/A |
+
+In this example, you believe that your team only really has two (of these) problems that need solving: “unclear project or task status” and “team member silos or other lacks of communication”.
+
+The current Status Report “Standup” is solving the “unclear project or task status” problem. If you wanted to get rid of this meeting and solve that problem in another way, you could work with the Project Manager and/or Team Lead to find out why your project management system can’t produce this without a daily update from individual contributors. From there, you could experiment with other solutions that fill that gap.
+
+The problem “team member silos or other lacks of communication” is not being solved at all! You could propose that the team schedule other meetings with this explicit purpose. Or, if you want to expand the current “Standup”, you could make socializing an explicit part of that meeting.
+
+## Alternate Solutions to “Standups”
+
+If you have these kinds of “Standup”, consider proposing these alternative solutions. 
+
+Almost all of these solutions reduce the number of meetings team members have. The effect of this will vary per person, but in general, it provides more uninterrupted time for deep work.
+
+**Status Reports**
+
+- **Smaller Tasks:** During project planning, break the larger tasks into smaller tasks that can be accomplished individually. Bonus points for making these smaller tasks deployable and valuable to the system or users.
+    - *Why It’s Better:* With larger tasks, you can spend a long time on one task with no discernible progress in the project management software. With smaller tasks, you can see (for example) 3 out of 5 smaller tasks for a larger chunk of work in the project management software.
+- **More Status Labels:** In your project management software, you may need more statuses that can track where a task is. These could include Deployed to Staging, QA Review, and Ready for Design vs. Ready for Dev.
+    - *Why It’s Better:* Detailed status labels can make it clearer to stakeholders what the progress is as well as who’s responsible for moving it forward.
+- **Asynchronous Status Reports:** Status reports don’t really need to be made in a synchronous team meeting. Instead, have a rule that status reports be submitted in email or chat every morning.
+    - *Why It’s Better:* This provides a similar amount of value to stakeholders and leads without requiring a meeting.
+
+**Team Planning**
+
+- **Smaller Tasks:** During project planning, break the larger tasks into smaller tasks that can be accomplished individually. Bonus points for making these smaller tasks deployable and valuable to the system or users.
+    - *Why It’s Better:* If you have larger tasks that have more complex requirements, it is more likely that the task will rely on others’ work in some way. Breaking tasks into smaller pieces makes each individual step less likely to conflict with something else. It also makes it easier to see connections between tasks.
+- **Daily Strategy Meetings:** Yes, this is not exactly an alternative to the Team Planning “Standup”, more a refocusing of it. Define the meeting to be about planning the strategy of the day, explicitly.
+    - *Why It’s Better:* Instead of spending time on the ceremony of the standup, you are spending time on solving the problem at hand.
+
+**Context Sharing**
+
+- **Asynchronous Communication:** Add more context in pull requests, code comments, documentation, email, and/or chat systems. It’s important to have some team guidelines on when and where to do this. It really shouldn’t (only) be communicated in a meeting.
+    - *Why It’s Better:* Context that’s documented in an expected place is far more value for a far longer period of time than spoken briefly in a meeting.
+- **Frameworks/Conventions:** You can remove the need for some types of context sharing by establishing conventions or using frameworks.
+    - *Why It’s Better:* This allows future solutions to conventionalized problems to not need (1) novel solutions per problem or (2) sharing context of problem-specific solutions.
+
+**Community Building**
+
+- **Augment Standup:** Make it known and acceptable to socialize during Standup. Add an optional question to your format that’s more personal, like “do anything fun recently?”.
+    - *Why It’s Better:* Teams often work better if the members have a rapport. This should not be mandated, but should be encouraged.
+- **Virtual Breaks:** Set up specific times (like Tuesdays/Thursdays from 10am - 12pm) where people can join a virtual break room call. People can hang out, work, and/or chat in that space.
+    - *Why It’s Better:* Especially for remote teams, it can be easy to feel disconnected from your team. Having time specifically set aside for socializing can make it happen more smoothly.
+
+# Take Away
+
+Standups are not bad, just often misapplied. Understand the problems you need solved and what the best solutions might be. If that’s a standup-style meeting, then go for it. I just don’t think it should be the default.
diff --git a/app/templates/articles/theme-pact.md b/app/templates/articles/theme-pact.md
new file mode 100644
index 0000000..209cd29
--- /dev/null
+++ b/app/templates/articles/theme-pact.md
@@ -0,0 +1,111 @@
+<ArticleHeader @article={{this.model}} />
+
+Setting goals seems important, but never feels effective. I never have enough data to estimate proper terms for a goal to make it motivating instead of ignorable or daunting.
+
+- Should my goal be to reduce build times by 15% or 20%?
+- Should I achieve this by the end of the month or quarter?
+- What happens if I or the business decide that's not important between then and now?
+- What happens if I literally can't complete this because of technical or logistical blockers?
+
+I'll spare you my long (and boring) history with struggling to answer these questions and deal with the consequences of them. The point is that I need to either find a way to work within the typical framework or find a new one that works for me.
+
+I've tried the first approach for many years. It's time to try the second.
+
+# Theme Pact Framework
+
+Pulling from several sources, my framework for goal setting includes:
+
+- **Theme:** a guiding light, a default decision
+- **PACT Goals:** specific personal outputs I commit to
+- **Habits:** systems for making sure I achieve those outputs
+
+James Clear (of [Atomic Habits](https://jamesclear.com/atomic-habits) fame) really summarizes the framework compared to traditional approaches.
+
+> You do not rise to the level of your goals, you fall to the level of your systems.
+> 
+
+I like this model because you control the direction and personal outputs. Success is therefore under your control. You won’t fail because of external forces made your original goals impossible.
+
+By leveraging the power of direction, defaults, and habits, this framework makes success happen as a matter of course. Well, that's the theory.
+
+# What is a Theme?
+
+*This concept comes from the [Theme System](https://www.thethemesystem.com/), developed by [Myke Hurley](https://twitter.com/imyke) and [CGP Grey](https://twitter.com/cgpgrey/) through [Cortex](https://www.relay.fm/cortex).*
+
+Myke and CGP Grey define the Theme System in intentionally vague terms. They want users to use their framework to build a more specific system for themselves.
+
+The themes themselves are defined with a name, description, and a set of ideal outcomes. They call them "yearly themes" for convenience, but these can be seasons, quarters, or whatever works best for you.
+
+For my purposes, I decided a theme has to be:
+
+**North Star:** A theme is a North Star. It's a default position. When you come to a decision, you ask yourself, does one of the choices lead me towards my north star? If so, that is your default decision. You can still obviously choose something else, but defaults have incredible power.
+
+**Resonant:** A theme resonates with you as a deep desire for a high-level focus on a direction. This can be some major thing you want to change, improve, or maintain.
+
+**Flexible:** A theme is flexible. It should not be overly specific. It can adjust to life (and sometimes world) changes.
+
+**Infallible:** A theme is infallible. You cannot fail. It's a direction, not a destination.
+
+# What is a PACT Goal?
+
+*This concept comes from [SMART goals are not so smart: make a PACT instead](https://nesslabs.com/smart-goals-pact)* by [Anne-Laure Le Cunff](https://twitter.com/anthilemoon) through [Ness Labs](https://twitter.com/ness_labs).
+
+Anne-Laure defines a PACT Goal as:
+
+**Purposeful:** A PACT Goal calls out to a purpose in your life, similar to how a Theme should be Resonant. Aligning your PACT goals to your Theme will accomplish this by proxy.
+
+**Actionable:** A PACT Goal is be actionable. It focuses on outputs instead of outcomes to keep you in control of your progress on this goal.
+
+**Continuous:** A PACT Goal is continuous. It is something you can do periodically and frequently.
+
+**Trackable:** A PACT Goal is trackable. There should be some measure of either (1) whether or not you did a thing or (2) how many times you did a thing.
+
+I extend this further to include:
+
+**Accountable:** My PACT Goals are accountable. I share my goal with someone who can prod me when I'm not making progress on it.
+
+**Habitual:** My PACT Goals are habitual. They either rely on existing habits to trigger new behavior or define new habits I'll need to develop in order to accomplish the goal.
+
+# What is a Habit?
+
+*This concept comes from [Atomic Habits](https://jamesclear.com/atomic-habits)* by [James Clear](https://jamesclear.com/).
+
+James defines a habit as:
+
+- **Cue:** The trigger for the habit.
+- **Craving:** What you want that the habit will provide.
+- **Response:** The behavior you perform after the Cue triggers the habit.
+- **Reward:** The result of engaging in the habitual behavior.
+
+Cues need to be obvious. The best cues are location and time.
+
+Response needs to be easy. Something you can do quickly and without much effort, if at all possible. James suggests putting a 2-minute limit on this.
+
+Craving and Reward are two sides of the same coin. You need to make the habit result in something that you will enjoy in the short term so that you repeat it, leading to the desired long-term change.
+
+I focus mostly on setting new good habits here, but James makes it clear that you can use a similar system to break bad habits.
+
+# Setting a Theme Pact
+
+Steps:
+
+1. Define your Theme
+2. Define the duration (a quarter, season, year, etc.)
+3. Set your PACT Goals
+4. If any of your PACT Goals have blocker habits: define habit breakers
+5. If any of your PACT Goals needs support from a new habit: define new habits
+6. Track your progress
+
+# Outcomes
+
+My first stab at this was too much all at once. I did form some useful habits around my theme, but I couldn’t keep up with everything I tried to do. 
+
+I (re-)discovered that smaller iterations are better. If you are going from zero to Theme Pact, I suggest iteratively adding pieces until you are comfortable with a given piece. To start, define a theme OR work on forming one good habit OR work on breaking one bad habit.
+
+# Resources
+
+If you want to learn more about these topics, I recommend the following.
+
+- Theme System: [https://www.thethemesystem.com](https://www.thethemesystem.com/)
+- PACT Goals: [https://nesslabs.com/smart-goals-pact](https://nesslabs.com/smart-goals-pact)
+- The Power of Habit: [https://charlesduhigg.com/the-power-of-habit/](https://charlesduhigg.com/the-power-of-habit/)