How to Do Event Modeling vs Relational DB Modeling

Event data is a powerful data format that allows us to track and analyze things that happen around us. 

However, if you’re used to relational data modeling, event modeling can feel pretty foreign and awkward. 

Let’s compare and contrast these data formats so we can better understand their weaknesses and their superpowers. It’s not a contest. Most business use both, and they each have their place.

The simplest way I can think to contrast the two is this:

Event Data = Verbs
Relational Data “Rows” = Nouns

Event data answers questions about what things have done. Actions that happened.
Relational data answers questions about the state of things.

Questions that are trivial to answer with a relational data model, like “what class is Sam currently enrolled in?” can be maddeningly complicated to answer with event data. But on the flip side, event data can make other types of questions suddenly very simple and easy, like “how many classes has Sam enrolled in over the course of his life?”.

Something is Amiss

To illustrate why it’s important to get this right, let’s look at some real-world examples of trying to use the wrong data format. It’s like trying to use a screwdriver in place of a hammer.

Trying to use event data for a relational data problem

Let’s say you’re tracking events for every time a new products are added to your inventory. You’re also tracking events for every time products are sold. This is useful data for many types of analysis. But it it would be a really nightmarish way to keep track of which products are currently in inventory, something that would be trivial with a relational table.

How many hammers are currently in our inventory?
# relational model: oh let's just go look at our inventory table
inventory table:
nuts 8
bolts 3
hammers 89
# event data model: uhhh, let's count every time a hammer was ever added since the store opened, then subtract every time a hammer was ever sold, and theoretically that should tell us how many we have.

Trying to use relational data for an event data problem

A recent example that comes to mind is a training company providing reporting on course completions.

The symptom they noticed was that when looking back at historical training course completion, the numbers would sometimes change. Like, the number of courses completed last March would inexplicable change from 3842 to 3833 a month later. What the heck!?

Turns out, they were counting the course completions by joining data across several tables. If courses were ever deleted, which occasionally they were, the 

Trying to use event data for a relational data problem

Relational Data (aka Entity Data)

If you’ve ever worked with an application database, you know about entity data. It’s the standard format for the most common type of database, the relational database. Here’s an example:

image

Entity Table Example (Enemies Table)

Relational data is stored in tables. Entities are things like users, products, accounts, posts, levels, etc. There is a separate table for each of type of entity, and each table has columns to hold properties about the entities. There is one row in the table for each entity. In this example, the entities are enemies.

Relational databases are really good for capturing the current state of your application. Things like users, product inventories, accounts payable, etc. You can very quickly lookup information about any entity.

One characteristic of entity databases is that they are normalized. Data is rarely duplicated. For example, you might have a table for Accounts, with attributes like the account name, type, category, etc. Accounts have many users associated with them, but you wouldn’t store information about those users in the Accounts table. Instead, you would include a key in each user record which links to its account. From a data storage (disk usage) perspective, this is very efficient.

image

Normalized relational data example from the excellent Wikipedia article on joins

Event Data (aka Analytics Data)

Now let’s look at the characteristics of event data. Here’s an example:a

image

Event data example: “publish” event

Event data doesn’t just describe entities; it describes actions performed by entities. This example above describes the action of publishing this blog post. You can imagine we have a collection of events called “publishes” where we track an event for each new post.

What makes this “event data”? Event data has three key pieces of information. I first saw these identified by Ben Johnson in his speakerdeckon Event Data (he calls it “Behavior Data”).

  1. Action
  2. Timestamp
  3. State

The action is the thing that’s happening (e.g. “publish”). The timestamp is self explanatory: the point in time the thing happened. The state refers to all of the other relevant information we know about this event, including information about entities related to the event, such as the author.

Let’s look at a more complex event. This is a “death” type event:

image

Event data example: minecraft death event

Here is an example data point for a player death in the game minecraft. Imagine we are recording every player death that happens in the game.

