<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Documentation on MacWorks</title><link>https://macworks.dev/tags/documentation/</link><description>Recent content in Documentation on MacWorks</description><generator>Hugo</generator><language>en</language><atom:link href="https://macworks.dev/tags/documentation/index.xml" rel="self" type="application/rss+xml"/><item><title>Engineer Reads</title><link>https://macworks.dev/docs/week/blogs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/</guid><description>&lt;h1 id="engineering-reads--week-of-2026-06-17-to-2026-06-25"&gt;Engineering Reads — Week of 2026-06-17 to 2026-06-25&lt;a class="anchor" href="#engineering-reads--week-of-2026-06-17-to-2026-06-25"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="week-in-review"&gt;Week in Review&lt;a class="anchor" href="#week-in-review"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The dominant theme across this week&amp;rsquo;s reading is the persistent friction between idealized abstractions and messy, underlying hardware or operational realities. From the hidden environmental state that breaks reproducible C++ builds to the way mean latency metrics discard the user&amp;rsquo;s actual lived experience, the literature is heavily focused on the dangers of lossy compression in systems design. We are increasingly aware that whenever we try to flatten a complex domain—whether it&amp;rsquo;s AI capabilities, memory management, or performance monitoring—the suppressed complexity inevitably leaks back into the application layer.&lt;/p&gt;</description></item><item><title>2026-06-22</title><link>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-06-22/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-06-22/</guid><description>&lt;h1 id="engineering-reads--2026-06-22"&gt;Engineering Reads — 2026-06-22&lt;a class="anchor" href="#engineering-reads--2026-06-22"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="the-big-idea"&gt;The Big Idea&lt;a class="anchor" href="#the-big-idea"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The most impactful technical optimizations are those that reduce human toil and cognitive load, whether by recognizing that the most maintainable code is no code at all, or by aggressively automating away the tedious friction of documentation maintenance.&lt;/p&gt;
&lt;h2 id="deep-reads"&gt;Deep Reads&lt;a class="anchor" href="#deep-reads"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href="https://blog.codinghorror.com/every-choice-changes-everything-the-show/"&gt;Every Choice Changes Everything: The Show&lt;/a&gt;&lt;/strong&gt; · Jeff Atwood · Coding Horror
Atwood underscores a foundational engineering truth: our ultimate goal should be &amp;ldquo;survivable code,&amp;rdquo; acknowledging that the absolute best code is &amp;ldquo;none&amp;rdquo;. He frames software development not merely as a technical pursuit but as a deeply human process that requires robust engineering practices and genuine empathy for the team. Expanding on modern tooling, he provides a technically grounded critique of Large Language Models (LLMs), characterizing them as &amp;ldquo;JPEG for words&amp;rdquo;. He notes they excel at lossy compression tasks like summarizing complex discussions, but fundamentally lack structural understanding, often optimizing blindly without semantic awareness. He also touches on the socio-economic responsibilities of the tech industry, arguing that we have the means, but lack the will, to solve structural issues like systemic poverty. Practitioners who think critically about the socio-technical impacts of their tools and the systemic liability of code maintenance will find these reflections highly resonant.&lt;/p&gt;</description></item></channel></rss>