Starting off with YNAB when paying credit cards in full

I have a couple friends who are YNAB-obsessed. I tried it like five years ago, and couldn’t get over the initial adoption hump — the UI was too clunky, I wasn’t willing to invest the amount of time it would have required to educate myself on the software to the point where it was useful, etc.

So I tried it again; I’m obsessed. The user experience is vastly improved, the documentation and learning resources are super robust — in short, most of what prevented me from getting into it years ago has definitely been addressed.

One thing I found lacking was a guide/resources for people who pay off credit cards in full every month. I feel like I’m over the hurdle, and want to A) write that for anyone else who finds it useful and B) be able to refer to it myself later.

I treat my credit cards like debit cards; I only spend what I have, and pay my balance in full. I put a lot of my expenses on my credit card for the miles, and because I’m afraid of how risky using a debit card is. I maintained a spreadsheet with my main monthly recurring expenses, but didn’t really “budget” super hard beyond that, mainly because I didn’t think I had to — I lived well within my means, I saved, I called it a day.

I called it a day because I felt my money was doing pretty much what I wanted it to do, and I thought looking closer at it would be stressful. It’s been exactly the opposite. Rule #1 of the YNAB method is “Give Every Dollar a Job.” I thought I had been avoiding stress, but embracing the control to give every dollar a job has given me a significantly fuller sense of financial peace I didn’t even know I needed.

So here’s my guide to getting started with YNAB as a heavy credit card user who fully pays off balances.

Day 1 with YNAB

1. Tell YNAB about your funds and debt.

When you start, there are only two things you need to tell YNAB: funds available (+) and standing debt (-). At first, it was very hard for me to think of my credit card balance as debt because in my mind the dollars I was spending were in my checking. But, of course, it is actually debt.

When adding accounts, you have the option to go “linked” or “unlinked”. “Linked” connects with your banking institution and automatically imports cleared transactions. “Unlinked” is fully manual. In my internet travels, I’ve heard the pros and cons of both.

Linked. Pros: Ease of automation. Cons: Bank connections can be unreliable. (Mine syncs once a day so far, which is fine for me). Can make you complacent. Security concerns.

Unlinked. Pros: You have full control. Some feel they have a greater awareness when having to manually enter all transactions. You can still download and manually import things if you want. No bank connection minimizes security concerns. Cons: You have full control. It’s totally up to you to make sure everything is up to date and accurate.

I have opted for “linked”, but I understand the pros of “unlinked”. I’m trying to go for a hybrid, where I take a few minutes in the morning to check in and do “YNAB gardening”, making sure everything is reconciled and categorized appropriately. Also if you manually enter a transaction, you can match it with the later-directly-imported transaction. (YNAB does what it can to match them up, but it’s not perfect, so this does take a mindful eye). So, in my opinion this method still requires awareness to maintain, but if you wanted to set it and forget it you could (although if you wanted to do that, I’d just use Mint).

Let’s say we added a checking account with $2000, a savings account with $5000, and a credit card with a balance of $600.

2. Budget your dollars.

It might sound weird, but this took some crazy getting used to for me. I’m accustomed to thinking about the money in my checking account as “available money”, and the money in my savings account as “unavailable money”. But after telling YNAB about my available funds, I had to face a question: Do I budget my savings money?

It made me think a lot more about savings in an active sense, rather than a passive sense. (“Aside from adding to it, just leave it alone and try not to look at it.”) What am I saving for? It’s not truly just a lump sum of savings, in intent. It’s a rainy day fund, it’s a checking buffer, it’s Christmas gifts, it’s saving for a car downpayment. It’s all of those things and more.

YNAB comes with pre-templated categories to get you started. What works for everyone is different; The first thing I did was create categories that made sense to me:

  • General spending (groceries, coffee shops, etc)
  • Fixed bills (rent, internet, auto insurance, etc)
  • Variable bills (electric, cell phone, etc)
  • Subscriptions (spotify, local NPR station, etc)
  • Fun fund (dining out, bars, entertainment, etc)
  • Savings (rainy day fund, car down payment, checking buffer, etc)

So now I have a categorized list of the things I spend money on, and a lump sum of available money (based on the funds available (+) I’ve told YNAB about).