There are a lot of ways in which the player can experience death: falling from great heights, starvation from not eating enough pork chops, drowning, clumsily stumbling into lava, zombies scaring the crap out of you in a cave, etc.

Let’s say we want to analyze these player deaths in Minecraft. Perhaps we want to find out the most common type of death, the average player age at the time of death, the most lethal enemies, or any number of death-related questions. Perhaps we are trying to find out if the game is too difficult on certain levels, or if the new villain we introduced is causing way more destruction than we’d imagined, or if there is any correlation between types of users and types or frequency of deaths.

We can find out all of these things using the simple event data model shown above. The event data model has a few special qualities:

1. The data is rich (has data about lots of relevant entities)

2. The data is denormalized (we often store the same data repeatedly on all the relevant events)

Additional perks of event data: it can be nested, and that it has a much more flexible schema compared to the rigid tables of entity databases.

image


How should deadlines be used in software engineering?

How many conversations have you had about deadlines where at least one person scoffed at the concept? Pfft!

I have heard this a number of times — including from myself — and I want to fix this.

The world of software is very different from the world of print media, where our current concept of deadlines is derived. However, just because there can be no universal definition of deadlines across all software projects doesn’t mean we shouldn’t use them or that they aren’t valuable.

Deadlines are extremely important for planning and parallelizing work. Without expectations about when dependent work will be completed, all teams would have to work in serial. This would drastically slow down delivery times.

At the same time, deadlines can be frustrating and counter-productive if people disagree about what they actually mean.

Problems and solutions

In my experience, these are the most pertinent problems with deadlines in engineering organizations, and the most promising ideas for how to solve them.

1) They are interpreted differently from person to person.

Person A: “The deadline is next week so I’m pulling a ton of extra hours.”

Person B: “Why? It’s a fake deadline and doesn’t matter.”

Person A: “But I don’t want to get fired!”

This shows that a deadline means vastly different things to Person A and Person B. This can lead to confusion and frustration on the team working towards that deadline.

Instead, deadlines need to be a rallying point. Everyone needs to understand why this deadline is important. They need to know what impact missing the deadline has on their world (that can be other teams, customers, or the business as a whole).

More importantly, deadlines that are met need to be celebrated. Wildly. This is often overlooked. Building a culture around celebration for meeting deadlines is a much better practice than berating people for missing them.

2) They are used too early in a project life cycle.

Person A: “Hey we need to accomplish [insert_really_hard_unknown_thing]. When can we have that done by?”

Person B: [quickly wikipedia’ing what that thing even is] “uhhhhh, I don’t know.”

Person A: “I need a timeline!”

Person B: “Thre–FOUR! mmmmo-wee-months. Four. Months.”

Person A: “Great, see you in four months.”

Asking for a deadline when EVERY aspect of a project is unknown is a recipe for disaster. It’s stressful for everyone involved and sets the project up for failure. So let’s take a deep breath. Wait a few days for some exploration to be done. We will be spending time to buy information, but then we can come up with a meaningful estimation of the work. This information will help us set deadlines that have a better chance of being accurate.

3) They aren’t updated often enough.

Person A: “Hey, deadline is in 5 days. Are we still on track?”

Person B: “We’re a little behind but yeah, we can make it.”

Person A: “Great!”

[ 4 days, 23 hours later ]

Person A: “Just checking back on that project. We good to go?”

Person B: “Uhm, no we’re not gonna make it. Something came up. It looks like another week of work.”

Person A: “$%@!*”

In this case, the deadline wasn’t moved or re-evaluated when new issues became known. Instead of raising that flag immediately, Person B waited until the deadline itself to inform others. Now Person A is affected as well AND the team gets to feel the stress of coming up on yet another deadline in the future.

Deadlines shouldn’t be set to force humans to do inhuman amounts of work. They should be used to set expectations externally and enable a sense of predictability for planning. They need to reflect reality as accurately as possible or trust is lost and they can no longer deliver that predictability. Now, I’m not advocating for changing deadlines hourly or daily. But perhaps weekly, or at the very least within a standard planning cadence.

