When you die, will it matter?
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.
Effective Refactoring Strategies
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.
The Value In Offering “Time To Tinker”
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.
Giving Thanks
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.
Lessons Learned From An Impromptu Job Search
When I lost my job on October 12th, I knew that the PHP community was an invaluable resource for finding a new one. What I didn’t expect, though, was the outpouring of support and assistance I would receive from that community. I learned a lot of lessons from the job search, and thankfully, largely due to the involvement of the PHP community, I have a long-term contract that is both paying the bills and letting me form my own consulting company – a long term dream I’ve had (more on this in a future blog entry).
I wanted to share some of the lessons I’ve learned, because I think that they are important, and they helped me to find a position quickly, effectively, and easily. I actually had more than one opportunity to choose from – something that’s almost unheard of in the current economy.
To The New PHP Programmers…
Nearly five years ago I started writing PHP code for fun. I had a project that I was working on, and I needed some sort of a programming language that would do calculations for me, and hopefully make managing a website easier. So I wrote my first web application.
Boy, was it bad.
Books
Write better object oriented PHP today.
Object oriented programming always leaves you with a headache. What if you could master it instead? Stop struggling with object oriented PHP. Mastering Object Oriented PHP is the answer!
Write clear, compelling PHP code that communicates intent.
Imagine if you could write clear, compelling code each and every time you sat down to work. You can do this. I'll show you how with The Ten Commandments of Clean Code.
Brandon Savage has been a software developer since 2003. Ever since discovering that he could use software to automate routine tasks, he's been hooked. Brandon is passionate about perfecting the art of software development.