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.
Design patterns suck. This is a cold hard truth faced by many developers. They’d rather ahve their teeth extracted by a sadistic dentist who uses cayenne peppers instead of Novocaine than try and implement the Abstract Factory or the Mediator Pattern. And can you blame them? Reading the Gang of Four Design Patterns book is about as exciting as being hit over the head with a mallet. Seriously, that thing could double as a sleeping pill; it should carry a “Do not operate heavy machinery” label.
Sure, you might think “I’ll pick up a copy of X instead.” But if you write in pretty much any language besides Java, you’re out of luck on the code examples. Maybe, if you’re lucky, maybe you can understand them. But for most of us, we look at Java and our eyes glaze over. And we start dreaming of that dentist again.
Everything we ever start will eventually end. It’s the natural cycle of things. We can’t avoid it. For me, the time has come, and my last day at Mozilla will be December 31st, 2013.
Working for Mozilla has been the most challenging, rewarding part of my career so far. Working with great people like Laura Thomson, not to mention the talented team on which I serve, has been tremendously amazing. It’s made me a better engineer with a greater perspective on the world and the way in which professionals in our field work. To say that I’ll miss it would be the understatement of the year.
Whenever you instantiate an object in PHP, you automatically create an object with an implicit type. In fact, you can “type hint” on just about any object in PHP, whether it’s a concrete object, an interface or an abstract class. Yet in object oriented development, there is in fact a distinct difference between an object’s class and type.
The difference is subtle but important. An object class deals with specific implementation details of the object. An object’s type is about the interface that the object uses to communicate with other objects.
There’s an old saying: don’t write to get rich. Most writers never make anywhere close to minimum wage on their books, and some don’t even make up the advance on sales (if there was an advance at all). Writing a book isn’t always about making lots of sales anyway; it can be about having that line on your resume, sharing your knowledge with a small group who needs it, or just generally wanting to spread the word about something you love.
I definitely didn’t get into writing for the money. In fact, my first book was published by php|architect, a fine group of folks who have a great lineup of books. My second book was self-published, and priced in line with the first.
There’s a “new” post out by Anthony Ferrara, called Beyond Design Patterns In this post, Anthony boils down most well known patterns into a single goal, and articulates that moving past design patterns is best for everybody. He says,
Are design patterns useful? Absolutely. But I’ll assert that once you understand OOP and object communication, the patterns will “fall out” of the code you write. They come from writing OOP.