Adam Culp has a great new post to his site sharing some of his thoughts and advice about advancing in a career in development for those that might feel a bit "stuck".

As the organizer of the SoFloPHP User Group I am often approached by entry to mid-level developers asking what they can do to advance in their career or become better developers. Of course I am nowhere near perfect but have been around long enough to get a few bumps and bruises along the way, so [this list] is what I usually share as some pointers.

Some of the things are PHP-specific, but a lot are just general good practices any developer should follow. His list includes things like:

• It's okay to stay up late once and a while, but get some sleep
• Track your time and get in the habit of knowing what you did with each hour
• Certifications will not actually carry much value on your resume, so I would not make them a main focus.
• Pick an IDE to use and learn it FULLY. I will not recommend one in this post, so explore and find one that fits how you want to work.
• Always strive to make yourself replaceable. If you are replaceable you are also promotable, and you can go on vacation pain free.

He also suggests learning a few other tools like git (and github), a good IDE and having a "pet" full-stack framework. Check out the full post for more great tips.

On the PHPClasses.org blog today Manuel Lemos has shared some advice on tracking and fixing bugs and some strategies to help prevent them in the future.

No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs. Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover. Read this article to learn about a several good practices that you can apply to track bugs in production code, so you can fix them before it is too late.

Suggestions included in his list are things like:

• Test as Much as Possible Before in your Development Environment
• Separate your Code from Environment Configuration files
• Track PHP Errors with Assertion Condition Tests
• Send PHP Errors to an Error Log File
• Monitor the PHP Error Log File to Quickly Fix Serious Bugs
• Fix Your Bugs but Never Edit Code on the Production Server

He also includes a brief look at some things to think about when considering "defensive coding practices" and links to other articles with more information.

On 7PHP.com there's a new interview posted with a PHP community member, Craig Willis, about starting a user group.

This is the #1st set of How To Start A PHP user group in an attempt to help PHP guys all around the world to spring out a local PHP user group if they do not have one nearby. So before you embark on this journey, you need to know what you have to expect, how to prepare yourself, the pitfalls, the to-do lists, the workload behind, the commitment behind and above all the gratification this can bring to your PHP life.

Craig, the founder of the Leeds PHP User Group. He talks about starting the user group, some of the challenges involved and a few tips to help you get started. He also shares a few helpful hints about keeping the group going and how to plan/find speakers.

On NetTuts.com today they've posted a list of tips they think will help you learn a new technology faster. They've broken it up into ten different steps, some which could be done at any time but some have a bit more of an order.

We live in a very exciting time. Never before has education been so cheaply available to the masses (if not free). The medium, itself, has made tectonic shifts from a classroom setting, to blogs, screencasts and complete university classes, as a set of videos and interactive forums. Given these resources, there's absolutely no excuse not to dive in and learn. However, with such a wealth of resources, filtering through the options can often become overwhelming. In this article, I will outline a simple process to kick-start your education.

Among the items in their list there's things like:

• "Let the Information Flow Begin"
• "Listen and Watch"
• "Blogging"
• "Feel the Pulse"
• "Meetups and Conferences"

Each tip comes with a bit of description and some links to other resources and tools that can help you along your way.

PHPMaster.com has posted a list of six things they think you should think about as you're selecting the framework for your next application.

You've decided that it makes sense to use a framework when writing your next new application, and chances are that if you're already familiar with a specific framework, then you'll probably be leaning towards using that one when you start. But are you sure it's really the most appropriate for the task at hand? In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you're not programming "against the grain" and also to make sure it will be able to meet your needs now and in the long-term.

He doesn't get into any specifics of any PHP frameworks out there, but suggests general questions to ask even before getting too deep into the technology:

• What do I need from the framework?
• Do I expect the framework to help manage consistency?
• Is good documentation available?
• Is the framework actively developed, and does it have an active user base?
• Does the framework work in what I run in production?
• What business factors are influencing my decision?

Not every application needs to be written using a framework. But if you've decided that yours does, then it's beneficial to compare your needs against the features and benefits of the various framework offerings.

On Reddit.com a discussion has started up around a question asked about legacy application migration - things to consider when moving a large existing project onto a framework.

I am working for an online store that has a codebase which has spanned dozens of developers and has been constantly upgraded. The codebase has its problems but it is not too bad. I would love to put it onto a framework like laravel and systematically start cleaning up as I go, but I am unsure if it will work trying to shove a framework into the current site. Has anyone done something similar, it would take me months to rewrite the whole system, has anyone done something like this successfully? Any advice would be appreciated.