Updating a deadline isn’t limited to extending the date. Scope reduction is also an option. Choosing which action to take (or a combination) is a conversation the engineering and product teams need to have.

4) All the “knowns” aren’t taken into account… just the fun ones.

Person A: “How long to ship this feature?”

Person B: “Two weeks.”

[ two weeks later ]

Person A: “Why isn’t this done?”

Person B: “Well, it technically IS done. Now we’re working on testing it, building a new deployment mechanism for it, and we’re gonna roll out a beta first. Also, I was on vacation last week.”

This deadline was made without a complete understanding of the work to be done, and the time to dedicate to it. (not to mention Person B also threw problem #3 into the mix.)

We need to make sure we take all known challenges into consideration when determining a deadline. Will we be losing person-hours to a known cause? Vacation? Company offsite? Birthday party which will cause missed mornings due to hangovers?

Also, what un-sexy tasks are we potentially forgetting about? How many tests are we gonna write for this? How do we get this sucker into a production environment? Slow down and think thoughtfully about your process and the availability of resources. It’ll make your deadlines much easier to deliver against AND it will make deadlines easier to defend against scrutiny.

On estimation: uncomfortable but necessary

Deadlines that are set by engineering teams will largely be informed by estimating work. That means that everyone on the team is going to have to get comfortable with being wrong. A lot. Saying anything that you know to be wrong and have little confidence in can be a very difficult thing to do.

We need to have a collective understanding that it’s our best guess and that we’ll get better at it over time. Estimation is a skill that gets better with repeated use. In the early stages, it’s going to feel uncomfortable, but we need to do it.

Estimating tasks

Before we can define the delivery date of a large project, we should break the project down into tasks, where tasks are defined as things we believe we can accomplish in roughly 5 workdays or less.

Some helpful questions to ask when estimating a task:

  • Is the project green field or in a pre-existing area?
  • What is the quality of code in that area?
  • How well do I know the area of code?
  • How familiar am I with the programming languages involved?
  • What touchpoints or integration points with other pieces of code are there?
  • How good is existing test coverage?
  • Does this work touch any business-critical areas? (write path, billing, load balancers, signups)
  • Has anyone done this work before? What are their thoughts?
  • What are the tradeoffs I am making?
  • What is the objective of this task?
  • Does this task need to be done at all?

Estimating projects

Projects are typically defined as a larger body of work that multiple people can work on in parallel.

Some helpful questions to ask when estimating a project:

  • How much time will we actually be dedicating to working on it?
  • What is the objective of the project?
  • Do we have any known days off?
  • What are ALL the tasks required to be done?
  • Do we have any blocking dependencies on other teams?
  • Are any tasks blocking other tasks in the project?
  • Is any new infrastructure/hardware required for this project?
  • What are the Doneness Criteria for this project?

Doneness criteria

Even knowing when something is done is difficult. Different roles within the team can have different perspectives on “done” so we need to have specific criteria that can determine what that means for the project.

Some examples of typical Doneness Criteria:

  • Deployed in production
  • Tests fully automated
  • Communicated internally or externally
  • Spent a certain amount of time in an internal or external pilot
  • Documentation in production
  • Education of sales or marketing team complete
  • Landing page launched
  • Analytics and tracking
  • Operational runbook and observability

Conclusion

Deliverability is essential to any company as it grows and matures. Deadlines are a major tool in the toolbelt. When used properly, they are incredibly useful. But it takes time and practice to get better at using deadlines. So, I suggest that engineering organizations treat them as alive and breathing, continue to learn about them, and document shared experiences internally and with the engineering community.

If you have any tips or suggestions on using deadlines effectively, we’d love to hear them. You can drop me a line at ryan@keen.io or ping us on Slack

Subscribe to stay up to date on future software engineering posts (no spam, ever):


Compute Performance Improvements & Magic of Caching

I’m happy to announce that we’ve rolled out some significant performance and reliability improvements to the Keen platform for all query types.

Improved Query Response Times

The overall response times have improved. Queries to Keen (via the API or through the Explorer) should be faster now. The following graph shows the impact of the changes.

95th Percentile Query Duration

Improved Query Consistency

We have also made our query processing more robust by fixing a bug in our platform that could cause query results to fluctuate (different results for the same query) during certain operational incidents like this one.

The Magic of Caching

These dramatic results have been possible due to more effective caching of data within our query platform.

We’ve been working on improving query response times for many months and to understand the most recent update it would be useful to have a little background on how Keen uses caching and how it’s evolved over time.

Query Caching Evolution

At the lowest level we have a fleet of workers (within Apache Storm) responsible for computing query results. Any query can be considered as a function that processes events.

Query = function(events)

Workers pull pending queries from a queue, load the relevant events from the database, and apply the appropriate computation to get the result. The amount of data needed to process a query varies a lot but some of the larger queries need to iterate over hundreds of millions of events, over just a few seconds.

If you want to know more about how we handle queries of varying complexity and ensure consistent response times I wrote a blog post on that earlier which is available at here.

Simplified view of a Query being processed

(Simplified view of a Query being processed)

We started experimenting with caching about a year ago. Initially, we had a simple memcached based cache running on each storm worker for frequently accessed data. At this stage, the main problem that we had to solve was invalidating data from the cache.

Cache Invalidation

We don’t store individual events as individual records in Cassandra because that won’t be efficient, so instead we group events (by collection and timestamps) into what we call ‘buckets’. These buckets sometimes get updated when new events come in or if our background compaction process decides that the events need to be re-grouped for efficiency.

If we used a caching scheme that relied on a TTL or expiry, we would end up with queries showing stale or inconsistent results. Additionally, one instance of cache per worker means that different workers could have a different view of the same data.

This was not acceptable and we needed to make sure that cache would never return data that has been updated. To solve this problem, we

  1. Added a last-updated-at timestamp to each cache entry, and
  2. Set-up memcached to evict data based on an LRU algorithm.

The scheme we used to store events was something like the following:

Cache Key = collection_name+bucket_id+bucket_last_updated_at_

Cache Value = bucket (or an array of events)

The important thing here is that we use a timestamp bucket_last_updated_at as part of our cache key. The query processing code first reads a master index in our DB that gives it a list of buckets to read for that particular query. We made sure that the index also gets updated when a bucket is updated and has the latest timestamp. This way the query execution code knows the timestamp for each bucket to read and if the cache has an older version it would be simply ignored and eventually evicted.

So our first iteration of the cache looked something like the following:

Query Caching V1

(Query Caching V1)

This was successful in reducing load to Cassandra and worked for many months but we weren’t fully able to utilize the potential of caching because we were limited by the memory on a single storm machine.

We went on to create a distributed caching fleet. We decided to use Twitter’s Twemproxy as a proxy to front a number of memcached servers. Twemproxy handles sharding of data and dealing with server failures etc.

This configuration allows us to pool the spare memory on all our storm machines and create a big, distributed-cache cluster.

Query Caching V2

(Query Caching V2)

Once we rolled out the new configuration the impact was pretty dramatic. We saw a major increase in cache hit-rate and improvements in query performance.

Improved cache hit rate after distributed caching rollout

(Improved cache hit rate after distributed caching rollout)

Improving Query Consistency

Keen’s platform uses Apache Cassandra, which is a highly available and scalable, distributed database. We had a limitation in our architecture and usage of Cassandra such that we were susceptible to reading incomplete data for queries during operational issues with our database.

Improved cache hit rates meant that most of the query requests were served out of cache and we were less sensitive to latency increases in our backend database. We used this opportunity to move to using a higher Consistency Level with Cassandra.

Earlier we were reading one copy (out of multiple copies) of data from Cassandra for evaluating queries. This was prone to errors due to delays in replication of new data and was also affected by servers having hardware failures. We now read at least two copies of data each time we read from Cassandra.

This way if a particular server does not have the latest version of data or is having problems we are likely to get the latest version from another server which improves the reliability of our query results.


How companies are delivering reporting and analytics to their customers

Today’s users of technology expect stats and charts in each and every one of their favorite apps and websites. Many companies are turning advanced analytics into a paid feature, while others are bundling analytics into their core product to improve engagement and retention. Keen’s Native Analytics lets every company differentiate with data and analytics that are truly native to their product.

In this on-demand webcast you’ll learn:

  • Key applications of Native Analytics and how companies like Triptease, Bluecore, and SketchUp use Native Analytics to deliver analytics to their users, right within their products and drive ROI
  • Why ease of use and the right capabilities are crucial to your success
  • Key considerations for a successful Native Analytics implementation

How companies deliver embedded analytics and real-time reporting for their customers

Don’t forget to download the Native Analytics checklist.

Thinking about adding Native Analytics to your product or want to improve your existing implementation? Contact us for a free consultation!

Originally published on Tumblr


SxSW Field Report, Day 1: Arrival / Destruction

I HAVE ALREADY FAILED YOU (SURPRISE)

There is simply no way on this earth I could’ve written this field report last night. Or, I mean, I could have done, but it probably would’ve been a 15,000 word treatise on the merits of Austin’s Deep Eddy grapefruit-infused vodka (which is pretty amazing, btw, but certainly feels a bit less so this morning), followed by the letter h 400 times. hhhhhhhhhhhhhhhhhhhhhhh

My point is, I made a judgment call, and I believe it was in your favor. OK, let’s go.

OH MY GOD, BIRDS

I think I made a joke in my first field report about how I was going to write an essay at some point about why birds exist. Well, let me answer that for you right now: Torment and destruction.

I am on the roof of our beautiful AirBnb right now, and I would just like to quietly and miserably plow through this field report, so that I can crawl back under the bathroom cabinets and hide there in peace, but there are these monstrous birds making just the absolute worst cacophony of peeps.

I mean, admittedly, I am not in the best state for any noises, so even normal, happy bird sounds feel like nails on a chalkboard right now (I keep protectively hunching down like the sounds might wound me), but I should also say that these are not normal, happy birds. These are GRACKLES.

Grackles (which is one of those perfect, hilarious-sounding names for something horrible — much like brambles), if you’ve never heard them, sound like a regular old bird maybe ate an 8-bit Nintendo, a faulty one, and now they just go around making these insane beepy explosion monster sounds.

Dustin Larimer and I spent the night in the RV, and we were absolutely cracking up at the massive ruckus these little monsters were creating, all rattling around in the bushes doing the music from the Chip & Dale Rescue Rangers NES game. (Here is that what sounds like, by the way, but you should under no circumstances go there if you are reading this as hungover as I am writing it.) Then we actually started watching a bunch of grackle YouTube videos (which are all terrible, by the way — maybe learn how to edit your damn grackle videos, people!)

Anyway, I just wrote an awful lot about grackles, so a) maybe I actually love them? and b) sorry I just did that? I maaaay be a little too stream-of-conscioius-y this morning. Let’s talk about something that’s not birds, shall we?