Say I like to keep a buffer of $500 in my checking, and YNAB is showing I have $7000 “to be budgeted” (which represents all the funds I’ve told YNAB about). Possibly the first thing I do (just as an example) is budget $500 to my buffer category. Now I have $6,500 “to be budgeted” dollars remaining to distribute to my categories.

Now let’s talk about credit cards. The balance on the credit card I told YNAB about was $600. Once, and only once, I need to budget $650 of my available dollars to pay off the credit card. (Note again, I’m talking about paying off the full balance. If you’re trying to get out of credit card debt, YNAB has tons of support material about that).

Now I have $600 set aside for my existing credit card debt, and $500 set aside as my checking buffer, leaving me with $5,900 left to be budgeted.

Now I’d continue down my budget categories, giving each of my dollars a job, according to my priorities for the month, stopping when “to be budgeted” sits at $0.

3. Budgeting for credit cards without budgeting for credit cards.

I said above, once and only once do I need to budget directly to paying off my credit card when getting started with YNAB. Why is that?

When you give each of your dollars a job, the money goes toward that job — not the credit card. YNAB deals with this in a really nifty way.

Say my monthly internet bill is $50, and I’ve budgeted $50 toward it — I have $50 available for the job of paying my internet bill:

I pay my internet service provider with my credit card, and associate the transaction with my “Internet” category:

Heading back over to my budget, something interesting has happened:

Because the transaction was 1) a credit card transaction and 2) associated with the “Internet” category, YNAB has moved the $50 available dollars from having the job of paying my internet bill to having the job of paying my credit card company the $50 more dollars I now owe it for paying my internet bill for me.

Note: When you are fully paying off the balance, the balance of your card should always equal the amount “available” for payment. If it isn’t, it’s a good indicator something has gone awry.

Now let’s pay off the credit card:

In this transaction shown above, I’ve paid the balance of my credit card ($650) from my Checking account.

Looking back at my budget, the $600 that I gave the job of paying off my initial balance have done that, and the $50 that I gave the job of paying my internet bill have now repaid my credit card company for paying my bill.

Gotchas and takeaways

Only budget the dollars you have.

One mistake I made when starting YNAB was pre-budgeting. It was toward the end of the month. I gave each of my dollars a job for the month, getting my “to be budgeted” amount down to $0. (I’ll admit this somehow feels wrong at first, but now it feels very zen).

Then, perhaps being a touch overeager, I started “budgeting” the next month for the amounts I expected to pay for fixed bills. (Bear in mind, I had assigned all my dollars jobs for the current month, and had my amount down to $0).

Instead, set a funding goal. For the internet example, I’d set a funding goal of $50 a month. As more dollars come in to be budgeted, you can fund your budget in order of priority.

Reconcile often.

Basically the YNAB version of personal hygiene. To trust your budget as a foundation to make spending decisions on, it needs to be in total agreement with your bank records. The longer you go unreconciled, the greater the opportunity for inconsistency and mistakes to creep in, and the uglier it will be (probably) to try to untangle it later.

When you reconcile, transactions are “locked” — you know they are trustworthy. If something goes wrong, the number of transactions is more limited; If the pool is smaller, the mistake is easier to track down.

Use the web version for heavy lifting.

I can’t speak for the iOS app, but on the Android app, the ability to undo/redo and manage categories is so limited compared to the web app. I only use the Android app for a few things:

  • Reviewing my budget.
  • Getting notifications that new transactions have been imported and require approval/categorization.
  • Adding transactions on the go.

Do the workshops.

I consider myself pretty financially literate. I thought it was a bit silly to take some of the basic workshops. 100% do it. I had several ‘aha!’ moments that contributed to me finally getting over the hump I couldn’t get over five years ago. They are also live, and free. You have instant support for answering a question that has been plaguing you.

The YNAB workshops are basically no-cost financial literacy courses. They’re about the software, of course, but anyone can benefit from the principles covered, even if they never use YNAB.

Reddit. Read it?

The r/ynab subreddit is awesome. You see every issue under the sun, and there are some very knowledgeable folks there willing to lend a hand.

Seriously, though. What is a progressive web app?

In attempting to define progressive web apps, I always end up stumped. Across the web I find vagueness and confusion, or authoritativeness lacking citation. So I went down the rabbit hole attempting to clarify the history of the term and cite the dang thing.

➡️ Read the post: Published on Medium, cross-posted on dev.to.

Note: I plan to keep revamping this blog, but until then I’m mostly publishing elsewhere, linking out from here.

