The virtuous thank-you cycle

We talk a lot about vicious cycles, and how it’s easy to end up in bad places because the incentives are all bad, but let me tell you a story.

It’s a pleasant Saturday, my family is watching Star Trek: TNG together, and I’m in my home office, working on a side project and slightly resenting it. It’s the collateral for a workshop Carol Smith and I are giving at LISA about the non-technical part of interviewing, and we think it’s really an important part of helping people get jobs. So the workshop will be great and important, but I’m currently wishing I was doing something else. And then this comes across my twitter:

Marie says she uses the principles I espoused in that talk even when she starts side projects, like Call My Congress. Because she set it up to be easily localized, anyone could come through and easily add instructions in Spanish or Somali, without having to fight the project to do it.

I gave that talk 17 times. I took it to a different continent. I got most of my expenses paid, and I got an honorarium exactly once. I figure I spent 60 hours researching and writing it, and and 3-5 hours in prep and rewriting each time I gave it. I was working for myself, so no one paid me for that time.

A thank you note like this makes that all worthwhile. I give technical talks for the same reasons that novelists say they have to write – because it’s something burning in me, and I need and want to share everything I have learned the hard way so that other people don’t have to. In my grandiose moments, I think of it as reducing the entropy of the technical world, giving people a boost up the ladder. Most of the time I think it’s funny that all of my teacher-mother’s children have found our own ways to teach, far from school classrooms.

Now I have a job that pays me for development time for talks, and means that travel and conferences are not lost productivity for me, and that means the world to me, but most of the technical speakers you see at conferences are like I was — working evenings and weekends and taking vacation time to battle entropy with education.

I’m going to try to remember to do better about saying thank you, and thus spread the cycle of appreciation further and wider. A virtuous cycle perpetuates because the rewards are so good. Thank your mentors, and the friends who want you to expand your horizons, and the organizers who make safer spaces to speak in, and the bosses who don’t make you take vacation days. Thank them publicly and specifically.

The Seven Righteous Fights: Now What?

This is the conclusion to my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Hopefully I have convinced you that these fights are worth having, worth putting some of your capital and effort into. But now how do you do that?

You can’t fight alone and win. You’ll burn yourself out trying. So take the parts of this talk you find useful back to work and see where you can fit them in.


I’ve given you some strategy, the big goals for making your products more usable, extensible, beautiful, and well-designed. Here are some tactics.

  • Write a coding style guide and follow it
  • Host brown bag lunches
  • Pair programming for best practices
  • Add tests for accessibility and usability
  • Cultivate diversity and representation on your team
  • Ask questions

Cash is King


Money is the root of all business decisions

Money is the root of all business decisions.

Companies don’t usually (ever) change their behavior because of a desire to be more ethical, inclusive, or even more efficient. They change because it makes financial sense. If there’s one thing I’ve learned about fighting the righteous fight, it’s that money is a ridiculously effective argument.

If it won’t cost much and will save a lot, that’s your lever to move the weight of the whole company’s behavior and culture.

So what do the seven righteous fights help with? Mostly making users lives better, but also making building and maintaining the product significantly cheaper.


This was a long set of essays, I know. You may just be reading the last one to see if I sum up. Here it is:

Don’t build in compounding technical debt that your could trivially avoid.


Be productively lazy.

To be productively lazy is to be lazy over the long term. It’s automating tests and teaching your kids to do chores. It’s investing a tiny bit upfront to save yourself late nights and expensive reworks.

I’m begging you. Be lazier. Teach your teams to prize efficiency over instant results. Make future-you happy, or at least less angry.

This blog post is the final installment of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Accessibility

This is the seventh fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

We all use computers different ways. Does your software allow that?

Here are some ways you can add accessibility with relatively little effort.

Take your glasses off. Can you see any of the interaction elements on the screen? I just started wearing reading glasses this year, and I’m so surprised by how easy it is to, y’know. See things that are small or close to my face.

If you have uncorrected vision, borrow a co-worker’s glasses – gently. It’s a medical device.

