Moving On (Again), but Don’t Panic

So today I’m starting a new full-time position at Truth Initiative®, the anti-smoking nonprofit. They have an internal group there who work on various applications to help people stop smoking, and they needed senior PHP help. When I cofounded mojoLive, a large part of my motivation was to work more on long-term web applications instead of simply more content management sites, and this move helps me do that.

This doesn’t mean php[architect] or is going anywhere. I’ll still be a part owner, but it will become my avocation rather than my vocation. As will surprise no one, becoming a publisher in the 2010s is not the most lucrative endeavor, and try as we might, trying to do that plus doing enough consulting to keep us in regular, albeit small paychecks was beyond our reach. In order to keep things the way we were doing them, I was basically becoming the consultant I’d wanted to take a break from five years ago…and when consulting was scarce, we’d have to sacrifice our paychecks in favor of paying our bills. Hopefully now the magazine, books, training, and conferences plus a little advising will be enough to keep our Editor full time and keep One for All Events producing the conferences. If you know of any senior design jobs, I know a guy.

So I’m moving on, and I expect this job will give me more practical topics for talk ideas. I’ve already confirmed that Truth Initiative has an excellent commitment to career growth, so I’ll be able to be involved in the community one way or another. If you’re coming to php[world], I’ll be there on Monday and Tuesday teaching and will try to stop by the evening events.

If you’re concerned about the future of php[architect], the best way to help is to subscribe to the magazine if you haven’t already, encourage others to do so, and spread the word about our books, training, conferences, and, of course, the magazine.

Conference Talk Criteria

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.

My First Hackathon

This past weekend, I went to the Washington Post’s Election Hackathon. I hadn’t been to one before, but my friend Oscar had the idea that it would be a good way to possibly get a little more exposure for If nothing else, we’d get a nice portfolio piece.

And we did indeed: Check out Oscar’s piece on its creation and some ideas for going forward. It was a good example for how quickly you can get a site together using Treb, the framework we built for mojoLive.

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.

Help Kickstart BubbleSorter and GridSorter

I’ve always been careful to say that my new company,, 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.

BubbleSorterBut 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.

CMS, Framework, or DIY: How do you choose?

Web developers and web development companies frequently start each project as if they only things that need to be built require merely different types of nails, and luckily they have a hammer. In fact, they often call themselves “Drupal developers” or “Ruby on Rails developers” rather than Web developers (or software engineers). The opposite also happens, where someone will approach each project as a custom, ground-up web development project. Wars inevitably break out over what platform is “best” for web development. Purists slag framework devs as lazy and imprecise, framework devs slag CMS developers the same way and purists as wheel-reinventors, and CMS devs slag the others as wheel-reinventors and one another as using an “inferior” CMS.

The best developers I know may have favorite tools, but they either put them aside when they’re the wrong tool or pass on inappropriate jobs in favor of projects that match their preferred development niche. Others simply choose the best tool for the task at hand…but that choice can be the first point of blank page syndrome. What follows are questions to ask yourself and how the answers can influence your choice.

What does the client expect?

Every project has a client. Even if that client is yourself or your boss, let alone someone who is paying you for a bespoke web application. Sometimes they have particular ideas, for good or ill. You can try to argue the choice if you think it’s wrong, but ultimately the person paying will have to approve your choice. Obviously if you’re adding on to a Drupal website, you have to make a pretty strong argument that Zend Framework is the right choice. (Though I’ve seen it done.) In the nonprofit sector, for example, there’s a huge preference in favor of Drupal for anything larger than a basic site or blog. A previous company I worked for tried to argue for a different solution, but ultimately had to deliver what clients wanted as many dropped non-Drupal proposals immediately.

What is the legacy technology stack?

It’s been a decade since the average web development project was “helping an organization finally get on the web.” Even new projects in existing organizations are often project-specific websites in addition to the main organizational site. Sometimes organizations have a large infrastructure dedicated to serving other sites. While in general I’m not a fan of people hosting their own sites and often throw out the sunk cost fallacy in arguments, sometimes it’s easier to reuse existing equipment and experience than introduce a new technology stack. So if an organization has a ton of ExpressionEngine sites, asking them to host a Drupal site may not end well if they’re not familiar with keeping Drupal up to date or staff need a lot of handholding to use a new system.

What does the end product mostly do?

