<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Design on Geeky Schmidt</title><link>https://geekyschmidt.com/categories/design/</link><description>Recent content in Design on Geeky Schmidt</description><image><title>Geeky Schmidt</title><url>https://geekyschmidt.com/images/papermod-cover.png</url><link>https://geekyschmidt.com/images/papermod-cover.png</link></image><generator>Hugo</generator><language>en</language><copyright>Copyright ©2002-2026, Nicholas Schmidt; all rights reserved.</copyright><lastBuildDate>Tue, 25 Jan 2022 04:15:57 +0000</lastBuildDate><atom:link href="https://geekyschmidt.com/categories/design/index.xml" rel="self" type="application/rss+xml"/><item><title>Optimise Later</title><link>https://geekyschmidt.com/post/2022-01-25-optimise-later/</link><pubDate>Tue, 25 Jan 2022 04:15:57 +0000</pubDate><guid>https://geekyschmidt.com/post/2022-01-25-optimise-later/</guid><description>&lt;p&gt;One of our design philosophies at &lt;a href="https://blueprintpower.com"&gt;Blueprint Power&lt;/a&gt; is that you don&amp;rsquo;t spend too much time optimising code early on but instead focus on writing maintainable code with maintainable languages. More often than not, I have watched teams concentrate on picking the fastest language or improving the processing by some percentage instead of defining a solid data model and design pattern for the code.&lt;/p&gt;
&lt;p&gt;This hunch has served me well throughout the years. More often than not, by the time the performance bottleneck impacts you if your teams have been writing documented code in a readable language, it is easy enough to profile and optimise those areas that need it. For every performance landmine you find, there are at least a hundred you missed by focusing on this philosophy.&lt;/p&gt;</description></item></channel></rss>