So, yesterday, our team had one of the best meetings I’ve been in for quite some time. It was a bit overdue, the five of us have been needing to be in the same room for at least a month to begin to hash out the vision of our project that each of us have in our heads, and to know where each person is coming from. The meeting started out (and actually ended) talking about Identity (well, more the practical aspect of identity — user registration and authentication) — but in between it managed to cover some of the “vision” aspects of the tool(s) our group is to offer, and to merge/mesh/integrate different ideas about that. The funny part, and I imagine the seemingly contradictory part for those that I’ve interacted with only a few times, is that the way I thought it should be (and for some of the points still think it should be) is not what we came to settle on. And I still thought it was a good meeting. (those that know me best know that’s not a contradiction).
One of the challenges that you have when you hire a group of experienced technical staff is that each come in with a set of work habits, notions, and more than a few strongly held opinions of “the way it should be”. If the team works together, this is a great thing. In technology decisions, there is no right way. There is always more than one way to do it (to borrow the Perl mantra). I absolutely love reasonable, well thought debate, with the end result being that the person/group that has to do the work has to work with something they are most comfortable with. What I can’t stand is people that think there is only one answer, and don’t concede that the other opinion has some validity (which is why I dislike most political punditry). I think the great thing about our group so far is that we don’t have that. And I don’t think we will.
Anyway, that’s not what this post is about. During a tangential comment thread in the meeting, I made the comment that I was just a “sysadmin that’s a wanna-be developer” (I tend to be pretty self-deprecating in technology discussions). And that’s kinda true. I’ve written programs and scripts for years, in fact focusing more on that than installing hardware and software packages — but it’s always been oriented to systems things. But I’m also “programmer by training” — I think in terms of state machines and program flowcharts.
So what that combination turns out to create is that I’ve always written these massively over-engineered “system scripts” (e.g. I put error handling and stuff in just about every script I write — most sysadmins don’t). And I’ve always done that, be it Hypercard, Excel Macros, Win32 C/pidgeon C++, Perl, PHP, or shell scripts. I was trained in an Computer Science era that was at the tail-end of the functional programming epoch, so I’ve never really done objects, I’ve always done highly modularized and abstracted functional blocks that are “object-like” — which the languages I’ve used have let me do that. And while I’m aware of good code libraries, I’d often reinvent the wheel, either out of distrust of a given code library, or the fact that they required all this extra code I didn’t need, etc. I also have realized that I really do have a Unix-philosophy (even being a Windows geek for too many years). I believe in lots of little small tools cobbled together to make a bigger project.
The “wanna-be” part stems from the fact that I know that’s not the theoretical “real developer world” (even though I imagine it’s more like it than the enterprise folks would have you believe). I’ve never done programming teams, never written specs and design documents, I’ve never leveraged framework-oriented tools and languages, never really done real testing (functional programming == test by printf, though I use debuggers more than most systems people), and I’m still confused a little by “branches, releases, and regressions”. So I’ve always felt a little like a person playing with one of those 100 in 1 toy electronics kits where you build your own AM radio in a room full of Electrical Engineers. A sysadmin with a developer inferiority complex.
Well, that got triggered a bit with our tangential discussion. My co-worker, someone with a crap-ton more real development experience than I (and as it should be for our roles in the group and team) and I had a mostly joking exchange about languages and such. He’s a Java dude, a framework guy, dislikes PHP for all sorts of reasons that many developers do, among them that it doesn’t enforce a kind of Model-View-Controller way of working that well designed frameworks enforce. He’s got some well-formed opinions on “how things should be” — and he’s earned them — so I have no problems with that. The mostly joking exchange centered on something that I do in my PHP code:
I use print statements to output all (well, just about all) my html. I don’t use PHP the way it was designed initially — with server-parsed code fragments in html pages. e.g. I will do:
<?php
$myname = "Inigo Montoya";
$mysite = "https://rambleon.org";
print 'My name is <strong>'.$name.'.'
print 'You killed my <a href="'.$mysite.'">Web site</a>.'
print 'Prepare to die...'."n";
instead of:
<?php
$myname = "Inigo Montoya";
$mysite = "https://rambleon.org";
>
My name is <strong><?php echo $myname; ></strong>.
You killed my <a href="<?php echo $mysite; >">Website</a>
Prepare to die...
or even better, using some kind of templating framework. The is a simplified example, but yes I do this for all of the output usually, and all. Basically, I write PHP apps just like C-based CGI apps.
This turns out to be anathema to my co-worker. I think “horrible” was the mostly joking exchange 😉 I wasn’t and I’m not offended by it, because I really like and respect my co-worker and I don’t think he’s trying to be offensive, but as it touched upon my wanna-be-ness, I’ve been thinking about it a lot since the exchange. Do I do it because I don’t know better? Am I violating the way PHP was supposed to be used? Am I preventing the use of useful HTML editors that help you design good HTML? Am I a horrible developer because I write it horribly? Certainly I’m making it so a web designer can’t really do much with this. Certainly it might be hard to read for html-oriented web people. (although when I wrote bigger apps like the wiki/weblog that I wrote, I basically printed a standard set of div’s for the page and entries, and then real designers could have at the CSS, which I thought that was the way to do it). I’ve gone back and looked at a fair amount of the perl and php could that I’ve written over the years for web pages — it made me reflect on it that much.
Well, at the end of the day after a lot of reflection, I probably won’t end up changing all that much. Maybe because I have this entrenched, C-oriented functional background. And because I can read and debug conditionals much better in a print statement world, I can control output buffering, I can reuse large blocks of text by storing them into strings (and eat all kinds of memory). And lots of other little tricks. But mostly because it’s really about ‘TMTOWTDI’ — and that’s the core technology philosophy that I hold near and dear — get all these things done differently and have them work together — kinda like our great team we’ve formed.
So I guess I’m just going to have to keep writing horrible web applications 🙂