<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: William T Luce</title>
    <description>The latest articles on DEV Community by William T Luce (@willluce).</description>
    <link>https://dev.to/willluce</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F10553%2F2023994.jpeg</url>
      <title>DEV Community: William T Luce</title>
      <link>https://dev.to/willluce</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/willluce"/>
    <language>en</language>
    <item>
      <title>Metrics that can Drive Change?</title>
      <dc:creator>William T Luce</dc:creator>
      <pubDate>Sat, 14 Apr 2018 17:33:11 +0000</pubDate>
      <link>https://dev.to/willluce/metrics-that-can-drive-change-51i3</link>
      <guid>https://dev.to/willluce/metrics-that-can-drive-change-51i3</guid>
      <description>&lt;p&gt;Here's the deal. I just got my first "senior developer" job in a company that's moving from the "Ahhh! Write all the code and deliver all the things so we can get some marketshare!" phase to the "Ok, now we need a professional codebase" phase. It's AngularJS and the things that need to change are seemingly obvious (add tests, reduce duplication, clean things up, etc), but I keep finding myself asking the same questions. &lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;How can I prove that one version of the application is better than another?&lt;/li&gt;
&lt;li&gt;How can I set up an environment that allows my devs to prove that a change they want to make is worthwhile?&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;I feel that all of these things come down to metrics, but as of now, there are no metrics being gathered that I can use to drive my decisions. I don't believe there's a need to change something on a hunch or because the community says I should be at one version of a framework over another. I'd like to add that I believe &lt;em&gt;better&lt;/em&gt; can me measured from the user's POV or from a developer's POV. A version of an application that's easier to maintain is better that one that isn't, although not directly to the user. Below are a few things that I already know:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Page load time is the most important metric to the user.&lt;/li&gt;
&lt;li&gt;Tests allow change to happen safely. They are absolutely necessary, but the "what to test" conversation is for a different post.&lt;/li&gt;
&lt;/ul&gt;

</description>
      <category>discuss</category>
    </item>
    <item>
      <title>Can we ship mobile apps that are not monolithic?</title>
      <dc:creator>William T Luce</dc:creator>
      <pubDate>Mon, 04 Sep 2017 23:17:21 +0000</pubDate>
      <link>https://dev.to/willluce/can-we-ship-mobile-apps-that-are-not-monolithic</link>
      <guid>https://dev.to/willluce/can-we-ship-mobile-apps-that-are-not-monolithic</guid>
      <description>

&lt;p&gt;It's common in web applications to serve several small applications, combined through domain routing, to a user as a single service. I could have separate application for login, profile management, and chat being served as:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href="http://www.website.com/login"&gt;www.website.com/login&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://www.website.com/profile"&gt;www.website.com/profile&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="http://www.website.com/chat"&gt;www.website.com/chat&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;It's a trivial example, but it serves its purpose. To the user, it's one website, but for developers, it's several small applications. This comes with plenty of advantages that mostly boil down to having a small codebase.&lt;/p&gt;

&lt;p&gt;I'm beginning mobile development (react-native) and wondering if this pattern has found it's way into that environment? My hunch is "no" due to the type of deliverable. A mobile application is delivered as one thing to an app store where a website can be "composed" through URL mapping, but I also know developers are smart and I could be totally wrong. &lt;/p&gt;


</description>
      <category>discuss</category>
      <category>reactnative</category>
      <category>ios</category>
      <category>android</category>
    </item>
    <item>
      <title>What's your process for working through a story?</title>
      <dc:creator>William T Luce</dc:creator>
      <pubDate>Sat, 17 Jun 2017 01:11:36 +0000</pubDate>
      <link>https://dev.to/willluce/whats-your-process-for-working-through-a-story</link>
      <guid>https://dev.to/willluce/whats-your-process-for-working-through-a-story</guid>
      <description>&lt;p&gt;Development is complicated. Not only because of the technologies and patterns that are required knowledge, but also because of the myriad of tasks that are involved in getting work to production.&lt;/p&gt;

&lt;p&gt;As an example, I picked up a story this week that was adding a new field to a form. Simple enough, but it went like this.&lt;/p&gt;

&lt;p&gt;First thing's first. I need to make sure I have the right tools to do my job here. Does the ticket have acceptance criteria? Do I understand what changes need to be made to accomplish what's entailed? &lt;em&gt;These checks are the first set that I'll run through when starting the process of working a story.&lt;/em&gt; &lt;/p&gt;

