<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (cwinters)</title>
    <link>https://pinboard.in/u:cwinters/public/</link>
    <description>recent bookmarks from cwinters</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/"/>
	<rdf:li rdf:resource="https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html"/>
	<rdf:li rdf:resource="https://htmx.org/essays/no-build-step/"/>
	<rdf:li rdf:resource="https://how.complexsystems.fail/"/>
	<rdf:li rdf:resource="https://danluu.com/essential-complexity/"/>
	<rdf:li rdf:resource="http://rachelbythebay.com/w/2019/10/05/nxdomain/?ck_subscriber_id=512839195"/>
	<rdf:li rdf:resource="https://hackernoon.com/complexity-and-strategy-325cd7f59a92"/>
	<rdf:li rdf:resource="http://alexsquest.com/texts/complexity-in-software-1-black-boxes-and-message-oriented-programming"/>
	<rdf:li rdf:resource="https://www.facebook.com/notes/kent-beck/competence-1-complexity/362494960450041"/>
	<rdf:li rdf:resource="http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html"/>
	<rdf:li rdf:resource="http://www.macroresilience.com/2011/12/29/people-make-poor-monitors-for-computers/"/>
	<rdf:li rdf:resource="http://perspectives.mvdirona.com/2012/02/26/ObservationsOnErrorsCorrectionsTrustOfDependentSystems.aspx"/>
	<rdf:li rdf:resource="http://en.wikipedia.org/wiki/Wicked_problems"/>
	<rdf:li rdf:resource="http://www.imatix.com/articles:whats-wrong-with-amqp"/>
	<rdf:li rdf:resource="http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763"/>
	<rdf:li rdf:resource="http://scripting.com/stories/2010/10/17/howToDoAStandardPart3.html"/>
	<rdf:li rdf:resource="http://www.newyorker.com/online/blogs/newsdesk/2010/06/gawande-stanford-speech.html"/>
	<rdf:li rdf:resource="http://blog.publicobject.com/2010/06/glass-houses.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/">
    <title>Thoughts on slowing the fuck down</title>
    <dc:date>2026-03-26T14:37:24+00:00</dc:date>
    <link>https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[nice rant, but also some solid non-ranty advice toward the end. Rant example: "You have zero fucking idea what's going on because you delegated all your agency to your agents. You let them run free, and they are merchants of complexity. They have seen many bad architectural decisions in their training data and throughout their RL training. You have told them to architect your application. Guess what the result is?"]]></description>
<dc:subject>ai programming design complexity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:17d457fa7f50/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html">
    <title>Code rant: The Configuration Complexity Clock</title>
    <dc:date>2024-09-06T14:34:53+00:00</dc:date>
    <link>https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html</link>
    <dc:creator>cwinters</dc:creator><dc:subject>configuration programming deployment complexity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:53b969e9f0ee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:configuration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://htmx.org/essays/no-build-step/">
    <title>&lt;/&gt; htmx ~ Why htmx Does Not Have a Build Step</title>
    <dc:date>2023-08-26T13:43:36+00:00</dc:date>
    <link>https://htmx.org/essays/no-build-step/</link>
    <dc:creator>cwinters</dc:creator><dc:subject>javascript compatibility complexity</dc:subject>
<dc:identifier>https://pinboard.in/u:cwinters/b:5474943e2204/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:compatibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://how.complexsystems.fail/">
    <title>How Complex Systems Fail</title>
    <dc:date>2022-05-16T17:30:42+00:00</dc:date>
    <link>https://how.complexsystems.fail/</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[(also a pretty sweet url) "But all practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes. The degree of uncertainty may change from moment to moment. That practitioner actions are gambles appears clear after accidents; in general, post hoc analysis regards these gambles as poor ones. But the converse: that successful outcomes are also the result of gambles; is not widely appreciated."]]></description>
<dc:subject>complexity failure engineering postmortem management distributed operations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:2a6efb1abab4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:failure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:postmortem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:operations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://danluu.com/essential-complexity/">
    <title>Against essential and accidental complexity</title>
    <dc:date>2021-01-02T17:02:56+00:00</dc:date>
    <link>https://danluu.com/essential-complexity/</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[I think part of this is the fact that the author (Dan Luu) is likely only presented with problems that have a great deal of accidental complexity -- similar to the President only being presented with questions that were unanswerable by all lower levels of the Executive Branch

