<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mathematical Dev (Posts about python)</title><link>https://www.mathematicaldev.com/</link><description></description><atom:link href="https://www.mathematicaldev.com/categories/python.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><copyright>Contents © 2026 &lt;a href="mailto:info@mathematicaldev.com"&gt;Fabian Parzer&lt;/a&gt; </copyright><lastBuildDate>Tue, 11 Aug 2026 18:58:20 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Personal Programming Guidelines</title><link>https://www.mathematicaldev.com/posts/personal-programming-guidelines/</link><dc:creator>Fabian Parzer</dc:creator><description>&lt;div&gt;&lt;blockquote&gt;
&lt;p&gt;“The secret of good writing is to strip every sentence to its cleanest components.”&lt;/p&gt;
&lt;p&gt;— William Zinsser, &lt;em&gt;On Writing Well&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Programmers are known to often obsess over what is and is not "good code." Google is famous for its Readability process, which is seen as a role model but has some critics even inside the company (see also &lt;a href="https://www.oreilly.com/library/view/software-engineering-at/9781492082781/"&gt;Software Engineering at Google&lt;/a&gt; and &lt;a href="https://www.moderndescartes.com/essays/readability/"&gt;Readability: Google's Temple to Engineering Excellence&lt;/a&gt;). I have seen disagreements on best practices lead to lengthy, exhausting discussions in meetings or during code review, delaying important work without leading anywhere. I have also seen some colleagues, for these reasons, develop the reactionary view that insisting on clean code and enforcing a lot of software patterns are impractical for real-world projects and something that most enterprises outside Big Tech cannot afford. I recognise that an over-obsession with coding standards can be detrimental to project success, and that the requirements for code quality and maintainability should take the expected scope and lifetime of the code (one-off notebook vs. PoC vs. core infrastructure) into account. But I'm not a big fan of the "we'll fix it later" mentality.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://www.mathematicaldev.com/posts/personal-programming-guidelines/"&gt;Read more…&lt;/a&gt; (33 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>programming</category><category>python</category><guid>https://www.mathematicaldev.com/posts/personal-programming-guidelines/</guid><pubDate>Sat, 02 May 2026 00:00:00 GMT</pubDate></item></channel></rss>