<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Expressive Code on Lost in IT | Kromg</title><link>https://kromg.github.io/tags/expressive-code/</link><description>Recent content in Expressive Code on Lost in IT | Kromg</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://kromg.github.io/tags/expressive-code/index.xml" rel="self" type="application/rss+xml"/><item><title>Let it speak: when code should speak for itself - but it does not</title><link>https://kromg.github.io/posts/let_it_speak_01_a_tale_of_failures/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://kromg.github.io/posts/let_it_speak_01_a_tale_of_failures/</guid><description>&lt;p&gt;I&amp;rsquo;m writing a book about how to write Bash code, and how to write it well.&lt;/p&gt;&#10;&lt;p&gt;That book is all about the little things that I would have liked to know when I started putting together my first scripts,&#10;contraptions that did what they had to do, but were not pleasant to look to (well, not too much).&lt;/p&gt;&#10;&lt;p&gt;One of those contraptions has made it to these days, buried deep down into one of my oldest backups, and I found it while&#10;spelunking in search for examples of what &lt;em&gt;not&lt;/em&gt; to do in a script.&lt;/p&gt;</description></item></channel></rss>