500 Lines or Less is available now

For the last two-and-a-half years, I’ve been editing and producing “500 Lines or Less”, the 4th volume in the Architecture of Open Source Applications series. I’m excited and relieved to announce that it is now generally available.

I hope to be writing here (and elsewhere) a bit more now that this project is over. However, right now I’m just going to stare at the ‘buy’ page for a little while, and feel good about this.

Thanks to the zillions of people who helped make this possible. I have never worked on a project that involved so many contributors before, and in addition to making the final product a lot better than it would have been otherwise, it was also a great feeling.

Raising Money for your Regional Event – Part 1

Ever since we ran the first PyCon Canada in 2012, I’ve had many conversations with would-be organizers about how to raise money for their own local events. In this series of posts, I’d like to discuss some of our approaches to attracting sponsors, as I feel like this is one of the biggest sources of trepidation for first-time organizers.

Before we begin

I’m going to assume that you’re planning an event that would be considered large for your region. By ‘large’, I’m talking in terms of headcount, duration, or both. (If you’re running a single-day event for a small group of people, I will discuss strategies for that in a later post.)

I would also assume you’ve come up with a draft budget for your event. This is obviously important, but I’m not going to say much about it here. Two things that I will say about budget/sponsorship interaction are:

  • What your event costs to run and what sponsors are willing to pay are only loosely correlated. That is, running an expensive event does not mean that sponsors will want to pay a premium to participate. If this is your first event, control costs as tightly as possible until your sales start to come in. That means focusing on the most vital parts of the experience first.
  • I would be pessimistic about how much money you will raise, and then work as hard as you can to prove yourself wrong. Assume 25% of your leads will buy; assume 75% of those will actually pay you. PyCon Canada was very lucky with this — every single one of our sponsors paid us on time — but we were prepared for the worst.
  • Being pessimistic is useful even if you end up hitting all of your sales targets in the end, because most sponsors will buy in very late in the process. (Both PyCon Canadas raised 50% of their sponsorship money in the 6 weeks before the event.) You will need to spend money long before that, though, so it’s good to get used to operating on a tight budget. Any money left over after the event can be used as a bootstrapping fund for your next one — you were intending on making a habit of this, weren’t you?

    So where do we start?

    In my experience, most organizers start by designing a prospectus. I personally feel that this is the wrong approach, especially if you are simply looking at your budget and then working backwards to make sure that your pricing matches the amount you need to raise. (See my comment about your budget and what sponsors can pay being loosely correlated.)

    I would suggest thinking about what unique aspects of your event will be attractive to sponsors. The bulk of my experience is in developer-focused events, where sponsors tend to be interested in some subset of these three things:


    What sorts of devs will be attending? Are you going to attract devs who don’t normally come to the region? What is the region in question? What defines its boundaries?

    Selling services (hosting, infrastructure, PaaS, IDEs/devtools, etc.):

    For services and products that sell B2B — will there be decision-makers in the audience? (i.e. people who control budget.)

    For services that sell directly to developers — what sorts of devs will be there? Are they people likely to use or champion our services?

    External press for these companies is also a big thing, so think about what unique channels you have there as well. Are any of your public-facing organizers popular community figures? Will there be press releases or dev periodicals reporting on the event?

    General branding:

    There are some forward-thinking companies out there who want to be involved and associated with cool things that are being done differently than the status quo. Even if your event is pretty standard in format and content, think of things you’re doing (or could do!) that would tie in well with what you know about these sorts of companies.

    Reaching out

    Once you have some idea of what makes your event a special snowflake, think about the companies in your area (virtual or physical) who you are best connected to, or who are most likely to be interested based on the factors above.

    If you’re running a regional conference, I think it’s better to win local companies as early adopters. If you can convince them that you’re going to attract a pool of potential recruits or sales leads who aren’t normally in the area, you can close them early and use that success (and money) to keep you going while you try to approach the bigger players. The best early leads, in my opinion, are the small-to-mid-size companies where you can reasonably talk directly to the founder, CEO, CTO, etc. and convince them that your event is worth investing in.

    Got that list of companies down? Great. Whatever you do, do NOT send them a prospectus yet. In the next post, we’ll discuss how you can use some initial sales calls to get early feedback on some of your ideas about pricing.

3 Mistakes I’ve Made When Starting Up (and will probably make again)

I have the privilege of meeting a lot of highly effective people who are early in their career, and in the process of joining a new company or team. One of the most interesting parts of this experience is watching them make the same mistakes that I’ve made when I’ve been in the same sitation before.

