<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: heyimsunflower</title>
    <description>The latest articles on DEV Community by heyimsunflower (@imri).</description>
    <link>https://dev.to/imri</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F602884%2F12e9bb21-1a2f-4b08-947c-311ffdbfdb7e.png</url>
      <title>DEV Community: heyimsunflower</title>
      <link>https://dev.to/imri</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/imri"/>
    <language>en</language>
    <item>
      <title>I got tired of waiting for my teammates to review my code, so I created a bot that helps</title>
      <dc:creator>heyimsunflower</dc:creator>
      <pubDate>Tue, 02 Apr 2024 14:04:39 +0000</pubDate>
      <link>https://dev.to/imri/i-got-tired-of-waiting-for-my-teammates-to-review-my-code-so-i-created-a-bot-that-helps-15n4</link>
      <guid>https://dev.to/imri/i-got-tired-of-waiting-for-my-teammates-to-review-my-code-so-i-created-a-bot-that-helps-15n4</guid>
      <description>&lt;p&gt;Hi all, I'm a software developer and in every team that I've been at, code reviews were a major bottleneck.&lt;/p&gt;

&lt;p&gt;This bottleneck causes practical problems for our team:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;It takes a lot of manual coordination and effort for me, as a dev, to get my PR reviewed and merged.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Code left unmerged often blocks progress on other tasks, and continues to demand attention from me for a longer time (which reduces my ability to perform other tasks).&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;In general, longer PRs == less output (more time for our code to reach customers)&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;I identified three major issues that cause this problem:&lt;/p&gt;

&lt;p&gt;Devs usually have to manually coordinate the review with the reviewers ("Hey, I've replied to you on Github, can you take a look?" - stuff like that). These discussions occur on multiple chats (team channels, DMs) and different platforms (Slack, Github), and require significant manual coordination and attention from the dev.&lt;/p&gt;

&lt;p&gt;Code frequently becomes unmergeable or requires attention, and it's hard to stay on top of all open PRs and perform needed actions on time (rebasing if conflicts arise, re-running CI fails, replying to an open discussion as a reviewer)&lt;/p&gt;

&lt;p&gt;PRs are often undocumented, and it's tough to "reverse-engineer" a PR to understand what it does - especially if your team owns multiple domains.&lt;/p&gt;

&lt;p&gt;To overcome that, I &lt;a href="//devoro.co"&gt;created a bot&lt;/a&gt; that integrates with Github and Slack and more efficiently structures your code review workflow.&lt;/p&gt;

&lt;p&gt;The bot opens a Slack channel (and invites all reviewers) for every new PR. This way, reviewers collaborate on one space and are automatically updated (no need to coordinate manually!).&lt;/p&gt;

&lt;p&gt;It also sends real-time notifications whenever your code needs attention. This helps you keep your code reviewable and mergeable at all times.&lt;/p&gt;

&lt;p&gt;To reduce PR pickup time, the bot sends a daily report on all open PRs to keep everyone in sync. The report contains all needed information on each PR - increasing transparency and accountability between team members (everyone knows what they need to do to keep the team unblocked).&lt;/p&gt;

&lt;p&gt;Curious to hear what you think! Is this an issue you've encountered as well?&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Treating code reviews like engineering tasks?</title>
      <dc:creator>heyimsunflower</dc:creator>
      <pubDate>Fri, 15 Mar 2024 19:59:48 +0000</pubDate>
      <link>https://dev.to/imri/treating-code-reviews-like-engineering-tasks-2doi</link>
      <guid>https://dev.to/imri/treating-code-reviews-like-engineering-tasks-2doi</guid>
      <description>&lt;p&gt;I'm managing a team (around 6 devs, ~200 devs in the entire company) and we've always had some issues with code reviews and specifically collaboration between team members on reviews.&lt;/p&gt;

&lt;p&gt;The way it used to work was as follows - someone would throw their merge request in the team's channel, and then start pinging team members for reviews.&lt;/p&gt;

&lt;p&gt;This works eventually, but it keeps the dev blocked until someone takes a look at his code; moreover, some MRs are forgotten about/lost in the channel - until the dev remembers them and resends them again.&lt;/p&gt;

