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 QuickerWP blog there's a new post with some recommendations of plugins and techniques you can use to make your WordPress blog "fly" (increase the overall performance).

WordPress sites are notorious for their poor loading times. The platform itself comes with very few optimizations, and once you start adding plugins, things will only go south from there. [...] Most of the performance penalties actually come from having too many plugins installed, a poorly optimized site configuration, and a theme that does not optimize loading speeds (most of them don’t).

[...] It’s rare to see high marks [on Yellow Lab Tools] (a B or A result), but after applying the tweaks listed here, we’ve managed to get our own site to score an A (92/100) result, and surprisingly low loading times. Try it on your site to see how you fare.

They have a list of seven recommendations:

• Autoptimize plugin
• WP Fastest Cache plugin
• PurifyCSS
• TinyPNG plugin
• Guetzli (for image optimization)
• CSS Sprites
• QuickerWP

Each item in the list comes with a brief description of the enhancement it brings to the table and links to find out more information.

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.

In a post to his site just before the new year Patrick Louys shared some of his thoughts about how to become a better developer in 2018 as a sort of programming-related New Year's resolution.

Do you have any programming related New Year’s resolutions? A lot of people don’t follow through with their resolutions. But don’t let that discourage you. When you make resolutions, you are much more likely to achieve your goals (10x more).

I wrote this post to show you how you can achieve your programming New Year’s resolutions. Every year I have been writing down my goals, for over a decade. It helped me grow a lot in my personal and professional life. It’s not just about setting goals and achieving them. You have to pick the right goals.

He begins by making a few recommendations when it comes to setting goals and how to set yourself up in your day to day work to achieve them. He then relates this back to programming goals, suggestion you focus more on patterns and practices rather than specific technologies (unless they're relevant to your work). He also recommends several books to read during 2018 to either learn new concepts if you're just starting out or wanting to refine your own skills.

On the Toptal.com site they've posted an article from Fernando Martinez with some suggestions about how to attract and retain software developers. The ideas cover the full range - all the way from the job posting/interview process out to how to keep them with the company and help them thrive in their role.

Management is all about people. Whether managers or employees, both are thinking about how to achieve their personal and professional goals. The combination of these goals and the personal traits of the people involved give shape to relationships that, in time, can be positive, productive, and fulfilling, or sometimes just plain stressful, demanding, and conflict-prone.

[...] This is especially true in managing software developers, because of their job’s technical complexity and creative nature, compressed into often narrow timelines for producing results. [...] In this article, we will focus on the main management aspects, rather than on the technical ones, that we think should be considered by anyone who wants to be successful in managing to retain software developers.

He starts with a look at how to attract and hire the right people for the roles you're trying to fill with suggestions about the interview process and the job offer. Next he gets into recommendations about managing the team itself and the importance of training, organization and communication. The article then goes on to cover other topics like conflict management, keeping up motivation and assigning objectives/follow up.

In a new post to the Exakat blog they propose an interesting idea: making everything private in your PHP classes with the basic idea being that you can more easily move from a place with more control (private) to less control (protected/public).

It is a good recommendation to make everything private in a class : constants, methods, properties. With private, comes a tighter control on the element : no one from outside may use it, limiting the unwanted impact on the object. Of course, some of the class has to be accessible from the outside, or the object may only be manipulated as a token.

[...] Eventually, when the code matures, it becomes desirable to apply the above principle of encapsulation. This helps keeps the code clean and made of independent components. This is the beginning of a long hunt.

They show how the results look for an Exakat scan of a class and go through each of the results touching on class constants, methods and properties. It also catches when a class property is a "constant" and not modified - or able to be modified - by any means. The post ends with a recommendation to "update your code with your brain" based on the interpretation of the results.

In a recent post to his site Herberto Graca shares some of his thoughts around packaging and namespacing and how it relates to the overall architecture of your application.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems: components, relationships between components [and] principles guiding the design and evolution of components and relationships.

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

The post then goes on to talk about "spaghetti" architecture, what makes for a more maintainable codebase and how this impacts the overall structure. He shares a few of the "packaging principles" previously defined by Robert C. Martin and the concept of "screaming architecture" (it should be very clear about how it's structured).

The SitePoint PHP blog has made an update to their "Being a Full Stack Developer" article covering what it means to be "full stack" and various technologies that can be used (or skills to learn) to get there.

A full stack developer who can get from a prototype to full MVP (minimum viable product) is often considered a jack of all trades, master of none, and with good reason. To define the modern full stack developer, we first need to focus on what the full stack developer used to be.

The article talks about what it use to mean (back around the early 2000s) to be "full stack" and some of the things they needed to know. He then goes through the things you'll need to know now to be considered basically on the same level:

• [Basic] Server Admin / Devops
• Cloud [Services]
• Back End [Development]
• Front End [Development]
• Design
• Logging
• Mobile

He ends the post by answering the question "is it worth it" to be a full stack developer versus focused on one thing, basically boiling down to two things. First, that most devs aren't actually full stack (even if they say they are) and that it can help to have this experience to, at the least, be able to approach a wide range of projects easier.

On the CloudWays blog there's a new post with comments from several members of the PHP community about why they feel that managed cloud hosting is a better option when it comes to hosting their applications.

Not many people realize that their choice of hosting solution could determine the success or failure of their project. Even the best code base fails to perform to its maximum potential because of a hosting solution that fails to provide appropriate support.

[...] In order to understand why many industry leaders recommend managed cloud hosting for PHP projects, it is important to understand the benefits of these hosting solutions. In effect, managed cloud hosting offers three important benefits.

These three benefits involve the offloading of the usual hassles of server management, improved security and scalability. Members of the PHP community that contributed their opinions include:

• Anna Filina
• Adam Wathan
• Josh Lockhart
• Tessa Mero
• Matt Stauffer
• Manuel Lemos

Check out the full article to read their thoughts on why managed cloud hosting is the way forward.

The Delicious Brains blog has an interesting post, the second part of a series, talking about staying healthy - both mentally and physically - while working from home. In this new article several people share their own ideas, habits and experiences that have helped them keep up while being a part of a remote team.

It’s been just over a year since we posted about our struggles to stay healthy whilst working from home in a remote team. In that time we’ve had two new members join the team, one full company meetup and one regional, one new baby, two engagements and three home moves, so I thought it was about time we give an update on where we are with our health. Ian did promise an update 6 months after the last, but don’t hold it against him.

He post shares thoughts and comments from eight different people, each with their own unique experiences and recommendations (what works for some doesn't for others). Most of the suggestions include recommendations of regular exercise, making mental health a priority and better sleep habits.