Can you still see where you are supposed to be interacting with the product?

I blame Steve Jobs

Have you ever noticed that even in a Windows shop, the designers get shiny Macs with giant Retina monitors? It’s because layout and design tools are slanted to the Mac ecosystem, so it’s self-perpetuating.

The thing is, our users mostly don’t have giant Retina monitors. Or even giant Dell monitors. Or even giant hand-crushing phones. You have to assume that there are users out there who are looking at this on old, crappy monitors and old, crappy phones. We live in this wonderland of technology, but that’s not what it’s like in the rest of the world.

Have you looked at your product on a mediocre laptop? Have you looked at it on a phone? I know we all have CSS that’s supposed to reflow based on available screen size and resolution, but have you actually looked at it, yourself, not in an emulator?


8% of men are red/green colorblind. That’s not even counting the ones who have rarer expressions of colorblindness. Strangely, very few of the men who are colorblind go into design or UX work.

You can tell, because software products CONTINUE to have red/yellow/green status indicators that are the same shape. Guess what? That’s hard on people who can’t tell red from green. A product I worked on recently had nine colors of little dots to indicate the crucial status of monitored items. Only on a beautiful monitor with perfect vision can I tell the difference between a little orange dot and a little red dot.

There are a bunch of online colorblindness emulators that you can use to take a look at your product.

Color Oracle

And I’d like to acknowledge my current addictive game habit, Blendoku, which has some really excellent color-blindness accomodation that just happens to help the rest of us, too. Hurrah for Universal Design!

We are judging your link text and tabbing

Descriptive links take an extra 30 seconds to write, but they keep a screen reader from returning nothing but a sea of identical links which all say “Click here for more information”. It also reassures people that they are actually going to a legitimate site if someone has taken the time to describe the destination.

Consider your navigation in a keyboard/screen reader sense. To test this, unplug your mouse and hide it in a desk drawer for a week. How’s that working out for you? As an example, I tried to tab-navigate this WordPress composition page. I’m pretty grateful I can still use a pointing device, because there are a lot of menu items, they are all at the same level, the tab order is confusing, and I’m not sure I actually got back to the composition page. 

You would be surprised by the number of people who prefer not to use a mouse, or can’t. Who have moved from mouse to trackball to trackpad and are still actively experiencing pain from trying to use a pointing device. I know of at least three senior-level technologists who are using a Wacom tab and stylus as their menu navigation device because keyboard navigation is that bad.

Fix this by setting up a reasonable tab order, allowing people to collapse long menus from the keyboard, and bringing back keystroke shortcuts.

The internet is not of uniform density

Not everyone has high-speed broadband

Not everyone has high-speed broadband

This may shock you, but not everyone has broadband, and not everyone has employer subsidies for their cell phone data, and sending people video that starts without their action is RUDE. There are lots of other reasons people don’t have infinite data or access to the internet. They may not live in a tech city in a developed country. They may not be able to afford that much data on their phone. If you require people have access to always-on data, you are shutting out a huge percentage of the world.

I worked on the Microsoft Server team for a while, and I fought and lost a righteous fight there. Lots of the Windows documentation was moving to an on-demand model which allowed us to update and tune the documentation after the software was released.

That is a pretty cool idea, but there are exceptions. The most important one is that there are lots of servers that should not be connected directly to the internet and need a firewall with pretty ferocious security rules to keep out web traffic. People who run server rooms are not excited about reading web pages from in there. Letting your server touch the internet is like letting it lick a dirty toilet seat.

But because we as a team had always-on internet and no particular firewall restrictions, none of us were feeling the problem of not having the ability to download documents on the fly, so the documents we put on the distribution were sadly minimal and server administrators had to switch to another computer to try and get the help for their problem. But the other computer wasn’t licensed as a server instance. You see the problem.

Because we had access, we assumed everyone did, and because of that, there were a lot of angry server admins who could not get to help that we had actually written.

There are also people who live in rural areas of this country who don’t have cell phone service, let alone any data fast enough to stream. There are people in other countries who are charged the equivalent of multiple days pay for data. We are, to put it mildly, not very polite about this. Maciej Cegłowski wrote a great talk/post called The Website Obesity Crisis. You should read it.