THE TOILET MANUAL

Not last night, the one before, I slept in the RV as well, because the hotel was a little crowded, and I am uncomfortable with human closeness.

It was pretty cold and stuff, which wasn’t great, but the shittier part happened when I woke up to go to the bathroom at 3 am and found I had no idea how to use the toilet.

Recreational vehicles have pretty much all the amenities of a home, but (naturally) there is a somewhat more involved process in using any of them. So, like, to use the toilet, you have to turn on some switches and pull and push a lever, and probably a few other things. It’s not complicated, exactly, but it’s also not the sort of thing you can intuit your way through all groggy and hungover at 4am while doing a pee-pee dance.

So, I had to go find the manual for the toilet, which sounds like a silly concept until you need it, and then you are thanking your lucky stars for whatever blessed, miserable copywriter had to write that thing up 17 years ago.

OK, I swear I am getting to Sx. I can feel it. We’re getting close.

THE McCAFÉ CARAMEL FRAPPÉ IS ATROCIOUS

I took 1 and a half sips and threw that garbage out.

I am not precisely sure what sorghum is, but I am positive I could taste it.

At least with a Shamrock Shake, you know you’re in for some trash. I was hoping for a nice little coffee beverage, not a caramel-flavored PlayDoh tube being squirted into my mouth. 1 star.

