<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>blog.harterrt.com</title><link>https://blog.harterrt.com/</link><description></description><lastBuildDate>Mon, 04 Aug 2025 07:54:00 -0700</lastBuildDate><item><title>Data storytelling mistakes</title><link>https://blog.harterrt.com/2025-08-04.html</link><description>&lt;p&gt;Almost a decade ago, I started this blog when I decided to get really good at writing documentation. I like testing how far I can push improvements to these under-appreciated soft skills. It's easy to make these skills a superpower. Nobody else seems to know they can be trained.&lt;/p&gt;
&lt;p&gt;Four …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 04 Aug 2025 07:54:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2025-08-04:/2025-08-04.html</guid><category>2025</category></item><item><title>Humidity and ratios</title><link>https://blog.harterrt.com/humidity.html</link><description>&lt;p&gt;My house gets super dry in the winter and I didn't understand why.&lt;/p&gt;
&lt;p&gt;My weather station says it's drier inside than outside,
which didn't make a ton of sense. 
I'm cooking, and sweating, and showering inside.
It should be &lt;em&gt;more&lt;/em&gt; humid.&lt;/p&gt;
&lt;p&gt;I suspected my forced hot air system was to …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Sat, 07 Dec 2024 17:24:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2024-12-07:/humidity.html</guid><category>2024</category></item><item><title>A webring</title><link>https://blog.harterrt.com/data-webring.html</link><description>&lt;p&gt;I added this blog to Randy Au's &lt;a href="https://www.counting-stuff.com/its-2024-lets-have-a-webring/"&gt;webring for data writers&lt;/a&gt;.
Take a &lt;a href="/pages/webring.html"&gt;look here&lt;/a&gt;, or below:&lt;/p&gt;
&lt;hr&gt;
&lt;div id='data-ring-dot-list'&gt;
&lt;link rel="stylesheet" href="https://randyau.github.io/datawebring/onionring.css"&gt;
&lt;script type="text/javascript" src="https://randyau.github.io/datawebring/onionring-variables.js"&gt;&lt;/script&gt;
&lt;script type="text/javascript" src="https://randyau.github.io/datawebring/onionring-widget.js"&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;p&gt;I'm struggling to describe why I think this is so interesting.&lt;/p&gt;
&lt;p&gt;Most of the writing I've seen about doing data work is misleading.
It misrepresents what data work actually looks like.&lt;/p&gt;
&lt;p&gt;Everyone writing …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 14 Oct 2024 15:20:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2024-10-14:/data-webring.html</guid><category>2024</category></item><item><title>SQL style - where do the commas go?</title><link>https://blog.harterrt.com/commas-sql-style.html</link><description>&lt;p&gt;&lt;strong&gt;TL;DR:&lt;/strong&gt; there are good arguments for leading commas,
but I recommend using trailing commas for consistency.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;We didn't take an opinionated stance on comma placement when writing
&lt;a href="https://docs.telemetry.mozilla.org/concepts/sql_style.html"&gt;Mozilla's SQL Style Guide&lt;/a&gt;
probably to avoid a quagmire.
I'm trying to figure out where I stand now, so I wrote it …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 05 Jun 2024 20:45:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2024-06-05:/commas-sql-style.html</guid><category>2024</category></item><item><title>Talk: Practical Strategies for Data Storytelling</title><link>https://blog.harterrt.com/storytelling-odsc-2024.html</link><description>&lt;p&gt;I gave a talk at the Open Data Science Conference a few weeks ago titled: 
&lt;a href="https://odsc.com/speakers/practical-strategies-for-data-storytelling/"&gt;Practical Strategies for Data Storytelling&lt;/a&gt;.
I have more to say on the subject, but in the meantime you can see my 
&lt;a href="/static/odsc2024/index.html#p1"&gt;slides and speaker notes here&lt;/a&gt;.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;For the last two years, I've hosted a biweekly …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 05 Jun 2024 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2024-06-05:/storytelling-odsc-2024.html</guid><category>2024</category></item><item><title>Getting Credit for Invisible Work</title><link>https://blog.harterrt.com/getting-credit-for-invisible-work.html</link><description>&lt;p&gt;As I moved up my company’s career ladder,
my job description became more ambiguous.&lt;/p&gt;
&lt;p&gt;I stepped back to take a look at my work, and I was surprised to find that my
biggest wins hadn’t come from technical feats or shipped code. Instead, I
realized that most of …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 01 Jul 2022 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2022-07-01:/getting-credit-for-invisible-work.html</guid><category>2024</category></item><item><title>Data Intuition Case Study: Grain-free Dog Food</title><link>https://blog.harterrt.com/fda-dog-food.html</link><description>&lt;p&gt;My vet told me I should stop feeding my dog grain-free dog food. Apparently,
grain-free dog food is linked with a heart condition called Dilated
Cardiomyopathy (DCM). This set off my &lt;a href="/data_intuition.html"&gt;data intuition alarms&lt;/a&gt;,
so I decided to dig deeper.&lt;/p&gt;
&lt;p&gt;The FDA has a great document explaining their investigation
&lt;a href="https://www.fda.gov/animal-veterinary/outbreaks-and-advisories/fda-investigation-potential-link-between-certain-diets-and-canine-dilated-cardiomyopathy"&gt;here …&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 18 Feb 2022 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2022-02-18:/fda-dog-food.html</guid><category>mozilla</category></item><item><title>Getting Credit for Invisible Work</title><link>https://blog.harterrt.com/invisible-work.html</link><description>&lt;p&gt;Last month I gave a talk at &lt;a href="https://csvconf.com/speakers/#ryan-harter"&gt;csv,conf&lt;/a&gt;
on "Getting Credit for Invisible Work".
The (amazing) csv,conf organizers just published a 
&lt;a href="https://www.youtube.com/watch?v=W7zT-GRDSCw"&gt;recording of the talk&lt;/a&gt;.
(&lt;a href="https://blog.harterrt.com/static/invisible_work_preso/#p1"&gt;slides here&lt;/a&gt;).
Give it a watch! It's only 20m long (including the Q&amp;amp;A).&lt;/p&gt;
&lt;p&gt;Invisible work is a concept I've been trying to …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 03 Jun 2021 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2021-06-03:/invisible-work.html</guid><category>mozilla</category></item><item><title>Opportunity Sizing: Is the Juice Worth the Squeeze?</title><link>https://blog.harterrt.com/opportunity_sizing.html</link><description>&lt;p&gt;My peers at Mozilla are running workshops on &lt;em&gt;opportunity sizing&lt;/em&gt;.
If you're unfamiliar, 
opportunity sizing is when you take some broad guesses 
at how impactful some new project might be before writing any code.
This gives you a rough estimate of what the upside for this work might be.&lt;/p&gt;
&lt;p&gt;The …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 15 Apr 2021 13:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2021-04-15:/opportunity_sizing.html</guid><category>mozilla</category></item><item><title>Optional Comments</title><link>https://blog.harterrt.com/opt_comments.html</link><description>&lt;p&gt;I spend a lot of my time at Mozilla reviewing my peers' work.
It's a joy, but it's hard to do well.
Review can be a great opportunity for mentorship and growth,
but it's also an opportunity to be overbearing.
Striking the right tone is a struggle.&lt;/p&gt;
&lt;p&gt;Part of the …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 21 Jan 2021 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2021-01-21:/opt_comments.html</guid><category>mozilla</category></item><item><title>Controlled Experiments - Why Bother?</title><link>https://blog.harterrt.com/why_experiment.html</link><description>&lt;!-- tweets: I guess Ben Franklin was the first person to lick a 9volt battery in spirit --&gt;
&lt;!-- tweets: I wrote down some notes about why we spend so much energy running controlled experiments at Mozilla --&gt;
&lt;!-- tweets: In this post I compare A/B tests to hold-my-beer-type experiments like flying a kite in a thunderstorm --&gt;