TAB: Temporarily Able-Bodied

We are all only temporarily able-bodied. Eventually, we will pass into the realm of accident, age, or disease. Some of already have and are sitting next to you in the room. We swear under our breath at grey-on-grey websites with grey buttons, or bottomless scroll that makes it impossible to get to the links at the bottom of your page with tab controls.

Aren’t they worth fighting for? Aren’t you worth fighting for?


Accessibility isn’t just about users with impaired vision, and it isn’t about Other People. Accessibility is about building something that people can use without pain or distress.

This blog post is part 7 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Acceptance

This is the sixth fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Have you shown this product to any actual humans who are like the users?

Acceptance is the act of testing your vision against the user’s needs. It’s not about whether the software works, or whether it’s usable, it’s about whether the user thinks it will help them get their work done.

The people you need to get to test it are users. This is not the same as people who you are selling the product to, and it may not be the same as the people you meet at trade shows. These are the people who sit down at their cubicle, or in their fire truck, or whatever they use, and count on their software to help them do their job. Find one of those people. Find five of those people. You don’t need statistical significance for this early stage test, you just need to hear something from outside the echo chamber.

Lego jobs

Not everyone works at a desk

Running an acceptance test

Show them the product. You can use a mockup if you need to, but don’t ask them how they work. Ask them what they are trying to do, and if you already know that, give all of them the same user script for consistency.

Shut up and watch. No, shut up. Don’t help them. Don’t explain how you meant it to work. Just ask them to perform a task and see how it goes. Take notes. It’s lovely to have a big expensive testing center like Microsoft and Intel have, with two way mirrors and cameras, but you can learn enough to be useful with a Webex and some listening skills.

You will come out of this test (probably) feeling ruffled and angry and frustrated with the users. Why would they want to even DO that? Why couldn’t they see the logic of the workflow? I feel like this when I get critiques on documents I have written. I sometimes feel like the feedback is wrong.

The user is not wrong.

The user is trying to tell you what you need to know to delight them, or at least satisfy them, and that is really important to your health as a company.

If you can’t hire an expert, become a student

If you can’t get people to agree to hiring UX, learn how to do it yourself. It’s really difficult to get people on a tight budget to pay for someone expensive to ask users about their feels about the software. It just is. You can talk them into hiring a user interface/front end person, but user experience? Nah.

So you’re going to have to do it yourself. You’re going to have to be the advocate for designing in not just utility, but usability. This is an amazing career-builder, but it probably won’t pay off at your current company. Maybe later.

To teach yourself the fundamentals of user experience, I suggest starting with Kathy Sierra’s excellent book, Badass: Making Users Awesome. Do buy it in paperback — the layout is unique.


There are lots of websites, books, talks, and skywritten messages on specific ways to do user experience, but it all comes back to the same question: am I helping the user do the thing they want?

Other suggested books:

Microinteractions by Dan Saffer

The Design of Everyday Things by Don Norman

Don’t Make Me Think by Steve Krug

The User’s Journey: Storymapping Products That People Love by Donna Lichaw and Eva Lotta-Lamm

This blog post is part 6 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Affordance

This is the fifth fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Affordance is what the interface makes easy and obvious. Affordances tell us all sorts of things about the tiny interactions we have with the world, and with software.

Most people talk about the affordances of hardware, which way your USB plug goes, things like that. But software interfaces also offer us affordances, with a big green yes button and a small grey more information button.

Affordance is making the world encourage the behavior you want

This picture is where I crossed the street to go to work. As you can see, the place that the sidewalk goes does not correspond to either the crosswalk button or the crosswalk itself. This is bad for the grass, bad for the mobility impaired, and a nightmare when the snow gets plowed off the sidewalk and in front of the button. I live in Minneapolis, we measure our snow in feet. In the winter, the crossing button can be literally covered by a plow drift.

This is a bad affordance, but sometimes you are doing this with software design, where you are putting the sidewalk “where it belongs” and not where users need it.

