How to Taint Your Brand - Bell's Brewing Edition

Bell's Brewery decided to combat a small brewery named Innovation Brewing, located in Sylva, North Carolina, over Innovation's filing of a federal trademark for the name "Innovation Brewing".  There is no official lawsuit or court proceedings as of yet, but apparently there will be in Innovation does not withdraw its trademark application.

Bell's states that it is trying to protect it's brand.  A quote from their Vice President:

Our concern is with their United States trademark application and potential impact on our brand, which we have spent 30 years building.

As many have noted, the name Innovation appears basically nowhere in Bell's branding.  Do you want some evidence?  Here is a google query for Innovation on Bell's website:

In a nutshell, Bell's is trying to protect... bumper stick sales?  Perhaps future uses of the word Innovation? Ok, sure.

But, if Bell's were truly trying to protect their brand they would have kept their mouths shut and their legal documents in their drawers by realizing that the court of public opinion is is pretty damn powerful when it comes to consumer product consumption.  I can't think of a better way to tarnish your brand than by enraging the community you were originally built to serve - and craft beer drinkers are a sympathetic community to the small, grassroots breweries that Innovation currently is and that Bell's Brewery once was.  To turn against another brewery, who is not even a direct competitor to you, over something as petty as the use of name that happens to be a single word that appears in a slogan you barely use is on par with the legal shenanigans of InBev(1).

Bell's was subsequently slaughtered on social media for being a bully and rightfully so.  I've personally boycotted their products since the legal challenge began.  I hope "protecting" their brand was worth it.


  1. Bell's isn't the only brewery guilty of this.  Lagunitas and Sweetwater are also other larger craft breweries that come to mind that engaged in silly trademark/copyright disputes, though Lagunitas had the good sense to withdraw theirs after they were equally lambasted the way Bell's is now).

IRC as a Hiring Filter

Resumes:  StackExchange certainly believes it should be used as one, as it has a monetization strategy in its careers site, and I've heard more than a handful of times that your Github account ought to be your resume.   Both websites are extremely useful for evaluation in addition to the typical resume and in-person interviews in hopefully determining what kind of skill and/or talent one might have for a professional programming position.  Though, were it possible, I personally would rather see the logs or of a potential candidate from IRC networks and channels centered around discussing programming - freenode being the prime network for this and the one I use, though I knew others exist.  

I realize this is almost entirely hypothetical as many folks in our field do not bother with IRC for multitudes of reasons.  However, if I were trying to scour the Internet to find a potential hire as a developer, I'd argue that if one could view a potential candidate's behavior and displayed competence on IRC programming channels, then it would be more useful in ways that that Github and StackExchange may not provide.

For starters, IRC itself is a bit of a technical shibboleth in ways that differ from at least Github.  Depending upon the choice of IRC client, in order to actually join a channel you would have to figure out how to get a client to connect to a server, likely register yourself with a nickserv, and figure out how to list out and join channels.  Many clients hide this behind nice GUIs and menus, but it's still a bit of a ceremony when compared to more recent chat systems.

If you believe that alone is silly criteria and that any monkey could connect to an IRC server, consider that in the past a former colleague and I have actually decided not to work with specific developers before in a professional setting partly because they literally could not figure out how connect to freenode and join a keyed channel that we had already established months ago for work.  They instead wanted to use email and Skype for our work, which are both wretched for team communication.  Let that sink in for a moment – if a person's or team's stated skill set matches all of the criteria  of being technically competent, but then they lack the persistence or savvy to even use to one of computing's most useful and enduring communication protocols, especially given how easy it is in modern graphical IRC clients, then do you really want to depend on them when it comes to delivering professional software?  

Taking the point to a logical extreme, you can deduce a baseline about how technical and curious a person is based on their choice of tools for IRC.  The response of `/ctcp $nick version` may end up being the name of a bouncer or a command line client and you can probably assume this person is going to be very comfortable working out of a terminal shell, which is itself a merit one should place much weight in.  You may eventually find out the person maintains/develops an IRC bot or is making use of or writing plugins on their client – though getting this deep in to what tools a person uses for their IRC experience may be taking the technical aspects a bit far beyond what is useful. 

