On the DotDev site there's an article from Sharon Steed with a reminder to the developers out there - it's not all about the code (despite what it may seem like in the job description).

Soft skills get a bad rap; especially in tech. Code has always been king, but software constantly changes. The need to be good communicators and generally pleasant coworkers will always be there. That’s why it’s important to dedicate parts of your day to improving those skills that don’t involve code. No matter how great of a dev you are, you aren’t going to to be nearly as successful if you are difficult to be around. Here are a few soft skills crucial to working in tech.

She covers four major topics around these "soft skills", what they are and what you can do to help improve them:

• Being Accessible
• Solving People Problems
• Keeping Your Ego in Check
• Considering the Big Picture

She ends the post by reminding developers that code is only "one part of the machine" and that by developing soft skills you can much more easily further your career as a developer, regardless of how amazing or clean or manageable your code may be.

In a new post to his site Frank de Jonge shares his "battle log" when looking into routing performance considerations in Symfony after a "deep dive" into the component's code.

Last week I took a deep dive into Symfony's Routing Component. A project I worked on suffered from a huge performance penalty caused by a routing mistake. This lead me on the path to discovering some interesting performance considerations. Some common practices align nicely with Symfony's optimisations, let's look into those.

He starts off by describing the process he took to start the investigation and what prompted him to investigate the performance issue. He talks about his use of profiling to locate the bottleneck and track down the root cause. He answers the five "why's" about the issue and uses that to guide an approach. Ultimately he located the source of the issue - YAML parsing that shouldn't have been needed - and what the component does to make it more performant in non-development environments. He ends the post with a list of four performance considerations as you're going through your own development to get the most out of the component.

Ralph Schindler has a new post to his blog describing some of the what he's done to understand dependency injection in PHP and includes some illustrations to share that information.

Whatever the reason, one of the newest concepts (at least over the past 3 years or so) that has emerged as one of our heated topics of debate is how to manage object dependencies. Interestingly, the argument of how to manage dependencies is generally named by the solution which it’s proponents give as the solution: dependency injection (the abstract principle is actually called Inversion of control).

He starts with simple examples - pushing an object into the creation of another - and backfills with a brief history of dependencies in PHP applications for a little context. He talks about DI frameworks like Spring and some of the other criticisms and thoughts you'll need to consider when using DI (and DI containers) during development and deployment.

Brandon Savage has posted his own response to the "don't be afraid of the upgrade" thread that's been going around concerning updating to PHP 5.3. He takes a different approach to the matter, though - one of a bit more caution.

When it comes to open source projects endorsing PHP 5.3 as their one and only PHP platform, I encourage caution. When it comes to open source projects that use PHP, there are three main issues that I believe should be considered before making the leap to PHP 5.3 (or any new release of any new software).

He sees three considerations projects and companies should consider before making the upgrade on their servers - the amount of control you have over the environment, deciding if the upgrade is worth possible backwards compatibility breaks and how much support you want to still provide for the pre-5.3 version(s).