Here are the top three that seem to jump out at me the most often:

Conforming to the average schedule of the team

I’m naturally a morning person; if I haven’t started on something productive by 6:30am, it’s going to be a bad day for me. As a general rule, I like to have my most important work done by 11am.

Some of the most unproductive times in my life have been when I let myself be dragged into the work schedule followed by the rest of my team. I definitely think it’s important to have 3-4 hours of overlap in working hours, but I often see people new to the game sitting around on their laptops “reading articles” way past when their brain has shut down and they don’t want to be the first to leave.

I learned to fight that urge. I still lose the battle once in a while, though, and I always pay for it the next day.

Refusing to set boundaries

When you first start on a new project or join a new team, there is a period of time where you’re learning what everyone else’s working habits are. It’s tempting to be “on call” all the time during this period. This can mean allowing interruptions at any time, or being connected to email / IM from the moment you wake up until the moment you go to sleep.

It’s also very easy for this “adjustment period” to stretch onwards into infinity.

This is another thing that has been disastrous for me in the past. I’ve actually found the inability to set “do not disturb” times during the day to be even worse for me than staying having to stay connected all night, since the former often necessitates the latter.

I’ve also found that certain personalities won’t ever respect these boundaries. It took me a while to accept that this is my problem, not theirs, in the sense that trying to change someone like that is going to be a fruitless battle. I’ve had this behaviour crop up in supervisors, clients, etc., and I’ve had to develop strategies in each case for dealing effectively with such people. This is a whole topic on its own, though, so I’ll leave this one for another time.

Trying to change things too drastically, too soon

Here’s a scenario I see pretty often: Let’s say you’re an engineer who has had the opportunity to learn the best engineering practices from your previous job experience at places like Facebook, Google, Twitter, etc. You decide to join a smaller company with maybe 10 engineers on the team where you can “make a greater contribution.”

So you sit down on the first day, check out the code, and build it… only to find that the build is a manual, 7 step process. All the “unit tests” are broken, but still take 16 minutes to run. You take a deep breath, go to your first scrum meeting… which drags on for over an hour.

And so on.

If you’re especially optimistic, your first instinct might be one of elation. “I have so much I can help them with!” you may think. And it’s true; there probably is a lot you can help them with.

But not right now.

Unless you’ve been specifically tasked with the job of “fixing things”, take your time with it. Get to know your teammates first. Go for coffee or lunch with them; learn about their lives as human beings first, and as coworkers second. My general rule of thumb is that I’ll know I’m in a position to tentatively suggest real changes to someone when I can first comfortably call them an asshat and not get in trouble for it.

I’m sure there have been exceptions to this rule in the past, but I personally haven’t witnessed any. Trust has to come before change. If only I’d learned this a decade ago, I could have my past teammates and myself a lot of unnecessary angst.

I know I’ve made these mistakes before, and I’ll probably make them again. But at least next time around, I’ll recognize when it’s happening.

Python’s Optional Parameters and the Perfidy of the Human Spirit

I wanted to briefly comment on something I’ve observed myself doing that I consider to be an antipattern.

Let’s say I’m knee-deep in that swampy mire known as Someone Else’s Code. I’m working on a search service that has this API:

class SearchService(object):
    def search(self, query):
    # Mega complicated stuff follows.

I need to change this method to be aware of the content-type of the media it returns.

OK, let’s go see how often this thing is used.

~$ ack search_service.search
<.. SPEW of 86 distinct invocations of this service method>


I pick one of those service calls and crack open open the relevant buffer:

def viewThatHasNoContentTypeInfoWhatsoever(request, query):

Even better — now I have to figure out how I’m going to get the content-type information I need to the service I’m calling here.

And there are 86 more of these to go.

So now I’m sitting here thinking that the job I initially thought was going to take 5 minutes is probably going to take much longer.

So what are my options?

  1. Make content_type a required arg on the search method and just deal with the upstream changes.
  2. Refactor the parameter list to search to take a SearchParams object that encapsulates the parameters that are required for a search.
  3. Create a different, content-type-aware method on SearchService, since this is a conceptually different search, and use that instead.

1 and 2 both require changes to all 86 call sites, but at least 2 is a bit more future-proof. 3 just seems like it’s asking for an explosion in combinatorial complexity on that service interface.

This is generally the point where I begin to consider option 4, which is to make content_type a keyword arg with a reasonable default.

