<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Teamwork on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/teamwork/</link><description>Recent content in Teamwork on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Thu, 09 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/teamwork/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Communication and Knowledge Sharing [Sprint 2, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-c/s2w2-communication/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-c/s2w2-communication/</guid><description>&lt;h2 id="overview">
 &lt;a class="anchor" href="#overview" data-anchor="overview" aria-hidden="true">#&lt;/a>
 Overview
&lt;/h2>
&lt;p>Sprint 2 Week 2 (April 3 to 9) communication work centered on three substantial code reviews posted as GitLab discussion threads, merge coordination for 13+ teammate MRs, and Linear ticket management. The reviews caught several critical bugs that would have reached production, including a broken SQL join and an auth bypass.&lt;/p>
&lt;hr>
&lt;h2 id="1-threaded-mr-reviews-with-severity-grading">
 &lt;a class="anchor" href="#1-threaded-mr-reviews-with-severity-grading" data-anchor="1-threaded-mr-reviews-with-severity-grading" aria-hidden="true">#&lt;/a>
 1. Threaded MR Reviews with Severity Grading
&lt;/h2>
&lt;p>Three MRs were reviewed this week, all following the same structured approach: positive callouts first, then issues grouped by severity (P0 blockers through P3 nitpicks), with code fix suggestions for every issue.&lt;/p></description></item><item><title>PPL: Communication and Knowledge Sharing [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-c/s2w1-communication/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-c/s2w1-communication/</guid><description>&lt;h2 id="overview">
 &lt;a class="anchor" href="#overview" data-anchor="overview" aria-hidden="true">#&lt;/a>
 Overview
&lt;/h2>
&lt;p>Sprint 2 Week 1 (Mar 24 to 30) communication focused on two detailed code reviews posted as GitLab discussion threads, merge coordination for the team, and direct code contributions to address review findings.&lt;/p>
&lt;hr>
&lt;h2 id="1-threaded-mr-reviews-with-severity-grading">
 &lt;a class="anchor" href="#1-threaded-mr-reviews-with-severity-grading" data-anchor="1-threaded-mr-reviews-with-severity-grading" aria-hidden="true">#&lt;/a>
 1. Threaded MR Reviews with Severity Grading
&lt;/h2>
&lt;p>This sprint I shifted to posting reviews as &lt;strong>GitLab discussion threads&lt;/strong> rather than plain comments. Discussion threads can be individually resolved by the MR owner after addressing each issue, making it clear which feedback has been handled and which is still open.&lt;/p></description></item><item><title>PPL: Building an Integrated Tool Ecosystem for a 9-Person University Team</title><link>https://blog.abhipraya.dev/ppl/part-a/teamwork-tools/</link><pubDate>Thu, 12 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/teamwork-tools/</guid><description>&lt;h2 id="why-tooling-is-a-team-problem-not-a-devops-problem">
 &lt;a class="anchor" href="#why-tooling-is-a-team-problem-not-a-devops-problem" data-anchor="why-tooling-is-a-team-problem-not-a-devops-problem" aria-hidden="true">#&lt;/a>
 Why Tooling Is a Team Problem, Not a DevOps Problem
&lt;/h2>
&lt;p>Most university software engineering courses teach you &lt;em>which&lt;/em> tools to use (Git for version control, Jira for tickets, Docker for deployment). What they rarely teach is &lt;strong>how tools interact with each other&lt;/strong>, and what happens when they don&amp;rsquo;t.&lt;/p>
&lt;p>In a professional environment, a single commit can trigger a cascade: CI runs tests, a Slack bot notifies the team, a coverage report lands in SonarQube, and the ticket moves to &amp;ldquo;In Review&amp;rdquo; on the project board. This doesn&amp;rsquo;t happen by accident. Someone has to build that integration layer, and in a university team, that someone is usually whoever cares enough about developer experience to do it.&lt;/p></description></item><item><title>PPL: Communication and Knowledge Sharing [Sprint 1, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-c/s1w3-communication/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-c/s1w3-communication/</guid><description>&lt;h2 id="overview">
 &lt;a class="anchor" href="#overview" data-anchor="overview" aria-hidden="true">#&lt;/a>
 Overview
&lt;/h2>
&lt;p>This week&amp;rsquo;s communication contributions fall into five categories: detailed code reviews, merge coordination, issue tracking, direct code contributions to teammates&amp;rsquo; MRs, and proactive Discord communication to unblock the team.&lt;/p>
&lt;hr>
&lt;h2 id="1-detailed-code-reviews-with-actionable-fixes">
 &lt;a class="anchor" href="#1-detailed-code-reviews-with-actionable-fixes" data-anchor="1-detailed-code-reviews-with-actionable-fixes" aria-hidden="true">#&lt;/a>
 1. Detailed Code Reviews with Actionable Fixes
&lt;/h2>
&lt;p>Reviewed 15 MRs this week. Each review goes beyond surface-level &amp;ldquo;LGTM&amp;rdquo;: they include issue categorization (Critical/Important), before/after code snippets, and concrete suggested fixes that the MR owner can directly apply.&lt;/p></description></item></channel></rss>