&lt;p&gt;We started with a new pilot - sending a &lt;a href="https://devoro.co/"&gt;general Slack message &lt;/a&gt;before our daily standup and assigning each team member to an MR he should review; so far it's working much better, and team members are integrating reviews into their workflow.&lt;/p&gt;

&lt;p&gt;Has anyone experienced anything similar? would appreciate some extra tips to reduce the time it takes to merge code/improve collaboration.&lt;br&gt;
Thanks!&lt;/p&gt;

&lt;p&gt;(Full disclosure - I'm building a &lt;a href="https://devoro.co/"&gt;tool&lt;/a&gt; that originated as a solution for this exact problem. I'm curious about how different teams approach and solve this issue )&lt;/p&gt;

</description>
    </item>
    <item>
      <title>How we reduced our code review time by 30%</title>
      <dc:creator>heyimsunflower</dc:creator>
      <pubDate>Fri, 29 Dec 2023 20:05:34 +0000</pubDate>
      <link>https://dev.to/imri/how-we-reduced-our-code-review-time-by-30-44ed</link>
      <guid>https://dev.to/imri/how-we-reduced-our-code-review-time-by-30-44ed</guid>
      <description>&lt;p&gt;As a team manager overseeing a group of talented developers, I'm constantly seeing the common pain points associated with code reviews and pull request management.&lt;/p&gt;

&lt;p&gt;With a team size of approximately six developers and a broader organization comprising around 200 developers, it became evident that our existing approach was falling short.&lt;/p&gt;

&lt;p&gt;The traditional method involved throwing PRs into the team's communication channel, resulting in the need to ping team members for reviews constantly. This approach proved to be suboptimal, with developers often experiencing unnecessary delays, and PRs occasionally being forgotten or overlooked.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Experimenting with a New Approach&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;To address these challenges, we experimented to integrate code reviews seamlessly into our daily workflow. During our daily standup meetings, we started assigning unreviewed PRs to each team member based on relevancy, code ownership, and availability. This approach aimed to make code reviews an integral part of our daily routine, ensuring that reviews were completed on time and reducing the need for continuous follow-ups and pings among team members.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The Results and Benefits&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The implementation of our new approach yielded promising results. Developers were more proactive in completing their assigned reviews, taking ownership of their time slots, and allocating dedicated periods for code reviews. This proactive mindset expedited the review process and reduced the effort required to coordinate and ping other team members for reviews. The overall impact was a significant reduction in the time it took to merge code, enhanced collaboration, and increased team productivity.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Seeking Further Insights&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;While our new approach has shown considerable success, we believe in the power of shared knowledge and continuous improvement. We invite fellow engineering managers and developers to share their experiences and provide additional insights into reducing code merge time and improving collaboration. By fostering a community of learning and collaboration, we can collectively refine our practices and optimize the code review process.&lt;/p&gt;

&lt;p&gt;From that experiment, we created &lt;a href="//devoro.co"&gt;devoro&lt;/a&gt;. It's a simple Slack bot that sends a Daily Digest report of all open PRs before your daily standup--creating accountability between team members and reducing pickup time.&lt;/p&gt;

&lt;p&gt;Curious to know if any other devs here adopted a similar workflow? How did it end up working for you?&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>javascript</category>
      <category>programming</category>
      <category>productivity</category>
    </item>
    <item>
      <title>We started to approach code reviews as engineering tasks. We're merging now faster than ever</title>
      <dc:creator>heyimsunflower</dc:creator>
      <pubDate>Fri, 29 Dec 2023 11:18:11 +0000</pubDate>
      <link>https://dev.to/imri/we-started-to-approach-code-reviews-as-engineering-tasks-were-merging-now-faster-than-ever-220i</link>
      <guid>https://dev.to/imri/we-started-to-approach-code-reviews-as-engineering-tasks-were-merging-now-faster-than-ever-220i</guid>
      <description>&lt;p&gt;As a team manager overseeing a group of talented developers, I'm constantly seeing the common pain points associated with code reviews and pull request management.&lt;/p&gt;

&lt;p&gt;With a team size of approximately six developers and a broader organization comprising around 200 developers, it became evident that our existing approach was falling short.&lt;/p&gt;