THE R.V. HAS A NAME

Yesterday I reported the dire need to give our glorious apartment on wheels a suitable moniker. I suggested Janet — to which Becky, like, immediately replied back, “ANYTHING BUT JANET.” So, say hello to our friend Not Janet. She is like a friendly whale, and I sleep in her belly.

image

Note that, despite the obvious temptation, I am not saying “‘Murica” here, because that is a lazy non-joke, and we are better than that.

THE TRIP DOWN TO AUSTIN

Was pretty uneventful, to which I give full credit to the stable hands of our two amazing helmsmen, Tim Falls and Justin Johnson. I mostly lied in the little pirate bunk above the cockpit and tried to get a final bit of sleep in before The Reckoning. I used my shoe as a pillow, and only nearly rolled off once. Drool level: medium. 4 stars.

image

Phone people, phone people, phone people, phone people…

OUR MAGNANIMOUS HOST

Yesterday I joked about our drunk-dialing AirBnb host, but that guy is rad, and he set us up. Beautiful place. Full bar of amazing, quasi-obscure, top-shelf stuff. A fridge full of drinks and treats. He even managed to track me down an iron, because I am a weirdo and iron my shirt literally every. single. day.

Listen, y’all, even if I’m puking next to a dumpster, I want to look fully-pressed and professional, OK? (I did not puke near a dumpster. That one was a joke.)