My evolving relationship with my sister with Angelman syndrome

[This post was originally written for and published on The Arc’s blog on March 19, 2018 for Developmental Disabilities Awareness Month.]

It’s now been almost five years since I first wrote about future planning. I was 22, and living in Washington, DC — 1,300 miles away from my family in Dallas.

At the time, my sister Caroline was 18. We were both entering new phases of our lives. I was fresh out of college, and she had just reached legal adulthood. (Her birthday milestones honestly were always more striking to me than my own). Caroline was born with a rare neuro-genetic disorder called Angelman syndrome. The prevalence of AS is estimated to be somewhere between 1/12,000 and 1/24,000.

I was in third grade when we finally discovered my sister’s diagnosis. I know, because my mom tells the story of how I went to school, and told my third grade teacher that I was worried about how I would take care of Caroline when something happened to our parents.

Years later, when my parents took our family out to dinner to celebrate my high school graduation, I have a perfect memory of sitting at the table feeling deeply guilty, and near tears. I was soon to move to DC for college. At the table, my parents expressed how important they thought it was that I go. When I later moved away to college, it was deeply unsettling for about a semester. Everything I had to do every day suddenly only revolved around, well, me.

The years passed, and I thrived in DC. I love that city. It’s my home away from home. But I felt those tugs. Sometimes the feeling was quiet, sometimes it was loud; but it was there. Feeling too far away, feeling too selfish. Feeling the desire to be a present fixture in the lives of my family members — to be a more active part of Caroline’s care network.

I’m now almost 28; she is almost 24. I lived in DC for eight years. Two years ago, I moved back to Texas. For one of those years, I lived in Dallas. It’s hard to explain the internal battle between feelings of obligation and not knowing with any certainty what you really want, personally. But you know what I’m talking about. It’s part of the human experience. It has nothing specifically to do with having a sibling with disabilities. It’s a universal experience. This is just a particularly salient part of how I experience this struggle. None of us can know if we’re making the right choices; We just do what we can, and keep moving forward.

What I can say with certainty is that living in closer proximity to my sister deepened our connection considerably. When living further away, I could still say hi to her on the phone. (Or like when she somehow figured out how to FaceTime with me while I was at work and she was in class).

Screenshot of FaceTiming with my sister

But living back home, she would spend the night over at my apartment. We’d make dinner, and watch The Great British Baking Show. She loves to watch my pet rabbits run around. I got back in sync with her nonverbal cues, and she got back in sync with my micro-movements. (I swear to you she can tell when you’ve had a thought, and haven’t even said anything yet — her emotional intelligence is through the roof). It’s these subtleties that were difficult — near impossible, even — to maintain, in a long-distance relationship with her.

Me and Caroline

 

There’s no right decision for me, or for other siblings. But I can say for certain that I don’t regret moving back to be closer.

I was reflecting on these past ten years just recently; I was doing some work in a coffee shop, and a family came in. A mom, dad, older sister and younger brother. The younger brother had Down syndrome. They were all hanging his art on the coffee shop wall. As I understand it, the sister had independently reached out to the coffee shop about featuring her brother’s work, and the other artist currently featured on the wall had volunteered to share space. As I chatted with them, and watched as they arranged his art, I had an odd sense of deja vu. Reflecting on being the sister’s age, and pondering college. (She appeared to perhaps be in high school). These thoughts can feel so isolating, but they are such a deeply shared experience. Meeting them by happenstance reminded me of that.

Growing up feels like continuously uncovering that behind the tapestry is a mess of loose ends. From chaos, comes order (or at least hindsight). When I was younger, I worried about Caroline’s future with a general sense of anxiety. Now that I’m older, I worry about increasingly complicated specifics. We have been having active planning conversations for years, and on some level, it grinds away in the back of my brain nonstop. Despite working so proactively, we still don’t feel close to having an answer, or feeling prepared.

I hope that for anyone reading this, these thoughts inspire thoughtfulness, not paralysis. I accept that we can’t ever know anything for certain. It can be overwhelming, but I fervently hope that other siblings and families don’t shy away from these conversations.

Amberley Romo is a software developer in Austin, Texas. She is part of a project to build a free, open-source, web-based communication app.

Getting started with GatsbyJS and WordPress

[This post was also published on the Gatsby blog on January 22, 2018.]

