Matthew Weier O'Phinney
Matthew is an open-source web architect. While his expertise lays with PHP, he has dabbled in Linux systems administration both personally and professionally, reined in Apache on many servers, and originally cut his teeth in object oriented programming with Perl (true story!). Today, he is widely known in PHP circles as Project Lead for Zend Framework, arguably the most popular and de facto industry standard PHP framework.
When I was in fourth grade, I was given an assignment to interview a family member and then to write their biography. I chose my great-grandfather, who was born in 1900. Interviewing him in the early 1980s, his life story was fascinating: he remembered the first time he’d seen an automobile, the first moving picture he saw, the first time he saw something man-made in the air, the first time he’d heard a radio, the first he saw a television. In his lifetime, humanity went from horse-drawn buggy to walking on the moon. Everything I take for granted was once new to him.
I’m reminded of this because my generation will have a parallel story, though likely less dramatic, to tell. My children cannot remember a day without the internet.
My first encounter with a web browser was in the early nineties. I had entered the computer lab in order to print out a term paper, and a friend of mine waved me over. “You’ve got to see this!” He had this window open, and typed something in and suddenly we were seeing a news report about the spread of the Ebola virus, accompanied by pictures. It was grotesque and fascinating.
A few years later, I was working at an engineering research center, and tasked with putting together an online glossary, and finally got to see how such pages were put together. HTML reminded me of working in WordPerfect documents, which, back then, had a mode that allowed you to work directly with the declarative codes used to alter the appearance of text.
Fast forward to the year 2000. I was working at a small publisher and book catalog. We’d recently moved our online catalog in-house, thanks to the fact that our catalog software had a module for IIS. I was asked to give the site a new look, since I’d done some HTML before. I quickly discovered that the HTML was not hard-coded, but being generated by this language called “Active Server Pages”. I figured out what needed to be done.
A few months later, my boss noticed that this up and coming company, and competitor, really, “Amazon,” was now allowing people to review books on their site. He asked me to add that feature to the site.
The software we had used FoxPro, and while I could get things out of it, I couldn’t quite figure out how to put things into it, particularly not in a way that would allow us to upgrade easily. So I did some research, and decided to use Perl to accomplish the task. I got some books, studied hard for a few weeks, added Perl and MySQL to our IIS installation, and banged out the functionality.
And at that point, I was hooked by the web, and specifically creating content for the web.
Today, I have two kids. Neither of them knows a world without the web. They’ve never seen a regular modem, much less a phone that connects to the wall, or with an actual dial. How foreign will my life be to their children, and their children’s children? And will the internet as I first saw it be only the first in a pioneering step towards bigger and better technology? Or one of history’s failures?
Either way, I can’t wait to see what the future holds.
Time is a limited resource. As web developers, we’re busy people, and I know I often wish I had more hours in a day to get things done. However, no matter how busy you are, how many tasks you have, you also need to save time to replenish your energy. Sure, you could stay in front of the computer another hour or two or four, but you may find you’ll accomplish more by stepping away, and returning refreshed the next day.
Now, if only I’d remember this more often and practice it…
Ever work on an open source project? If so, and for long enough, you’ve likely encountered users who feel entitled and become abusive when the code does not work the way they expect, or contributors who belittle the contributions of others.
If these same people worked face to face, would they act the same way? And if they did, would we tolerate it?
We would not. Disagreements can happen and still be conducted in a civil fashion. We should not tolerate abusive behavior online.
I’ve felt honored and somewhat amused to be a part of the Pastry Box Project. As I look around at my fellow bakers, I find that the majority are designers and usability gurus. I sit at the other end of the spectrum when it comes to user interactions — the work I do is on the server side, handling the incoming requests and providing responses; only the side effects of my work are seen by the end user, and often those are filtered through visual design I never touch.
And yet, I’d argue there’s another level of design that happens in this arena. The code written must be readable and maintainable, both by myself in the future as well as others. The interactions between different code responsibilities must be clear and concise, and readily understood. The class names and methods should communicate their purpose.
It’s tremendously easy and seductive to be able to write a few, quick lines of code that get the job done. It’s a more interesting and rewarding job to make functional code self-documenting and maintainable.
Code requires good design, too.
Know the tools available to you, their strengths, weaknesses, and what they are designed for. Do not reject a tool because it’s not hip, or popular (or, too popular). If it fits the task at hand, use it, and spend the time you save developing something awesome.
Open source software requires effort.
Many times, I’ve encountered individuals with fantastic ideas. However, when pressed for code or more detail, I’ll get the answer, “I don’t have time right now.” And yet, the expectation is that somebody will take that idea and run with it.
A few times, I’ve taken up such challenges—and in almost all cases I’ve regretted it, because once implemented, the person with the original idea will come back and say it doesn’t match their expectations. In the world of open source, such criticism is often very public, and generally damaging to the projects and people behind them.
So now, my mantra is: an idea does not have merit unless there is effort behind it: effort to provide a detailed explanation of how you envision it, effort to provide a prototype detailing the idea, effort to test the work others have done to implement your idea. Anybody can spit out ideas, but it takes effort to make those ideas a reality, and that effort should be valuable enough to warrant effort on your part as well.
I recently was able to see Douglas Crockford speak. He had a fantastic premise: we are flawed beings attempting to create perfect programs for machines. What struck me during the talk was how few developers acknowledge this. We all make mistakes—we may have missed a keystroke because we were distracted by music we were listening to, hunger, or the phone ringing. And yet we all too often relish pointing out flaws in other people’s code, as if we could never be guilty of the same. Perhaps more humility and acceptance are in order in our industry.
As programmers, who are we programming for? On the one hand, we're writing code to be interpreted by machines; considered this way, code should be logical, consistent, and machine readable. But unless you're writing code in Assembly, the fact of the matter is that the code you're writing will never be directly interpreted by the machine—a compiler will take that code and make it machine readable.
So, in the case of interpreted languages, who is the code for, in the end? I'd argue it's for you, the developer, and those who will be maintaining it later.
As such, I've always taken Larry Wall's aspiration for coding in natural language to be a lofty and noble goal (despite the fact that idiomatic Perl is considered a write-only language). Name variables meaningfully, instead of using short, cryptic names. Follow natural grammar when you can. Use white space to separate discrete ideas and concepts in your code.
Code can be poetry, if you work at it.
As a project lead, I'm often looked to for guidance or approval of ideas. Interestingly, I do the same—but perhaps for a different reason. I toss my ideas over the fence in the hopes that somebody else will be able to execute it better than me, or come up with an even better design. Usually, they can and do.
Step away from the computer when angry.
Edge cases are often the bane of a developer's existence. Even good unit tests often will not save you—because edge cases will identify inflexible design, or insufficient configurability, leading to painful refactoring. On the flip side, however, solving edge cases can be one of the most rewarding accomplishments we can achieve.
As an open source lead, I communicate a metric shit-ton on a daily basis. There are folks who have problems, folks who want to help, and everything in between. One of the hardest problems I have is dealing with contributors who live half a world away, speak English as a second language at best, and with whom my entire relationship is text-based. I can't tell you how many times I've either hurt somebody's feelings or been inadvertently offended due to the inability to translate body language and linguistic nuances to text.