Even if the excitement is around a small application on the site, if the bulk of the requested functionality revolves around managing web pages, articles, and comments, then starting with a CMS may be the responsible thing to do. While every CMS entails design tradeoffs and limitations that often drive experienced developers nuts, I’d rather focus my development effort on getting that one web application right and adapting it to the CMS’s module structure and API than rebuilding page, menu, login, admin, and comment functionality again.

What will the application do over time?

Small organization sites may live forever as a basic set of rarely-updated pages. Most restaurant pages only need to update menus and maybe an events calendar. Intranet applications will tend to get added on to and fixed over time but never have a vast number of users. And that social networking site may become Facebook.

While lots of startups jumped on the Ruby on Rails bandwagon after Twitter took off, Twitter ended up rewriting most of their site as they scaled. The tradeoff was a quick minimum viable product versus a platform they could easily grow as time went on, and there was a period in which had another service arisen on a more reliable stack, we’d remember Twitter the way we remember Friendster. At mojoLive, we looked seriously at Zend Framework since it was built to have any individual component thrown out for a custom replacement as was needed for scaling, but ultimately it didn’t help us do enough of the hard things easily and would require a significant learning curve to build something we knew was going to be thrown away. Building a custom app based on some code Eli had lying around with a minimal MVC layer didn’t slow us down appreciably over picking up a new framework.

Startups and large enterprise applications also have developers working on them all the time, unlike small organization sites. In the latter case, a well-known CMS is going to be a lot easier than a custom-built CMS for someone to come along and update when you’ve gone on to bigger and better things.

What do you know?

Unless you’re doing a project specifically to learn a technology (and it’s either personal or the client has approved you taking on something you don’t already know because they’re awesome, desperate, or you gave them a big discount), it’s rarely a good idea to start with something you don’t know. Even if you know PHP inside and out, Zend Framework and Drupal have layers of best practices specific to those environments that take time to learn. And jumping from an object-oriented or imperative language to a functional language is…challenging, to say the least.

When is the project due? What’s the budget?

There’s no point in building a new CMS that’s going to take over the world just to churn out a 3-page site due end of the week. The less time you have, the more you’re going to want built for you. Similarly, you’re going to want to stick closer to what you know.


There is, unfortunately, a lot of overlap in the capabilities of systems. Obviously you can ground-up write any app in existence, if you have enough time and budget. (And skill and experience and…) That being said, you can make Drupal into a 300+ mini site system with overlapping permissions, 12,000+ shared users, and single signon with Salesforce. It wasn’t my first choice, but the mix of familiarity, budget, and client expectations led me there. That being said, it was a huge pain and the gains of the CMS components were probably overwhelmed by trying to shove a very idiosyncratic enterprise-level set of requirements onto a CMS whose sweet spot is rapidly building middling complexity content management sites with community features.

In general, though, sites that primarily content belong to CMSes, sites that are primarily web apps with tighter deadlines or without huge growth requirements are better off with frameworks, and sites that are going to be constantly developed and scale rapidly are likely best ground-up. You can find exceptions to all of these, and there are clever people who’ve built simple ground-up CMS apps and made WordPress run massively complex sites, but that rule of thumb should keep your next project from being a cautionary tale of trying to hammer in screws.

On Grieving for the Famous

Two quick things about reactions to Steve Jobs’s passing:

1. Bill Gates would get a much bigger outpouring if he were to pass away under similar circumstances than people think. It would just be of a completely different character because the only people connecting emotionally to what Gates did would be reacting to his philanthropy and his business success. They might overlap strongly with the people who continue to fail to get why Apple did so well after Jobs’s return and attribute his success to showmanship and marketing. The reason is that nobody connects emotionally to any of Gates’s technical work. Nobody loves Windows. And fewer hate Windows than old Mac partisans would like to believe. But legions love and hate the iPhone, iPod, iPad, or the Mac. If you don’t understand the difference, I can’t teach you in this post.

2. Dave Winer complaining that Steve Jobs is viewed too nicely in his bio is like Mubarak complaining that Lenin is viewed too nicely in bios. It may be true, but just because you’re gonna be a footnote in history doesn’t make you not an asshole, too. Hey, at least you’re a footnote: I haven’t even achieved that. And maybe you’re like Jobs at NeXT, a genius between highs. But there’s no denying “mercurial” would be a polite way to describe your interactions with others.