The righteous fight in affordance is to figure out how to make it easier to do the right thing than the wrong thing. Sometimes the wrong thing is depositing your check to the wrong account because the app has tiny buttons on your phone. Sometimes the wrong thing is that it’s easy to harass other users without consequence.  Whatever your intentions for the thing you’re building, users will see it a different way.


One of the things that I classify as affordance is the privilege level it takes to do something. To test this, perform one of your user’s daily tasks.

Now step your permissions down to the level of ordinary mortals. Oh, is that less fun? Are there more hoops and confirmations and things you need to do? Can you even do the job without advanced permissions? Setting excessive security or blocking on ordinary tasks is an affordance and security anti-pattern. It means that people demand elevated access, and makes them and your organization more vulnerable to accidents and malice.

Task frequency

This is a homunculus. It is a weirdly shaped human because the size of the body parts represents nerve density and sensation, instead of physical appearance.

As developers, we often look at things in terms of the architecture, or where the data is. But the user has a really different idea of what is important, what gets used most. Our software needs to reflect what they are actually doing, not what is most logical to us.


Affordance is our opportunity to nudge users into patterns that they will find useful, rewarding, and not hideously irritating. We can only take advantage of that opportunity if we are thinking about their needs as well as our own.

This blog post is part 5 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Documentation

This is the fourth fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

I’m a technical writer, so you knew I’d get here.

Documentation is not state secrets / Documentation is subtle self-promotion

by @davebould

Documentation is not a secret!

I often deal with product and business people who want to put the documentation behind a login. They want to know who’s reading, they want to harvest sales contacts, that information is valuable to them.

But from the user point of view, having to log in is an extra step, one that not everyone requires. If a sysadmin is looking for information on your product, and they can’t get it without signing up to be pestered by sales calls, they may look at another product first.

On the other hand, if your documentation is clear and helpful and easy to get at, then they are half persuaded right away.

User documents are not the problem

A lot of user docs are actually straightforward to retrofit. That’s what I do for a living.

I come in and create all the first set of documents for a product, and the structure to sustain it.

What’s not easy is:

Developer onboarding

Imagine if you had a tax that took 10 developer hours a week for a month.

I’m here to tell you do, you just aren’t aware you’re paying it. It’s absolutely vital for you to add developers as fast as you can, but it’s also pretty darn important that you not bog down the existing developers who are running as fast as they can.

Taking the time to write a development onboarding document is going to save you a lot of wasted coaching time, and means that when your new devs do have questions, they’re interesting and relevant, not repetitive.

Production and build scripts

This is probably not anything you’d use a tech writer for, but you should think about storing that information somewhere safe. It is pretty devastating for a company’s ability to produce builds consistently if the only person who knows how to do it is gone or sick or has taken a new job.

When you hire a build or production engineer, be sure you get some writing samples from them of how they have made it possible to work without their physical presence.

This is the worst place in the company to keep someone cagey and secretive.

Release Notes

If sysadmins and installers and application owners read nothing else, they read the release notes. It’s vital to know if you are going to install something incompatible, or if a release fixes your problems.

People care deeply about release notes and shoving them into an unloved readme is no way to treat the people actually touching your product and setting it up for others.


Documentation, it’s not just for professionals to write, and it’s not just for end-users to read. Build in that assumption from the start.

This blog post is part 4 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Extensibility

This is the third fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

What can you do that would make your product more extensible, more configurable, easier to put into the ecosystem you are trying to serve? I always explain APIs as a sort of Lego connector between a given piece of software or data, and anything else someone chooses to stick on it. Make your APIs standard and DOCUMENT THEM WELL.


You can connect anything to this.

What makes you so sure this API will always be internal?

On a recent contract, we started to create APIs for our internal services. We bodged them together in a really ugly way, with names that only made sense internally, based on dead products we didn’t release. I argued that it would be better to build them correctly, but obviously I didn’t argue enough, and when I left, they were having to rewrite the whole API call structure because an external client had requested access it.