Great, right? This is a “minimally disruptive change” — I’m guaranteed not to break any client code, which is good because our test coverage is low and I’m not confident that I’ve even found all the relevant call sites.

The biggest problem I have with this is that it’s a terrible idea.

If this feature was being designed for the first time right now, I’d probably decide there there is no “reasonable default” for content_type at all, and I’m thus fragmenting the interface to the call at the intersection of version n-1 and version n.

New developers on the team aren’t necessarily going to be aware of the entire release history of the project, and so seeing media_type as an optional parameter will suggest to them that this is just a minor detail of the interface, where it is actually just as important as the querystring itself is.

I wonder — do you ever catch yourself being similarly lazy? I feel like this technique might actually be a good first step in getting hooks into legacy code for some preliminary unit testing before elevating the parameter to first-class status and making the upstream changes, but that’s only valid if you’re committed to making those changes in the first place.

In the meantime, I’ve forced myself to assess my motives carefully each time I add an optional kwarg to a function or method in Python. (Constant vigilance!)

Why It’s Hard To Learn About Domain-Driven Design (or any other kind of design, for that matter)

I’ve recently been revisiting the books I read on Domain Driven Design a few years back when I was just getting my feet wet with the literature in that area. (These two are my favorites so far.)

In the first couple of chapters of the canonical DDD book, Eric Evans opines that developers are often very happy to tinker with a new technology, a new design pattern, or a new process, but they are usually unwilling to invest effort into the actual business of modelling the core concepts of the problem domain itself.

He continues by talking about how projects where even a few of the developers were not invested in this process meant that the effort was largely wasted, and that productivity stayed more or less constant despite the enormous effort poured into the modeling process by the rest of the folks there.

This isn’t particularly surprising to me; there are a variety of reasons I can see as to why your average developer would be more excited about adopting a new library to make cloud deployments easier, or adding a new code review process or the like to their dev teams repertoire of practices:

  • There exists a lot of documentation and material that one can learn independently from.
  • The effects are seen pretty much immediately (whether for good or for bad).
  • Credit from the organization can generally be traced to the originator of
    the practice
  • It’s a unit of work that can be done on e.g. lunch breaks, spare time, on
    the transit ride home, etc.

Building a rich domain model, on the other hand, bears very few of these favorable characteristics. Why not?

  • Practicing it independently is not all that helpful, as a domain model is
    only provably robust when a variety of developers and domain experts can use it
    to improve communication and productivity in the team.
  • You rarely see the payoff until the middle-to-late stages of the project,
    and it does generally slow things down at the beginning.
  • Because buy-in from the team is required to make it effective, there is
    rarely going to be a single person who is going to get the credit for the
    initiative, and so the risk/reward is diluted across the team.
  • It takes long, concerted bouts of practice to get good at it (preferably in
    the presence of people who have done it well before.)

As I was thinking about this in the context of Evans’ book, I realized that these difficulties prevent experience reports on DDD from being communicated effectively in the developer community at large. In addition to my involvement in PyCon Canada, I have also been involved in a variety of meetup groups in Toronto, San Francisco, and Vancouver that are focused on code quality and best practices (e.g. Code Retreat, Agile/XP groups, clean coding groups, etc.) And yet, I don’t think I’ve ever heard a talk on how a team switched from Approach X to development into a tight focus on creating a rich domain model, and what the subsequent consequences were.

Again, one can imagine a variety of reasons as to why this would be the case.

  • There are probably relatively few developers who have even had this experience before. (Evans was possibly the first to write a book on it, and even he only had 3-4 examples to show off in the first few chapters. Half of them were failures.)
  • Some prior experience with the domain itself is required to benefit from the discussion, which necessitates a significant introductory component (which has the potential to be boring.)
  • Since the benefit of DDD is generally seen in the long run, the speaker would have to condense an enormous window of experience into a single talk.
  • The amount of work it would take to address the topic properly (choosing the appropriate level of depth for each part of the discussion) is daunting.
  • Many people with real-world experience in this space are prevented from talking about it due to NDAs, etc.

Nonetheless, this is the sort of talk that I would love to see attempted more
often at any general technical conference. The closest that I think we get are
focused refactoring sessions like this recent (awesome-sounding) talk from RubyConf AU.

I am going to play with creating some ‘artificial’ DDD scenarios that are in problem domains that are more likely to be familiar to developers, much like Vaughn Vernon did in his recent book.

In the interim, if anyone out there has seen an effective talk or presentation on a project that used (or better yet, was refactored to focus on) a rich domain model, I would love to see it!