<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Research on Hillel Wayne</title>
    <link>https://www.hillelwayne.com/tags/research/</link>
    <description>Recent content in Research on Hillel Wayne</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 09 Mar 2020 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.hillelwayne.com/tags/research/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>This is How Science Happens</title>
      <link>https://www.hillelwayne.com/post/this-is-how-science-happens/</link>
      <pubDate>Mon, 09 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/this-is-how-science-happens/</guid>
      <description>I love science. Not the &amp;ldquo;space is beautiful&amp;rdquo; faux-science, but the process of doing science. Hours spent calibrating equipment, cross-checking cites of cites of cites, tedious arguments about p-values and prediction intervals, all the stuff that makes science Go. And, when it does happen, the drama. I also want us to use more empirical science in software. That&amp;rsquo;s why I wrote a talk on it!
One thing lay folk don&amp;rsquo;t realize is that science is social.</description>
    </item>
    
    <item>
      <title>The best software engineering paper you haven&#39;t read</title>
      <link>https://www.hillelwayne.com/post/the-best-se-paper/</link>
      <pubDate>Fri, 12 Jan 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/the-best-se-paper/</guid>
      <description>I want to call attention to one of the best papers I&amp;rsquo;ve ever read on software engineering, ever. Ready to be dazzled? Here goes:
Fixing Faults in C and Java Source Code: Abbreviated vs. Full-Word Identifier Names (preprint)
I know, right? Sheer brilliance.
Okay, maybe it doesn&amp;rsquo;t have the most exciting subject matter, but I think everybody should read it. Here&amp;rsquo;s why:
Manageable scope. &amp;ldquo;Is clean code good?&amp;rdquo; Too broad, what is &amp;lsquo;clean code&amp;rsquo; and what is &amp;lsquo;good&amp;rsquo;?</description>
    </item>
    
    <item>
      <title>What&#39;s the Right Tool for the Job?</title>
      <link>https://www.hillelwayne.com/post/right-tool/</link>
      <pubDate>Sun, 10 Dec 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.hillelwayne.com/post/right-tool/</guid>
      <description>&amp;ldquo;Use the right tool for the job&amp;rdquo; is a pretty tired cliche. Mostly it&amp;rsquo;s used to dismiss overengineering and one-size-fits-all solutions to problems, like using microservices for your 10-user app. It isn&amp;rsquo;t a bad saying, it&amp;rsquo;s just tautologically true. I don&amp;rsquo;t think anybody wants to use the wrong tool for the job, unless they&amp;rsquo;re trying to sabotage it. &amp;ldquo;Should I use the right tool for the job?&amp;rdquo; is a rhetorical question.</description>
    </item>
    
  </channel>
</rss>