There are millions of PHP developers, but only a (large) handful of contributors, authors and maintainers of open source software. Packagist reports a little under 50,000 packages in the PHP ecosystem. This is a huge number of open source packages, but is a small number compared to the PHP developers in the world.
The truth is, many developers who use open source never contribute to it. Whether that’s out of lack of interest, fear of failure or other considerations, I want to present The Definitive Guide To Contributing to Open Source*.
Few things bring out fights among programmers quite like a fight over documentation. There are many schools of thought, from “document every line” to “let the code self-document.” For the most part, PHP seems to have agreed on a generalized standard for documentation in code, called PHPDoc. Actual blocks of documentation are referred to as “Docblocks”*.
But within PHPDoc, there are many different styles and behaviors. And so, I have developed what I consider to be my “best tips” for documenting your code with Docblocks.
Of the questions I get asked regularly, the most common is, “how can I be a better developer?” It seems everyone wants to get better at what they do, to get a better job, earn more money, or simply to enjoy their work more. And by the number of times this topic comes up, it seems people haven’t figured out the best way to accomplish it.
But rather than leave the answer for individual conversations, I want to address my best suggestions for improving your developer skills right now.
On Friday of this week, Cal Evans will host Day Camp 4 Developers: Building APIs Developers Will Love and Use. The best part is this event is completely free! It’s being sponsored by MuleSoft, meaning that your ticket is covered. All you have to do is sign up and show up and learn.
DC4D is a great way to move your career forward, and being able to attend for free is an amazing deal that you shouldn’t miss out on. Cal is a good friend of mine and having participated before in his prior DC4D talks, I can tell you that this is an event worth attending. I’ll be there; get your ticket and join me!
The PHP community is engaged in a discussion on whether or not developers should spend time writing new packages that solve existing problems with existing solutions. Ian Landsman uses Laravel as an example of a framework that wouldn’t have existed if nobody ever pushed the envelope of package development. While I agree that Laravel has been a huge leap forward for the PHP world, I happen to disagree with many of Ian’s points.
The fact that Laravel has been successful is not evidence in and of itself. There are hundreds if not thousands of small frameworks that have never taken off. Pointing to Laravel as an example of how developers can and should move forward is a logical fallacy known as post hoc ergo propter hoc, or “after, therefore because of.”
Back in 2009, I signed a contract to write a book. The book was published by php|architect, and was called The PHP Playbook. It was published in 2011. Being my first book, I assumed that going the route of a traditional publisher made sense, but after publishing a book this way, I opted for self-publishing for my next two books.
For individuals considering publishing a first book, going the traditional publication route offers some distinct advantages: credibility, editing, cover and layout, as well as marketing and promotion. Developing an idea for a book can take time, and for those inexperienced with the process, this can be helpful.