It never fails. Someone will write me after reading my book or taking a class with the same story. They were so jazzed: they felt like they were on top of the world, ready to attack their next programming task with vigor! They had studied hard, connections had been made, understandings had been formed. And then, inevitably, reality sets in. They look at their code, same as it was before, and realize: this is going to be harder than I thought.
It can be easy to feel dejected when looking at a pile of code you inherited from four generations of programmer ago. None of the best practices or principles. No tests. Hell, you’re lucky if you even have objects that don’t rely on PHP 4 style constructors. You’re in legacy code hell.
There’s a great little book that’s a must-have for every aspiring chef, called Ratio. It’s written by a man named Michael Ruhlman, and the point of the book is that many basic cooking concepts can be broken down into a ratio that any chef can apply and come up with a delicious pastry, stock or cake.
The point of the book is that recipes don’t matter as much as understanding the basics of how those recipes are created. In fact, the book contains only one or two recipes for each specific type of item; the rest of it dedicated to explaining how the ratio works. Yet the outcome is quite powerful: knowing that 1 part sugar to two parts fat to three parts flour makes a serviceable cookie or that five parts flour and three parts liquid (plus yeast and salt) makes a decent loaf of bread opens a world of possibilities to someone willing to experiment.
All around the world, millions of developers trudge to their jobs. They sit in bland cubicles, dealing with pointy-haired bosses who don’t get them, and working on projects, some of which never see the light of day. It’s a meager existence, and they long to do something else. They’re working for the weekend.
I used to do a job like this. I sat in a grey cubicle with my back to the window (don’t ask me why). I worked for a man who thought that delivering client projects was the most important thing on earth and that if weekend plans had to get broken to do it, so be it.
Including today, there are six business days remaining in 2013 (five if you are lucky enough to get New Year’s Eve off). My brother used to call this week “the lost week” – there’s hardly anything to get done because so many people are on vacation or preoccupied with setting goals for the new year. But the downtime provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake.
With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.
Years ago, I worked for a company that had a strictly governed bug fixing process. The bugs to be fixed per release were specifically regimented, right down to the amount of hours available to fix each issue. Developers were expected to meet or beat their estimates, and failing to do so meant overtime (since the deadline was immutable). With effectively every working moment spoken for, there was never any free time for innovation, invention or creativity (at least on the schedule). Developers were effectively bug fixing or feature building machines, with no input into the process or product features.
Unfortunately, this seems to be an all too common trend in the development industry. Employers, who love the ability to measure things, disdain the fact that engineering is first and foremost a creative art, that cannot be effectively measured. They attempt to install artificial measures of productivity like tests written, lines of code added, bugs solved, and number of bugs reopened by the quality assurance team. Sadly, these measures all fail to effectively measure the effectiveness of development teams, because the developers themselves see immediately through the schemes, and learn quickly to game the system.
In the United States, we take the fourth Thursday in November to give thanks for all the things we appreciate, and all the people who matter. I know that without PHP, my life wouldn’t be nearly the same; the language I use every day plays a critical role in everything else I do: it provides money to pay bills, a sense of accomplishment, and the joy of working in a language that is truly fantastic.
We owe lots and lots of people for the PHP language, people who are not often thanked nearly enough. Thus, I have decided to pick five people that have contributed significantly in the last year, and (in no particular order), discuss their accomplishments and thank them each personally. I realize that PHP is an effort of several hundred individuals, and that each one deserves credit; there simply wouldn’t be the space to thank them here personally, but each contributor should know that I personally appreciate each and every one of you.