AUSTIN, YOU GET ME

Listen, I love SF, and over the past 2 years, I have definitely come to think of it as home. But I don’t have the vehement level of enthusiasm that some people do for San Francisco.

Like, back when I used to use OK Cupid, I would say at least a full third of everyone’s profiles began with something about their intense love of SF or pride in their identity as a San Franciscan. Which, wonderful! Good on you for finding your place! But I’m not quite there yet with SF.

Austin, though. Hm.

I am not sure what it is, but we just click, Austin and I. It always feels hot and dark here even when it isn’t (that doesn’t make any sense, sorry), and it’s forward-thinking and inventive but still manages to hold on to some of the good, fun, gritty, twangy Texas parts. Also, the music scene is just astounding. My first time here as an adult, I was waiting for a friend to meet me, so I just poked into this random bar for a beer, and these amazing women called The Whiskey Sisters were doing a sound check and did this twanged-up version of “Like A Virgin” that was like the best thing I’ve ever heard in my life.

So, yeah, Austin.

It is on my bucket list to live here one day, so that then I can be the one complaining about all these tech money hacks taking over my city and stuff. (Sorry, by the way! We’ll be gone soon, and we’ll try not to make too many messes!)

SPEAKING OF WHICH…

Harmony isn’t one of my Top 5 StrengthsFinder strengths, but it’s pretty high up there. And I have definitely been sensing some animosity from the local Austinians (Austinites? Austrians? Argonauts?) about the tech invasion for Sx. So my question for the locals is this: What can we do to be less bothersome? As I said, I love it here, and I would like nothing more than to be a gracious guest. Anything we can do to endear ourselves to you? Besides, you know, FOAD?

I talked to this one bartender about this, and he said the main thing that annoys him is that, because our schedules aren’t exactly packed out here, he tends to see a lot of us standing around, doing poses and trying to look cool? Which, if that is the case, god, I’d hate us, too.

