Welcome to Addison Joy

by jesse in

IMG 2514

Addison Joy Noller;  Born 11:50pm June 2nd - 19 3/4 inches, 7.8lbs

Yup, as I mentioned in On Family, Cranking and Changing - we've been in the home stretch of completing forking our second child process - Addison Joy Noller. Everyone who is crazy enough to be following me on twitter saw me "live tweeting" the events on the second. Interestingly, sharing it with all my friends and acquaintances made the difficulty and frustration and other crud that much more bearable for me, so another huge thank you to all of you who reached out to me there, and in private to give my wife Dusty and I well wishes. It meant/means a lot to our entire family.

Despite all of the problems, complications, hospital stays pain and risk, my wife and Addison are doing amazingly well, and we're already at home. There was a lot of very trying things leading up to this, and up until the moment when Addison finally joined us, there was a lot of fear and anxiety surrounding this. Birth can not just be risky for the infant, but also for the mother, and we has risk out the wazzoo. I think all of my Java programming knowledge was replaced with intricate knowledge of various pregnancy related complications and methods of managing a strong-willed child.

IMG 2557

Big Sister giving the thumbs up of approval.

That's all behind us; new challenges await - figuring out feeding/sleeping schedules, teaching our beautiful four year old who is incredibly excited to be a big sister how to be a big sister, figuring out the little 7lbs enigma sitting next me in the crib. Hopefully she'll like me reading K&R out loud to her as much as her big sister did. The entire process of birth, despite thousands of years of human evolution still remains a mixture of science, the unknown and a lot of guesswork. I know the term "it's a miracle" is beaten like my four year old's drum, but it really is a miracle - the amount we don't know and the amount of guessing that goes into the "process" is astounding and humbling.

Time to break out the Boppys, sanitize the bottles and explain to my pug what the heck this beautiful little creature is here in the bassinet. Maybe later she'll let me finish my blog post on vim and mow the lawn. Or we might just sit here on the couch and chill out. It's amazing how far we've all come since this post for my first daughter in 2007.

Obligatory Flickr set here.

Python Debugging; Embarrassment, Contracts and Nothing is private

by jesse in , , ,

Random links

(photo courtesy of Sean MacEntee via flickr)

Some interesting bits and pieces (leftovers) from the weekend - I have a tendency to queue up a pile of "read later" stuff or emailing myself a pile of things to talk about/link to/etc. Sometimes, I actually get to go through it all. Today - I get to share it to!

First up - Michael Foord (fuzzyman) did two excellent posts - the first is on privacy in Python - not big-P privacy, but rather the programming/object privacy. It's a good read because it reenforces the point that even if you think you're being clever and hiding something in a closure to make it private, you can still get access to it. Remember too - dunders (__foo) are just name-mangling. In Python, nothing is private (insert bad tasting joke about Python being facebook here).