Earlier this week I began rebuilding my blog using GatsbyJS + WordPress. As I familiarized with Gatsby, I found myself flipping through a million tabs, and I thought it might be useful to summarize concepts and to aggregate links I found helpful.

I recently decided to tackle a redo of my blog. I wanted to do something different and I’ve been hearing a lot about GatsbyJS. A static site generator for React that I can pull my existing WordPress data for? Sold. I’ll try it.

The documentation is a little scattered — I started by reading the tutorial and quickly veered off. I generated a new site using the default starter and read through what it gave me. Assuming you have the Gatsby CLI installed, run:

gatsby new gatsby-example-site

That gets us a new site directory with a couple (mostly) empty “gatsby”-prefixed files and a src directory with some basic scaffolding. The configuration and lifecycle hooks for Gatsby get put in those “gatsby”-prefixed files, gatsby-config.js, gatsby-node.js and gatsby-browser.js.

gatsby-config.js

Essentially the Gatsby home base. The two main things defined here initially are siteMetadata and plugins.

module.exports = {
  siteMetadata: {
    title: 'Gatsby Default Starter',
  },
  plugins: ['gatsby-plugin-react-helmet'],
};

gatsby-plugin-react-helmet is just a plugin the starter includes. It’s a document head manager for React.

Also, there isn’t currently documentation on arguments for gatsby-config, but you can get an idea here if you’re (also) curious.

gatsby-node.js

We can make use of any of Gatsby’s node APIs by exporting a function with the name of that API from this file.

For my purposes, the only one I had to interact with so far was the createPages API. This gets called after our data has been fetched and is available to use to dynamically build out our static pages. More on this later.

gatsby-browser.js

Same as above, we can make use of any of Gatsby’s browser APIs by exporting them from this file.

I haven’t needed to make use of any of these yet, but they provide a hook into client runtime operations — for example, replacing the router component, as seen in this example.

Plugin: gatsby-source-wordpress

My natural next step is getting my data successfully pulling from WordPress. There’s a plugin for that. gatsby-source-wordpress is Gatsby’s plugin for sourcing data from WordPress sites using the WordPress JSON REST API.

(Fun fact: the WordPress REST API is already included starting with WordPress 4.7 — no longer requires installing a WordPress plugin. I didn’t actually know that, not having used the WordPress REST API for anything before).

I started by reviewing the code for the demo site for using the plugin.

Configure the plugin to pull your data

In gatsby-config.js, add your configuration options, including your WordPress site’s baseUrl, protocol, whether it’s hosted on wordpress.com or self-hosted, and whether it makes use of the Advanced Custom Fields (ACF) plugin.

module.exports = {
  ...
  plugins: [
    ...,
    {
      resolve: `gatsby-source-wordpress`,
      options: {
        // your wordpress source
        baseUrl: `amberley.me`,
        protocol: `https`,
        // is it hosted on wordpress.com,
        // or self-hosted?
        hostingWPCOM: false,
        // does your site use the Advanced 
        // Custom Fields Plugin?
        useACF: false
      }
    },
  ]
}

Use the data to dynamically construct pages.

Once your source plugin is pulling data, you can construct your site pages by implementing the createPages API in gatsby-node.js. When this is called, your data has already been fetched and is available to query with GraphQL. Gatsby uses GraphQL at build time; Your source plugin (in this case, gatsby-source-wordpress) fetches your data, and Gatsby uses that data to “automatically infer a GraphQL schema” that you can query against.

The createPages API exposes the graphQL function:

The GraphQL function allows us to run arbitrary queries against the local WordPress GraphQL schema… like the site has a built-in database constructed from the fetched data that you can run queries against. (Source)

I used the gatsby-node.js file from the demo to get started. For my purposes the ‘posts’ code does what I need it to do out of the box (at least for the moment) . It queries our local WordPress GraphQL schema for post data, then iterates through each post node to construct a static page for each, based on whatever template we define and feed it.

For example, below is the part of the demo gatsby-node.js file that iterates over all the WordPress post data (annotations mine).

const postTemplate = path.resolve(`./src/templates/post.js`)

_.each(result.data.allWordpressPost.edges, edge => {
  createPage({
    // will be the url for the page
    path: edge.node.slug,
    // specify the component template
    // of your choice
    component: slash(postTemplate),
    // In the ^template's GraphQL query, 'id'
    // will be available as a GraphQL variable
    // to query for this posts's data.
    context: {
        id: edge.node.id,
    }
  })
})

