After the recent beating I gave Packt Publishing's "PHP Team Development" , I had a number of people ask what books I would recommend.  To be honest, that's one of the easiest questions I've gotten in a while.  And that's because when we put together Blue Parabola about a year ago, I had the chance to make this list exactly.  There are about 5 books that I believe should be in nearly any software developer's library:

At last month's DCPHP meeting, we did our first Code Review.  I wasn't sure how it would go or even if anyone would participate but when I put out the call for code samples, one of our long-time and respected members stepped up.  He provided us with a nice little ~100 line PHP class that was relatively self-contained but obviously part of a larger application.  All in all, a great example.

Obviously, one of the things that gets people worked up about Code Reviews - or showing their work in general - is that other people will look at their work.

To be blunt:  Well, duh.  That's the point of a Code Review.

A few months ago, I heard an interesting idea about the 2nd Worst Developer.  It's wrapped up in a simple statement:

... the quality of a software system is proportional to the skills of the second worst programmer

While at first pass, that may seem to be a silly statement, but here's why:

... everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.

On small teams with short projects and even shorter deadlines, this problem is multiplied.  Not only are you dealing with overlooked problems, but you're dealing with less-than-perfect decisions consciously made to "get it launched".  Now you have two problems that compound on each other... Brandon Savage covers this one well in "Paying Down Technical Debt".

In the past few years, I've had the opportunity to review resumes from job candidates, friends, family, and random ones that I find online.  Some have been great, some have been good, but the vast majority are boring, worthless crap.  Considering the current economic times, I thought I should share some tips.

Disclosure: I didn't come up with these myself.  I went to a fantastic undergraduate school - Rose-Hulman - where the Career Services team hammered us on most of them.  From there, I've gotten more creative and added a few of my own.

First off, use the spell checker.  Spelling mistaces macke yuo look liek a maroon.

In my regular web wanderings this morning, I found something interesting.  A company that I'm familiar with just released v3.0 of their primary product.  At first glance, I was happy for them, then I remembered something odd, they released v1.0 early this year.  By all standards, going from v1.0 to v3.0 in under a year is aggressive... so I started to dig and found something interesting:

V1.0 was released in February...

v2.0 was released in July...

v3.0 was released in December...

with no point releases in between.

Wha?

That's right, they had three major releases in a 10 month span with no minor releases in the interim... which poses an interesting question about using their system:

What is compatible with what?

Yesterday marked four years of blogging for me.  While I can go on about how things have changed for me personally and professionally, I'd rather talk about the technology market... it's much more interesting.

Four years ago...

We were still recoving from the dotcom bust, now we're heading into rough times.

The concept of "web 2.0" was new and not horribly hammered into everyone's heads.

Social Networks were just coming online... Twitter didn't exist.

Although PHP had been around for about 9 years, it was just beginning to creap into the public spotlight.  The first ZendCon wouldn't happen for another year.

Any and all discussion and information in this post should be taken as professional commentary and analysis for a US-based audience, not legal advice.  Nothing on this site should be taken as legal advice.  When in doubt, talk to an attorney.  When not in doubt, talk to an attorney.  Either way, do some research first and have intelligent questions for them.  It will save you time, money, and stress.

Every so often in my professional life, I get a Non-compete Agreement across my desk.  The vast majority of them are along the lines of "you can't solicit our customers, we can't solicit yours for N months/years".  A few are along the lines of "any inside information learned from us cannot be used for anything other than what we authorize".

I find both of these to be reasonable and normally sign them with little - if any - hesitancy.