That said, the idea that increasing capabilities make new questions even *askable* is a powerful one, and it's probably worth rocking your world with completely different tools now and again to appreciate your unknown unknowns.]]></description>
<dc:subject>complexity programming performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:ad90858e4e39/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rachelbythebay.com/w/2019/10/05/nxdomain/?ck_subscriber_id=512839195">
    <title>Break before make, abstractions, and sleazy ISPs</title>
    <dc:date>2019-10-07T17:50:11+00:00</dc:date>
    <link>http://rachelbythebay.com/w/2019/10/05/nxdomain/?ck_subscriber_id=512839195</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[so many layers: "Did the cloud provider offer a way to update the existing record without having to delete it outright? Probably. Did the extra layer of abstraction know that? Maybe, maybe not. Did anyone have any idea what was about to happen? Absolutely not."]]></description>
<dc:subject>complexity cloudcomputing dns leakyabstraction</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:f3e11eceb3c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:cloudcomputing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:leakyabstraction"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hackernoon.com/complexity-and-strategy-325cd7f59a92">
    <title>Complexity and Strategy – Hacker Noon</title>
    <dc:date>2017-12-13T20:51:43+00:00</dc:date>
    <link>https://hackernoon.com/complexity-and-strategy-325cd7f59a92</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[long one, but worth the read; even worth coming back to every so often]]></description>
<dc:subject>complexity architecture management strategy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:97fc5deeb7b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:strategy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://alexsquest.com/texts/complexity-in-software-1-black-boxes-and-message-oriented-programming">
    <title>The Alex's Quest | Complexity in Software</title>
    <dc:date>2014-08-21T14:02:07+00:00</dc:date>
    <link>http://alexsquest.com/texts/complexity-in-software-1-black-boxes-and-message-oriented-programming</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[first of a solid (and short!) three-part series on managing complexity in software]]></description>
<dc:subject>complexity architecture design messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:fe661f770ac4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.facebook.com/notes/kent-beck/competence-1-complexity/362494960450041">
    <title>Competence = 1 / Complexity</title>
    <dc:date>2014-08-21T13:59:13+00:00</dc:date>
    <link>https://www.facebook.com/notes/kent-beck/competence-1-complexity/362494960450041</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[short post full of gold from Kent Beck, resulting in: "The programmer least likely to be able to handle the extra complexity is exactly the one most likely to create it."]]></description>
<dc:subject>architecture design experience complexity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:199a8ec037d5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:experience"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html">
    <title>Where is the complexity? - Coding the Architecture</title>
    <dc:date>2014-08-12T12:57:51+00:00</dc:date>
    <link>http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[someone needs to coin a "Law of Conservation of Essential Complexity" -- though that kind of begs the question as to what's essential and what's accidental; also a couple examples of pushing the problem around]]></description>
<dc:subject>architecture complexity pushingtheproblem</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:8bd712335d1c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:pushingtheproblem"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.macroresilience.com/2011/12/29/people-make-poor-monitors-for-computers/">
    <title>People Make Poor Monitors for Computers at Macroeconomic Resilience</title>
    <dc:date>2012-04-11T18:38:35+00:00</dc:date>
    <link>http://www.macroresilience.com/2011/12/29/people-make-poor-monitors-for-computers/</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[on how increasingly automated yet complex systems make it more difficult to deal with problems that come up, focuses on airlines for the part I read]]></description>
<dc:subject>automation complexity behavior econ toread</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:f8be6c2e91a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:behavior"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:econ"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:toread"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://perspectives.mvdirona.com/2012/02/26/ObservationsOnErrorsCorrectionsTrustOfDependentSystems.aspx">
    <title>Perspectives - Observations on Errors, Corrections, &amp; Trust of Dependent Systems</title>
    <dc:date>2012-02-28T15:03:12+00:00</dc:date>
    <link>http://perspectives.mvdirona.com/2012/02/26/ObservationsOnErrorsCorrectionsTrustOfDependentSystems.aspx</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA["Systems sufficiently complex enough to require deep vertical technical specialization risk complexity blindness. Each vertical team knows their component well but nobody understands the interactions of all the components. The two solutions are 1) well-defined and well-documented interfaces between components, be they hardware or software, and 2) and very experienced, highly-skilled engineer(s) on the team focusing on understanding inter-component interaction and overall system operation, especially in fault modes. Assigning this responsibility to a senior manager often isn’t sufficiently effective."]]></description>
