preed's blah-blah-blahg

While sitting here, waiting for the Firefox 2.0 RC 2 candidates to finish compiling (go Win32 SpeedRacer!!), I started thinking about that post I wrote (has it already been?!) two weeks ago.

After re-reading it, I fired up Google to scour the blogosphere to see if anyone else is writing about this stuff. "Build/Release Engineering blog" seemed like a good place to start.

The picking were pretty slim, with the first twenty or so results all posts referring to build/release engineers, job pages (including a cache of MoCo's old Careers page), and feed links to... well... my blog.

That's... uhh... real useful there.

Next I tried "build engineering blog," which pointed me at Make Magazine's blog and a bunch of Google API documentation? Hrm... alright.

"Release engineering blog" doesn't get us any closer, providing a weird combination of content from "build engineering blog" and random posts complaining about release dates of various products slipping.

Changing my search trajectory, I tried "scm blog." I guess the business majors' "SCM" is more popular than mine.

All in all, I managed to find two lighthouses in the Supply Chain Management-dominated sea.

The most engaging aspect of his essays is how they prompt me to consider subjects I normally wouldn't. Sure, a lot of the Win32-specific stuff he discusses every so often isn't directly applicable to my daily hacking-life, but most of it, including his treatises on scheduling and the other "soft stuff," apply in a "build land." Admittedly, the wavelength is often... a few degrees out of phase, so it does require some mental modulation.

But that probably isn't the most valuable aspect of his writings: I don't always agree with him.

Sometimes, he writes about Microsoft with a nostalgic flare that would choke a anti-trust judge. And I can't say that I'm impressed with his constant reference to Netscape's "huge mistake.¹"

But whether or not you agree, this valus is in pushing the discourse forward. Making others form their own opinions, translating to their own sandboxes as necessary, should never be underestimated.

And honestly, I've never seen a man—to say nothing of a software engineer—squee so much about his office space [re]design.

I just love it.

I asked a friend what he thought of when I said it, and he said "Oh, that's like 'poor little boy' in Spanish."

Urban Dictionary is less charitable, but as for the subject matter discussed herein, probably more accurate.

What I have yet to figure out is whether it refers to the author... or the reader(s?).

I guess you'll have to tell me.

And while you're at it, feel free to pass along any Google-fu on finding more lighthouses to be looking out for.

_______________________
¹ I go back and forth on that one; the truth is probably somewhere in between...

Posted by preed at 11:50 AM | Permalink

In case you've only ever read this "blahg" via its RSS feed, the tagline reads "What does a Build Engineer do all day, anyway?"

I've been thinking a lot lately about the answer to that question.

When I think about what my answer actually is, day-in-day-out—doing builds, triaging broken builds, restarting automatic builds, respinning builds, making sure there's enough space for builds, signing builds, staging builds, getting new places for people to get builds, fighting fires on the machines the builds are created on, making sure the builds... well... you get the idea—it all seems somewhat... repetitious.

(And the more I look back at that, actually somewhat depressing.)

But even though we, Rob, Coop, TR, and I, do work on those things, I'm pretty sure we all think about other things, especially the fourth or fifth time in a day you've logged into the same Tinderbox to kick it.

Part of this recent introspection about what we work on, what we want to work on, and what we should work on was prompted by a question Schrep posed to me a week or so ago: we had just finished a company-wide discussion of goals and missions and he asked off the cuff what the Build Team's manifesto would be, if we had one.

Something along the lines of "What should we be thinking about in the day-to-day that prompts us to work on things that have perceptible, positive impact, not only for ourselves, but for everyone else?"

There are the obvious ones: doing builds, triaging broken builds, restarting... well... you know... but isn't there more than that?

Should there be more than that?

If you've ever talked to Rhelmer or I right after a release, our reaction to the mere mention of the word "build" implies that there should be.

In trying to tackle the answer, the only thing I could think of was make a list. As I sat there, trying to brainstorm what the list should include, I found myself jotting down the things I think about all day (and sometimes worry about at night). Some of them had that dirty, five-letter b-word... but a surprising (to me) number had nothing to do with that.

As I sit here, counting the thirty-plus items on my laundry list, I wonder if anyone would be surprised that someone thinks about these aspects of a software project that stare back at me. Does anyone really care what the number of old builds we store says about us?

Or why bumping versions is a big deal?

Or what the deal with centralized build data stores is?

Ok, so maybe people wouldn't be surprised.

But, still I wonder. I've been in situations where I've been asked "Hey, can you guys do X?" When my answer isn't what they expect, it sometimes prompts what can be an involved conversation about why the answer wasn't a simple and immediate "Yes."

I think such conversations are useful in the long run.

But I can't help think if there were a good answer to the question my "blahg's" tagline poses, then maybe some of my weird answers to questions would make more sense to others sooner.

As a bonus, if I could distill the common themes behind those day-to-day answers, I might just have the makings of a manifesto that would at least frame our discussion for what unique qualities we bring to the "MozillaVerse" (or are the cool kids calling it "Mozillasphere" these days?)

Think of it as an attempt at a JoelOnSoftware knockoff, except... without all that annoying credibility and pestering about having created-Visual-Basic-for-Applications-but- before-it-was-called-that-because-I-only-worked-on-Excel-at-the-time getting in the way.

On the downside, I will admit: it is highly likely there will be fewer treatises on the speed of duck-typing.

Posted by preed at 8:08 AM | Permalink