Chris Roane has put together a list of things that he wishes someone would have told him back when he was starting out as a web programmer ten years ago, helpful hints that could have made things easier in the long run.

When I reflect on my past experience as a web programmer, there are many things that I know now that I didn't know ten years ago. The learning process was valuable, but I could have been at a different spot today as a PHP web programmer if I knew these things earlier. Sometimes you don't have the info when it would benefit you the most, but my hope is that this list will give you something to reflect on.

Most of the tips a more of the general tech nature with a few non-tech ones thrown in. Here's a few examples:

• Over Estimate Your Time
• Don't Assume that Where You are Working is the Best Opportunity
• Learn How to Use and Work with SVN
• Master Organization
• Learn Outside of Work

Read the full post for more great tips.

Many software developers (the ones that haven't been in on a start-up usually) are tempted to make the jump into the seemingly glamorous start-up world to build that next killer web app. Keith Casey has posted a bit of a reality check for developers thinking of making the move.

In the last few weeks, I've talked with a number of friends about career changes. Some are feeling antsy and just want to move, others are starting their own consulting, and others are starting and joining startups. While I've done all the above - to varying levels of failure success - I thought I'd share the things I've learned along the way.

He gives six things to keep an eye out for when considering your entry into the startup world:

• Everyone does everything
• There's no career path
• You never have enough money
• v1.0 never looks like the original Vision
• Every founder believes in him/herself
• Most startups don't explode, they fizzle

He's not saying all of this to push you away from startups, though - more to help you go in "with eyes open" and ready to ask the harder questions before you get into a bad situation.

Brandon Savage has a reminder for both those familiar with PHP and a warning for those new to the language - take the examples in the comments of the PHP.net with a grain of salt.

This morning, I was reviewing the weekly list of topics with the most comments throughout the PHP manual, and I stumbled upon the following code in the documentation for the date() function. This code is designed to tell you the day of the week for any valid date you give it. [...] I'm sure that this user put a lot of work and effort into this function. I'm sure they were excited to share it with the PHP community. I'm sure they thought they had stumbled on a solution to a problem that everyone needed to solve. I'm sure they had no idea that this code is a great example of using PHP precisely the wrong way.

His example, one that uses around 30 lines of code to do something that date could accomplish in one, is a perfect example of why blindly following the advice of others without thinking things through can be disastrous for your code. Do a bit of research before you cut and paste and remember that with someone else's code could come someone else's problems - think before you implement.

Following up on a previous post looking at characteristics of crappy software, PHPFreaks.com has posted ten more tips - this time, though, they're recommendations about how you can avoid writing crappy code of your own.

Here's their list:

• Learn OOP and common OO principles
• Employ Test Driven Design
• Refactor, refactor, refactor
• Simpler is better
• Use Design Patterns
• Don't Use Design Patterns
• Accept the limitations of your language
• Pretend you are writing a book
• Peer Review
• E_STRICT is your friend
• Create a distinction between "source code" and a "build"

That's right - there's a bonus one thrown in there to help out just a bit more. There's some good tips in there that any developer could benefit from no matter the skill level. They may not all be at your level, but at least they give you something to shoot for.

If you're a developer out there and are looking for that next job (contract or otherwise), you might check out this advice from Cal Evans as to what he, a hiring manager in the past, has looked for in a developer's resume.

am often asked to take a look at friends resume to give pointers on how that can make it more effective. Invariably, my advice is the same, so I'll share it here. When I was a manager and in charge of hiring, your resume had to get my attention for me to even consider it. If you got my attention, you had a much better chance at getting the job. That's the secret: get my attention, and get the job.

He points out that the usual situation is one manager to a large group of applicants. You may see the job post once, but so do 30 other people and you're all trying to grab attention. What's his recommendation? Brevity. Keep the first page short then dive deep behind that. There's more great tips in the rest of the post.

Stuart Herbert has asked for some suggestions for the "conference virgin" to know about before heading (and/or speaking) at their first conference.

I'm speaking at the PHPNW '08 conference in November, and I've just been contacted for advice by someone understandably excited at going to her very first conference. Thing is, I've never been a conference newbie (I've always been either speaking or running a conference) so I'm not the best person to offer advice on this.

His suggestions include meeting up with friends also attending, keeping an eye out for social groups to be a part of and to bring a laptop along with you ("a lot of the conversation at the conference happens online"). The comments have some suggestions too like "don't eat alone" and "hang out in the hall if there's no talks that interested you. it's a great way to meet others."

The NETTUTS website has posted a top ten list of things from the PHP masters out there, a few words of wisdom to live by. Here's the list along with the authors of each:

• Use PHP Only When You Need it - Rasmus Lerdorf
• Use Many Tables With PHP and MYSQL for Scalability - Matt Mullenweg
• Never, ever trust your users - Dave Child
• Invest in PHP Caching - Ben Balbo
• Speed up PHP Development with an IDE, Templates and Snippets - Chad Kieffer
• Make Better Use of PHP's Filter Functions - Joey Sochacki
• Use a PHP Framework - Josh Sharp
• Don't use a PHP Framework - Rasmus Lerdorf
• Use Batch Processing - Jack D. Herrington
• Turn on Error Reporting Immediately - David Cummings

Some of them are conflicting, but that just means that you'll have to do what you've always done - take advice with a grain of salt and ultimately decide what's best for you and your application.

As the Zend Developer Zone points out there's a new interview over on the PHPWomen.org website with Nancy Wichmann, one of the members of the PHP Women group, about some of her development experiences.

NancyW - a well known drupal developer, documentation contributor, module developer/maintainer apart from these a prestigious WOMEN in the world of opensource.

The interviewer asks a wide range of questions (with some interesting answers!) on topics ranging from her college major, how she got interested in Drupal out to things like her good/bad experiences in the open source world and some advice for those new to the community.

In a new entry on his blog today, Jeremy Privett shares some of his thoughts and asks the question that's crossed more than a few developers' minds out there - "is PHP doomed?"

As an outsider looking in, and being a realist instead of a fanboy, I'm finding it extremely hard to believe that PHP is going to continue its much hyped and proclaimed success in its current circumstances.

From his point of view there's a few things that, if the web was exposed to (like "tiffs that occur on PHP Internals") PHP's popularity would fade quite a bit.

As much as I hate to say this...You guys really need to take some advice from Ruby Devs. I've been watching the Dev List over there and following it as well, and I don't see even half of the virtual crap-flinging that's almost become an everyday occurrence on the PHP Internals list.