Both Adam Culp and Cal Evans had some slightly related thoughts about what is “wrong” with conference talks recently and how they intend to fix them.

For Adam, neither novices nor veterans are getting content sufficient to justify their attendance to the Big Mean Boss back home. He attributes this at least in part to “laziness” in preparing talks without sufficient preparation and hard technical code examples. Cal similarly self-diagnoses simply submitting to be accepted rather than submitting to speak to his passions.

If both were simply going to change how they pitched talks and encourage others to do the same, starting a conversation about why veteran speakers speak and what the focus of talks should be, I’d be all for it. Unfortunately both of them threw in their positions as conference organizers into the mix, including specific vows.

From Cal:

I am privileged enough to be asked to help score talks for several of different PHP conferences. in 2015, I will start be a lot more picky in the talks for which I vote. I will look for – and up vote – talks where the presenter makes a note that they have given this talk at a local event already.

Adam’s resolutions include:

Be tougher when rating talks I attend at conferences. I should walk out of a talk feeling like I truly learned something.

Be more critical when selecting talks to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen.

Ask to see slides and code for talks in advance if available, and at a minimum set a deadline of when these should be ready if the talk is selected. To ensure the talk lives up to the abstract.

There are a few problems I see in these proposals that warrant further discussion.

Both proposals suffer from something similar to Keynes’s (alleged) Paradox of Thrift: this is fine if a few speakers tailor their talks to these criteria, but if most or even many speakers do so, it could cause problems.

Take Cal’s proposal that talks should only be accepted if they have been previously given at a local venue. In North America alone, there are now several PHP conferences. There are many more web conferences that can include PHP talks or other talks that might appear at a PHP conference (Jenkins, Ansible, Selenium, etc.). Even if there’s heavy overlap in speakers and talks, that means something like 60-70 talks will need to be previewed at user group meetings. And that’s just assuming that pretty much everybody who submits is accepted. Recent ratios seem to be more like 5 or 6 speakers submitting for every 1 selected. So that means 300 to 420 (heh) talks that have to be given at local venues. That fills up every monthly meeting of 35 user groups.

But Cal goes further: he pledges to speak at 5 local user group meetings this year. Assuming every speaker makes the same pledge, just 40 speakers would fill every monthly meeting for 16 user groups. There are roughly 60 PHP user groups in the US and Canada. Assuming each one meets every month without fail (they don’t, not by a long shot), that means there’s room for 144 speakers who speak at 5 user group meetings each in the US and Canada. Reality is likely a lot lower, and that’s assuming local groups don’t insist on local talent that’s not going on to speak at conferences, or have panels, lightning talks, or genius bars.

That’s not web scale.

Adam’s proposal increases the PITA quotient for creating new talks considerably. Simple microeconomics tells us that if you raise the cost of something while keeping the price constant (e.g., the number of 2 nights and a flights available for each talk), you’ll get fewer. It also means you’ll get fewer new speakers willing to risk creation of new content just to have the possibility of being selected. Existing speakers will pare theirs down to what Adam says he does: a couple of talks that they submit to every conference.

That means attending one conference a year is all you’ll likely ever need to do, let alone be able to do. You’ll have the same exact experience with the same exact set of speakers you’ll see at every other conference. Furthermore, there will be no need to go back next year. Once every three or four years will be enough to get any new talks created by that same set of speakers or the handful that manage to break in. The hallway track, far from being a secondary benefit as Adam sees it, will become the only thing a repeat attendee values.

This will hurt diversity. Not just identity-politics-laden diversity, but diversity of experience, thought, approach, and, if Adam were to have his way for even more code-centric, hands-on, immediate-takeaway talks, style of presentation. The same PHP people saying the same PHP things. Not to mention that impostor syndrome is hard enough to overcome without creating new barriers to entry just to be considered.

