There's an interesting post over on the Hut 8 Labs blog looking at overconfidence in developers and how it effects their estimations of the time it takes to get things done.

I'm going to talk today about what goes on in inside developers' heads when they make estimates, why that's so hard to fix, and how I personally figured out how to live and write software (for very happy business owners) even though my estimates are just as brutally unreliable as ever. But first, a story.

He talks about one of his own experiences about overconfidence and how he found a connection point in a section of a book with it as it talked about overconfidence. He talks about why you (we, as developers) suck at making estimates and how it should be less of a "how long to do it" question and more of a "how confident am I that I can do it" question. He points out that there are some situations where estimations don't suck - 0-12 hour tasks.

So what do we do? Just accept that all our projects are doomed to failure? That we'll have poisoned relationships with the rest of the business, because we'll always be failing to meet our promises? The key is that you first accept that making accurate long-term estimates is fundamentally impossible. Once you've done that, you can tackle a challenge which, though extremely difficult, can be met: how you can your dev team generate a ton of value, even though you can not make meaningful long-term estimates?

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.

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.