Truly though, that's not where IRC's strength in evaluating a future teammate is.  Github's technical requirement of actually using git for contributions, which I'd argue is actually more difficult, makes it better in this regard.  Where the fun really begins with IRC is watching a person interact on an IRC channel:

  • Do they know how to ask questions to actually get answers and what is the nature of their questions?
  • How well do they help other people with their questions?  Do they spoon-feed answers or 'teach a man to fish'?
  • Do the openly discuss their choice of tools, libraries, and design decisions?
  • How do they handle others' trolling?  Do they themselves actually troll others?
  • Can they communicate well enough in text?  I mean full sentences with complete thoughts, without aolbonics, coming across like a college-aged stoner, and without hitting enter every fifth word. 
  • How well do they adapt to the culture and (unwritten) rules of a channel? How much do they influence, in a positive way, the discourse of a channel?

If the above sounds like unnecessary and contrived analysis from what is ultimately a chat room, substitute "workplace" for "channel" and then rethink the importance of knowing these things about a person you'd consider working with...

Question Answering and Asking: The first two bullets are pretty damn insightful in to how much of a self starter a person is, how they reason about problems, and how they go about solving them.  A potential coworker may be dead weight on your team if they are the type to continually ask a questions on IRC without first using a search engine, trying to answer simple questions themselves by asking their interpreter/compiler, or attempting to produce a SSCCE.  The lack of doing at least one of those three things shows a complete lack of respect for the time, attention, and mental energy of those around them and is indicative of selfishness.  Conversely the person who tends to ask questions in a smart way, jumps on the difficult to answer questions, and provides thorough and guided (without handholding!) help to newcomers is going to raise the tide for all around them.

Open Discussion: Is a person on IRC discussing new tools and techniques and interested in learning new things - irrespective of their present skill?  Do their preferences in tools align with what is both relevant, productive, and useful - or perhaps what you already use or wish to use on your projects now?

Trolling: Trolling is a bit of an analogue to passive aggressiveness and/or sarcasm - both of which are poison.  It is a no-brainer to avoid people who act and speak in those ways, but what is equally important is to avoid people who waste time feeding such behavior and becoming, at best, distracted by trolling behavior.

Speaking Intelligently:  It's a perfectly acceptable thing to be prone to misspellings or perhaps not being great at typing English because it is your Nth language.  However, one thing I've anecdotally observed in reading the text of others that the ones who have to abbreviate "you" as "u", "question" as "q", "because" as "cuz", and type in such a way that leads one to believe they are text messaging are generally people who tend toward sloppy and often unnecessary shortcuts in most things outside of talking in text based mediums.   There are exceptions to this rule, but in my few years of helping out and learning on freenode, this has been generally true.

Adapting and Influencing:  Can a person shift just enough to make themselves fit into a culture and can a person actually influence the behavior of others?  Every workplace has its norms, for better or worse, and so does each channel.  One can't know with a day or two interviewing if they truly will fit in to a place.  Further, workplace environments shift, management and coworkers often change, work pressures increase and decrease.  Is a person adaptable when change happens and there are new people to work with and new situations?  Can they positively influence their environment when it's new or when it changes?  If a person can /join a channel, ask a question, and help others, adapt to the rules of a channel that may have hundreds of people in it, then that person can probably fit in at any workplace they wished to join. 

Yes, you could possibly glean some of these things from Github, StackExchange, and others, but I'm of the opinion that such assessment is tarnished to the degree that I can't evaluate truly what kind of person I'd be working with by viewing their behavior on those platforms alone - so in that respect, they are just like a resume in that they don't tell me the whole story.  Those platforms are their own cultures with their own rules and are gamified to a large degree by the owners of each platform. 

So yes, IRC is a bit of the Wild West by comparison, but when judging a person with whom you'd like to work with, it would be truly interesting to see how act when such an environment around programming peers only and when there are not as many rules to follow.  You can observe with much greater precision who, as a person and not necessarily a programmer, you are dealing with.  That could potentially tell me much more about who you are than your Stackoverflow points or your Github profile.


Note to Readers Who Viewed the Original Post:

