This doesn’t mean php[architect] or musketeers.me 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.

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.

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.

And we did indeed: Candidata.me. 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.

Humans are notoriously bad at predicting what they will respond to. That simple fact has given rise to parts or all of the fields of behaviorism, psychology, user experience, efficiency, human factors design, and psychometrics. It turns out that we often state what we’d like to be true of ourselves and then do something different when forced to act. Economists have a term for this: revealed preference. The upshot is that we’re really bad at doing something like looking at a wireframe or design for a website and accurately predicting how we’d use it and if it will solve our problems.

So how do you create a successful website if you can’t test it on yourself and you can’t simply ask users what will work for them? There are of course general principles of user experience, and any good developer should steer you toward them. But those principles are notoriously hard to apply perfectly in every case. Fortunately, the software world has been aware of these problems for some time and has developed several methodologies to help, collectively known as Agile.

Even though details vary, all agile processes share one insight in common: users don’t know what they need until they try working software and their requirements change quickly over time. The goal is to quickly get out the most important features to users and let them begin working with them, and use metrics and usability tests to assess how well that version is working. By doing this over and over (iteratively, in Agile terminology), you can make small changes, measure their impact, and change accordingly until you get the feedback you want.

This is a big mind-shift from how nonprofits are used to operating, but it’s one that can make the difference between a website that you can demonstrate to funders actually fulfills its mission versus one you simply hope gives you good results by the next grant application. I’ll explore some of the challenges in adopting it unique to nonprofits in a future post, but meanwhile, Google and this article can get you started on understanding how selecting a developer who uses an agile methodology will make your project more successful.

This month, be sure to check out my company’s Kickstarter campaign and consider backing us: we’re developing two new productivity tools that will help non-profits.

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.

Nap buddy.

It seems like a strange sentiment, because why else would you build a website or application? The problem is that when you circulate requirements for the website, people focus on their own jobs and what would best represent how they think about their job. What they often don’t do is focus on the organization’s goals.

Your goals and your requirements aren’t synonymous by any means. Requirements are often just a wishlist of features collected piecemeal by people who take a moment to think about what they might want a website to do before going back to their main job.

The problem is, unless you’re building a site for use by your employees, they aren’t really the users of the site. The people the organization is trying to reach are the ultimate users of the site, and its their requirements that should drive the features of your website or application, not yours.

Instead, you should start with a list of your goals generally as an organization, and then the goals you have for the website. Those goals are the ones that usually triggered the decision to invest in a site or application in the first place, such as increased engagement with volunteers, reaching out to a broader base of smaller donors that aren’t feasible by traditional means, or convincing a key demographic that they should support a policy.

The goals for the website should logically support one or more goals of the organization. Goals are the “why”, and requirements are often the “how.” The tricky part is that each person in your organization also has a job that supports your organization’s goals. (Well, they should, right?) The tricky part is that the requirements they have to do their job better don’t usually map very well to what the ultimate users of your site will need to support your organization’s goals. So simply collecting their requirements and turning them into an RFP is a recipe for a site that makes everybody internally satisfied, but goes over with a big thud with the people you’re trying to reach.

This is another reason it’s a good idea to approach web developers with problems rather than solutions. The problem you have is that you have goals and you need to use the web to help you meet them. It’s the web developer’s job to help you figure out how to do that. Your staff should certainly be involved, but they have jobs of their own and shouldn’t be specifying your website for you.

This approach can also prevent some political problems, as specific requirements related to jobs can be conflicting, and wish lists are inevitably larger than budgets. Getting everybody’s input on goals and feedback on proposed solutions is easier than dealing with hurt feelings when a cherished feature doesn’t make the cut.

There are several techniques for getting to the heart of what users need, and they get to the heart of better ways to work with web developers. But by remembering the end users are the ones who hold the key to getting the right requirements for your site, you’ll set yourself up for success, and potentially avoid some internal conflicts.

I’d say that in the nonprofit world, it’s more a Flying Magic Unicorn Pony, as it essentially never happens in agency contracts with nonprofits. There are several reasons: often deliverables are spelled out in advance, budgets are unbelievably tight, and there’s a lack of trust if an answer isn’t immediately available–”I don’t know” isn’t accepted, by and large. That lack of trust extends to the idea that prototyping time is “wasted” if it’s not to be used in the final product.

What works better is an agile process where an idea can be tried out in a sprint. That requires some preconditions and a mindset that I’ll expand on in a future post.

In the meantime, prototypes can work in nonprofit engagements under very specific circumstances:

1. The requirement wasn’t in the initial discussions for the engagement, so it’s a legitimate surprise to the agency.
2. The prototype is incredibly focused to answer a yes/no “will this work with the technologies we’ve selected” or “will this work within the budget we have” question, rather than a “do you like it” or “will users respond to it” question.
3. The prototype can be done in less than a day’s time.
4. Resources exist to do the prototype immediately.

Ideally, the prototyping can be done internally to the web team without involving the larger circle of stakeholders.

Given those requirements, it’s not too surprising that it’s a rare-to-mythical beast. However, they can be a powerful tool, so if you can make room in your budget, they can free you from either getting an adequate but less than ideal site due to enforced conservatism or getting a feature that becomes a maintenance nightmare as attempts to fix a fundamentally wrongheaded approach are slapped one on top of the other until the whole thing is written off as a failure.