As a maintainer of an open source project there are things that can help to make your role easier. One of them is encouraging useful issues being filed on the project with good information about the problem or suggestion. In this post to his site Sebastian De Deyne shares a few helpful hints on what can make for a good issue.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

His suggestions include:

• as much detail as possible ("X is broken" isn't useful)
• having a single point or suggestion per issue
• being polite (remember, open source maintainers aren't often paid for this work)

His last point might be the most important: making a human connection. Sometimes it's easy to forget that there's a real person on the other end of the line. If you work with the person reporting the issue rather than just focusing on the technical parts it can make it an easier and more pleasurable process for all involved.

On the SitePoint PHP blog editor Bruno Skvorc has written up an article that wonders if 9-to-5 developers can be good developers.

While picking talks for the conference he’s organizing, James Titcumb recently tweeted that well known speakers get picked over others because, among other things, they’re reliable (i.e. they don’t cancel). I would argue that “among other things” carries more weight – I believe that most conference organizers pick such talks and speakers because they like to play it safe and fear risks.

Bruno gets into some of his own opinions about conferences and speaker selections first, noting that he sees a lot of organizers "playing it safe" with topics and speakers (and the idea of "intellectual diversity"). He then talks about the 9-to-5 developers out there that haven't been exposed to a lot of these "safe" topics because they don't branch out of their corporate bubble and attend conferences. He ends the post reflecting on one of the most used excuses for not branching outside of work hours - time, it being a "precious resource" and ideas about balance.

The PHP Town Hall podcast has posted their 51st episode: Good Riddance. The most notable happening in this episode is the announcement of co-host Phil Sturgeon moving on and Amanda Folson taking his place.

In this episode Ben and Phil discuss what’s new in their pathetic little lives, the state of the PHP-FIG, and bid an ecstatic.. ahem.. sad farewell to Phil as he departs the podcast. Starting with Episode 51 [Amanda Folson](https://twitter.com/AmbassadorAwsum) will be taking over as co-host. Ben is staying so don’t worry, we know he’s your favorite.

Phil, Thanks for 51 fucking fantastic episodes, 5 years of podcasting together, way too much booze, and a lot of fun.

You can catch this latest episode in a few different ways: either through the in-page audio or video player, directly on YouTube or by downloading the mp3 of the show to listen offline. If you want to keep up with the latest episodes and happenings from the podcast, be sure to subscribe to their feed and follow them on Twitter to get the latest updates.

On the Laravel News site there's a new post that tries to answer the question "can you be a an expert developer in 10,000 hours?" This is based on some prior research (not specific to programming) that anyone can be an expert on anything in about 10 thousand hours worth of work and study on the subject. This post takes the ideas presented there and applies them to the world of development, trying to see if there's a good match.

Back in 1993, psychologists K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Romer said that 10,000 hours of deliberate practice of a specific skill will make one an expert. Fast forward 15 years, and Malcolm Gladwell’s Outliers made the 10,000 hours rule famous. And in 2012, Macklemore solidified it’s fact status: it officially takes 10,000 hours to be an expert at anything.

How does this rule correlate to coding? If you’ve been working full time as a dev for five years, you’d be considered an expert by the parameters of the rule. [...] The problem with the 10,000 hours rule to excellence is that most domains aren’t static.

The article goes on to talk about the ever-changing world of technology (as compared to static activities where the rules aren't going to change). They talk about the Laravel framework and how it has evolved since beta/version 1 and how, if the 10k rule is applied, no one is an "expert" as it changes so fast. There's also a link to a study that debunked the 10k rule and so they shift to trying to answer another question: how much does it take to be just considered "good"? This is related back to software engineering and where in the process could it be that you move from "good" to "great".

Maybe the real question here is instead of trying to be an expert software developer, what aspects of your job can you improve in 20 hours of practice? Maybe the focus shouldn’t just be on the code; after all, your job is more than just staring at glowing screens all day. Identifying specific areas of weakness that you can devote time to strengthening every week may be the key to becoming that expert that you desire to be.

On the Toptal.com site they've posted a guide that aims to help you write good code that stands the test of time. They provide six "commandments" that they think can help make your code better and easier to maintain in the future.

Specifically, “good code” is code that is easily and readily maintainable by an organization (not just by its author!) and will live for longer than just the sprint it was written in. The following are some things I’ve discovered in my career as an engineer at big companies and small, in the USA and abroad, that seem to correlate with maintainable, “good” software.

Their list includes suggestions like:

• Treat Your Code the Way You Want Other’s Code to Treat You
• Good Code Doesn’t Reinvent the Wheel, it Stands on the Shoulders of Giants
• Don’t Cross the Streams!
• When Possible, Let the Computer Do the Work

Each item on the list comes with a brief description with a bit more detail and how to apply it to your development. It's not focused on any one language, however, so there's no code samples here - just links to other resources and tools that can help in their application.

In this new post to the Laravel Daily site Povilas Korop shares the second episode of his video podcast "Laravel Business" and talks about releasing Laravel packages.

Here’s the 2nd episode of my new Laravel Business video show where once a week I share the thoughts about Laravel-related work from the business perspective, as I’m transitioning from being a developer to being an owner of a small team.

Today I talk about packages – is it worth releasing Laravel packages? What are pros and cons? And can you earn money on it?

You can watch the episode either using the in-page player or directly over on YouTube.

On the Source blog there's a great post that reinforces something that all developers should keep in mind when developing their applications: good code runs on good communication. "Tech language" barriers can make this difficult, but this post gives you a few suggestions on places to start improving.

When I started the interactive team at the Sun Sentinel in 2013, I thought the biggest challenge would be the code. I was wrong. [...] It wasn’t always easy. When you need someone on your side, but they don’t speak the same tech language, it can be very difficult. Investing (not necessarily financially, but emotionally and mentally) in creating a space where teams can work better together is key. Here are some strategies for overcoming the language barrier to make collaboration smoother.

They recommend things like:

• having face-to-face conversations to work out the best solutions
• avoiding assumptions about skill levels
• pausing to check and ensure everyone understands the current state of conversation
• agreeing on common terms and naming

Finally, they make a recommendation that could make some of the developers out their cringe a bit: "document the madness". As they point out, having good documentation of not only the result of the work but also the process along the way can be crucial for future work and others not directly involved in the process to review.

On the SitePoint Web Blog there's a recent post by George Fekete with a few suggestions about how to be a good developer, regardless of the language or technology you're using.

As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day. What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art. In this article, you’ll learn about how to be a better developer by following the “etiquette” of programming and you’ll learn how to use this information to perhaps teach others to better themselves.

He starts with some tips about "being professional" overall that include things like being responsible and having a strong work ethic. Then he moves into writing good code. This isn't about actual code examples, more about good practices and tools. He also shares some tips about how to keep things (and yourself) on track and tips on how to "be a master" when it comes to social interactions and the work you're doing.

In two new posts to his site Stanislav Malyshev takes a look both forward and back at the PHP language, where it came from in the 5.4 version and ahead into the just released 5.6 version discussing the good, bad and road ahead.

With 5.6.0 having been released and 5.4 branch nearing its well-earned retirement in security-fixes-only status I decided to try and revive this blog. As the last post before the long hiatus was about the release of the 5.4, I think it makes sense to look back and see how 5.4 has been doing so far.

Having taken a look in the past, now it’s time to look into the future, namely 5.6 (PHP 7 is the future future, we’ll get there eventually). So I’d like to make some predictions of what would work well and not so well and then see if it would make sense in two years or turn out completely wrong.

In the look back at 5.4 he talks about some of the good (the release process, $this in closures) and some of the "not so good" including traits and the overall adoption rate. He also includes a few "don't know" items such as the overall performance and the inclusion of the mysqlnd driver. In the look forward he talks about the impact of things like constant expressions, phpdbg and function/constant importing (for better or for worse). He also briefly mentions two hurdles to the adoption of 5.6: OpenSSL becoming more strict and the overall adoption rate.

In Volker Dusch's latest post he makes a suggestion to the PHP community as a whole - stop pretending PHP is a good language and admit its flaws where it has them.

I'm currently observing two kinds of discussions around the core PHP language. A couple of folks say "Sure the language sucks but look at all the amazing stuff we build with it!" and the other camp goes "Look at all the amazing stuff we build - The language can't be that bad!". The main point here is that the PHP applications that have been created over the years are incredible. [...] The astonishing dominance of PHP in the Web doesn't come from the fact that it is a good language, it comes from the fact that it allowed people to create and maintain things that are really useful.

He gets into some of the "it's not okay when..." kinds of things that PHP allows, things like:

• Presenting the user with the "White Page of Death" when the script dies because of an error
• Output of basic operations could depend on the environment it's run in
• Problems with type hinting
• Not being able to talk to two backend sources at once

He also suggests a few things that you can do to help the situation including not sending angry emails to the internals mailing list and contribute back with something useful instead (like RFCs).

The claim that "PHP is this awesome enabling language that let's you focus on doing awesome things" doesn't hold up when all of the gains are wasting dealing with the obtuse errors.