Reflections on Midwest PHP Conference 2015: Software Craftsmanship

This was my first-ever PHP conference, gathering, or meet-up. I intended to keep an open mind and hope for the best. Fortunately, I was pleasantly surprised.

For the past many months, I’ve been reflecting on “software craftsmanship.” I’ve studied numerous ways to improve my practice of the art. Does “software craftsmanship” even apply to the PHP world? The published books generally refer to the Java world, for example, the Clean Code series by “Uncle Bob” Martin.

In the PHP world, where does Software Craftsmanship or a Pursuit of Excellence fit in the paradigm of getting the code into production? What’s important? What is not?

I’m coming to realize that I am not asking the right question.

In the sense of Software Craftsmanship, PHP has a lot of baggage. A very large proportion of PHP programmers have little to no formal training such as a Computer Science background. Nearly all PHP programmers that I’ve encountered call themselves self-taught. In large part this is because PHP was not thought worthy of being part of a curriculum.

That, of course, has changed. The language has matured. But of far more relevance is that the PHP community has matured. PHP code is ubiquitous. PHP is everywhere! The PHP community does appear to be centering in on certain practices becoming the de facto standard way of doing things.

You’ll notice I’ve not named anything concrete, such as the alleged demise of PEAR with the rise of Composer and PHP-FIG. Such concrete details don’t matter. Not to my question of Software Craftsmanship!

The issue, I think, is that things are moving so fast:

• The state of the art continues to rapidly evolve.
• The state of the technology for which we are writing code continues to rapidly evolve.

I think that perhaps this is why I’m having such difficulty placing a stake in the sand, stating, This is what Software Craftsmanship involves. The answer continues to change literally from month to month.

What is software craftsmanship, in the PHP world? Like the famous Supreme Court opinion in “Jacobellis v Ohio,” I can’t define it, but I know it when I see it.

As for myself, I can see that I’m asking the wrong question. The better question is, “How can I improve my own practice of the art?”

In the PHP world, that is NOT a theoretical question. Any answer must always include meeting the deadline. Another way to look at it is, “Who am I to even be asking that question?”

THAT question had an interesting answer provided by the final speaker of the weekend. She described the year-long process of gaining trust. Being from an older school, I call it “paying your dues.”

Thus the answer becomes simple: Set about doing my thing in my context, in a way that reflects favorably on myself and on the context.

What you’re reading now is one of those things: Bother to blog. Share snippets of code, discoveries, whatever. I have some larger things written down but as yet unpublished. Is the publishing a vanity project, and expression of arrogance, or is it appropriate promulgation of the art? I’m inclined to not publish until I figure that out. On the other hand, were I to publish, chances are good that I’d more quickly figure that out!

On a more concrete note, here are some takeaways for me personally.

Git and GitHub

I’ve used git before. I’ve done projects via github. However I’ve never bothered to use either in my own personal projects. I plan to do myself a favor and plan to learn to do just that. I can already claim git as a skill, but that’s a far cry from having a comfortable day-to-day working knowledge. Ditto with using GitHub as a personal code management tool.

PHP Extension Library PECL

I find this area intriguing, and I know full well that it’s intriguing as a vanity project. PECL, you see, isn’t PHP. It’s not c++ or anything else you might call “advanced” or “friendly.” It’s raw C with an unusually large proportion of preprocessor macros. Just like old times! Nostalgia can be fun, for sure!

As with anything else, it takes time to learn the ins and segfaults of writing rock-solid C code.

As our final speaker noted, there is a wealth of knowledge on the verge of dying out. That’s the tribal knowledge gained in the 1960s, 1970s, and even 1980s. I call it “Cold War knowledge.” Back then, code MATTERED because of the culture of paranoia. The Cuban Missile Crisis HAPPENED. 

Please, please bother to follow this link: http://www.pbm.com/~lindahl/real.programmers.html (Real Programmers Don’t Use Pascal). Think you can do evil code? Click through from that article and read the Story of Mel. I just re-read it. THAT is evil code.

Meanwhile, I’m not Mel, and in college I actually WAS taught Pascal. And assembly language, which proved to be far more useful from a career standpoint.

After ten years of working in assembly language, I was demoted to writing C. Exactly a quarter century later, that brings me full circle back to C as part of my PHP portfolio!

As I said, I’m not Mel, but I do have that Cold War education. Like Top Gun’s “the best of the best,” I was trained by Real Programmers. Sure, this was the Cold War, and I walked among Giants.

For that matter, I trained those giants! Do you happen to remember, or perhaps read about, the Morris Worm of 1988? It brought down the entire internet, which was kind of a big deal, at the time. It attacked Unix machines, and that meant the universities and government labs. When the Worm went down, I happened to be teaching operating system internals (in assembler) to those gurus in charge of those lab machines. They were in and out of the class all day as the disaster expanded. To be sure the internet was rather smaller, but it was quite cool to have a front row seat!

So what does this have to do with PECL? You can already see why it’s a vanity project. Given that it’s for-real C code in a fairly tricky environment, I don’t have to worry about a learning curve. I can simply focus on learning what is specific to PECL. That won’t be true of someone without the C background, and so of course that gives me potential entry to a relatively small area of the PHP world.

Do I have a PHP extension in mind? Nope. Am I a rank beginner? Yup. Those two facts, I find, have value. There is no introductory tutorial. There’s no book for PECL beginners.

This, then, is the tentative plan. It’s something concrete which I’m well positioned to provide to the PHP community. I can quietly learn the PECL way of doing things, and take good notes. If I can turn that into a book (or whatever) which helps remove the barrier to entry for real PECL developers, I’ve made a concrete contribution to the community.

Remember when Elizabeth explained about taking a year to gain the community’s trust? To me that’s just paying your dues. But either way, it is a truly important and valid consideration. Taking my time and quietly removing that barrier for others is my tentative plan for creating that trust.

Dev Environment

It looks like the standard development environment is Ubuntu linux on virtual box, managed via Vagrant and therefore Chef or Puppet. I’ve never used Vagrant, so I’ll add that to the list of prerequisites as well.

Reflection

Software Craftsmanship? As a label, it seems useless in that both the art and the technology it addresses continue to rapidly evolve.

Advancing the art? That seems the answer whether big or small. Gaining experience is advancing the art; advancing the PHP community is also advancing the art.