I made significant edits to this post four days after it was posted.  I originally wrote this to dump my thoughts I had during one caffeine induced morning helping out newcomers on IRC after having the day prior discussed the usefulness of IRC and considering how people like the cliche of "github as a resume".   The goal I intended would be to share my thoughts on how useful the medium is at identifying talented brains in programming that would also make for compatible coworkers. It helps to know my first full time developer position came from being identified from helping other newbies on a freenode channel.  When I refer to IRC I'm specifically speaking about IRC channels and/or networks dedicated to discussion about programming languages, open source software, and computing in general - freenode being the most well known of those.  And yes... there are probably a few orders of magnitudes more talented brains not on IRC, but the signal to noise ratio when trying to find them on the proper IRC networks/channels is a bit lower. 

I passively watched discussion about the original post without engaging.  I didn't realize the reaction would be quite as passioned as it was. Nor did I believe it would get as much attention as it did (8k views in a day is actually quite a lot for my writing).  There was a miscommunication in what I ultimately meant to convey , and that miscommunication lead to undertones of elitism.  

Human communication is a shared burden, but that burden is more heavily weighted on to the sender.  I pondered why the reaction was the way it was and concluded that 1) I may actually be insensitive in subconscious ways I did not previously realize 2) I'm a rather poor writer and choose very poor words (see overuse of 'prick') to describe my ideas.   I wanted to start writing again for that type of self growth - so that I may become a better writer and expand my mind through outward communication to a larger audience than friends/family.  That is why I have edited this post. 

Why Open APIs Should Have Limits

A few months ago I happened upon an interesting post on InfoQ summarizing a debate on rate limiting and throttling on public APIs and their effect on innovation around such APIs.

As someone who has worked on publicly consumable APIs and is now focused on an internal (for the moment) API that gets hammered by other internal services, I can outright say that the owners of APIs are correct in this argument that hard limits need to be in place.

An organization who is exposing an API will typically only do so when there is a perceived business gain of opening their data and functionality for 3rd party apps to take advantage of. Such apps will only be written if there is utility to be gained by actually consuming that API. It’s a business partnership without money being exchanged. The partners are the provider of the API and the developers writing applications consuming that API. It’s a nice symbiosis that end users ultimately benefit from.

However, when such a partnership becomes too one-sided it behooves the short side to alter the deal. Without limits on the API, simple game theory will tell us that API consumers will use the API as much as they can irrespective of what that means to system providing the API.

However, if you are the provider you must ask yourself why would you ever let your system arrive in a state where it can be abused in the first place? Unless rate and access bounds on an API exist, the users of the apps written to those APIs will hit bounds anyway - except they will be technical bounds in the underlying infrastructure that would result in a denial of service instead of arbitrary but reasonable usage bounds. Applying back pressure is a useful tool in many aspects of software architecture, and applying back pressure by imposing rate limits at the API tier is one such aspect.

There once was a great Stackoverflow podcast where Jeff Atwood discussed their ultimate conclusion that enforcing bounds on everything is absolutely vital. Below is a snippet from that transcript:

Atwood: Well I look at it this way, if somebody is going to design a system like StackOverflow, asking “how do I design this?”, I would say look, you've got to bound everything. From day one. Just put in the boundings, because we didn't and, you know, I kind of realised we'd have to do some of it but I didn't realise how pervasive those boundings would be, like in every aspect of what we do there's boundings in the system that you have to have.

Spolsky: So the system is counting basically.

Atwood: Yeah you're just making sure that nothing happens too much. Because if anything happens too much it's just bad. It just leads to really really bad things happening, both from the reputation system to the scoring perspective to the hardware perspective, it's pervasive throughout the system.

If your system depends on implicit bounds that aren’t technically enforced, your users will inevitably find a way to exceed and exploit those bounds to their individual advantage and perhaps to your detriment and detriment to other users.

Unintended DoS from greedy API consumers and a user gaming a question/answer voting system to gain a gazillion points in a day have a common root cause: failure to enforce constraints.

In order for innovation around an API to occur, the API in question must have reasonable availability guarantees that probably involve a number featuring three or more 9s. Imposing no usage limits would make such a number even more difficult to achieve than it is already, irrespective of the talent and resources of the provider.