&lt;p&gt;The traditional method involved throwing PRs into the team's communication channel, resulting in the need to ping team members for reviews constantly. This approach proved to be suboptimal, with developers often experiencing unnecessary delays, and PRs occasionally being forgotten or overlooked.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Experimenting with a New Approach&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;To address these challenges, we experimented to integrate code reviews seamlessly into our daily workflow. During our daily standup meetings, we started assigning unreviewed PRs to each team member based on relevancy, code ownership, and availability. This approach aimed to make code reviews an integral part of our daily routine, ensuring that reviews were completed on time and reducing the need for continuous follow-ups and pings among team members.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The Results and Benefits&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The implementation of our new approach yielded promising results. Developers were more proactive in completing their assigned reviews, taking ownership of their time slots, and allocating dedicated periods for code reviews. This proactive mindset expedited the review process and reduced the effort required to coordinate and ping other team members for reviews. The overall impact was a significant reduction in the time it took to merge code, enhanced collaboration, and increased team productivity.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Seeking Further Insights&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;While our new approach has shown considerable success, we believe in the power of shared knowledge and continuous improvement. We invite fellow engineering managers and developers to share their experiences and provide additional insights into reducing code merge time and improving collaboration. By fostering a community of learning and collaboration, we can collectively refine our practices and optimize the code review process.&lt;/p&gt;

&lt;p&gt;From that experiment, we created &lt;a href="//devoro.co"&gt;devoro&lt;/a&gt;. It's a simple Slack bot that sends a Daily Digest report of all open PRs before your daily standup--creating accountability between team members and reducing pickup time.&lt;/p&gt;

&lt;p&gt;Curious to know if any other devs here adopted a similar workflow? How did it end up working for you?&lt;/p&gt;

</description>
    </item>
    <item>
      <title>We started to approach code reviews as engineering tasks. We're merging now faster than ever</title>
      <dc:creator>heyimsunflower</dc:creator>
      <pubDate>Mon, 05 Jun 2023 19:00:43 +0000</pubDate>
      <link>https://dev.to/imri/we-started-to-approach-code-reviews-as-engineering-tasks-were-merging-code-now-faster-than-ever-1hfp</link>
      <guid>https://dev.to/imri/we-started-to-approach-code-reviews-as-engineering-tasks-were-merging-code-now-faster-than-ever-1hfp</guid>
      <description>&lt;p&gt;In the fast-paced world of software development, effective code reviews and seamless management of merge requests (MRs) play a crucial role in ensuring smooth collaboration and timely delivery. However, many teams struggle with bottlenecks, delays, and the risk of MRs getting lost in the shuffle. In this article, we will explore a practical approach to address these challenges and optimize the code review process, leading to improved team efficiency and streamlined collaboration.&lt;/p&gt;

&lt;p&gt;As a team manager overseeing a group of talented developers, I have encountered firsthand the common pain points associated with code reviews and MR management. &lt;/p&gt;

&lt;p&gt;With a team size of approximately six developers and a broader organization comprising around 200 developers, it became evident that our existing approach was falling short.&lt;/p&gt;

&lt;p&gt;The traditional method involved throwing MRs into the team's communication channel, resulting in the need to constantly ping team members for reviews. This approach proved to be suboptimal, with developers often experiencing unnecessary delays, and MRs occasionally being forgotten or overlooked.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Experimenting with a New Approach&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;To address these challenges, we embarked on an experiment to integrate code reviews seamlessly into our daily workflow. During our daily standup meetings, we started assigning unreviewed MRs to each team member based on relevancy, code ownership, and availability. This approach aimed to make code reviews an integral part of our daily routine, ensuring that reviews were completed in a timely manner and reducing the need for continuous follow-ups and pings among team members.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The Results and Benefits&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The implementation of our new approach yielded promising results. Developers were more proactive in completing their assigned reviews, taking ownership of their time slots and allocating dedicated periods for code reviews. This proactive mindset not only expedited the review process but also reduced the effort required to coordinate and ping other team members for reviews. The overall impact was a significant reduction in the time it took to merge code, enhanced collaboration, and increased team productivity.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Seeking Further Insights&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;While our new approach has shown considerable success, we believe in the power of shared knowledge and continuous improvement. We invite fellow engineering managers and developers to share their experiences and provide additional insights into reducing code merge time and improving collaboration. By fostering a community of learning and collaboration, we can collectively refine our practices and optimize the code review process.&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