&lt;p&gt;Once the ticket it good, I make a plan for getting the work done. This is my time to figure out what parts of our codebase I'll need to touch to get the new feature done. &lt;em&gt;I normally write this out in a notebook I use as a mousepad.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;For this story, I needed to update three things.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Database&lt;/li&gt;
&lt;li&gt;API&lt;/li&gt;
&lt;li&gt;Front End&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;It's important to point out that we have four environments in our delivery pipeline and work flows in this order: Local -&amp;gt; dev -&amp;gt; UAT -&amp;gt; Prod. &lt;/p&gt;

&lt;p&gt;I added a new column to the DB to hold the new value. Because all dev work starts locally and then is propagated to other environments as it moves through the delivery pipeline, I wrote a script to add the column.&lt;/p&gt;

&lt;p&gt;This is the first thing I need to keep track of. &lt;em&gt;Tasks like this are one type of work that is involved in the process for working through a story.&lt;/em&gt; If I push the code that uses the new column to another environment without first running the script for the DB in that environment, things will break.&lt;/p&gt;

&lt;p&gt;So, I write that down on a sticky or take note of it in my notebook. &lt;/p&gt;

&lt;p&gt;Secondly, I pull down the first of two repositories (the API) that will require changes to get this story done. &lt;em&gt;Here lies another set of things that have to happen in the right order.&lt;/em&gt; I run tests on the parent branch to make sure things work, then make my own branch, make my changes, run tests, make changes, run tests, fix tests, and make commits along the way.&lt;/p&gt;

&lt;p&gt;Once that repo is good to go (I know because I've tested it running against the DB changes I've made...locally), I move on to the second repo, the front end, and repeat the process.&lt;/p&gt;

&lt;p&gt;At this point, I have three separate pieces of work (DB script, API pull request, front end pull request) that all work together and depend on one another to meet the acceptance criteria of the story I'm working on.  &lt;/p&gt;

&lt;p&gt;&lt;em&gt;This is where I really have to start paying attention to process&lt;/em&gt;. Because I have multiple PRs out, it's inevitable that they are reviewed and accepted at different times. It's possible that one gets the green light one day and one the next. When they do get the ol' "good to go", "ship it", or :thumbs-up:, I'll need to merge them into the next environment in the pipeline. It's important they go in the right order so things don't break and I have to remember to run that damn DB script on every environment along the way.&lt;/p&gt;

&lt;p&gt;If my work gets kicked back by QA, the fix will more than likely only be in one of the two repositories I've worked in. So, at that point, I have to remember to pull back the other work as well so things stay together. &lt;/p&gt;

&lt;p&gt;All the while, because the work for that story is done and I'm just waiting on things to happen, I'm starting the process all over again with another story.&lt;/p&gt;

&lt;p&gt;The hard part about all of this is that this seems like one process, "Working a story", but in truth it's many disparate checklists, tasks lists, and time lines that have to be managed correctly just to get one field into a form. More than once, this concentric circle of checklists has bitten me and some piece of code was in an environment before it should have been.&lt;/p&gt;

&lt;p&gt;I'm wondering how other devs deal with this complexity. What tools or methods do you use to manage it? &lt;/p&gt;

</description>
      <category>discuss</category>
    </item>
    <item>
      <title>Hi, I'm William T Luce</title>
      <dc:creator>William T Luce</dc:creator>
      <pubDate>Sat, 17 Jun 2017 00:52:30 +0000</pubDate>
      <link>https://dev.to/willluce/hi-im-william-t-luce</link>
      <guid>https://dev.to/willluce/hi-im-william-t-luce</guid>
      <description>&lt;p&gt;I have been coding for 4 years.&lt;/p&gt;

&lt;p&gt;You can find me on GitHub as &lt;a href="https://github.com/WillLuce" rel="noopener noreferrer"&gt;WillLuce&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I live in Boulder, Co.&lt;/p&gt;

&lt;p&gt;I work for MakeMusic, TrainingPeaks, TrainHeroic&lt;/p&gt;

&lt;p&gt;I mostly program in these languages: JavaScript, .NET.&lt;/p&gt;

&lt;p&gt;I am currently learning more about data science.&lt;/p&gt;

&lt;p&gt;Nice to meet you.&lt;/p&gt;

</description>
      <category>introduction</category>
    </item>
  </channel>
</rss>
