Context is King

Or, What Made That Talk Good?

As I learn programming and try to become part of the software community, I go to a lot of meetups. Meetups are awesome, and I will put together a blog post on meetups later, but first there’s one meetup I’d like to talk about: an awesome talk hosted by the DC .NET users meetup. I was excited the whole time, learned a lot, and and made some friends. That evening definitely made me a better developer, and definitely re-energized me a bit. Today, I’ll talk about two things: What I learned at this talk, and why this talk was so good.

What I Learned

Really, you should go to this talk by @kendallmiller yourself (slides). I won’t be able to do it justice, but here are enough takeaways to convince you that you’ll learn from him:

Steps for optimizing a web application:

    1. Know your goals before you do anything else: A quick definition of goals would be a 95% percentile for response times given specific load. Example: I want 95% of requests hitting my server to be handled in less than 200ms, when there are approximately 125k requests per day. If we don’t start with a concrete number, we will make pointless optimizations, or even make things worse.
    2. Measure your progress. Look at you application’s logs and response times. Are you there already? Are you slower than you thought? If you’re done, stop. You’ve met the business’s requirements and you don’t want to spend much time throwing money after a goal when you’re already there.
    3. Cache things. One concrete example: You put your logged-in users’ usernames in the top right corner. Awesome. Do you hit the DB every page load for that? Applications ask the same questions over and over. If the answers are already in memory, the application will save performance. Caching data that rarely changes is the safest, cheapest way to improve performance. As always, if you’re done, stop. As we go down this list, the steps get more costly and riskier.
    4. Distribute work. Can you load balance the site between several different servers? This step is really the classic “scale out” model of building up an application. There are lots of things written about this step. Kendall’s main suggestions are: don’t do this unless you need it, and think about sticky sessions. One of the big takeaways from the talk is that scaling out with more web servers won’t help unless the problem is that requests are waiting on web servers. If your actual problem is that you get too much data from the DB too often, go to 3.
    5. Defer work. Kendall calls this, “async,” but I’m a C# developer and I kept thinking about they keyword instead of the concept. What Kendall means is “decoupling operations so that the critical path is not blocked.” Use queues for long running processes, perform expensive computations and retrievals ahead of time, etc. This step is the hardest to get right, and is a last resort.  
    6. Remember: Consistency is your limiting factor. In other words, the requirement that users visiting the site from different places at the same time see the same site limits the extent to which we can cache, because cache could be stale, it limits the extent to which we can distribute load, because the different instances might have different state, and it limits the extent to which we can defer work, because some work might finish before others. One of Kendall’s main points here is that most people overestimate the extent to which consistency is a business requirement. What if, when Amazon employees update the summary of a book, it changes after 8 minutes on the East Coast but it takes 12 minutes to change in Colorado? Who cares! Having the artificial requirement that two users see the description change at exactly the same time is silly, and puts a lot of strain on the app to implement.

That is a quick outline of Kendall’s talk. But now, the second part of the post:

What Made this Talk Good?

I am not a web application architect, but after a talk that lasted less than two hours, I was able to write down a great deal of practical, applicable advice. How did Kendall do that?

He began the talk with a problem: You want to build a web application that remains responsive at around 125K page loads per day, with a 95th percentile latency of 200 milliseconds. Boom. That is super specific. You could put that performance requirement in a work authorization without changing a word.

Specific context is important because it gives me a map for remembering things. Why are we caching the username? Oh yeah, because database calls are slow and we need to respond in 200 milliseconds. Ok, that makes sense. Why don’t we spend $10K on giant servers? Because we only need to respond every 200 milliseconds, not every 20.

The reason that Kendall’s talk was so memorable is because I was never left wondering why he was saying what he said. Why is he talking about cache? Response time. Why is he talking about network latency? Response time. There were no orphans in this presentation. That is, there were no paragraphs, slides, or statistics that were just up there for some reason, that I couldn’t connect to the surrounding context. Everything connected back to the goal.

I think that leads us to a rule of presentation:

Tell your audience why they care, and repeatedly connect everything back to this reason.

The second rule of a good presentation is also related to context: You must follow the Known-New Contract. (I learned this rule from my dad. I don’t have an authoritative online source to cite, but some quick googling reveals that many university writing classes teach this as well.)

The Known-New Contract basically says that you must progress from things people know about to things that are new in order for them to follow your reasoning. If you start with things that are new to people, they don’t have any context and lose focus, so you must start with the known. If you stay in the known, people aren’t going to learn a lot, and they might not come back, so you need to continue to the new. Start with the known, continue with the new, repeat.

This simple rule applies recursively to the order of information within a talk. For example, Kendall begins his talk with building a website, and having concrete performance requirements. His audience was a room full of developers, so this was “known.” He then quickly moved on to the things we didn’t know (see above). The rule also applies at the sentence level. (Did you see that? I started with ‘the rule,’ which we’ve been talking about for a while, so it is known, and then told you something new about it.) In a talk, this means that, in addition to using the rule to organize your sentences, you can use the rule to organize subtopics: “The goal is to build a performant web app. The three ways of improving performance are caching, distribution of load, and asynchrony. The first type of caching is to cache rarely changing data in memory. One strategy for caching rarely changing data in memory is to cache a dataset from the DB when the application starts, and simply drop the entire cache if any element would change. The advantage of this caching strategy….” Do you see the repeated structure? Set opening context, give fact A about context, give fact B about fact A, etc. Very often, when you read information that “doesn’t flow” or “is hard to follow,” what you’re really noticing is a violation of the Known-New Contract.