&lt;p&gt;I spent some time earlier this year orchestrating 
a massive experiment for Firefox.
We launched a bunch of new features with Firefox 80
and we wanted to understand whether these new features improved our metrics.&lt;/p&gt;
&lt;p&gt;In the process, I ended up talking with a bunch of Firefox engineers
and explaining …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 05 Jan 2021 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2021-01-05:/why_experiment.html</guid><category>mozilla</category><category>data-intuition</category></item><item><title>Leading with Data - Cascading Metrics</title><link>https://blog.harterrt.com/cascading_metrics.html</link><description>&lt;p&gt;It's surprisingly hard to lead a company with data.
There's a lot written about how to set good goals
and how to avoid common pitfalls (like &lt;a href="/surrogation.html"&gt;Surrogation&lt;/a&gt;)
but I haven't seen much written about the practicalities
of taking action on these metrics.&lt;/p&gt;
&lt;p&gt;I spent most of this year working with …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 09 Dec 2020 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-12-09:/cascading_metrics.html</guid><category>mozilla</category></item><item><title>Defining Data Intuition</title><link>https://blog.harterrt.com/data_intuition.html</link><description>&lt;p&gt;Last week, one of my peers asked me to explain what I meant by "Data Intuition",
and I realized I really didn't have a good definition.
That's a problem! I refer to data intuition all the time!&lt;/p&gt;
&lt;p&gt;Data intuition is one of the three skills I interview new data scientists …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 20 Oct 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-10-20:/data_intuition.html</guid><category>mozilla</category><category>data-intuition</category></item><item><title>Follow up: Intentional Documentation</title><link>https://blog.harterrt.com/int_d11n_preso.html</link><description>&lt;p&gt;Last week I presented the idea of 
&lt;a href="https://blog.harterrt.com/randy_au_d11n.html"&gt;Intentional Documentation&lt;/a&gt;
to Mozilla's data science team.
Here's a &lt;a href="/static/int_d11n/"&gt;link to the slides&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The rest of this post is a transcription of what I shared with the team
(give or take).&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;In Q4, I'm trying to build a set of trainings
to help …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 12 Oct 2020 18:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-10-12:/int_d11n_preso.html</guid><category>mozilla</category></item><item><title>Surrogation</title><link>https://blog.harterrt.com/surrogation.html</link><description>&lt;p&gt;A year or so ago, I read
&lt;a href="https://hbr.org/2019/09/dont-let-metrics-undermine-your-business"&gt;this article&lt;/a&gt;
about how Wells Fargo ended up in such a mess.
If you don't remember,
Wells Fargo was opening accounts in their clients' name without their consent
and ended up paying a few hundred million dollars in fines.&lt;/p&gt;
&lt;p&gt;Long story short, a …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 07 Oct 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-10-07:/surrogation.html</guid><category>mozilla</category></item><item><title>Intentional Documentation</title><link>https://blog.harterrt.com/randy_au_d11n.html</link><description>&lt;p&gt;Randy Au has a great post on documentation for data scientists here:
&lt;a href="https://counting.substack.com/p/lets-get-intentional-about-documentation"&gt;Let's get intentional about documentation&lt;/a&gt;.
Take a look, it's worth a read.&lt;/p&gt;
&lt;p&gt;I've been able to find some decent guides for writing documentation
but they're usually targeted at engineers.
That's a shame. 
Data scientists have significantly different 
constraints …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 29 Sep 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-09-29:/randy_au_d11n.html</guid><category>mozilla</category><category>documentation</category></item><item><title>What do you take home?</title><link>https://blog.harterrt.com/notebook/2020-07-10.html</link><description>&lt;p&gt;Every other week,
I go through my todo list and decide where I should focus my attention.
I review a list of prompts that help me choose important work.
One of the oldest prompts on my list is:
"&lt;strong&gt;What will you take home at the end of the week?&lt;/strong&gt;".&lt;/p&gt;
&lt;p&gt;I …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 10 Jul 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-07-10:/notebook/2020-07-10.html</guid><category>notebook</category></item><item><title>Keeping a Journal</title><link>https://blog.harterrt.com/notebook/2020-07-08.html</link><description>&lt;p&gt;There was a discussion of
&lt;a href="https://hbr.org/2017/07/the-more-senior-your-job-title-the-more-you-need-to-keep-a-journal"&gt;this HBR article&lt;/a&gt;
("The More Senior Your Job Title, the More You Need to Keep a Journal")
&lt;a href="https://news.ycombinator.com/item?id=23768624"&gt;on HN&lt;/a&gt; today.&lt;/p&gt;
&lt;p&gt;This is great advice.
I've kept a journal for almost a decade now
and it's definitely improved my career
especially as I've become more senior …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 08 Jul 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-07-08:/notebook/2020-07-08.html</guid><category>notebook</category></item><item><title>Post hoc ergo propter hoc</title><link>https://blog.harterrt.com/notebook/2020-06-17.md.html</link><description>&lt;!---
status: draft
---&gt;

