In a new post to her site Francesca Krihely starts looking at the developer experience - how developers relate to your service and product and what kinds of things you need to be doing to help engage them.

I had a great brainstorm a few weeks back with the members of the Developer Evangelists meetup on the topic of the User Journey, or as I'll call it now, the Developer Experience. The main problem we wanted to solve was how we convert new users into experts or awesoms users. In many ways, a Community Manager and/or Developer Evangelist is responsible for driving user adoption and making users successful, so this is a topic near and dear to all of our hearts. I walked away with three key things that help improve the developer experience: Great Product, Great Support and Empowerment.

This post talks about the first point - the "great product" - and notes that, if the product isn't useful and enjoyable to use, even developers won't bother with it. She also talks some about the need for quality documentation and how it can be seen as a sort of "marketing" to developers.

Work on making your product fit for an awesome developer experience. If you build it, they will come.

NetTus.com has followed up their previous article covering some of the basics of the HTTP protocol with this new post, part 2 of the series. They suggest that HTTP, the messaging format of the web, is the one protocol that every web developer should know.

In my previous article, we covered some of HTTP's basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we'll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

Davey Shafik, a long-time PHP developer and community member/speaker, recently had to learn Ruby on Rails for a project at work. He's shared some of the experience (from the perspective of a PHP developer) in a recent post on the Engine Yard blog.

I know PHP. I mean, I really know PHP. Not just the syntax, or the idioms and idiosyncrasies, but why. I can tell you why something works the way it does, under the hood; and I was probably around when the decision was made to do it that way. Thirteen years with any language is a long time. [...] Ultimately, it comes down to: Is it the right tool for the task? Because of this, ultimately when I come to write a web site, PHP is my tool of choice. Know thy tool well, and it shall treat you well. Then along came Engine Yard, and I was exposed to just a ton of fantastic engineers who happen to choose Ruby as their tool of choice.

His project was the site for the Distill conference Engine Yard is putting on in August. He lists a few "WTF" moments he came across when learning and creating the site with Ruby including issues with parentheses on metod calls, method naming rules, implicit returns and variations on control structures. He also talks about some of the other technologies used to power the site like OAuth and S3 for image uploads (via paperclip). He finishes out the post by wrapping up the experience and talking some about the benefits of getting outside your comfort zone and learning something wildly new (language or other technology) to give you perspective.

Anthony Ferrara has posted his latest episode of his "Programming with Anthony" video series, this time he talks about becoming a better developer (hint: it's not about knowing everything).

In today's episode, I talk a little bit about what it takes to become a better developer. Nobody will ever expect you to know everything, but you better know how to find it...

You can watch the video either in his post or over on YouTube. He also has this and his other videos set up in a playlist if you'd like to see coverage of other topics like design patterns, iterators, dependency injection and prepared statements.

Eran Galperin has a new post to his site today talking about the real cost of software development, how it's more than just time spent hands-to-keyboard.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

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.

If you're a PHP developer and have ever wanted to branch out into learning another language, Node.js is a popular choice right now. To help you ease into some of the concepts that Node development involves, Francois Zaninotto has come up with his "Node.js for PHP Developers" series of posts (4 of them now, one previously mentioned here):

• Part One - Event Driven Programming
• Part Two - Modules, Packages and the Strawberry House
• Part Three - Exceptions and Errors
• Part Four - Streams

in each article he provides code examples showing "the Node way" versus "the PHP way" to do various things. It's a great little series and can definitely kickstart your Node.js knowledge.

On NetTuts.com there's a great list of tips and things to keep in mind if you're a budding programmer - a set of common pitfalls to watch out for as you hone your skills.

Regardless of our current skill level, we all were beginners at one point in time. Making classic beginner mistakes comes with the territory. Today, we've asked a variety of Nettuts+ staff authors to chime in with their list of pitfalls and solutions - in a variety of languages. Learn from our mistakes; don't do these things!

The article starts off with some Javascript tips, but quickly gets into some more PHP specific things like:

• Use Ternary When Appropriate
• Use Guard Clauses
• Keep Methods Maintainable
• Avoid Deep Nesting
• Don't Overuse Variables

There's also two "extras" thrown in more concerning general programming practices - using methods to represent actions and some basic code readability suggestions.

On the Smashing Magazine site today they've posted a list of powerful CLI tools that every developer should at least know about to help make their lives easier - six of them ranging from SSH tunnels to HTTP testing.

Good tools are invaluable in figuring out where problems lie, and can also help to prevent problems from occurring in the first place, or just help you to be more efficient in general. Command line tools are particularly useful because they lend themselves well to automation and scripting, where they can be combined and reused in all sorts of different ways. Here we cover six particularly powerful and versatile tools which can help make your life a little bit easier.

The tools they mention are all things you'd install on a unix-based system:

• Curl
• Ngrep (network packet searching)
• Netcat (to work with network connections)
• Sshuttle (SSH tunneling)
• Siege (HTTP benchmarking)
• Mitmproxy (capturing proxy, both HTTP and HTTPS)

Michael Kimsal has a new post to his site with some recommendations for web developers as to the things they should know to do their job well.

The original question from was a 16 year old who's been doing some basic CRUD apps, but is getting bored and wanted to move on to 'real' development. There were some good replies, but few went in to the depth of detail that I think beginners are even aware of. Granted, this might scare off some, but for others it might give them some ideas about what's possible and what's involved in professional web development. I know I'm going to leave off some topics, so feel free to add on!

He touches on topics ranging from version control to performance and even a mention of mobile development. Each section includes a brief summary of the topic and some have specific topics to check out to help narrow things down to the important parts.