In a new tongue-in-cheek (humor) post to his site, Tomas Votruba shows you how to criticize like a senior programmer when offering feedback on code errors or architecture decisions.

As I spend most of my socials online time on Github and PHP-related discussion, I've noticed many people do so many wrong things while giving critics. I want to correct this once and for all, so I've prepared a guide for you.

His recommendations (again, the opposite of what is actually useful) include and eight step process to find a bug, never reversing your stance, repeating the same comments over and over and always telling, never asking. Following this list of "not to dos" he also includes a list of "to dos" correcting the misconceptions. This list includes:

• asking if feedback is desired
• determining your motivation for the feedback
• replacing "you" with "I"

In each recommendation there's examples of phrasing and comments that give you some guidance on how you can be more effective at giving feedback on projects and code.

On the Maatwebsite Medium.com site they've posted a retrospective of their last several years of work on the Laravel Excel Open Source package.

Laravel Excel (https://github.com/Maatwebsite/Laravel-Excel) turned 4 years last November and has reached almost 6 million Packagist downloads. A good time to reflect on 4,5 years of open source development.

The article starts with a bit of history behind the initial development of the package as a simple wrapper around PHPExcel. It covers some of the initial syntax of the tool and features included from the start. The project moved on to v1.x with a complete rewrite and then into v2.x with support for the Laravel v5.x framework releases. It then talks about their "support conundrum" as they reached 1 (then, later, 6) million package downloads. They cover some of the usual project support issues, a reduction in their work on the package and how they worked to "fix it for everyone".

The post also talks about their "open source rehab" and how it changed their view from its recent "because 1 million people use it" back to making a difference in developers' lives. It finishes up talking about some of the "lessons learned" in how it worked with Laravel, a retrospective on its current state and a look forward at Laravel Excel v3.0.

Anna Filina has a quick new post to her site today with some helpful tips on how to motivate your developers (and coworkers) to make for the best end result.

When developers are not motivated, progress is slow and quality is low. This ultimately affects company revenues and can lead to reduced opportunities for all employees. Motivation leads in the opposite direction: wealth and happiness. The first thing to understand about motivation is that it’s internal. We can’t force someone to become motivated, but we can still have a strong influence. Here are my top three picks to increase motivation from my presentation at IPC 2013 in Berlin.

Her top three are:

• Setting goals for the group and a purpose for making it good
• Focus on the "small wins" sometimes to keep motivation high
• Let developers use their full range of talents, don't force them into one niche

Anthony Ferrara has a new post today on his blog with some things he think you can do to become a better overall developer (and not just in PHP). He shares six things from his own experience to help answer this question.

One of the most frequent questions that I get asked is "How can I become a better developer?" I think that it's a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it's really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I've seen in others.

The things on his list are pretty simple, but they're easy to forget in your day to day development life. Things like being motivated to better yourself, gaining confidence in your abilities, sharing your knowledge and/or becoming a mentor to developers with less experience than you. Interestingly enough, this last one can sometimes teach you a little something about you and your processes too.

On the Blue Parabola blog Keith Casey has posed a question about the motivations for working on an Open Source project - "Why help/contribute to a project? What's your motivation?"

It's a very good question and the answer should sound familiar to quite a few people...despite working on some fun and amazing projects, I had nothing to show for it because all were proprietary and some were even classified. As far as my professional career went, I had nothing to show for it. I had some stellar references and could talk (in vauge terms) about some things but I had zero code.

To fix things, he set about to build his missing portfolio of "show it to anyone" code that he could hand to a potential employer to show the quality of his work. This produced a nice side effect too - an influence for the better on his "real work" at his job (see this article for more info on that effect).

Federico Cargnelutti has written up a brief look at PHP's contribution to Open Source. More specifically, how its helped the online community save money and have better software for it.

Open source developers don't write FLOSS applications because they have to, they write them because they want to. Motivation is not always driven by money, most of the time PHP developers do it for the joy of it.

He lists some of the motivation factors behind the work that a lot of PHP (and Open Source) developers do for and in the community like the potential to learn, credibility/notoriety, sense of purpose and the possibility of a financial reward. He also includes just a few of the Open Source projects PHP developers have contributed to the community such as WordPress, Magento and Gallery.