Don’t make future-you mad.

Make future-you happy by designing your product to consume APIs. That way when you get a sudden request to provide APIs for a customer, you’ll know that they work because you’ve used them yourself.

This blog post is part 3 of my Seven Fights series. You can hear me give this talk TOMORROW at The Lead Developer in London (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).


The Seven Righteous Fights: Security

This is the second fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Contrary to what you may have heard, the internet is not actually a series of tubes connected by guys in ski masks. There are bad actors out there, but your product probably won’t attract them right away.

But there will come a time where you have to send out a really embarrassing email to your clients because your waffle-buddies app has been breached and everyone’s syrup preferences have been posted to a pastebin somewhere.

Waffle and syrup

Syrup and waffle in gorgeous light.

It’s expensive in terms of reputation and in terms of productivity, because everything has to stop while you solve the problem.

Security is probably the place where it would be easiest to over-optimize your product without a lot of benefit, because it takes a lot of experience to do security correctly, and that experience does not come cheaply. It would be ridiculous to do a full security audit on an app that doesn’t handle money or personal identification before it is even out of beta.

That said, I think you can think MORE securely than the next person.

How can I be more secure?

  1.  Understand IN YOUR HEART the differences between authorization, authentication, and security. Being confused about it makes you more likely to build something with a serious flaw.
  2. Leave yourself room to perform encryption. It’s probably never a bad idea to start from HTTPS (on ALL the pages). It’s not going to hurt you to use SSL, even between your own services.
  3. Understand what kind of data needs to be protected, and what people can figure out from “innocuous metadata”. Every piece of data you collect increases the threat surface for you and your user.

    HIPAA and other protective agreements shelter obvious things like your social security number, but also less obvious things, like your birth year if you’re over 90. That’s because it is shockingly easy to figure out who someone is with enough bits of “meaningless” data.

Keep less stuff

Plan to delete users and delete data. Even if you flip a bit that disables logins, if you’re keeping the data, you’re the problem.

We grow and change. Eventually we end up dragging a lifetime of data, like Marley’s chains in A Christmas Carol. They are the chains we forged in life, and they never go away.

I want data jubilee.

Don’t reinvent the wheel

Use someone else’s auth* engine. You don’t have to reinvent the wheel, and you probably shouldn’t. This is especially true if you are in a social space or an enterprise space. The IT people installing your system would really rather you just used Active Directory or SAML or OpenID (but really AD) instead of lovingly hand-crafting your own.

Stop saying that word!

(the word is “secure”)

Imagine that a pack of rabid lawyers are waiting to gnaw on you anytime you claim something false. False things can include “we secure your data”.


You don’t have to build something entirely secure now – that’s prohibitively expensive. But do leave yourself the hooks and plans to add security before you have a major incident.