<dc:subject>complexity design hardware faulttolerance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:6ddba5e37b31/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:faulttolerance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://en.wikipedia.org/wiki/Wicked_problems">
    <title>Wicked problem - Wikipedia, the free encyclopedia</title>
    <dc:date>2012-02-06T16:56:28+00:00</dc:date>
    <link>http://en.wikipedia.org/wiki/Wicked_problems</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[understanding this and following its immediate web could probably suck up a month or two of serious time: "Conklin identifies the following as defining characteristics of wicked problems: 1. The problem is not understood until after the formulation of a solution. 2. Wicked problems have no stopping rule. 3. Solutions to wicked problems are not right or wrong. 4. Every wicked problem is essentially novel and unique. 5. Every solution to a wicked problem is a 'one shot operation.' 6. Wicked problems have no given alternative solutions."]]></description>
<dc:subject>design collaboration management complexity chaos change planning via:dancres</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:ac303862aece/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:collaboration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:chaos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:planning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:via:dancres"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.imatix.com/articles:whats-wrong-with-amqp">
    <title>What is wrong with AMQP (and how to fix it) - High Performance Solutions</title>
    <dc:date>2011-11-29T17:28:56+00:00</dc:date>
    <link>http://www.imatix.com/articles:whats-wrong-with-amqp</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA["...to solve complex technical problems does not demand deep technical competence, in fact that gets in the way. There is lots of deep technical competence around: thousands of highly skilled engineers who know messaging backwards and forwards, and who would enjoy working on something as juicy as AMQP....The way to solve complex problems is to make it easy for others to solve them. This is where competent engineers often fail: they understand technology but not people. Complexity is a human issue, and good design is about overcoming human limitations, not technical ones."]]></description>
<dc:subject>design amqp architecture complexity messaging standards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:d70cd94c02b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:amqp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:standards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763">
    <title>[#HHH-2763] (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush() - Hibernate JIRA</title>
    <dc:date>2011-01-11T16:33:24+00:00</dc:date>
    <link>http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[This is a great example of why you should be wary of ORMs. They can be very productive, but there's a lot of magic going on under the hood.]]></description>
<dc:subject>orm hibernate java complexity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:cwinters/b:c7e650971af8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:orm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:hibernate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://scripting.com/stories/2010/10/17/howToDoAStandardPart3.html">
    <title>Scripting News: The enemy of progress is complexity</title>
    <dc:date>2010-10-18T15:46:24+00:00</dc:date>
    <link>http://scripting.com/stories/2010/10/17/howToDoAStandardPart3.html</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[the point cannot be repeated enough: "The programmers of the previous generation felt secure that in order to make real software you had to understand all that they understood, which assured them a place at the top of the ladder, and made young dudes like me start out at the bottom. Heh. This is always a mistake. If you've created too complex a world, the next generation will just create a new one that's simpler. One that they understand and you don't. You're still at the top of a ladder -- your ladder. They just created a new one, and you're not even on it."
]]></description>
<dc:subject>complexity development architecture design</dc:subject>
<dc:identifier>https://pinboard.in/u:cwinters/b:f01d80596304/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.newyorker.com/online/blogs/newsdesk/2010/06/gawande-stanford-speech.html">
    <title>News Desk: The Velluvial Matrix : The New Yorker</title>
    <dc:date>2010-06-24T16:49:51+00:00</dc:date>
    <link>http://www.newyorker.com/online/blogs/newsdesk/2010/06/gawande-stanford-speech.html</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA[does this apply to software too? should it? "Why does anyone receive suboptimal care? After all, society could not have given us people with more talent, more dedication, and more training than the people in medical science have—than you have. I think the answer is that we have not grappled with the fact that the complexity of science has changed medicine fundamentally. This can no longer be a profession of craftsmen individually brewing plans for whatever patient comes through the door. We have to be more like engineers building a mechanism whose parts actually fit together, whose workings are ever more finely tuned and tweaked for ever better performance in providing aid and comfort to human beings. "
]]></description>
<dc:subject>healthcare complexity system development</dc:subject>
<dc:identifier>https://pinboard.in/u:cwinters/b:c98ce09cad1a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:healthcare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:system"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.publicobject.com/2010/06/glass-houses.html">
    <title>Public Object: glASS HOuses</title>
    <dc:date>2010-06-18T19:34:52+00:00</dc:date>
    <link>http://blog.publicobject.com/2010/06/glass-houses.html</link>
    <dc:creator>cwinters</dc:creator><description><![CDATA["Software is complex. Running unfamiliar programs can be frustrating. But if you condemn a program because it doesn't work just as you expect, you're being an asshole. "
]]></description>
<dc:subject>complexity learning hate</dc:subject>
<dc:identifier>https://pinboard.in/u:cwinters/b:05ff2b8c5a7e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:complexity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:cwinters/t:hate"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>