The documentation defines a Gatsby page as “a site page with a pathname, a template component, and optional graphql query and layout component.” See the docs on the createPage bound action creator and guide on creating and modifying pages for more detail.

… Take a step back to “templates”.

In the step above we dynamically create pages based on our data by passing the absolute path to a defined template to “component”. So what’s a template? Basically a page component we define and feed into the loop described above. We pass the post id to “context” to make it available as a graphQL variable in the template file. The graphQL query defined for the template then uses that id to query for data specific to that post.

… Take another step back to “pages”.

So a template is a just page component that we can use to programmatically create pages. Then what’s a page component?

Page Component — React.js component that renders a page and can optionally specify a layout component and a graphql query. (Source).

React components living in src/pages automatically become pages . The file name of a page maps to its site path. My site in its current state only has one good example of this — src/pages/index.js maps to amberley.blog. If I had an ‘about’ page, it would live at src/pages/about.js , and map to amberley.blog/about. (Since that doesn’t exist, it will actually end up hitting the only other page currently defined in my site, which is src/pages/404.js — (read about 404 pages).

If you include the “optional graphQL query” noted above, the result of that query is automatically passed to the component on a data prop (this.props.data). (Read more on graphQL queries).

Onward

While this isn’t a step-by-step tutorial, more a guided walkthrough of me walking through an initial Gatsby setup, if you’re following along with the demo code you’re probably close to (or already!) seeing your WordPress data populate your Gatsby dev site if you run gatsby develop!

Sidenotes

  1. You don’t need to know graphQL to get started with Gatsby. I didn’t. It’s been a good introduction.
  2. Gatsby makes heavy use of plugins — both official and community — for a lot of things, from one that implements Google Analytics, to one that adds GitHub’s accessibility error scanner to all pages.
  3. Read through some of the source code. I particularly enjoyed reading through the bootstrap process. (It’s beautifully commented).
  4. Gatsby.js is a static Progressive Web App (PWA) generator, but to be PWA friendly (at least according to the Lighthouse PWA audit), look into two plugins: gatsby-plugin-manifest and gatsby-plugin-offline.
  5. I did end up deploying with Netlify, and I’m super happy with it.
  6. Figuring out how to get GitHub gists to embed correctly is now on my list 🙂

Resources (aside from those linked throughout)

  1. Rebuilding my portfolio website with the great GatsbyJS and WordPress
  2. Migrating to GatsbyJS Part 1
  3. Experimenting with GatsbyJS and the WordPress.com API
  4. The Web App Manifest | Web Fundamentals
  5. App Manifest Generator

The Road So Far Pt III

Exactly a year ago I posted The Road So Far Pt II. I now have two full years under my belt since undertaking this career pivot. I’m still not sure what I want these recaps to be, but I feel compelled to keep going now that it’s a pattern.

2017. 2017 was a “growth year”. I always laugh at that phrasing (because which year isn’t) but while it wasn’t the greatest year, I learned quite a lot.

Continue reading The Road So Far Pt III

The Road So Far Pt II

Almost exactly a year ago, I first started writing about my pivot to working full-time as a web developer (aka The Road So Far Pt I). tldr; after dancing around the edges of embracing this career (in every possible way, for my whole professional life leading up to that point), it had become clear I wanted and needed to commit. I find that reflection is the only way to take stock of progress, and a year seems like a good time to look back.
Continue reading The Road So Far Pt II

The Year of the Blanket

I love blankets (in general, and to knit!) Big, squishy, comfy, cuddly blankets– likely, at least in part, due to my conflicting relationship with actually paying attention to gauge. It doesn’t matter as much if it’s off by a bit — it’s a bit like cooking vs. baking. Anyway, onto the assortment of blankets from this year:

Continue reading The Year of the Blanket

Event Roundup: Emberitas and Front Porch

Finally, finally, I have time to hit up local events and meetups again, and Austin has not disappointed. (See what I was up to the first half of the 2016.)

#Emberitas

First up, Emberitas. I found out about this event through the Women Who Code – Austin network. Three awesome women in the Austin Ember community decided to organize this free one-day workshop to introduce women to Ember.js. (All bootcamp grads, by the way — two from MakerSquare and one from CodeUp).

Continue reading Event Roundup: Emberitas and Front Porch