This blog post is part 2 of my Seven Fights series. You can hear me give this talk at The Lead Developer in London next week (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Localization

This is the first fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Are you ever planning on selling this to someone in another country? Or someone who doesn’t speak your company’s primary language?

I’ll tell you right now: Yes, you are.

There’s a big wide world out there, full of people who don’t speak American-flavored English. If you want to reach them and get their money, you’re going to need to speak to them in their language.

Unless you are working for 18F, everyone has the potential to sell their software overseas. Maybe not this release. Maybe not next release. But soon, and you had better plan for it. Hire a localization consultant for a couple days at the beginning of your project and ask them what they wish people would think of in advance. These are the ones I know of:

  • All labels referenced from a list.
  • No words besides the company name embedded in logos.
  • Extended character support baked in.

Hard-coded labels are going to make it very expensive to localize your user interface. Instead of a “normally expensive” translator to look at your labels file, you’ll need to find someone who can use your interface framework, and you will need to do that for every language you want to use. At this point, most people do the work of pulling the labels into a file for reference, but wouldn’t it be great to save that step?

If you have words in your logo, even things like “Professional” or “Edition”, that should get localized along with everything else. That means redrawing/re-rendering the logo for each language, and burning a bunch of artist time.

Extended character support is important so that you can render all the languages you’re going to use, but it is vital that everyone be able to enter their name, the way they spell it. It is extremely alienating to not be able to identify yourself accurately. Don’t make your users feel like you don’t respect their identity at the very beginning of your relationship.

Be careful of:

  • Explanatory videos
  • Humor
  • Fixed-width elements

Videos provide a powerful way to deliver tutorials on a complicated interface. However, even a user who could translate their way through written instructions may have trouble with the speed of video narration.

Humor translates very strangely. It’s very culturally-based and dependent on things like tone, register, and word choice, things that vary with language and culture. A very good (expensive) translator could translate humor for you, but it’s probably best to leave it alone.

Fixed-width interface elements are going to make you cry when you localize. If you want to see why, take a line of English and use Google Translate to take it to German.



File Datei
Settings Einstellungen
Edit Bearbeiten
History Geschichte
Log in Einloggen

Different languages take up different amounts of space!

If you use a few best practices while you are coding up your initial product, you will save yourself thousands and thousands of dollars when you go to release internationally. Localization estimation is complicated, but in this English to German translation example, the lowest price I found was 12 cents a word, and the fastest an average translator can work is about 2000 words a day. If you could translate 200 interface words in one referenced file, or 2000 repeated and hard-coded words across dozens of pages, which would you rather pay for?

This blog post is part 1 of my Seven Fights series. You can hear me give this talk at The Lead Developer in London next week (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Overview

This is a series derived from my popular talk “The Seven Righteous Fights”. It’s not an exact transcript, but I think having a written form to refer people to greatly increases accessibility and gives me room to expand my thoughts in a way that is not compatible with speaking.

There are seven fights that I have over and over again, whenever I start at a company. The more software you build, the more it’s obvious that there are seven fights that it will alway pay to have.

My background as a writer means that I am trained to perform a lot of analysis and synthesis. If I don’t understand the product from value proposition through implementation, it means that I am not the writer I want to be. I call it being a full-stack writer. The problem with having all this training in analysis is that you can’t exactly turn it off. I don’t stay in my lane well, I can’t notice problem that only fall into the narrow category of “documentation”. They’re all documentation problems, they’re all software problems, they’re all design and usability problems.

I’ve worked for roughly 15 companies and my conclusion is that when we create something new, we tend to make similar mistakes every time. This is probably because we all tend to settle in a comfortable stage of product development. Some people prefer mature products, some people like the very beginning and hate the mature product maintenance. But that preference means we don’t understand pain points that happen at other stages.

I’m an early-stage person. I love writing the first version of documentation. I love that green field and that new product smell. But I have done enough mid-stage stuff to know the emergent consequences of early-stage decisions. And like everything you’ve ever read about compound interest, early mistakes compound until they are enormous.

I was working with a startup that was pushing super hard to get their product ready to demo at a big industry conference. They were stripping off every feature they didn’t absolutely need in order to make sure they made their deadline, and I was helping. We made the deadline, there was documentation, and they got a POC contract… with a company in Brazil.

In the process of rushing to get ready, we had stripped out all of the plans to make the interface labels link to a file we could localize, and we had hand-coded all the labels. Now instead of handing off a single file to be translated into Portuguese (and having standard labels that could have been done with Google Translate, in a pinch), we either had to branch and hand-code Portuguese labels or spend twice as long digging into the original code and fixing what we had hacked. I’d love to tell you we decided to do it right, but you all know too much about software to believe that happened, don’t you?

The compounded interest from not using a best practice of referred labels when we built the user interface cost us five days of developer time to fix the wrong way, and two weeks to fix and rebuild the right way. That’s a relatively common example of things people skip and pay for later.

Leaving important considerations “until we get a working prototype” means that it’s going to be harder and more expensive to retrofit. Having these fights early prevents you from doing the software equivalent of poking chocolate chips into already-baked cookies.


Next: The Seven Righteous Fights: Localization

If you’d prefer to watch the talk as I delivered it:
Shortest recorded version: At The Lead Developer 2016

Longest recorded version: At SpringOne Platform 2016