On the matter of technical conferences

While reading Ben Ramsey’s blog post “The Fall of PEAR and the Rise of Composer“, I caught myself thinking of entirely different subject – technical conferences, in general.  Two bits in particular pushed my train of thought.

The first one is Ben’s experience as a first time speaker at a technical conference.  We’ve all probably been to one or seen one on YouTube, but that’s from the audience perspective.  Here is how it looks from the other side:

Palms sweaty, stomach aflutter with butterflies, I stood before my first audience as a technical speaker. It was a time of many firsts for me—my first PHP conference, my first time in Europe, my first technical presentation. I had been accepted to speak at the 2005 International PHP Conference Spring Edition in Amsterdam. I was nervous, jet-lagged, and tired from an all nighter working on slides.

[…]

After my presentation, I found myself downstairs during the break, discussing the topic of frameworks with a German gentleman. I don’t recall much of our conversation, but after a while, I made the biggest mistake I have ever made in my entire career as a speaker. I asked the question “how did it go?”

“Oh, I think we both know how it went,” responded the gentleman drily.

“No. No, I don’t think I do. Can you elaborate?” My second mistake.

“It was horrible!” he exclaimed.

Wow. I was floored. I had to get out of the conversation quickly. I thanked him for his frankness and excused myself. I found a quiet room and sat down for a while, taking deep breaths, trying to calm myself and recover before giving a second talk that day. If I was nervous before, I was frantic now. I didn’t think I could muster up the courage to give another presentation, but I pressed on, and I’m better for it.

That day, I learned two valuable lessons: 1) after giving a presentation never, ever, ever, ever ask someone how they thought it went; let them volunteer that on their own, and 2) unless you want a brutally honest response, don’t ask a German for their opinion.

I haven’t spoken at any major events yet – just a couple of local Linux user group meetings – but I can attest to the very humbling and crushingly nervous experience.  It gets easier, I guess, but who would want to listen to you when your first few times suck so badly?

The second bit that got me thinking was the this one:

At php|tek 2009, a group of leaders from a few of the frameworks and libraries communities got together to, as David Coallier described, “develop a set of common standards which PHP projects can strive towards adopting.” This moment represented a turning point in the PHP community. All modern PHP development hinges on this moment. As the Doctor might say, it is a fixed point in time.

This group produced what would become known as PSR-0, an autoloading standard for PHP userland frameworks and libraries, and the group’s name would eventually become the PHP Framework Interop Group (PHP-FIG). It was this autoloading standard that I think changed the course of all PHP userland development.

Quite a few people I know are under the impression that technical conferences are a waste of time.  People just go there to escape a day or two from their work.  And maybe learn a thing or two.  But it’s not just that.  It’s not only about the sessions, workshops and learning.

A great deal of networking and cross-industry communication happens at these events.  Some of these just forge friendships and beer sessions.  Yet others develop into powerful partnership and great accomplishments.  Like the one mentioned above.

Like it or not, but even the techiest of techiest among us need an occasional face-to-face session to fix “lost in translation” things, to discuss and argue about everything, and agree on something.

4 levels of PHP skill

Bruno Skvorc wrote an excellent post on 4 levels of PHP skill – beginner, intermediate, professional and elite – how he differentiates between them, and what you need to do to move up the ladder.  I don’t fully agree with everything he says, but I do think about it plenty recently, as I am being asked the same questions:

How does one get from beginner to pro and beyond? If one doesn’t know anything beyond the basics, how can they improve their skill enough to leave the bad practices behind and start practicing the more advanced approaches? This is a question I get asked a lot by beginners. In order to become a professional, one must first become intermediate.

What follows is a list of what one should go through on the path to PHP fluency.

Indeed, everyone who’s done a web form or interacted with a database starts as a beginner.  Professionals are the ones who are pretty comfortable with the language, frameworks, tools, libraries, and can undertake a project all by themselves.  Elite are the chosen few – usually book authors and conference speakers.  But who are the intermediate ones and how do move from beginner to professional – these are not as obvious to answer as they might seem.

Overall, I support Bruno’s way of thinking, which, in short, is: practice makes perfect.  Work, work, work, learn, learn, learn, read, read, read, and you’ll get it.  Learn from the best, participate in Open Source projects, and try things out.  There is no shortcut really.

I do have a few disagreements too.   Some are larger than the others.  The main ones are namely – PHP extensions and the use of IDE.  IDE is not a silver bullet – it’s a tool.  And it’s a kind of tool that works well for some people and completely misses the point for the others.  I wouldn’t call for or against it, but, instead, I would suggest to try both ways – a full featured IDE for a while, and a simpler text/code editor like Vim for a while too.  Pick the one that works, but try to make sure that you can afford it in worst of times, and that it runs on multiple platforms.  You never know where you’ll end up working, and a tool that you have muscle memory for beats any other.

As far as extensions go, it depends heavily on the kinds of projects you are working, on the kind of people that you are working with, and on the rest of your environment setup.  You might not always have a chance to use PHP extensions (especially in cases where you don’t control the servers on which the project will be running).   They are cool things to play with, but you’d have to get special kind of luck to end up with the project that absolutely requires them.  Not to mention that you wouldn’t code PHP extensions in PHP (hint: C).

But, as I said, overall, there is some solid advice and it makes a lot of sense.