Michael's second post is on the NamedTuple kerfluffle that was stirred up Kristjan Valur's post on the use of exec() and namedtuple (short version: namedtuple creates a string defining the class and then calls exec to create the object. I think Michael is spot on - I think exec() gets a bad rap frankly, sure - it's something of a hand-grenade, if you use it wrong, you're going to get hurt, but in this case I have to agree with Raymond in his comment on bug 3974 - the current implementation is clear and maintainable. I don't like the sternness of the reply - but he is right. Kristjan's use-case is an interesting one, but I don't think it's one that warrants the removal of the existing implementation. I'm wondering if a "fallback if exec doesn't exist" is worth inclusion.

Then again, I've spoken to people who refuse to use namedtuples because they now know how the sausage is made. I still think the sausage is delicious.

Next is a pretty interesting discussion on a presentation that came out of Pixar on getting over embarrassment in order to get things done - I don't have much to add above the comments on hacker news, except to say I think the same mental blocks they talk about for animators apply to programmers, writers, etc. We hide from code reviews, we hide our writing until we think it's "Pitch Perfect" - when in reality, we shouldn't. We should be sharing, discussing and collaborating earlier, more frequently and more often.

Share and Ship early and often - see also "Don't Go Dark".

Finally, I was happy to see the "Quick and Easy Debugging in Python" post from Jeet Sukumaran - it's always nice to evolve past sprinkling print fairy dust all over your code for debugging - even if we all still do it despite knowing or using PDB. Just to add to his post, if you want to increase your PDB-Fu, I recommend this "Debugging in Python" post by Steve Ferg, and the official documentation for PDB. We should really add a HOWTO for this.

p.s. For additional good-reading, check out "Priorities Don't Exist in a Vacuum" and "First Care"- while not germane to what's I've already written about, they're a good essays on priorities. Thanks to the latest "Back to Work" podcast.

PyCon: Everybody Pays

by jesse in , , , ,


There's been some recent discussion about DjangoCon(.eu | .us) and whether or not speakers should have to pay for admission as well - see Chris Wanstrath's (of Github) tweets (here and here) and this Convore thread for examples. Obviously, as PyCon is the "big dog" so to speak for Python conferences, everyone looks to "us" for a model to work from, or how we manage things. I've seen a lot of poop slung towards the DjangoCon organizers, mainly due to a lack of knowing "why" certain policies (such as "Everyone Pays") exist for DjangoCon, PyCon, and other conferences.

As co-chair and program committee chair last year, and program committee chair the year before, and now chair for the next two years - I figured it might be good to take a moment to explain the rationale behind PyCon's approach - as well as some statistics about the budget. I'm not going to state that this policy is perfect; nor that it won't be changed; I also will not release the budget publicly - I don't think giving everyone a spreadsheet without the context of the hundreds of man hours of work that go into it is useful, at all.

Important Note: PyCon is organized and managed by the Python Software Foundation - this means that, as part of being a 501c3 charity, some of the financials from past PyCon is available as part of publicly accessible financial documents of the foundation. You can find those on the PSF's site.

The same reasoning may not apply to a conference that is organized by a commercial entity or is done for profit. OSCON is a commercial conference, so having speakers get in free is generally expected. DjangoCon.us is in the middle - it is organized for profit by a commercial entity, but it also contributes heavily back to the Django Software Foundation. DjangoCon.eu is managed differently as well.

Policy and Financial Aid

First, what is the "policy" - well, first, it's not a policy per-se; it's part policy, and part tradition. The policy is "Everyone pays for a ticket" - attendees, tutorial presenters, organizers (meaning: all volunteers, including the chair) and sponsors - everyone pays their way. Yes, this means Van and myself both paid for our own tickets to attend. Everyone is treated as equal - sponsors get free admissions as part of conference sponsorship packages, and keynote speakers may be provided with either compensation or admission depending on the negotiated deal (some keynote speakers cost money, for example).

Now; an interesting aspect of this is that PyCon, as a conference, offers a very generous financial aid program - this means that some attendees, speakers, tutorial presenters, etc have some, or in rare cases, all of their expenses such as flight, hotel and admission provided to them from the PyCon budget. PyCon goes out of it's way to encourage people to apply for financial aid - even if we can't cover all of your expenses, we will give you free admission based on need. The FA application process is simple, and straightforward. It's also very liberal - the only caveat is that speakers at the conference "get bumped to the top" of the applications so that we don't lose a good talk because of financial need. We also don't ban anyone from applying (for example, I needed assistance in 2010 even as the PC chair).

We use the FA budget to not only help the "normal" attendees of the conference, we also keep an eye towards diversity - for example in 2010 we had a specific grant program (funded by Google) for women to attend PyCon - which they did in amazing numbers! We also try to help more people with less money than less people with more money - we want to spread assistance out as much as possible. This is why FA requires room-sharing at the conference hotel, this is why we may only cover part of a given applicant's costs - we want to help more people.

As you can guess - since financial aid is a part of the budget, we allocate a set amount of money to this - but, without a solid budget (meaning, admission ticket sales, sponsorships, etc) we can't have it - it's actually a dice roll. We can guess at how much FA we can carve out of the budget at the start of the process, and we will award that amount - but that means if we have low attendance, don't book enough rooms, or our catering costs spike, or lack sponsors, the conference can lose not insignificant amounts of money helping people. The rub being, you don't know for sure if this will happen until the conference actually happens.

So, how does "everybody pays" play into this? In two ways. First, it helps hedge our risk, institutionally speaking. PyCon had a good/bad year in 2009 - good for the attendees, but horrendously bad financially. We made various commitments in 2008 just as the markets were peaking, and we lost a lot of money when everything went south. Since then, it has been our budget policy to make sure that our revenues will cover our hard costs even if there is a 15% dip in attendance and a 35% dip in sponsorship.

Second, you may have guessed that the "everybody pays" policy allows us to pad the financial aid budget. This has the direct benefit of bringing more people to the conference, increasing the diversity of people attending, getting a larger proportion of the community together, etc.

I'm happy to say, that on most years, we very happily break our financial aid budget - meaning, if we have a positive outlook, we will gladly overspend on financial aid and take less "profit " for the conference. The point of the conference is the community, it's not about the conference! We help the community as much as we can by helping to cover the costs of people who would not otherwise be able to attend.

History and Tradition

Once you start organizing a conference you start to rapidly realize how costly things can get - and if you don't have sponsors with giant bags of money, or the conference is not being run for profit (such as OSCON), you can quickly get into trouble if you don't have a policy in place that will ensure financial viability. PyCon came from very small, humble beginnings but has grown year over year consistently - maintaining the "everyone helps, and everyone pays" tradition originally set forth.

It is my understanding that the policy/tradition has as much to do with financials as it does with "the feel". No one is treated specially, we - meaning the community - put together the conference, we are taking the financial risk that comes with it. We are in it together, and that means "everyone helps, and everyone pays" - it is the most equitable solution that helps us maintain fairness and the flavor/feel of the conference. When you realize that even Guido has to buy a ticket (even if it was paid for by Google) or that Van Lindberg had to buy one - it suddenly makes you realize that all of us truly believe in the spirit of "we are all in this".

Speakers; as a an additional guideline, while always paying for a ticket; always pay at the discounted early bird rate no matter when they register. So yes, we do discount them, but no more than anyone else who registers within the early bird window.

As an aside, the "everybody helps" is also part of what makes PyCon special. When people come to other conferences, they frequently come expecting to be coddled and catered to. When people come to PyCon, we hope they come expecting to contribute. Having everybody contributing is at the core of the best parts of PyCon - from stuffing bags, to lightning talks, to the wonderful Testing in Python BOF.

Hard Costs, Stats and Risk

So what makes up a PyCon budget? Well - Van covered some of it in his wonderful "Behind the Scenes" post for PyCon 2011 - but in more detailed terms of percentages of the total costs for the budget:

  • Catering (Food, beverages): 54%
  • Networking: 5%
  • Audio/Visual and Video Recording: 13%
  • Payments to Tutorial Instructors: 6%
  • Misc/PR/Sponsors and Administration: 16%
  • Swag: 2%
  • Financial Aid: 4%

Catering, plus Financial Aid and video recording is 70% of the budget alone. The total value "spent" for financial aid alone well exceeds 50,000$ We spend a massive amount of money for audio/visual and the video recording making all of the talks available on the web (see the python miro community). Tens of thousands of dollars spent on networking.

We could forgo feeding people - but with a conference that runs from 8am to 6pm for 5 days, that would suck - and people needing to leave to get food would be disruptive and ruin the flow. We could forgo recording the videos. We could do a lot of things to cut back and lower the budget numbers so we could give more away (such as comp'ing speaker tickets), but that doesn't make the risk and costs from the hotel go away.

  • Average Revenue per attendee: ~$300
  • Average Cost per attendee: ~$465

In total - these costs (for 2011) came to well over 600,000$ - that's right. Over half a million dollars in hard costs for a conference of 1,380 Pythonistas. Much of the payments, guarantees, deposits, etc have to be put down up front of the actual conference with no guarantee that we will make our sponsorship or attendee numbers. That means, in the case of PyCon - the Python Software Foundation fronts potentially hundreds of thousands of dollars in payments and risk. We also expect these to climb with the move of the conference to Santa Clara.

Conferences are unknowns - you put up a lot of time, energy and money - lots of money - and you hope you hit certain numbers. For example, you make a contract with the hotel that says "we will have X number of people book X number of rooms nights" - if you don't meet those numbers? The hotel penalizes you a stunning amount of money. You make a contact for catering - saying that you will serve X number of meals - and if you don't hit that? You get penalized. You put a lot of faith in making numbers on:

  • Sponsors - without corporate sponsors, we simply could not exist (at this scale), period.
  • Attendee Numbers - You expect X number of attendees, broken up into "corporate, individual and Y" rates - corporate rate tickets are where you make the bulk of registration rates.
  • Hotel Rooms - if you don't hit your contracted numbers, you will take a bath

Do you know what happens if, for some reason - say an economic downturn - you don't make those numbers? Your conference loses over $230,000, possibly more. That 230k number? Right around the amount PyCon 2009 lost, representing a massive financial loss for the Python Software Foundation. Yes, you try to mitigate the risks by careful planning - if you're lucky, you get some insurance to cover some of the potential losses. PyCon is actually really lucky in all of this - we've grown enough that we get to leverage economies of scale with the contracts we deal with. Small conferences? Not so much - they get harder in the face of failure, and they don't have the bargaining power we have..

It's a delicate balancing act, requiring careful planning and a lot of work to drive attendance and sponsorship - negotiations with Hotels, Catering, Unions, are all things that have to go right in order to make a conference that even stands a chance of not losing you massive amounts of money. In the case of PyCon - a massive loss of money (such as 2009) could cause the foundation to go bankrupt and dissolve. As it is, the foundation, already spartan in spending cut back even further to protect itself which represents a net negative for the Python Community.

Where does the profit go?

Alright - I've outlined the philosophy, the scale and the risk. Now, you're probably asking where, if we have it, does any profit from the conference go? Easy - straight back into the community.

Whatever profit - really, money left over, goes to cover the initial costs/risks for PyCon the next year, and the years after - it also goes to the Python Software Foundation that in turn, reinvests that money into the community (see the foundation blog).

Having a healthy positive margin also means we can increase things such as the financial aid budget for the next year, allowing even more Python developers to attend.

Why not run a budget that aims for 0$ +/-?!

Because, that is simply insane - you can aim for minimal profit by reinvesting into things such as financial aid, or other perks for the attendees but only after you have guaranteed you're going to make your numbers - see the issue? At best, you budget is a highly refined series of educated guesses. At worst? Someone goes bankrupt - at smaller conferences such as DjangoCon.eu, where some costs and contracts are secured by an individual and their credit card?

That person goes broke, because the entities you signed contracts with will get their money.

So, you never, ever aim for a loss, but you also don't aim for extracting "maximum value" from conference attendees. You aim, you plan, and you hope to provide the best value and experience to attendees and sponsors - you do this through a lot of hard work and sweat. You make sure attendees walk away raving about the conference, you make sure you generate the maximum return on investment for the community.

In Closing

Historically, PyCon has never been aimed at "extracting money" from the community - it could be run a lot more profitably. We could increase ticket rates, reduce FA and walk around in Nascar-esque suits with sponsor logos on them - there's lots of things that could be done to make PyCon a massive profit center for the PSF. We don't though - why? Because, that defeats the purpose of a community conference, put together by and for the community.

We take what money we end up with and we sponsor the sprints at PyCon itself, we hold the language and virtual machine summits. The PSF reinvests it into the Python community as a whole (see the sprints project, for example, or the 10,000$ check we gave to PyPy). The money is given out in the forms of developer grants, holding sprints, providing sponsorship to smaller Python conferences all over the world, outreach and education initiatives, etc. No one gets a shiny new car or anything - money that comes from the community conference goes back into the community. You can see how much goes where if you peruse the PSF resolutions page.

PyCon is beginning to also outstrip the ability for a small group of volunteers to put together - more and more we've had to bring on commercial entities (whom we have to pay) to assist in organizing or doing specific things (such as registration, or website development). I fully expect PyCon 2012/2013 to quickly hit the attendance cap meaning we're going to have more scaling issues and higher costs - this is a fundamentally good thing - PyCon, it is felt, can sustain it's current feel and quality up to a maximum of 1500-2000 attendees.

We do not have the intention of raising that cap.

Instead, we - as the foundation - intend on encouraging smaller more regional conferences such as PyOhio to grow - PyCon will continue to be the "big dog" so to speak - but it being the big dog will allow us to further cultivate and pollenate the entire Python community and ecosystem.

Given all of that - as the PyCon chair for the next two years - and being relatively comfortable that we will again, put on a highly successful conference - I am exploring the idea of steeply discounting the cost of tickets for speakers. I feel that not only is the conference viable once again, but that the speakers do help make the conference what it is - last year we had over 200 talk and tutorial submissions. All of those speakers submitted talks knowing that they would have to pay for a ticket to attend - but given the positive outlook, I'm comfortable in thinking that we will be able to provide accepted speakers with a discount to thank them for their talk.

It's all about community, and reinvesting in it in the right places, at the right times, and managing your risk. The risks putting on a conference - even a small one (especially a small one) are massive, but the returns - especially when you're standing on a stage in front of 1380 fellow Python hackers handing a big cardboard check to a fantastic project?

Well, the returns are well worth it.


Free Idea: Code equivalent to Morning Pages/750 Words

by jesse in

I had a bit of an idea that almost turned into another crank based on yesterday's blog post "On Family, Cranking and Changing" - the "code equivalent" for the idea stemming from the Artists Way's concept of "Morning Pages"/750Words and the Writing Down the Bones concept of "Keeping the Hands Moving".

I made the mistake however, of asking on twitter - never, ever ask a bunch of programmers quote "What do you think the char count or line number of a reasonably sized Python module is?" - never. Just don't. I'm not even asking that here. Instead, I'm giving you a simple idea for a web application. Take the implementation of github's gist's/pastebin, mash it up with a built in code editor (such as Ace), and kick out a programmer's version of 750 Words. The goal is not to force people to share code publicly - if they want, let them flip that bit (or just post/link to github's gist system). The goal is to encourage programmers/hackers to explore/write some new:

  • code
  • tests
  • docs

And I mean new - not something bogged down by their every day projects. It could just be a clever one liner ala Raymond's python tips. It could be a few-hundred-line piece of code that just tracks how many times they've watched their favorite show using some cool module. Just keep the hand moving; just take 3, 10 or 30 minutes a day and keep a private code journal of new ideas, concepts, etc. Write some morning pages.

Project Euler is algorithm problem solving, so it doesn't fulfill the goal. Code Kata's come damn close (see also Coding Horror's take) - but again, those are focused on providing a problem, and then having someone come up with a solution. I'd like something that just sets forth the ideas exposed for writers above, and sets it in a programming context.

If you want, allow users to seed it with suggested ideas. So that when a user logs in, they might have set a "preferred programming language(s)" and get a a little javascript popup with a problem sourced from another user, like say "use python threads" or "write an application that forks". This latter part ties into an idea I had stemming from Zed's original "Learn Python The Hard Way" posting - too many of these practice sites focus on algorithms and mathematical things that probably won't help you in the next 8 hours. Something that had problems like "send a receive UDP messages from a socket" and the like - focusing on common, practical things.

Anyways so what are the requirements for "XXXcode" or "xxxlinesaday"/etc:

  • Allow signup/signin
  • Allow public sharing of journals/non public
  • Allow submitted "ideas"
  • Outline the idea stemming from the Artists Way/Writing Down the Bones.
  • Make it look decent (I'm tired of ugly programmer sites. Go get something from themeforest if you need it)

There ya go. Take it and run with it if you want. Just stop bothering me about lines of code in a module. Man you guys can be pedantic.