So what makes a good meetup talk? Context, both given for the entire talk, and given for each sub-element within the talk, recursively down to the sentence level.

Please check out @kendallmiller and his company Gibraltar Software, and thank him for letting me use his talk on my blog. And the next time you’re at a talk that’s going really well (or really badly) as yourself: What’s the context? Are they following the Known-Knew Contract?

Till next week, happy learning,



What Comes after Counting Apples?

When I taught Latin and ESOL, it was super useful to have categories of words. For ESOL in particular, there are three main buckets that we’d put words into:

  1. Tier 1 words: These are simple words, concrete nouns and easy verbs, that are immediately understood. Words like “apple” and “seven.” Assuming you’re already old enough to count, teaching you another language’s word for “seven” is just a question of getting you to recognize and reproduce the sound and the symbol. Easy.
  2. Tier 2 words are words for linking concepts, words (or phrases) like although or so that. These words do not really lend themselves to dictionary definition. (If you want to see some really ugly, hard-to-read English, look up although or if in a dictionary sometime.)
  3. Tier 3 words: These are words that represent technical, discipline-specific concepts. Photosynthesis is a good example. It has a technically precise meaning in science class, and if I want to teach it to you, I need to be sure you recognize the sound and the symbol, and I need to be sure that you understand the concept at all.


The reason these tiers are so useful is that people learn the words in each tier differently. Therefore, teachers should teach them differently. For tier 1 words, you can just jam out something simple, repetitive association: flashcards, repeat after me practice, labeling pictures, etc. You need a lot of tier 1 words to be any good at a language, but they come pretty cheap. Continue reading “What Comes after Counting Apples?”

Linus on TED

Linus Torvalds gave a TED talk. This talk is interesting first because Linus has had such an influence on software; a majority of web servers and mobile phones are presently running code that he wrote. But second, it’s interesting because we get a chance to learn from such a great programmer. 

He says three things that I’d like to dig into:

  1. What he chooses to work on
  2. What personality traits he believes have helped him as a computer programmer
  3. What he thinks having good taste in code means

Continue reading “Linus on TED”

My Newest, Shiniest Hammer

“When all you do is hammer, everything looks like a nail.” That’s probably true, but I think there’s a second, more frequent cause of mistaking non-nail objects for nails. That cause is having a really really new, really really shiny hammer.

Have you ever seen a little kid with a new toy? Their parents want to take them to the swimming pool, but they want to bring their stuffed llama’s newest plastic hat. Why? Because it’s the newest, shiniest object that they have. They don’t want to be far from it! They might need it! They are, going back to hammers for a second, willing to assume that a random collection of unseen objects is likely to contain nails.

Adults do this too. As soon as I get a new phone, I try to use it to update my blog, or use it as a shopping list, or use it to play Minecraft, or whatever. There are even Android apps for writing code! On a little tiny touchscreen! Nothing happened that broke the little scraps of paper I used for shopping lists; nothing happened to my web browser or my big, fast computer that plays Minecraft just fine. I was excited to have a new toy, so I started using it for everything, even for things for which it is fundamentally unsuited.

Here’s a sad story about design patterns:

The other day, I caught a bad case of object happiness. Object happiness is a disease befalling new programmers that causes them to them to make more objects, more design patterns, and generally more code than is needed. I thought I saw a good place to use a strategy pattern, and I was off and running. Boom! Before you knew it there were strategy factories and strategies all over this little piece of our app. More abstract base classes! Turns out that was a bad idea.

Why? Because abstract base classes are hard to read.

I was over-engineering. I was asking whatever poor dev was going to read this code next to figure out what “ControlMapperStrategyFactory” did. In other words, I was using elaborate design features to solve a problem that could have been solved with four or five stupid, read-straight-down, does-what-it-says-on-the-tin methods. Someone should’ve slapped me.

I think the reason that I ended up over-engineering this poor little corner of our application so much is that the design patterns bouncing around in my brain were my newest, shiniest hammer. I was so excited that I understood the strategy pattern! I felt like I had come across a textbook example of when to use this pattern, and use it I did!

But I had forgotten software’s primary imperative: managing complexity. I was making a simple problem (CRUD app on a website) into a complicated problem (inheritance, two different design patterns, virtual methods, the works.) I was so excited to have a shiny new hammer that I forgot to ask myself whether this thing was a nail. The first rule of programming is to write the simplest program that will work. There are some problems that are inherently complicated, where having some strategies somewhere, in order to separate the logic for selecting which process to use from the logic of performing that process, is really necessary. I just hadn’t found one that day.

So the next time you’re reading your favorite programming book or programming blog, and you learn about something so cool you’ll have to try it, please take a moment to verify your target is a nail before swinging your newest, shiniest hammer. You’ll save yourself some time.

Till next week, happy learning,