&lt;p&gt;Economists have a handy phrase to describe a fairly common fallacy:
"Post hoc ergo propter hoc" meaning "After, therefore because".&lt;/p&gt;
&lt;p&gt;Wikipedia has an example of how this might look in the wild:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;A tenant moves into an apartment
and the building's furnace develops a fault.
The manager blames the tenant's …&lt;/p&gt;&lt;/blockquote&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 17 Jun 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-06-17:/notebook/2020-06-17.md.html</guid><category>notebook</category></item><item><title>Daily Writing and the "Notebook" Category</title><link>https://blog.harterrt.com/notebook/2020-06-16.html</link><description>&lt;p&gt;This past weekend I found 
&lt;a href="https://notebook.drmaciver.com/posts/2020-06-08-10:11.html"&gt;drmaciver's post&lt;/a&gt;
on starting a daily writing practice.
I like the idea and I'm going to give it a try.&lt;/p&gt;
&lt;p&gt;The content on this blog has never been all that polished,
but I do expect these daily posts will be less consistent 
in quality and …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 16 Jun 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-06-16:/notebook/2020-06-16.html</guid><category>notebook</category></item><item><title>Writing inside organizations</title><link>https://blog.harterrt.com/writing_inside_organizations.html</link><description>&lt;p&gt;Tom Critchlow has a 
&lt;a href="https://tomcritchlow.com/2020/05/27/filtered-for-org-writing/"&gt;great post here&lt;/a&gt;
outlining some points on how important writing is for an organization.&lt;/p&gt;
&lt;p&gt;I'm still working through the links,
but his post already sparked some ideas.
In particular,
I'm very interested in the idea of an internal blog for sharing context.&lt;/p&gt;
&lt;h2 id="snippets"&gt;Snippets&lt;/h2&gt;
&lt;p&gt;My team keeps …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 28 May 2020 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-05-28:/writing_inside_organizations.html</guid><category>mozilla</category></item><item><title>Syncthing and Open Source Data Collection</title><link>https://blog.harterrt.com/syncthing_data.html</link><description>&lt;p&gt;I don't see many open source packages collecting telemetry,
so when &lt;a href="https://syncthing.net/"&gt;Syncthing&lt;/a&gt; asked me to opt-in to telemetry
I was intrigued.&lt;/p&gt;
&lt;p&gt;I see a lot of similarities between how Syncthing and Firefox collects data.
Both collect daily pings and make it easy to view the data you're submitting
(in Firefox …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Sun, 05 Jan 2020 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-01-05:/syncthing_data.html</guid><category>mozilla</category></item><item><title>Syncthing</title><link>https://blog.harterrt.com/try_syncthing.html</link><description>&lt;p&gt;I did a lot of reading and exploring over my holiday break.
One of the things I'm most excited about is finding 
&lt;a href="https://syncthing.net/"&gt;Syncthing&lt;/a&gt;.
If you haven't seen it yet, take a look.
It's like and open-source decentralized Dropbox.&lt;/p&gt;
&lt;p&gt;It works everywhere, which for me means Linux and Android.
Google Drive …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Sun, 05 Jan 2020 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2020-01-05:/try_syncthing.html</guid><category>mozilla</category></item><item><title>Pub True</title><link>https://blog.harterrt.com/pub-true.html</link><description>&lt;p&gt;I'm ramping up on a project to understand how Firefox retains users.
Right now I'm trying to build some context quickly.
For example, what's our monthly retention? How about our annual retention?
There's a bunch of interesting and nuanced measurement questions
that we'll eventually have to answer,
but for now …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 13 Dec 2019 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2019-12-13:/pub-true.html</guid><category>mozilla</category></item><item><title>Analysis Maturation Plan</title><link>https://blog.harterrt.com/analysis_maturation.html</link><description>&lt;p&gt;I was talking about tooling with Mark Reid a few weeks ago.
I've been trying to find a way to simplify sharing analyses throughout the company.
This is an old problem at Mozilla that I've tried to address a couple of times
but I haven't found the silver bullet yet …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 12 Dec 2019 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2019-12-12:/analysis_maturation.html</guid><category>mozilla</category></item><item><title>Technical Leadership Paths</title><link>https://blog.harterrt.com/keavy-tech-leadership-path.html</link><description>&lt;p&gt;I found
&lt;a href="https://keavy.com/work/thriving-on-the-technical-leadership-path/"&gt;this article&lt;/a&gt;
a few weeks ago and I really enjoyed the read.
The author outlines what a role can look like for very senior ICs.
It's the first in a (yet to be written) series about technical leadership
and long term IC career paths.
I'm excited to read …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 08 Nov 2019 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2019-11-08:/keavy-tech-leadership-path.html</guid><category>mozilla</category></item><item><title>When the Bootstrap Breaks - ODSC 2019</title><link>https://blog.harterrt.com/odsc-2019.html</link><description>&lt;p&gt;I'm excited to announce that I'll be presenting at the
&lt;a href="https://odsc.com/boston"&gt;Open Data Science Conference&lt;/a&gt;
in Boston next week.
My colleague &lt;a href="https://www.linkedin.com/in/saptarshiguha/"&gt;Saptarshi&lt;/a&gt;
and I will be talking about
&lt;a href="https://odsc.com/training/portfolio/when-the-bootstrap-breaks"&gt;When the Bootstrap Breaks&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I've included the abstract below,
but the high-level goal of this talk is to strip some varnish off the …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 24 Apr 2019 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2019-04-24:/odsc-2019.html</guid><category>mozilla</category></item><item><title>Slow to respond through 2018</title><link>https://blog.harterrt.com/2018_slow_to_respond.html</link><description>&lt;p&gt;I'm working on an urgent and high priority request for the next few weeks.
To make sure I can finish this work in 2018
I'm &lt;strong&gt;limiting my meetings and communications&lt;/strong&gt; for the remainder of the year.&lt;/p&gt;
&lt;p&gt;Slack is good for getting my immediate attention,
but if your request takes more …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 10 Dec 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-12-10:/2018_slow_to_respond.html</guid><category>mozilla</category></item><item><title>If you can't do it in a day, you can't do it</title><link>https://blog.harterrt.com/day_barrier.html</link><description>&lt;p&gt;I was talking with Mark Reid
about some of the problems with &lt;a href="coding_in_textboxes.html"&gt;Coding in a GUI&lt;/a&gt;.
He nailed part of the problem with soundbite too good not to share:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;"If you can't do it in a day, you can't do it."&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;This is a persistent problem with tools that make …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 27 Jun 2018 14:21:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-06-27:/day_barrier.html</guid><category>mozilla</category><category>tools</category></item><item><title>Planning Data Science is hard: EDA</title><link>https://blog.harterrt.com/planning_eda.html</link><description>&lt;p&gt;Data science is weird.
It looks a lot like software engineering
but in practice the two are very different.
I've been trying to pin down where these differences come from.&lt;/p&gt;
&lt;p&gt;Michael Kaminsky hit on a couple of key points
in his series on Agile Management for Data Science
on &lt;a href="https://www.locallyoptimistic.com/"&gt;Locally …&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 26 Jun 2018 17:19:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-06-26:/planning_eda.html</guid><category>mozilla</category></item><item><title>You can't do data science in a GUI</title><link>https://blog.harterrt.com/ds_gui.html</link><description>&lt;p&gt;I came across 
&lt;a href="https://www.youtube.com/watch?v=cpbtcsGE0OA"&gt;You can't do data science in a GUI&lt;/a&gt;
by Hadley Wickham a little while ago.
He hits on a lot of the same problems I mentioned in
&lt;a href="https://blog.harterrt.com/coding_in_textboxes.html"&gt;Don't make me code in your text box&lt;/a&gt;.
Take a look if you have some time.
In the first 15m …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 26 Jun 2018 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-06-26:/ds_gui.html</guid><category>mozilla</category><category>gui</category><category>tools</category></item><item><title>Why bootstrap?</title><link>https://blog.harterrt.com/why_bootstrap.html</link><description>&lt;p&gt;Over the next few quarters,
I'm going to focus my attention on Mozilla's experimentation platform.
One of the first questions we need to answer is
how we're going to calculate and report the necessary measures of variance.
Any experimentation platform needs to be able to
 compare metrics between two groups …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 25 May 2018 12:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-05-25:/why_bootstrap.html</guid><category>mozilla</category></item><item><title>SQL Style Guide</title><link>https://blog.harterrt.com/sql_style_guide.html</link><description>&lt;p&gt;I'm happy to announce, we now have a 
&lt;a href="https://docs.telemetry.mozilla.org/concepts/sql_style.html"&gt;SQL style guide&lt;/a&gt;.
Check it out!&lt;/p&gt;
&lt;p&gt;If you have any suggestions,
feel free to file a PR or issue in
&lt;a href="https://github.com/mozilla/firefox-data-docs/blob/master/concepts/sql_style.md"&gt;the docs repository&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Many thanks to all who participated in the 
&lt;a href="https://github.com/mozilla/stmocli/issues/9"&gt;St. Mocli conversation&lt;/a&gt;
and @mreid for the review!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 17 May 2018 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-05-17:/sql_style_guide.html</guid><category>mozilla</category></item><item><title>PSA: Don't use approximate counts for trends</title><link>https://blog.harterrt.com/hll_trends.html</link><description>&lt;p&gt;I got caught giving some bad advice this week,
so I decided to share here as penance.
TL;DR: Probabilistic counts are great,
but they shouldn't be used everywhere.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;Counting stuff is hard.
We use probabilistic algorithms pretty frequently at Mozilla.
For example, when trying to get user counts,
we …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 24 Apr 2018 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-04-24:/hll_trends.html</guid><category>mozilla</category></item><item><title>Don't make me code in your text box!</title><link>https://blog.harterrt.com/coding_in_textboxes.html</link><description>&lt;p&gt;Whenever I start a new data project,
my first step is rooting out any false assumptions I have about the data.&lt;/p&gt;
&lt;p&gt;The key here is iterating quickly.
My workflow looks like this:
Code a little, plot the data, what do you see?
Ah, outliers.
Code a little, plot the data …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 28 Mar 2018 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-03-28:/coding_in_textboxes.html</guid><category>mozilla</category><category>tools</category><category>gui</category></item><item><title>The 5 Stages of Experiment Analysis</title><link>https://blog.harterrt.com/stages_e13n.html</link><description>&lt;p&gt;I've been thinking about experimentation a lot recently.
Our team is spending a lot of effort trying to make Firefox experimentation feel easy.
But what happens after the experiment's been run?
There's &lt;strong&gt;not a clear process for taking experimental data and turning it into a decision&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;I noted the importance …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 28 Feb 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-02-28:/stages_e13n.html</guid><category>mozilla</category><category>experimentation</category></item><item><title>Asking Questions</title><link>https://blog.harterrt.com/preferred_media.html</link><description>&lt;p&gt;Will posted a great article a couple weeks ago,
&lt;a href="https://wlach.github.io/blog/2018/01/giving-and-receiving-help-at-mozilla/"&gt;Giving and Receiving Help at Mozilla&lt;/a&gt;.
I have been meaning to write a similar article for a while now.
His post finally pushed me over the edge. &lt;/p&gt;
&lt;p&gt;Be sure to read Will's post first.
The rest of this article is an …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 09 Feb 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-02-09:/preferred_media.html</guid><category>mozilla</category></item><item><title>Managing Someday-Maybe Projects with a CLI</title><link>https://blog.harterrt.com/sdmb.html</link><description>&lt;p&gt;I have a problem managing projects I'm interested in but don't have time for.
For example, the &lt;a href="/slack_alerts.html"&gt;CLI for generating slack alerts&lt;/a&gt; I posted about last year.
Not really a priority, but helpful and not that complicated.
I sat on that project for about a year before I could finally …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 03 Jan 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-01-03:/sdmb.html</guid><category>mozilla</category></item><item><title>Removing Disqus</title><link>https://blog.harterrt.com/disqus.html</link><description>&lt;p&gt;I'm removing Disqus from this blog.
Disqus allowed readers to post comments on articles.
I added it because it was easy to do,
but I no longer think it's worth keeping.&lt;/p&gt;
&lt;p&gt;If you'd like to share your thoughts,
feel free to shoot me an email at &lt;code&gt;harterrt&lt;/code&gt; on gmail.
I …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 02 Jan 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-01-02:/disqus.html</guid><category>mozilla</category></item><item><title>Productivity Systems for Stress Management</title><link>https://blog.harterrt.com/productivity_systems.html</link><description>&lt;p&gt;Over the years, I've developed a pretty involved productivity system.
It was originally based on &lt;a href="https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/"&gt;Getting Things Done&lt;/a&gt;,
but now it's grown to include the good bits from other systems.
It's involved, but I love it.&lt;/p&gt;
&lt;p&gt;I get a lot of comments,
especially on the little black book I keep …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Tue, 02 Jan 2018 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2018-01-02:/productivity_systems.html</guid><category>not-mozilla</category></item><item><title>CLI for alerts via Slack</title><link>https://blog.harterrt.com/slack_alerts.html</link><description>&lt;p&gt;I finally got a chance to scratch an itch today.&lt;/p&gt;
&lt;h2 id="problem"&gt;Problem&lt;/h2&gt;
&lt;p&gt;When working with bigger ETL jobs,
I frequently run into jobs that take hours to run.
I usually either step away from the computer
or work on something less important while the job runs.
I &lt;strong&gt;don't have a good …&lt;/strong&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Fri, 08 Dec 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-12-08:/slack_alerts.html</guid><category>mozilla</category><category>tools</category></item><item><title>Experiments are releases</title><link>https://blog.harterrt.com/experiments_are_releases.html</link><description>&lt;p&gt;&lt;a href="https://github.com/mozilla/missioncontrol"&gt;Mission Control&lt;/a&gt;
was a major 2017 initiative for the Firefox Data team.
The goal is to provide release managers with near-real-time
release-health metrics minutes after going public.
Will has a
&lt;a href="https://wlach.github.io/blog/2017/10/mission-control/"&gt;great write up here&lt;/a&gt;
if you want to read more.&lt;/p&gt;
&lt;p&gt;The key here is that the data has to be …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 07 Dec 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-12-07:/experiments_are_releases.html</guid><category>mozilla</category><category>experimentation</category></item><item><title>Desirable features of experimentation tools</title><link>https://blog.harterrt.com/good_experiment_tools.html</link><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;At Mozilla,
we're quickly climbing up our
&lt;a href="https://cdn-images-1.medium.com/max/1600/1*7IMev5xslc9FLxr9hHhpFw.png"&gt;Data Science Hierarchy of Needs&lt;/a&gt;
&lt;sup&gt;1&lt;/sup&gt;.
I think the next big step for our data team
is to &lt;strong&gt;make experimentation feel natural&lt;/strong&gt;.
There are a few components to this (e.g. training or culture)
but improving the &lt;strong&gt;tooling is going to be …&lt;/strong&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 06 Dec 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-12-06:/good_experiment_tools.html</guid><category>mozilla</category><category>experimentation</category></item><item><title>Submission Date vs Activity Date</title><link>https://blog.harterrt.com/dates.html</link><description>&lt;p&gt;My comments on
&lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1422892"&gt;Bug 1422892&lt;/a&gt;
started to get long,
so I started untangling my thoughts here.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;From
&lt;a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1422892"&gt;the bug&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;We experimented with using &lt;code&gt;activity_date&lt;/code&gt; instead of &lt;code&gt;submission_date&lt;/code&gt;
when developing the &lt;code&gt;clients_daily&lt;/code&gt; etl job.
We should summarize our findings and decide on 
which of these measures we'd like to standardize against …&lt;/p&gt;&lt;/blockquote&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 04 Dec 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-12-04:/dates.html</guid><category>mozilla</category></item><item><title>OKRs and 4DX</title><link>https://blog.harterrt.com/okrs_and_4dx.html</link><description>&lt;p&gt;I feel like I'm swimming in acronyms these days.&lt;/p&gt;
&lt;p&gt;Earlier this year,
my team started using Objectives and Key Results (OKRs) for our planning.
It's been a learning process.
I had some prior experience with OKRs at Google,
but I've never felt like I was fully taking advantage of the …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 30 Nov 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-11-30:/okrs_and_4dx.html</guid><category>mozilla</category></item><item><title>Evaluating New Tools</title><link>https://blog.harterrt.com/new_tools.html</link><description>&lt;p&gt;At Mozilla, we're still relatively early in our data science journey.
As such, we're always evaluating new tools to improve our analysis workflow
(&lt;a href="http://jupyter.org/"&gt;jupyter&lt;/a&gt; vs. &lt;a href="http://rmarkdown.rstudio.com/"&gt;Rmd&lt;/a&gt;),
or make our infrastructure more usable
(our home-rolled &lt;a href="https://github.com/mozilla/telemetry-analysis-service"&gt;ATMO&lt;/a&gt;
vs. &lt;a href="https://databricks.com/"&gt;databricks&lt;/a&gt;),
or scale our knowledge
(&lt;a href="https://medium.com/airbnb-engineering/scaling-knowledge-at-airbnb-875d73eff091"&gt;knoledge-repo&lt;/a&gt;.
vs. &lt;a href="https://www.gitbook.com/"&gt;gitbook&lt;/a&gt;)&lt;/p&gt;
&lt;p&gt;Most of these tools look like …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 26 Oct 2017 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-10-26:/new_tools.html</guid><category>mozilla</category><category>tools</category><category>mozilla</category></item><item><title>Documentation Style Guide</title><link>https://blog.harterrt.com/docs-style-guide.html</link><description>&lt;p&gt;I just wrote up a style guide for our 
&lt;a href="https://docs.telemetry.mozilla.org"&gt;team's documentation&lt;/a&gt;.
The documentation is rendered using Gitbook and hosted on Github Pages.
You can find the 
&lt;a href="https://github.com/mozilla/firefox-data-docs/pull/41"&gt;PR here&lt;/a&gt;
but I figured it's worth sharing here as well.&lt;/p&gt;
&lt;h2 id="style-guide"&gt;Style Guide&lt;/h2&gt;
&lt;p&gt;Articles should be written in
&lt;a href="https://daringfireball.net/projects/markdown/syntax"&gt;Markdown&lt;/a&gt;
(not &lt;a href="http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/"&gt;AsciiDoc&lt;/a&gt;).
Markdown is usually …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 24 Aug 2017 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-08-24:/docs-style-guide.html</guid><category>mozilla</category><category>mozilla</category><category>documentation</category></item><item><title>Beer and Probes</title><link>https://blog.harterrt.com/probes.html</link><description>&lt;p&gt;Quick post to clear up some terminology.
But first, an analogy to clear up my thinking:&lt;/p&gt;
&lt;h2 id="analogy"&gt;Analogy&lt;/h2&gt;
&lt;p&gt;Temperature control is a big part of brewing beer.
Throughout the brewing process I use a thermometer
to measure the temperature of the soon-to-be beer.
Because I take several temperature readings throughout the …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 23 Aug 2017 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-08-23:/probes.html</guid><category>mozilla</category></item><item><title>Bad Tools are Insidious</title><link>https://blog.harterrt.com/bad-tools.html</link><description>&lt;p&gt;This is my first job making data tools that other people use.
In the past, I've always been a data scientist -
a consumer of these tools.
I'm learning a lot.&lt;/p&gt;
&lt;p&gt;Last quarter, I learned that bad tools are often hard to spot even when they're damaging productivity.
I sum this …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 15 Jun 2017 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-06-15:/bad-tools.html</guid><category>mozilla</category><category>tools</category></item><item><title>Literature Review: Writing Great Documentation</title><link>https://blog.harterrt.com/lit-review.html</link><description>&lt;p&gt;I'm working on a big overhaul of my team's documentation.
I've noticed writing documentation is a difficult thing to get right.
I haven't seen any great example for a data product, either.
I don't have much experience in this area,
so I decided to review what's already been written about …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan Harter</dc:creator><pubDate>Fri, 03 Feb 2017 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2017-02-03:/lit-review.html</guid><category>mozilla</category><category>mozilla</category><category>documentation</category></item><item><title>Is moving to the Bay Area worth it?</title><link>https://blog.harterrt.com/is-moving-to-the-bay-area-worth-it.html</link><description>&lt;p&gt;I came across &lt;a href="http://blog.triplebyte.com/does-it-make-sense-for-programmers-to-move-to-the-bay-area"&gt;this article&lt;/a&gt; on the front page of Hacker News yesterday.
The author argues that Bay Area housing prices may be high, but the salary increase probably makes it worth while.
The author pulls together some interesting data to make their point,
but I have major &lt;strong&gt;issues with …&lt;/strong&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Wed, 14 Dec 2016 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2016-12-14:/is-moving-to-the-bay-area-worth-it.html</guid><category>random</category><category>critique</category></item><item><title>Announcing the Cross Sectional Dataset</title><link>https://blog.harterrt.com/announcing-the-cross-sectional-dataset.html</link><description>&lt;p&gt;I'm happy to announce a new telemetry dataset!&lt;/p&gt;
&lt;p&gt;The Cross Sectional dataset makes it easy to describe our users by providing
summary statistics for each client.  Like the Longitudinal table, there's one
row for each client_id in a 1% sample of clients.  However, the Cross Sectional
dataset simplifies your analysis …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 14 Nov 2016 00:00:00 -0800</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2016-11-14:/announcing-the-cross-sectional-dataset.html</guid><category>mozilla</category></item><item><title>Meta Documentation</title><link>https://blog.harterrt.com/meta-documentation.html</link><description>&lt;p&gt;You'll see a lot of posts coming down the line on documentation.&lt;/p&gt;
&lt;p&gt;We surveyed our customers last quarter and asked where our data pipeline was lacking.
It turns out the most painful part of using our data pipeline, is reading the documentation.
I've been interesting in learning how to write …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 03 Nov 2016 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2016-11-03:/meta-documentation.html</guid><category>documentation</category><category>documentation mozilla</category></item><item><title>Why Markdown?</title><link>https://blog.harterrt.com/why-markdown.html</link><description>&lt;div class="toc"&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="#better-process"&gt;Better Process&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#better-tools"&gt;Better Tools&lt;/a&gt;&lt;ul&gt;
&lt;li&gt;&lt;a href="#one-less-tool"&gt;One less tool&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a href="#the-documentation-sits-next-to-the-code"&gt;The documentation sits next to the code&lt;/a&gt;&lt;ul&gt;
&lt;li&gt;&lt;a href="#syncronization"&gt;Syncronization&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#discoverability"&gt;Discoverability&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;p&gt;Last week I finished a &lt;a href="https://github.com/mozilla/telemetry-batch-view/pull/128"&gt;pull
request&lt;/a&gt; that moved
some documentation from &lt;a href="https://wiki.mozilla.org/Telemetry/LongitudinalExamples"&gt;mozilla's
wiki&lt;/a&gt; to a &lt;a href="https://github.com/mozilla/telemetry-batch-view/blob/master/docs/longitudinal_examples.md"&gt;github
repository&lt;/a&gt;.
It took a couple of hours of editing and toying with pandoc to get right, but …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Thu, 03 Nov 2016 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2016-11-03:/why-markdown.html</guid><category>documentation</category><category>documentation</category><category>mozilla</category></item><item><title>Working over SSH</title><link>https://blog.harterrt.com/working-over-ssh.html</link><description>&lt;div class="toc"&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="#introduction"&gt;Introduction&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#tools"&gt;Tools&lt;/a&gt;&lt;ul&gt;
&lt;li&gt;&lt;a href="#tmux"&gt;tmux&lt;/a&gt;&lt;ul&gt;
&lt;li&gt;&lt;a href="#session-persistence"&gt;Session Persistence&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#multiplexing"&gt;Multiplexing&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a href="#homeshick"&gt;Homeshick&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Working over SSH can be impossibly frustrating if you're not using the right tools. 
I promised my teammates a write-up how I work over ssh.
Using these tools will make it significantly easier / more fun to work with a remote linux system …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ryan T. Harter</dc:creator><pubDate>Mon, 05 Sep 2016 00:00:00 -0700</pubDate><guid isPermaLink="false">tag:blog.harterrt.com,2016-09-05:/working-over-ssh.html</guid><category>mozilla</category><category>tools</category></item></channel></rss>