No posing, you guys. I feel like that one is a gimme. I know we nerds are finally having our heyday and stuff, but let’s keep a level head about it and not, like, artfully blow e-cigarette smoke in a slow arc as we regard the sunset. None of that please.

OUR ILLUSTRIOUS COMMUNITY TEAM

TF and JJ both just woke up, and told us that, after a full night of partying and meeting people, the only business card either of them had — actually, they both had it — was for the local weed club. Solid community outreach, fellows.

NOT A SECRET FOR LONG: ISLA

Yeah, sorry I am the guy who’s always ruining things, but listen: I met a friend for a drink last night at this new tiki bar here called Isla, and that place is both incredibly solid and, at the moment, disproportionately unpopulated. I was there around 6, and the place was mostly dead, whereas anything along Congress was just swarming with humans.

Anyway, the place is adorable, and the drinks are outstanding. It’s tiki stuff, but it’s not cloyingly sweet like island drinks can sometimes be. There is good balance there. Also, this is the most aesthetically perfect drink I’ve ever seen in my life:

image

Sorry I don’t take many photos, by the way. I’m a writer, not a photographer. I create pictures with worddddsssssssss.

WATCHING SOMEONE CON THEIR WAY INTO PARTIES IS ABSOLUTELY AMAZING AND IMPOSSIBLE

It is an astounding skill. After Isla, my friend got us into two parties with live music and open bars and free food just by talking fast and acting confident and vaguely indicating she might know someone of importance at the company who was hosting them. It doesn’t sound that hard on paper, but, left to my own devices, I am pretty sure I would’ve just started nervous puking and weeping. Confidence, man. It is a super power.

SPEAKING OF SUPER POWERS

We have capes! Which, OK, admittedly, I am a little too embarrassed to wear in public, but good for anyone who can!

image

(Side note to our designer, Micah Wolfe: Micah, do not look too closely at the colors used on the logo. They are all wrong, but it seems we went for glitter over brand cohesion, and I regret very little with regards to glitter.)

Apparently people kept asking us what our super powers are, which turns out is a pretty fun improv game. My answers, in order:

  • lead into gold
  • horses into gold
  • immortal life
  • giving ghosts restored bodies
  • frag trolls
  • trolls into gold
  • etc.

WE ALSO HAVE INSANE T-SHIRTS

Which, not to brag (and I shouldn’t, because the Photoshop work is fairly atrocious), but I made them!

image

Backstory: I came stumbling into the Keen office a couple weeks ago, hazy and exhausted from the aftermath of our 2-day writeathon. Justin and Tim pulled me aside — “Hey, man, Josh had an idea for a t-shirt for Sx. Can you help us Photoshop it?” A blurry eyed-zombie, I grabbed a white board pen and said, “OK, talk me through it.”

“So, it’s a cat.” I draw a cat face.

“A cat professor.” I add a graduation cap, because I don’t really know what professors are.

“And he’s pointing at a bar chart made of bacon.” Yep. Got it.

“Next to a donut pie chart.” Done.

Now, at the time, I was running on like 2 hours of sleep, so I thought it might have been on me that this seemed like a totally fucking demented idea. A couple days later, though, when I consulted my notes and the photo I’d taken of my drawing, I was able to safely confirm that I was not the crazy one here. But, that certainly didn’t stop me from taking like 6 hours to make it.

Feedback has been pretty positive on them, though, it sounds like — except for Micah again, I imagine, who is probably drinking poison so as to not have to look at them any longer. Sorry about my skills, Micah! Sorry this is all I can do!

Hopefully we can have some of these shirts made for all y’all, too, so you can look as cool as we do. >_<

I AM NO LONGER THE ONE WHO BUYS US SHOTS, ALL RIGHT?

After the two parties we conned our way into (which I will talk about in a future post, because I certainly have Thoughts, but I imagine I am already trying your patience, word-count-wise), I caught back up with my fellow Keenies, who were still in East Austin and hadn’t made it past the second bar, which I found kind of hilarious.

