Telecommuting Experiment Concluded

Three months ago, folks, I began “The Telecommuting Experiment” with what I now know as a small “start-up” based in the Pacific Northwest. This little ditty has come to a conclusion and I have learned loads of new things about building Web sites. My job now is to ramble though all of these things as best I can, using a few Delicious.com links along the way:

CSS Stuff

My biggest of the spoils taken from this intense Web-building experience is revisiting grid-system theory and frameworking—in short, I was exposed to the 960 grid system. This system is far more mature, modern and elegant than my Biggest Box stuff.

A little less embarrassing than my previous ignorance of the 960 grid system is not knowing about Flash of Unstyled Content (FOUC)—very hip jargon. I got FOUC for free with jQuery UI widgets. In “How to prevent a FOUC but still gracefully degrade the jQuery UI tabs,” Timothée Carry-Caignon writes, “They are pretty useful actually, but I always hated that FOUC they produce. For one split second, you’ll see all your tabs content, then they’ll be neatly re-arranged in tabs.”

In “Styling select, optgroup and options with CSS,” Chris Hope says, “As per my conclusion at the end of the post, it’s probably better to leave styling of select boxes, optgroup and options alone and just leave them as the defaults because cross browser styling is so inconsistent it’s not worth the bother.” I agree with this but I often forget about this—so writing this down (finally) might help me.

Eric A. and Kathryn S. Meyer have CSS Reset. I can appreciate this but do not find it necessary. But remember this coming from the guy that had no idea about the 960 grid system.

“Pure” JavaScript Stuff

The number one “pure” JavaScript takeaway for my 2011 is Underscore.js—whenever there is the desire to some LINQ-like things in JavaScript this is the place to be. The _.sortBy method described in the docs had me at hello.

I do risk being perceived as “negative” instead of accurate when I must mention that there is thing I’m calling JavaScript bloat. My use of the term comes not from seeing file payloads over the wire. What gets me is the sense that the web browser is working very, very hard to crunch though the script code in memory. Because I know what I can do in Silverlight (and Flash/Flex) I am not biased toward trying to get HTML/JavaScript to do “everything” such that the bloat gets out of control—these bloated stacks may be working just fine on a developer’s gaming PC but taking the client-side code to more economical devices (in terms of cost, power consumption and thermal waste) shows how things fall apart.

jQuery Plugins

This article, “Looking for a JQuery plug-in similar to [Accordion], but that allows multiple sections open at once,” underscores the

The jQuery Time Entry plugin seems to work without any surprises.

Eric Hynds has this jQuery UI Multiple Select Widget that impressed me in the field. I’m feeling like it can be alternative to tree views—speaking of which jsTree worked without unexpected inconveniences.

jQuery Plugins: Hiding/Showing Certain Super “Rich” Widgets, an Unexpected Inconvenience

Super rich widgets/plugins like SlickGrid and CKEditor have super-inconvenient unexpected behaviors when attempts are made to wrap them in containers that hide and show (like sticking a grid inside of an accordion panel). It was difficult to accept that I had to call some kind of refresh method (in the case of SlickGrid) or destroy these visuals and rebuild them (in the case of CKEditor—it has a “destroy” method). But I had to accept this for last three months.

Visual Studio 2010, an Early 2010 Version of CodeRush and VS Extensions I have this picture that I showed to Seth Juarez of DevExpress. He’d never seen anything like it. I was getting this annoyance every few minutes followed by the error message, “Visual Studio has encountered an exception…” This was really getting in the way over the last few months. I have uninstalled CodeRush and have not seen the error since. I am still not convinced that CodeRush is culprit… it could be other Visual Extensions (as the error message denotes) but the extensions one would suspect are all written by Microsoft and are quite popular (like PowerCommands for Visual Studio 2010 and Productivity Power Tools).

### Mercurial and Bugs

In “The IT Workplace: Doing it Basil Style,” I wrote about the excruciating experience of having my code overwritten—especially when working by the hour with a bunch of miserly cretins. What I have experienced with Mercurial over the last three months effectively takes that pain away… I was using Mercurial with Kiln from the Joel Spolsky camp. Mercurial allows developers to have local repositories—so this whole overwriting thing can happen on the communal server but, locally, there should be a changeset to run hg merge (see “How to fix multiple heads?”).

Yes, speaking of Joel on Software, I did use FogBugz over the last quarter but I can’t really say much more about it—apart from having no complaints about user experience. With FogBugz and Team Foundation Server (before), I am already used to writing comments about resolving a bug—but what’s new for me now is writing down the analysis process—describing what I call the bug situation. I find these advantages:

These writings about the bug situation can turn into email messages for another programmer better positioned to resolve the bug and can use your writing as instructions to get the job done, very, very fast (and look very impressive to penny pinchers wearing rose-colored glasses). This happened to me twice just over the last few days—and I’m willing to do this again (I don’t care about making other programmer’s look “good” in the eyes of unobservant managerial types in a healthy job market).
It helps me to actually learn about someone else’s code instead of looking like I have learned about the code—I don’t look like that.
It helps me to actually manage the complexity of an application instead of being intimidated by the complexity of an application.
It helps me to remember the particular viewing angle into the tiers. I often rebel against a design that I assume is too complex and I have difficulty remembering what I’m looking at…
In most “fast paced” environments you have no idea which bug will take five minutes and which will take three days (this is actually a sign of managerial/architectural problems or a sign of “rock star” programmers hiding their faults from managers that trust them—or both). By journaling through the bugs you can get a better idea about which ones will be “easy” and then the others…
It helps me deal with what I consider one of the worst kinds of bugs: bugs that are actually requests for missing features. What can be quite evil is when these “bugs” are “sincerely” regarded as trivial issues when these are actually serious, full-blown development tasks. What this can mean is that the “rock star” programmer of the IT shop is not really doing their job and is marking tasks as complete when they are not. This makes the “rock star” appear timely, on schedule when they are really passing the buck among penny pinchers.Formally writing down the bug analysis should be considered a part of the analyst part of the job title Programmer/Analyst, which I have held for many, many years. I have no guilt, hate or deformed respect for any penny-pinching barbarians out there that are quick to assume that you are trying to overcharge them for spending an hour (or more) analyzing a bug. These cheap folks can’t have it both ways: a bug quickly marked resolved and a resolution carefully done that does not cause regression (or a new bug).

One interesting thing about FogBugz is the concept of Evidence-Based Scheduling (EBS): “EBS doesn’t give you a single ship date. Instead, it produces a probability distribution curve. That means that for any given date, it tells you what the probability is that you will ship by that date.” EBS is quite different from GBS—Greed-Based Scheduling.

The Telecommuting Experience

I can find another job. But I am not likely to find another telecommuting job. This job allowed me to take my seven-year-old daughter to school personally every day. In spite of the huge technical benefits, this time spent with my daughter was the greatest reward of the experiment.

It is very likely that I will return to fossil-fuel commuting.