There's lots of good recommendations made in the comments including:

• "If it were me, I'd take a step back before trying to build on top of a framework. I'd start by refactoring the existing codebase out into PSR-0 compliant namespace."
• "In my experience you only rewrite an entire application if what you have has become too expensive to maintain. At this point it is actually more cost effective to rewrite it using a framework."
• "We have recently moved our website to the Symfony2 framework at my company [...] it definitely is not a one programmer job."
• "Whatever you do, replace one bit at a time. And always strive to de-couple code."

Read up on the rest of the responses or add your own to the post.

On Reddit.com recently, it was asked what kinds of things someone would need to know if trying to move from being a senior developer to a lead developer in their role. There's lots of answers - some serious, some not - but it's an interesting read.

I'm fairly confident that I am able to move into a lead developer role quite easily. I have worked in many places where the CTO was so incompetent that I've ended up doing a CTO's job as well as coding. Now I want to find a job where I can be a good lead developer. I might have some holes in my self-taught PHP knowledge, so what do you think I should know?

Some of the recommendations include:

• "The lead engineer is not the smartest guy in the room. Sometimes you will know the right answer, but just telling people what to do won't always get the right results. Ask them how to solve problems and let them own it."
• "It may be different where you are but I expect lead developers to be more of a 'lead' as in 'leader' than 'lead' as in 'best developer'. That is, you'll probably be expected to actually manage, delegate, and architect on top of your development abilities."
• "The lead dev will guarantee the whole architecture of the application and the processes of development."
• "If you, as a lead dev, are project managing then your employer is doing it VERY wrong."

Check out the full post for more discussion and to add your own thoughts.

In his most recent post Chris Hartjes looks at the concept of "test whenever" (vs TDD) development practices and how, sometimes, writing tests for things that are may get tossed when they're done may not be the best option.

Let's look at TDD vs. Test whenever. The trade-off being made here is not about quality of code or guarding against regressions. It's about opportunity cost. This had occurred to me but I had dismissed it as being "anti-testing". But I think I was wrong, and here's why.

He talks some about a presentation from Dan North< ("Decisions, Decisions") about when to test (not whether to test or not) and how he noticed his development team was being very productive, but with a "spike and stabilize" development method. He also talks about the concept of "opportunity cost" and how it plays a factor in when tests are introduced to the process.

The key to all this is being able to identify at what stage in this particular pattern your code is at. Is it still a spike, meaning you are working out implementation details and trying to figure out if it will even have the desired result? Or is it stable, providing solid value to the application as a whole and ready to be wrapped in tests to protect against regressions?

Adam Culp has written up a great post with some good suggestions about how you can more effectively foster a better technology community in your area or company.

As most know, I am the organizer of the South Florida PHP Users Group and I am passionate about helping the PHP community grow in south Florida. Over my years as a developer I have noticed the decline of technology in this market, and specifically the PHP community. It was this that led me to organize a group dedicated to turning this trend around, and and grow the PHP community rather than continue to watch it decline.

He shares suggestions on a few different topics, spurred by a conversation at a recent meeting he attended:

• Having a litte-to-no distraction workplace
• Being open to telecommute/remote workers
• Avoiding the "sweat shop" mentality
• Advocating bringing in a fresh perspective (hiring an entry-level dev)
• Supporting company-provided training opportunities
• Respect them as professionals
• Not worrying as much about salary and more about the quality of the developerA

Chris Hartjes has written up a new post for his site, So you want to write tests, giving a good overview of some of the things you'll need to consider when wanting to move into a more test-friendly development world.

I often get asked for some advice on how to get started with writing tests for your PHP code. It's a fair question, since I am presenting myself as an expert-ninja-rockstar-sensei-opinionated-egomaniac on the topic. I often struggle with coming up with an answer that can fit into the 140 characters available via Twitter, but clearly this is not a good strategy. As an early Christmas 2012 present to all my loyal followers, who put up with my never-ending stream of nonsense and provide a slowly-increasing portion of my income, here are my thoughts on how to get started with testing your PHP code.

He offers a list of suggestions, each with a bit of explanation:

• Learn how to recognize untestable code
• Keep learning the language
• Chain units of code together for greatness
• Start asking "how am I going to test this?"
• Stop people from pushing code without proof it's fixed
• Stop people from doing things manually
• Stop using tools without test suites
• Always wonder if you're doing it right