I’m only just getting to know our Eric, Keen’s most recent Canadian acquisition, but apparently so far I have made a horrible impression by having been the only one so far to keep suggesting taking group shots together. This is a horrible, inaccurate framework.

I don’t even like shots, man. My body can’t really do ’em. Like, the whole point of shots, right, is to bypass the TSA in your mouth and get the alcohol straight to your belly. Except the way I do them, the shots hits the back of my throat, and my throat’s all like, “Um, NOPE. Exactly what in the hell are you trying to pull here, kid?” and then sends it back to my mouth for closer inspection. And upon inspection, yes, it does appear to be warm, low-grade tequila. Spit. Barf. Death.

Anyway, thankfully, Alexa has now taken the title from me, forcing tequila shots on us no less than 3 times in an hour. It is your fault I feel this way, Alexa. This is on you.

THE PHILLY CHEESESTEAK FOOD TRUCK HAD A TIP JAR THAT SAID SOMETHING TO THE EFFECT OF, “EVERY TIME YOU TIP US, NICOLAS CAGE WON’T MAKE ANOTHER MOVE,” SO I SAID, “OK, LOOK, I WOULD LIKE TO TIP YOU ALL, BECAUSE YOU ARE DOING A GREAT JOB, BUT I DO NOT AGREE WITH THE POLICY OF YOUR TIP JAR, BECAUSE NICOLAS CAGE IS, IF NOT A GOOD ACTOR, AT THE VERY LEAST AN INTERESTING ONE, AND HONESTLY THE MORE WORK HE PRODUCES, THE BETTER,” AND THEY WERE CONFUSED, I IMAGINE, BUT THEY WENT WITH IT

End of story.

THIS IS ALL TRICKY, BY THE WAY

Writing these, I mean. And not just finding the time and energy to do them, although that, too. I mean writing these quickly and not always clearheadedly, and (hopefully) making them fun and funny and authentic, but also making sure I don’t say something totally stupid or hurt people’s feelings because I didn’t think something all the way through. I mean walking that fine line been sassy and mean, and irreverent and inappropriate. Punching up at big chain restaurants for serving unhealthy food, and not punching down at the people who eat there. That sort of thing. And it is tricky.

This is not to make excuses. This is just to say that I know I am going to fail a little bit on each of these entries, and that is utterly terrifying. In all honesty, it’s a huge reason I’ve always been kind of reluctant to share my work with a wider audience — in the back of my head, I know that, pretty much no matter how careful I am about choosing my words or considering who’ll be reading my work, at some point, there are things I’m going to miss, and mistakes I’m going to make, and audiences I am going to marginalize or offend, and oh my god that is horrifying. That is the last thing I want to do. I mostly just want to make people laugh and enjoy themselves and maybe, MAYBE think about something new.

Because of this fear, though, I’ve mostly kept my work to myself, or to a group of close friends who know me, because it’s safe, and they are already familiar with my faults, and more or less forgive me them. But, doing that is also pretty cautious and limiting and yeah probably kind of cowardly.

So, I’m glad I’m taking this chance to write to a wider audience. Yeah, doing it is scary, and my inevitable failures will be shameful and disappointing, but, like, how the hell else am I going to get better? You can only learn so much in a vacuum — to start filling in my blind spots and growing as a writer, I have to present my work to the larger community and hear back from you, good and bad.

So, as I mentioned in my first post, please please get in touch if anything I say here bugs you — even if it’s just a passing flutter of annoyance. I would so much rather know than not, and hopefully over time, these mistakes will get fewer and fewer. Thank you for your patience, and for the opportunity.

OK, I am still on the roof, and I’ve had to keep moving to avoid the shifting gaze of the hateful, hateful sun, but I am pretty much out of room now, so let’s just call it. See you out there, I hope.

❤❤
Nate