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.

There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!

Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.

He breaks it down into five main tips (here's a tl;dr for those in a rush):

You don’t need to learn every new thing in order to stay relevant.

Writing good code takes less time than writing bad code, BUT it doesn’t feel that way.

Working 24/7 does NOT make you a hero. Managing expectations does.

Not all time spent “improving” code has the same ROI.

Scheduled down time makes you more productive.

Each item on the list has a paragraph or three explaining it in a bit more detail. There's also some other interesting ideas and thoughts in the comments of the post from other readers.

It is easy to become a web developer these days. The only things you need is a computer and Internet. But I believe there is big difference between a developer and a good one. Good developers are like little heroes. They are awesome in what they do and are there when you need them. A real benefit to the our world and definitely someone you can look up to! I believe everyone can make this step and start being a better developer today. This is why I asked great developers from all around the world what they think makes someone a really good developer.

His list covers more than just good coding practices too. He suggests things like:

Experimentation

Reading the code of other good developers

Just build websites

Contribute to other projects

Watch out for the Hypetrain

Never give up

He includes a quick summary of each of these and the rest of the top ten list too. Be sure to check out the full post for more.

In his latest post Jani Hartikainen makes a recommendation for those wanting to become better developers: first become a teacher. He suggests that communication is the second most important skill a developer can have.

What is the most important skill for a developer besides actually writing code? Communication. What do you typically do when you communicate as a developer with someone else? You explain problems, you describe solutions, you talk to non-programmers about what you’re doing. You could also say that you’re teaching others about what you’re doing. [...] Being a good communicator is often completely overlooked.

He looks at why it's important for a developer to have good communication skills and what it means to "communicate well" with fellow developers. He suggests that real teaching can start when developers understand the domain and code they're working with. He also talks about the flip side of things, the importance of listening to other developers and those trying to help. Listening well means understanding the question and being open to different ideas, even if they contradict your own.

As with all aspects of programming, the best way to improve communication and your ability to reason about code on a higher level is practice.

On PHPClasses.org today they've posted the latest episode of their "Lately in PHP" podcast series - Episode #35, "Better Documentation for PHP internals".

With the inclusion of Zend Optimizer+ extension in PHP 5.5, the need for better documentation of PHP internals became more evident, so PHP contributors can write extensions that take the most of the core PHP features. That is one of the topics discussed by Manuel Lemos and Ernani Joppert in the episode 35 of the Lately In PHP podcast. They also talked about having more optimized PHP opcodes, some interesting PHP feature proposals that got rejected, as well the article about the top version control systems used by PHP developers.

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.

In a new blog post on PHPClasses.org today Manuel Lemos has gathered together some of the things that PHP doesn't have (yet). Most of them are things that developers have expressed a desire for in the core and either have yet to make it into a RFC or are still just being implemented in "userland" code.

The PHP development process is still a bit frustrating. Many developers hoped that PHP had certain features but those are still missing due to several reasons. One way to see those features happen is to write code to implement the features and then submit the code to the PHP core. However that is not a guaranteed process. Even if you provide the necessary code, other developers may object to the addition of those features and the effort is wasted.

Among the things he lists as features that are desired but not implemented yet are things like:

Aspect oriented programming

Annotations

Class generics

Introspection of private variables and functions

Named parameters

There's a summary of each of the features mentioned and in some cases links to RFCs that presented the same ideas. If you're interested in presenting your own ideas to the PHP project for inclusion, you can "demystify" the RFC process by checking out this post from Chris Jones with lots of good suggestions and the flow of how the process (usually) works.

PHPMaster.com has a new post with ten helpful tips for you to consider using during your development. These tips can help to not only make your current development simpler but make for easier to maintain, stronger code in the future.

Good code is maintainable, reusable, and testable. The following tips address how you and/or your development team can handle various coding tasks and how to keep everything as neat as possible. I will introduce you to some "best practices" that will help you write better code and help make you and your team happy and efficient.

Among the suggestions on the list, there's things like:

Use a Coding Standard

Refactor

Use Meaningful Names

Use Automated Build Tools

Use a Testing Framework

Links are provided in several of the tips to other resources/tools that can provide you with more information about how to use it in your development.