It’s also not accurate that everyone can get two or three talks accepted in many venues. There are dozens of variables that go into talk selection: conferences like people to give two talks because it cuts down on travel and hotel costs and keeps tickets more affordable. Just having two great talks isn’t enough, though. They must be great talks that meet the demand that’s out there. One year Puppet is all the rage, the next year Ansible. What if you have one talk that’s unique but your second talk is the umpteenth proposal on that topic? Another guy with a slightly less unique approach but a second talk that isn’t as common may fit better. I’ve had to watch many of my favorite talk submissions rejected because we just couldn’t work them into the schedule for sometimes arcane reasons.

Obviously, I’ve taken these issues to task by extending them to an extreme. But had both gentlemen not emphasized that they select or help select talks for multiple conferences and urged others to do the same, I’d applaud. Let a hundred flowers bloom, and all that. Sunshine PHP can become where you go for veteran speakers giving advanced, hands-on talks chock full of code samples. Another conference can have a mix, another lean more toward skills talks, another toward career development, etc.

I’d find Adam’s preferred talks kind of boring if I wasn’t interested in the given technology. I’m a sucker for soft talks. I love talks about the principles of OO design and honing software development as a craft. Thirty slides of 12-point code and watching someone type into the command line to do the same thing as another tool with slightly different (no doubt superior!) syntax put me to sleep. Sure, a good technical talk can have tons of code samples at a readable length and size as well as be entertaining with a smoothly-practiced WOW factor demo, but I’ve seen enough veteran speakers giving talks to know that even for well-honed and -practiced talks, the ideal is rarely met. Plus my ideal is not everybody else’s ideal (see what I said above re: having a diversity of opinions in rating talks at php[architect]). However, there are lots of other people like me.

One of the things I’ve learned as I’ve taken on the training curriculum here is that people don’t learn the same way. You encounter perfectly intelligent people who have to hear things said, others who learn by watching videos, others who need diagrams, others who need to type things out, and others who need to read dead-tree books. Too much homogeny across our conferences will leave a significant portion of people behind.

Furthermore, it’s not a surprise to me that developer advocates and evangelists are the ones behind these proposals. When you literally get paid to network with developers, put on demos, and get speaking engagements, you have lots of time to craft a just-so presentation with lots of hands-on application. But for those of us who move from client to client on old hosting solutions, or are frantically building out the next feature before the upcoming investor meeting, or simply value family time because we learned a long time ago that all work and no play leads to burnout and strife, doing all this on top of our existing commitments is just not realistic, or we’re forced to slowly develop a couple of talks we’ll be giving for the next five years. That violate’s Cal’s stricture to be passionate about what you present.

Finally, I’m not sure why either one says he will be more strict about selecting talks. Unless they are actually planning on reducing the number of speaking slots, they are going to be just as selective as they have been every other year. Their criteria may change slightly, but it’s not actually stricter. They’re just proposing criteria that put a larger burden on speakers. If fewer people submit to their conferences as a result, they’ll actually be less selective, as they’ll be forced to go with the talks they have, rather than the talks they want.

Now, the good

After all that slagging, I want to emphasize that they do identify some key things that speakers should heed as a matter of course: too many speakers do wrap things up five minutes before they start their presentation. Talks do evolve and benefit from feedback, which means in ideal cases giving them 3-4 times. However, the more experienced the speaker, the more a new talk can be exciting and valuable from the first time it’s given. In fact, I’ve noticed recently that veterans giving a brand new talk have been better than when they give that same old talk. Cal addresses this with his insistence that speakers talk on their passions, not just what will get them that next slot.

But if you’re just starting out? I’m pretty confident in my Regex talk, because I’ve given it a few times now. But I’m giving a brand-new talk that was accepted without me writing it first, and yes, I’m going to practice it at my local user group. I’ve also let other speakers trial run their talks.

I’ve also let lots and lots of people who’ve never given a talk before try their hand at it. And I’ve given entry to people who are accomplished speakers, but not in the PHP community.

Now my experience in conference organizing is different, since it’s exclusively for larger conferences (in breadth and length, if not always attendance). While it’s a huge effort to comb through 600+ submissions to fill 40 speaker slots, we’ve had a few people new to the PHP community hit the ball out of the park, as well as first-time talks from old PHP hands that blew people away.

