When the highly esteemed Zend'er Cal Evans was in DC earlier this week, a number of local DCPHP'ers met up with him for drinks.

One of the hottest topics we discussed was conferences. He - and much of the PHP Community on Twitter - are currently at php|tek in Chicago. Then we have the 2008 DCPHP Conference in less than two weeks. Then we have ZendCon 2008 in September.

And the question always comes up...

Why should I go to these conferences?

Well, they're fun.

But don't tell you boss that.

This past week, an interesting article hit my radar from Wired magazine, titled simply "Top 5 Reasons It Sucks to Be an Engineering Student". As a former engineering student myself*, I thought I'd share some perspective on this one...

First, yes, most of the textbooks are awful. Some of them are beyond awful.. some of the worst ones are written by your own profs.

I remember getting chewed out by my Department Head and having to apologize to another Department Head when I publicly criticized the choice in a text book change and would not allow usage of the old book. Yes, because apparently thermo tables changed somewhere in the last year... oh wait, it was that Department Head's book. ;) That said, the single best "book" I had was a 90 page super cliff-notes guide to circuit analysis written by another prof. I still keep that one on hand.

A long, long time ago before I started CaseySoftware, I didn't understand the point of an introduction.  I considered it irrelevant and not all that important to day to day business, goals, or even your personal/professional standing...

Ah, one of the joys of the new year is that everyone makes commitments that they're going to keep this year. It doesn't matter that they failed last year or the year before at the exact same thing going about it the exact same way... this year they're going to do it.

Well, this year in addition to the goals for CaseySoftware, I've set a trio of major goals for myself... one professional and the other two personal. Each one is a daily task that I've already been doing for a while. About a year ago, I adopted a simple practice of marking my calendar when the task got done.

I didn't really think of the implications of it until the New Year started this week... and read Quadzilla's post on How to Keep Your New Years Resolutions & Achieve all Your Goals:

You see, it’s easy to do things one day at a time or one moment at a time. That’s the secret of maintained willpower. As long as you don’t break the chain today, you’ll be fine (because tomorrow you can tell yourself the same thing).

Don’t break the chain.

I generally don't use this space to get quite this personal, but after an enlightening conversation yesterday and this being Christmas Eve, I figured "why not?"

In a gross overgeneralization, one of the problems with an engineer mindset like mine is that we tend to follow formulas. We learn early on that formulas work, they're predictable, and we know how to interact with them. While I consider my ability to improve to be one of my most valuable talents, I find myself falling into formulas now and then in my personal life, but hadn't thought about it much in my professional life. So the conversation yesterday struck me. Here's the other half (and the important part) of the conversation:

I realized that when I give you specifics you stick to them

it's best to not give you specifics have you figure it our and let you have the room to explore and be creative

I need you on your toes

well...being a leader is finding what's best for those around you, although it might for a little while be tougher on you and on them

you are welcome...and it's what's best for all of us. I have to know that you can make the best decisions in my absence based on you not on just on what I would do or the guidelines provided...that's how the right decisions will be made

Disclaimer: The author of this book - Bob Walsh - was a CodeSniper last year, set me up with a free copy of this latest work, and recently invited me to contribute to the new Business of Software Wiki on Joel On Software. I may be biased, but would I buy it again? Read on...

When I left on my most recent cross-country trip for the MySQL Conference in April, I brought this book along. I had already had the book sitting on my shelf for a couple weeks and knew I should give it a shot. After reading the Cluetrain Manifesto a few years ago, I thought it would be old hat. "Yes, markets are conversations... yes, people should blog... yes, people can learn from each other." You know what I mean, the same old stuff, different day. But I was pleasantly surprised... then as I dug in, whoa.

While clearing out my reading stack a few weeks ago, I was flipping through IEEE Computer and came across this article: Assessing the Health of Open Source Communities and as a member of the Open Source community for 5+ years now, I found it fascinating. First a quick summary and then I'll get to the guts.

The first big aspect discussed is the shape of the community. The authors point towards an onion model being the most common and normally the most effective. This consists of a Founder, Release Coordinate, and Core Developers. In most cases this is a small group of people that have been working together for a while, are familiar with each other, and generally set the direction, pace, and tone of the project. Next, we have the Codevelopers. These are individuals who can't commit directly to the codebase but are making and submitting fixes for review. As time progresses, they can move into the Core Developer group but don't always. Next, we have the Active Users who know how to use the system, provide comment, feedback, and often basic user support. Finally, we have the Passive Users who are simply there and don't do much.