<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>links.lmorchard.com - #process</title>
    <link>/tags/process/</link>
    <description>Recent bookmarks tagged #process</description>
    <lastBuildDate>Mon, 02 Nov 2026 08:24:50 +0000</lastBuildDate>
    <item>
      <title>Using GraphViz for CLAUDE.md</title>
      <link>https://blog.fsck.com/2025/09/29/using-graphviz-for-claudemd/</link>
      <description>One of the things that I thought they said during the talk was that they were using .dot (GraphViz) as the language that they are using as the formalization for new processes for their coding agent. It made sense to me. There&#39;s enough dot on the Internet that models can read and understand it quite well. And it removes a whole bunch of the ambiguity of English language specifications.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #ai #claude #dev #dotviz #llms #process&lt;/p&gt;</description>
      <pubDate>Wed, 01 Oct 2025 03:31:31 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:37767</guid>
      <category>ai</category>
      <category>claude</category>
      <category>dev</category>
      <category>dotviz</category>
      <category>llms</category>
      <category>process</category>
    </item>
    <item>
      <title>Kanban? No, it can&#39;t</title>
      <link>http://aidylewis.heroku.com/2012/11/18/kanban-no-it-cant/</link>
      <description>That&#39;s an... interesting perspective: &#34;Kanban is a paternalistic project management theory that aims to set developers on the right path. It promotes the idea that the manager is the arbiter of success and the deliverer of change. And like its forbear Scrum, its major proponents are those who don’t code for a living.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #agile #coding #dev #imported:pinboard #kanban #process #scrum #to:fb #work&lt;/p&gt;</description>
      <pubDate>Thu, 22 Nov 2012 15:35:50 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:32646</guid>
      <category>agile</category>
      <category>coding</category>
      <category>dev</category>
      <category>imported:pinboard</category>
      <category>kanban</category>
      <category>process</category>
      <category>scrum</category>
      <category>to:fb</category>
      <category>work</category>
    </item>
    <item>
      <title>Kanban? No, it can&#39;t</title>
      <link>http://aidylewis.heroku.com/2012/11/18/kanban-no-it-cant</link>
      <description>That&#39;s an... interesting perspective: &#34;Kanban is a paternalistic project management theory that aims to set developers on the right path. It promotes the idea that the manager is the arbiter of success and the deliverer of change. And like its forbear Scrum, its major proponents are those who don’t code for a living.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #agile #coding #dev #kanban #process #scrum #to:fb #work&lt;/p&gt;</description>
      <pubDate>Thu, 22 Nov 2012 15:35:50 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:22783</guid>
      <category>agile</category>
      <category>coding</category>
      <category>dev</category>
      <category>kanban</category>
      <category>process</category>
      <category>scrum</category>
      <category>to:fb</category>
      <category>work</category>
    </item>
    <item>
      <title>geewax.org | Agile git Workflow</title>
      <link>http://geewax.org/2009/11/21/agile-git-workflow.html</link>
      <description>&#34;Agile&#34; is kind of a dirty word in some circles, but this describe some actually agile ways to deal with revision control using git. &#34;When we started using git to manage our source code at work, we actually jumped in a little bit too fast. It seems like there is a lot of writing about how you can do lots of really neat things with git, but no real guide about one particular way of using git for your project. This post is going to describe how we use git day to day on a reasonably large “agile-style” project.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #development #git #process #productivity #tips #tutorial #workflow&lt;/p&gt;</description>
      <pubDate>Tue, 16 Mar 2010 18:47:17 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:13033</guid>
      <category>development</category>
      <category>git</category>
      <category>process</category>
      <category>productivity</category>
      <category>tips</category>
      <category>tutorial</category>
      <category>workflow</category>
    </item>
    <item>
      <title>Alex Payne — Don&#39;t Be A Hero</title>
      <link>http://al3x.net/2010/01/09/dont-be-a-hero.html</link>
      <description>Cue the Tina Turner... o/` We don&#39;t need another hero o/` &#34;Managers: stop rewarding people for pulling long hours. Don’t punish them, of course, but rephrase the conversation within your company. If someone is working at four in the morning, something is deeply wrong. Figure out what’s broken and delegate the work out evenly across your team such that it doesn’t happen again. Don’t pat your hero on the back for “pulling another late-nighter”. You’re clearly managing someone highly motivated, but you need to shape that motivation into something more constructive. That energy needs to go into design, architecture, planning, and testing, not late night patch sessions.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #dev #heroes #process #work&lt;/p&gt;</description>
      <pubDate>Sun, 10 Jan 2010 07:04:00 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:12726</guid>
      <category>dev</category>
      <category>heroes</category>
      <category>process</category>
      <category>work</category>
    </item>
    <item>
      <title>Lessons Learned: Work in small batches</title>
      <link>http://startuplessonslearned.blogspot.com/2009/02/work-in-small-batches.html</link>
      <description>&#34;Software should be designed, written, and deployed in small batches.Small batches mean faster feedback. Small batches mean problems are instantly localized. Small batches reduce risk. Small batches reduce overhead. &#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #development #process #productivity #software #testing #work&lt;/p&gt;</description>
      <pubDate>Tue, 16 Jun 2009 14:49:14 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:12341</guid>
      <category>development</category>
      <category>process</category>
      <category>productivity</category>
      <category>software</category>
      <category>testing</category>
      <category>work</category>
    </item>
    <item>
      <title>Things You Should Never Do, Part I - Joel on Software</title>
      <link>http://www.joelonsoftware.com/articles/fog0000000069.html</link>
      <description>&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #process #qft #rewrites #webdev&lt;/p&gt;</description>
      <pubDate>Wed, 28 Jan 2009 03:28:03 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:11944</guid>
      <category>process</category>
      <category>qft</category>
      <category>rewrites</category>
      <category>webdev</category>
    </item>
    <item>
      <title>A web-focused Git workflow</title>
      <link>http://joemaller.com/2008/11/25/a-web-focused-git-workflow</link>
      <description>&#34;The key idea in this system is that the web site exists on the server as a pair of repositories; a bare repository alongside a conventional repository containing the live site. Two simple Git hooks link the pair, automatically pushing and pulling changes between them. &#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #deployment #git #hosting #process #tips #webdev&lt;/p&gt;</description>
      <pubDate>Thu, 25 Dec 2008 15:18:42 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:11809</guid>
      <category>deployment</category>
      <category>git</category>
      <category>hosting</category>
      <category>process</category>
      <category>tips</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Hacknot - If They Come, How Will They Build It?</title>
      <link>http://www.hacknot.info/hacknot/action/showEntry?eid=97</link>
      <description>&#34;the opening gambit for the vast majority of development efforts I have participated in where I have not been amongst the first generation of programmers to work on the project.&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #collaboration #dev #documentation #process #programming&lt;/p&gt;</description>
      <pubDate>Wed, 12 Sep 2007 14:20:46 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:9600</guid>
      <category>collaboration</category>
      <category>dev</category>
      <category>documentation</category>
      <category>process</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