If either Adam or Cal want to road-test new talks at DCPHP, they are more than welcome! There are still lots of people who come to user groups who never get to conferences. Well-rehearsed technical talks with great code samples and actionable content are great. All I want to ensure is that we don’t correct one set of deficiencies with another.

[Let me start this piece with a caveat: This is not a #slatepitches-style article arguing that Impostor Syndrome is a good thing or that people with it are better off keeping it. It has profound negative effects and plays very neatly into the self-defeating internal narratives that major depression can give you. Depressives in particular don't need another excuse to tell themselves they suck; most of us are really good at that already. Read this first if you need to learn about Impostor Syndrome, the harm it can do, and how to start overcoming it.]

At the last DCPHP meeting, Sean Prunka talked about Impostor Syndrome during his talk on dealing with distractions. At the end, I asked the group how many suffered from it, and the vast majority of hands went up. So clearly, a lot of the type of programmers who read blogs and go to user group meetings are the type who also think they’re a misstep away from being “found out” as not really deserving of the position/title/place they hold.

It got me thinking about why really good programmers paradoxically suffer from the feeling that they are the really crappy ones and have gotten where they are by sheer luck. Knowing that many programmers who give talks nonetheless feel like frauds gave me some new things to listen for, and I think I’ve distilled some good habits that shouldn’t go away with the crippling and unrealistic self-doubt as you fight these feelings within yourself.

There is some evidence that depressives perceive things (apart from themselves and their own worth) more clearly than those who don’t suffer from the disease. (The theory is called Depressive Realism.) Similarly, self-doubt can give programmers some good habits of mind along with the bad habits that make it a problem. Here are some I think are related to my impostor syndrome:

Pessimistic estimation: If you assume you don’t know what you’re doing, you tend not to assume everything will go well as you attempt any task. In my case, it’s made me a better estimator, because I’m able to identify rosy assumptions and allow for the very real possibility that those assumptions will be wrong. It could be my memory of how much pain working with a given module causes and not assuming that this time it will be different. It could be assuming that the client won’t come through with the required design in time, and I won’t be able to just “make it happen” by the deadline. It could be realizing I haven’t completely mastered a given technology and using it will require research to address a specific problem. All of these things enable me to be a pretty good estimator because I naturally assume that things won’t just “go my way.”

Research first, coding second: With a nod to Donald Rumsfeld, Impostor Syndrome makes you keenly aware of the known unknowns as well as wary of the unknown unknowns. Being aware of the limitations of my knowledge encourages me to research a problem before tackling it. A common junior developer mistake is to take a half-understood requirement and immediately begin building a new framework to solve an entire class of problems like the one they’re given instead of simply searching to see that there’s an existing plugin that can solve the problem in minutes. Another frequent problem is assuming a component will solve your problem based on the general description without looking into the specifics of its implementation. Some of this is experience, but I’ve seen senior developers fall prey to cheery assumptions. Knowing I don’t know a new component inside and out makes me look into it more deeply before committing to using it to solve a problem.

Continuing education: One reason I suspect many hands went up in the room at a programming meetup was that we are a self-selected bunch. Those of us who don’t think we know everything are motivated to learn more. Even as you realize you’re a better programmer than you give yourself credit for, don’t lose the drive to chip away at your ignorance. Programming is as much of a craft as it is a science, and crafts take continual mastery.

Teaching and mentoring: Having felt adrift in a sea of acronyms and reading conversations where it felt like everybody in the room had singlehandedly built Facebook equivalents except me gives me a lot of empathy for the new or developing programmer. It’s really intimidating at first, and that’s one of the reasons I’ve become excited about what we do at php[architect] and what the community has done through its mentoring program. mojoLive was an attempt to encourage people to continually develop their skills, and I support PHP Women because they help lots of people deal with the learning curve and Impostor Syndrome. So my career has become as much about enabling other people to do great things. Perhaps self-doubt has kept me from tackling some of those problems, but it has given me the push to help others to develop their own career. I think feeling that dread at learning yet another technology has inspired many in the community to share their findings with others to spare them the pain. To Impostor Syndrome sufferers it can be more than just the pain of coaxing aging neurons to form new connections; it’s also the pain of “can I do this yet again or did I just get lucky last time?” each time we approach something new. That empathy helps push us to give a hand so the next person doesn’t suffer. We also appreciate those who have spared us the pain in the past.

That crippling self-doubt is more of a hindrance than a help, and Impostor Syndrome is something to be fought. But appreciating the good things it has driven me to do has helped me realize I have actually learned things along the way…and that I’m not an impostor at a programming conference.

We didn’t win, partially as there were some really awesome ideas done by others at the hackathon, but partially because we misjudged the criteria for the site and provided something potentially useful but stopped early to polish it rather than really digging into the APIs to uncover some insights. With only a few hours of designer assistance from Kevin, the polish worked well, but the judges went for incomplete ideas with potential. As the Musketeer with the occasional appellation “product guy,” ultimately that’s my fault. On the other hand, I got to dust off some programming chops that had been put on the shelf while I pursued funding at mojoLive and gladhanded for clients for the Musketeers.

We did get selected to present our app. You can totally identify Oscar, right?

One other note: Oscar will expand on it, but I think we did demonstrate good principles if you’re going to design something to be responsive: keep the design clean with simple boxes and rows that could reflow rather than try to replicate the report-ish layout that websites have aspired to since the 90s and that are the bane of the nonprofit world. The site still looks good on a desktop browser, but it also works really well on an iPhone.

Design for your medium, people. Don’t try to force it to be something it’s not. And as “product guy” I will take a little credit for that part.

I’ve always been careful to say that my new company, Musketeers.me, is a consulting and product company. Today we’re getting closer to the second (but to us, first) part of our mission. We’re launching a Kickstarter campaign to build two products: GridSorter and BubbleSorter.

GridSorter is best explained by relating the story of how Eli White first created the prototype: ever have a list of things that need doing around the house? Or worse, a honey-do list? Eli had that problem, and he’d already ranked everything by most important to least important. The problem was that when he had some spare time, he would look at the first thing on the list, which was a weekend-long project. So he’d put it down, and go do something else instead, and nothing was getting done. He quickly realized that he needed to categorize his tasks by both how long they’d take and how important they were.

Being a programmer, he naturally sat down and hacked out a solution: put his tasks on a grid, with one axis being importance and the other axis being time required. So now when he had an evening, he could simply look down the “takes an evening” column and grab the first task off the list, knowing he was getting the most important thing he could do with that time.

We’ve realized that a lot of you might have that problem, and the principle is even more powerful than just tasks versus time: you might have any number of things you need to sort by two different categories: for mojoLive we categorized our last push of features by importance versus user engagement, and picked the most important features that would also engage users. So the final product will have the ability to pick your two categories and drag and drop your list accordingly.

But what if you’re having trouble figuring out what’s important? Once I was trying to get a client to give us a prioritized list of tasks so we could ensure we did the most important things first, since the budget was tight and the list was long. They came back and said, “Well, everything here is Priority 1.” Not too helpful. But when I started asking, “Would you like to put more effort into Feature A or Feature B?” the client would quickly reply, “Feature B.” Out of that inspiration comes BubbleSorter.

While even just bringing in a list and prioritizing it is useful—and we’re going to give you that for free—it’s really useful when you have groups of people who are having trouble agreeing on a list of priorities. So for a low yearly subscription, you’ll be able to invite others to come in and perform the same ranking, and then using an algorithm we’ll be able to tell you what the group’s collective priorities are. This is really powerful if you’re regularly trying to get consensus in teams.

So help us make these products a reality: watch the video, see what you will get for each backing level, and join our Kickstarter.

Over at the new blog, I show how starting with the phrase “How hard would it be to make a button…” usually ends up costing extra and frustrating everybody. Try instead to say, “Here’s the problem I’m having. What can we do?” You’ll be amazed at the results.

On the side, I’ve started a new blog and consulting practice. Since I’ve worked as a web dev but have business, strategy, and policy experience, I’m in a good position to help organizations help themselves when they contract with web developers and web development shops.

So if you need some help figuring out how to get the best results out of your next web engagement, contact me.