It's been a week since tekX completed and there are a number of other tekX writeups to read but I thought I'd share one last one from a different point of view. To add some context, I'm not the guy that signs the contracts, approves the expenses, schedules the sessions, arranges the speakers, or anything useful. Due to other project commitments, I basically served as backup for some of those things and then as social chair for the evening events.

First off, I'm proud of our first time tekX speakers. Easily half of the speakers had never spoken at a tek before, off the top of my head that includes - Bill Karwin, David Strauss, Jason Austin, Josh Holmes, Kanwalijeet Singla, Kristina Chodorow, Matt Schmidt, Matt Turland, Ryan Stewart, Sumit Chawla, and myself. Since tek is the Community Conference and it tends to be incredibly technical, it takes a different mindset than many of the other conferences. Even better, a few of those people were first or second time conference speakers period.

This is incredibly late since tek·X starts in four days, but it's definitely worth noting here. After a headed battle of Rock-Paper-Scissors against Cal Evans and Marco Tabini, I finally lost. While I thought we were deciding who was going to pay for dinner, it turns out the stakes were a bit lot higher.

It turns out that I will be Live Coding for two back to back sessions at tek.

You don't believe me? Well, here's the description:

So, it's your first conference. Yes, it can be a little intimidating. Yes, it will be exciting. Yes, it will be exhausting. Here are some tips to get you started:

Do: Look at the schedule to find your "must see" sessions. Once the conference is running, you're going to be overwhelmed. If there's a session you absolutely need to attend, you need to figure that out now and plan accordingly.

Don't plan to attend every session. I know, I know... you want to "get your money's worth". You want to get exposed to every great new idea out there and you can't wait to dive in. First of all, no one can handle that much in a few days. Even the sharp guys over at North Carolina State University were overwhelmed at their first conference. Second of all, you can't forget the "Hallway Track".

Over the last few months, I've heard a common thread in a number the various Open Source communities I participate in or watch:

How do I get involved with the Open Source Community?

When someone considers how to get involved, they always think first and foremost about code.  They believe that the only way to contribute or participate on a project is to write code.  Well, not quite, so the answer becomes quite simple:

It depends.  What are your skills and interests?  That's right, it's not all about code!

First of all, yes, a project needs code that eventually get released.  But code is just one part of the Open Source Community.  Yes, it tends to be what we talk about, what we spend most of our time on, what starts/encourages licensing arguments, and what eventually gets released, but the other aspects can be even more important.

Last week at php|tek 2009, there were numerous sessions on improving your development practices.  There were some focused on better SVN usage, some offering better Object Oriented design practices, some on better Linux-fu, but none of them generated as much discussion - and angst - as "PHP Code Review" (slides here).  Here's the description:

In this workshop, three PHP experts with different software engineering focuses (testing, architecture, and security) will perform an interactive code review together with the audience. Attendees of this lab will learn how experts look at code what good code and bad code looks like, and how to avoid the most common gotchas. They are invited to bring their own code for an anonymous code review for an increased benefit from the workshop.

Seemingly benign, right?  The reaction to the session was something else entirely.