<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Development on Michael Kent</title><link>https://michaelkent.me/category/development/</link><description>Recent content in Development on Michael Kent</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>© 2026 Michael Kent</copyright><lastBuildDate>Sun, 19 Mar 2023 16:26:19 +0000</lastBuildDate><atom:link href="https://michaelkent.me/category/development/index.xml" rel="self" type="application/rss+xml"/><item><title>Steps To Figuring Out Performance Issues</title><link>https://michaelkent.me/steps-to-figuring-out-performance-issues/</link><pubDate>Sun, 19 Mar 2023 16:26:19 +0000</pubDate><guid>https://michaelkent.me/steps-to-figuring-out-performance-issues/</guid><description>&lt;p&gt;Programming performance issues can be a frustrating and time-consuming problem for developers. However, tracking down these issues is a crucial step in creating software. Here are some steps that developers can take to track down programming performance issues:&lt;/p&gt;
&lt;p&gt;The first thing to do is &lt;strong&gt;ALWAYS&lt;/strong&gt; hook up a profiler to your code, reproducing your issue, and measuring what is causing it. Performance issues are often not obvious and if you don’t profile you’ll waste a bunch of time speeding up things that don’t matter(or just hide the base issue).&lt;/p&gt;</description></item><item><title>Form Validation is No Fun</title><link>https://michaelkent.me/form-validation-is-no-fun/</link><pubDate>Thu, 27 Sep 2018 17:13:00 +0000</pubDate><guid>https://michaelkent.me/form-validation-is-no-fun/</guid><description>&lt;p&gt;Over the years Software Engineering has gone through many iterations of best practices. Form field validation is no exception to this.&lt;/p&gt;
&lt;p&gt;The morale of the story here is stop rolling your own validation. This is one of those things that seem super easy to do, so you just quick roll your own and then move on. Except you never move on because you’ll get tickets to fix stuff until the end of time.&lt;/p&gt;</description></item><item><title>NLog Setup</title><link>https://michaelkent.me/nlog-setup/</link><pubDate>Sat, 14 Jan 2017 22:21:29 +0000</pubDate><guid>https://michaelkent.me/nlog-setup/</guid><description>&lt;p&gt;Every time I make a file new project I need to add logging – how many times have I spent time figuring out what needs to go where, how to format the error email, and how to log uncaught errors(oh noes!). Too many times. So here is me condensing adding NLog to a web project quickly and easily:&lt;/p&gt;
&lt;p&gt;Install NLog.config(and with it NLog) on your web project.&lt;/p&gt;
&lt;p&gt;Add these to NLog.config:&lt;/p&gt;</description></item><item><title>Exceptions Deserve to be Handled</title><link>https://michaelkent.me/exceptions-deserve-to-be-handled/</link><pubDate>Thu, 28 Jan 2016 16:34:11 +0000</pubDate><guid>https://michaelkent.me/exceptions-deserve-to-be-handled/</guid><description>&lt;p&gt;Some code smell I came upon today! Exceptions should always be handled in some way, even if just logging it and continuing on(the next person troubleshooting a problem will thank you). Also, exceptions should be exceptional – they are slow and break up code flow; avoid using them for normal circumstances, like bad user input.&lt;/p&gt;
&lt;div class="highlight-wrapper"&gt;&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-csharp" data-lang="csharp"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="k"&gt;try&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="p"&gt;{&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; &lt;span class="c1"&gt;//do something&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="k"&gt;catch&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Exception&lt;/span&gt; &lt;span class="n"&gt;e&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;</description></item><item><title>Development, Testing, and Quality Assurance</title><link>https://michaelkent.me/development-testing-and-quality-assurance/</link><pubDate>Thu, 30 Apr 2015 16:46:03 +0000</pubDate><guid>https://michaelkent.me/development-testing-and-quality-assurance/</guid><description>&lt;p&gt;How important is it that your software runs correctly and to spec? For most software it is of the utmost importance. One of the &lt;a href="https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/" target="_blank" rel="noreferrer"&gt;Joel Test&lt;/a&gt; 12 is “Do you fix bugs before writing new code?”. Smart development, testing, and QA help prevent bugs in software.&lt;/p&gt;
&lt;p&gt;Fixing Code Before Production and After&lt;/p&gt;
&lt;p&gt;Fixing code before it goes to production will save you time. I have had bugs that would have taken 30 seconds to fix before going to production that I spent more than a week on fixing after it went to production because it messed up data in another system.&lt;/p&gt;</description></item><item><title>When Building An Interface, Think About the Customer</title><link>https://michaelkent.me/when-building-an-interface-think-about-the-customer/</link><pubDate>Mon, 23 Mar 2015 16:36:17 +0000</pubDate><guid>https://michaelkent.me/when-building-an-interface-think-about-the-customer/</guid><description>&lt;p&gt;When building an interface/class, a software engineer should think about how other software engineers are his target customer. This means that the interface should be designed with the needs and preferences of other software engineers in mind.&lt;/p&gt;
&lt;p&gt;Here are some reasons why software engineers should consider other software engineers as their target customer when building an interface:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Efficiency in Workflow: Other software engineers will have similar workflows to the developer who is building the interface. The interface should be designed to facilitate efficient workflows, using well-established patterns and conventions to streamline the process.&lt;/p&gt;</description></item></channel></rss>