Ornoth

After a record-short 333 days, my tenure at Buildium is over.

Last winter’s ludicrous snowfall finally put the nail in the coffin of continuing to live in Boston. But it also became clear that moving out of Boston wasn’t compatible with my employer’s plan to centralize their personnel locally and stop supporting people working remotely. I had hoped to stay on while relocating, because it would obviate the need for any Pittsburgh job hunt, but given our opposing directions it was inevitable that Buildium and I would have to part ways when I left town.

In the past, when I left a company (as opposed to being laid off or having the company move out from underneath me), I’ve always been fortunate to move on to something better. In 1995 I jumped from a failing medical software company to a rapidly-growing nascent internet consultancy, which was without question the best career move I’ve ever made. And in 2006 I left a tiny professional services contractor to return to large-scale internet consulting just as open-source and “Web 2.0” were taking off. It would be awesome if this departure leads to similar improvement, especially given the way front-end coding has transformed over the past couple years.

The unfortunate aspect of my departure is that I’ve been really happy at Buildium and would prefer to stay. While property management software isn’t the noblest purpose in the world, it was a huge improvement over my previous job spamming students and funneling leads to student loan companies. I greatly improved my technical skills, the hours and stress level were uncommonly humane, and the pay was good.

And the people were awesome. Buildium’s leadership team has its share of challenges, but it’s been very satisfying to once again work with and for people with a healthy dose of both intelligence and common sense—as might be expected from a company founded by and stocked with fellow Sapient alumni.

But more than that, what makes Buildium unique—both among my former employers as well as across the industry—is that its staff are enthusiastic and uncommonly personable and caring, without being contrived or dogmatic about it. From top to bottom, the positive attitude of their team members sets Buildium apart from other places I’ve worked.

That’s a big reason why I would have preferred to stay on as one of several remote workers on their engineering team. Sadly, the commitment to centralizing operations in Boston made that impossible. And after 25 years here, my life is taking me in a different direction.

Although that didn’t stop me from feeling a certain righteous amusement when HR asked the employees to vote on what Buildium could do become a better place to work. Someone added “Work remotely” to the list of ideas, and sixteen people put their checkmark-votes next to that item: more than twice as many as any other suggestion!

And if that input had been put into practice, I would still be working there, rather than going my own way and diving back into the job market in an unfamiliar town.

Before I talk about my new gig, a brief word about the old one. I spent nearly three years working for a student loan marketing company called Edvisors. In 2013, a company from Las Vegas bought them out and phased out our Boston headquarters.

The title of this article is a bit of an inside joke. Edvisors had a lot of turnover, and people came to appreciate the euphemism “Transitions”, which was the usual subject line on the emails announcing another coworker’s departure.

Edvisors was pretty political and had (insert superlative adverb) outdated technology. On the other hand, I’m very proud of what my team accomplished. We built a good frontend team from scratch, set up vastly improved processes and standards, and dragged the company kicking and screaming toward 21th century technology and design practices.

Even after a six-month soft landing at Edvisors, I still took some additional time off. In the past year or two, the frontend technology field has advanced radically, most particularly in client-side Javascript frameworks like Angular and Ember. At the same time, I started hemorrhaging money thanks to repairs and medical bills from two big bike crashes, diagnosing and removing a faulty gall bladder, big vet bills after the sudden death of my pet cat, and renovations to my condo. Between rapidly changing technologies and a shrinking nest egg, it was time to get back to work in earnest.

Once I got serious about the job hunt, it took just a month. I only sent out four resumes, and got responses from three of them. I’m immensely thankful to have so many helpful local connections and a nicely loaded resume. It was also nice to get through the always-stressful tech interview; you never know what questions (or coding exercises) you’ll be asked, and despite having lots of experience, one always wonders how one’s tech chops will measure up against other candidates.

So two weeks ago I joined a company called Buildium, which was founded by a couple old coworkers from my Sapient days. Once upon a time, they bought and started renting a couple apartments, but discovered there was no good software to help them manage their properties and renters and contractors and taxes… So they built it themselves and started selling it, and they’ve built a thriving business around it.

I’m a senior member of their growing frontend team, and I’m really excited that they are transitioning to the Angular framework, which is a tremendous opportunity for me. They also have a strong UX design practice, which is a real differentiator for a small product company.

In addition to the two founders, Buildium employs four other old friends from my Sapient days: one’s still a working designer, and the others each manage Buildium’s technology, design, and product management practices. And there’s at least one more old friend starting in January.

Even though it’s been about twelve years since we worked together, I was surprised by the things my old friends remembered about me. One of them recalled that I was the kind of person who absolutely didn’t want to climb to senior/leadership positions, and another fondly remembered the “Snackland” website I built (in ASP & ADO!) to help teams vote for what snacks they wanted to spend their collective money on.

Having kept in touch with some of those guys, I recognized the company name when a developer position at Buildium appeared in my RSS feed of job listings one day. I reached out to one of those buddies, and the rest was pretty straightforward.

This constituted the unlocking of one new achievement: the first time I’ve ever received a job offer without ever meeting anyone at the company face-to-face! Most of the vetting was done by phone, with one video chat for the tech test with a developer in California. In fact, I was the one who insisted on coming in to check out the office and meet a few people before accepting their offer! Very different experience.

As a company that prioritizes employee satisfaction, the benefits are refreshingly good: completely flexible PTO, the potential to work remotely, and of course I’m pretty happy to have decent health insurance again, after footing the bills for my recent medical issues. And they have not just one, but TWO foosball tables, which means I need to work on restoring the meisterly skills I had six years ago. Initial indications are positive, but considerable practice will be required! There’s also the opportunity to rewrite FRank, the foosball league ranking site I made so long ago, perhaps adding a mobile interface and speech recognition!

They’re located at the opposite end of Downtown Crossing from where I used to work at Optaros, so I know the area pretty well, and plan to revisit Lanta, the Thai place that formerly was Rock Sugar, my go-to lunch spot.

I’ll also enjoy a reprise of the walking commute I had down the statue-lined Comm Ave mall and through the Public Gardens and Boston Common. Or ride a whopping two stops on the Green Line… Definitely beats the hell out of the 40-minute commute down to Quincy that I had last year! Although I’ll miss having that nice, long bike commute, too. It’s not worth riding one mile to Buildium; it’d be as pointless as going out for a two-block jog!

On that note, there is a Buildium Strava cycling club, and their big company outing is to ride the 175-mile Cape Cod Getaway charity ride for MS each year. It goes from Boston to Provincetown, like the Outriders ride I do each year; while the MS ride takes a leisurely two days, Outriders does a shorter 130-mile route in just one day! Amusingly, it usually takes place one week before the MS Ride.

I also garnered an enviable second new achievement: coming in to work wearing jeans on my first day! Very cool! But my first day ended with something a lot less cool: when I went home and checked my postal mail, I received a note that my gall bladder surgery was scheduled for Thursday, only two days later! So at the end of my first workday, I had to ask on short notice for two days of PTO!

After taking Thursday and Friday for the operation, I returned to start my second week of work a week ago. I set up my development environment and finished my first code fix. Then Friday was the company holiday party…

I already posted to Facebook about the awkwardness of starting a new job right before the holiday party, which is an experience I’m always desperate to avoid (as related in this anecdote from my Sapient days). Fortunately, two weeks was sufficient to break the ice with some officemates—thank goodness for the non-threatening mixer value of foosball!—and so I survived our seasonal Mandatory Fun.

My third week began with the deeply exciting experience of PAYDAY!!! I also have transitioned into a new (semi-permanent) team, so that I can cover for another frontend dev who is moving away at the end of the week. That’ll provide some immediate challenges, but it’ll also be exciting to be able to really dig into the work.

So overall the new job is Really Good.

Here’s one final observation. Having always set money aside when I was working, I’ve had the flexibility to take some time between jobs to unwind and just enjoy life before jumping back into it. But this fall I looked back at my resume and was a little surprised when I added up the numbers; since 2002, when I left Sapient, I’ve taken almost seven of the past 13 years off!

And being honest, I have to say that it was a really good thing. I’ve enjoyed entire summers kayaking or cycling, and been free to travel or devote time to my meditation practice. Given how insanely stressful and frustrating and exhausting software development can be, I think those periods of relaxation have been a real lifesaver for me. I definitely think it’s nice to pull a year or two of one’s retirement forward, so that one can enjoy time off while one’s still (comparatively) young, strong, and healthy. And the break gives one time to decompress and reconnect to one’s enthusiasm for work (and money!) before going back to the daily grind.

Now my most recent little sabbatical is over, and it’s time to dive back into the melee. But at Buildium, I’m really excited by the company, the people, and the technology, so I’m planning on enjoying it quite a bit.

With the perspective that comes from thirty years in tech, I’ve gained quite an appreciation for the basic absurdity of developing software.

A quick look in the rear-view tells a revealing story.

Of the volumes of software I’ve written, perhaps a quarter of it was never even used. And nearly all of the code that did make it into production was gone and deleted within five years of its creation. Heck, half of the companies I worked for disappeared within eight years! And nearly every programming environment I ever learned was obsolete within ten.

While everyone talks about how rapidly technology evolves, it’s rare that anyone thinks through the implications. The software that I was quite well paid to craft has been astonishingly ephemeral, and the development tools that I’ve used have had a useful lifetime somewhat shorter than my last pair of socks.

Needless to say, this isn’t just my problem; everyone in our industry faces the same underlying challenge. Nothing lasts forever, but in tech, everything we learn, use, or create should come with a “use-by” date of fewer than 60 months.

When you were young, you probably got the impression that your career would be a linear journey from Point A (your first job) to Point B (a comfortable retirement).

In the tech field, it’s more like trying to steer a sailboat at sea. You can point yourself toward a destination, but the water’s hidden currents and tides will pull you in different directions. The wind, waves, and other people’s passage will also push you off course. Never mind that every employer and project asks you to use their own boat with completely different rigging! And sometimes, either by choice or necessity, your destination changes mid-stream. About the time you reach the middle your career, you realize that your industry and career trajectory are far more fluid than you foresaw when you first set out.

While all this change and dynamism makes it hard to make progress in any one direction for long, if you develop the insight and skills to respond to these changes wisely, you can still get to a happy destination, even if it might look nothing like what you imagined when you got your first offer letter.

What follows are a list of observations I’ve made over the course of my shifting career: some often-overlooked implications of trying to navigate my way through such a turbulent industry. I hope they are of value to you on your own journey.

First, let’s look at the implications the ephemeral nature of software has on companies as a whole.

As soon as a development team delivers a software system, companies and product managers need to immediately start planning for its replacement. These days, you have two options: either factor a perpetual enhancement and revision process into your product strategy, or plan to simply throw away and reinvent your system at great cost a little further down the road. The traditional concept of implementing a system once and then scaling back for a lengthy “maintenance phase” died about the same time as pay phones and busy signals. It’s a nice old-fashioned idea that will lead you directly toward your Chapter 7 filing.

Whether you are a product manager or a development lead, you must accept and somehow communicate to your development team that time to market is infinitely more important than the elegance or academic correctness of their code. Bug-free code does not exist, and companies are much more rigorous about following the old 80/20 rule. If you’re truly following the Agile model (rather than pretending, as so many companies do), your top priority is to ship the beta: get an initial offering with a minimal feature set out into the market, and then react rapidly to customer feedback. These days, software that is “good enough” is almost always good enough.

When I first became an engineer, my older brother offered me one of the most valuable insights of my entire career: never hire technical staff for the knowledge they already have; instead, evaluate candidates primarily on their ability to learn new skills quickly and effectively. Five years down the road, the knowledge they walked in the door with will have no value; their usefulness as employees will be determined by how easily and quickly they can become productive with new languages and tools. Furthermore, the optimal way to retain the best technical talent is to support their desire to keep up with current and emerging technologies.

Now let’s talk about a few things that apply both to individuals as well as companies.

Whether you’re an individual managing your to-do list or a product manager specifying features and enhancements, you’re always going to have more tasks than time and resources to complete them. Therefore, always work on the highest value item. Constantly ask yourself whether you and your team are working on the most strategically valuable task. Always attach yourself to the tasks that truly have the most impact, and don’t waste your time on anything else.

Risk is uncomfortable. Risk is a threat to one’s company and one’s career. And yet risk is an inherent part of every single thing we do. While moving cautiously forward might seem like the most comfortable and risk-free approach, it really only defers that pain, because there is a huge hidden risk associated with not moving forward assertively enough. Both corporations and individuals must learn how to embrace risk, tolerate its associated discomfort, and recover from failures.

Software engineers and managers often have a grand dream of software reuse: the idea that if you’re building a program to handle Task A, you should invest some extra time into making it generic enough to handle anticipated future Tasks B and C. In the real world, B and C might never be needed, and their requirements are likely to change between now and then anyways. While it goes against our sensibilities, it is often quicker and easier to just duplicate and customize old code to handle new tasks. If the additional cost of maintaining multiple versions becomes sufficient, only then should you invest the resources to refactor it into a single generalized solution. That might sound like blasphemy, but in thirty years I’ve rarely seen a compelling example where software reuse saved money in the long run.

Finally, let’s talk about how we as individual employees should respond to the fact that our work has such a surprisingly short lifetime.

On a purely tactical level, as soon as you finish a project, save some screenshots and code samples for your portfolio. Six months later, those sites you built will have changed significantly, if they survive at all.

While everyone wants to be the best at what they do, building deep expertise in any tool or language no longer makes sense, because most languages are supplanted in a few short years. Rather than becoming an expert at one thing, a better strategy is to become the long-derided jack of all trades: someone who has a wide breadth of knowledge, an understanding of the general principles that apply to all environments, and the ability to adapt to changing business needs and a changing job market. Cultivate your passion for perpetually learning new tools, and your ability to be comfortable doing so under stress and time pressure.

In terms of getting your resume noticed, what you have done is not always as significant as who you worked for. Sites and projects are ephemeral, but major companies last longer and will catch the reader’s eye. Working with companies that are household names will—for the rest of your life—help you get that first phone screen.

My advice to all individuals is to focus on saving cash when you’re working, so that you can comfortably weather the inevitable downturns in the business cycle. Every time I’ve been laid off, I’ve been able to take a year or two off to decompress, have some fun, wait for the next upturn in hiring, and then be selective in my hunt for a new position. Layoffs and buy-outs weren’t personal emergencies because I had the cash on hand to weather any situation that arose. But if you take time off, devote some time to keeping your skills up to date and learning marketable new technologies.

Unlike the coding I’ve done, the one element of my career that has proven surprisingly durable over the long-term has been the relationships I’ve built with my coworkers. Despite everyone moving from project to project and job to job and often city to city, people remember you forever, and a robust contact list is immensely helpful in finding great places to work (and knowing which ones to avoid). It might sound crazy, but this has been one of the most important elements of my career success: put just as much effort into developing good relationships with your coworkers as you put into the software you write. Software doesn’t last, but people do.

Finally, one closing bit of advice about the long-term. If you want to be happy when you look back on your career, you must work for companies and projects that improve people’s lives, rather than just making a buck. Being a successful spammer or marketer might pay the bills, but money isn’t fulfillment. No matter how elegant, satisfaction will not come from the short-lived systems you build; real, lasting fulfillment comes from the impact your work had on real people’s lives. Life is too short to waste your time working on shit that doesn’t have any meaningful value, so make sure you’re contributing to a business you can really believe in.

And, of course, don’t be surprised or dismayed when the systems you worked so hard to build disappear overnight. It’s one of the facts of life as a software developer…

There really needs to be a corollary to Newton’s Second Law of Thermodynamics, stating that website maintenance is a constant (and un-winnable) battle against the Stupid introduced by other people.

Usually this involves a lot of quiet fuming while cleaning up the garbage left behind by the incompetent agents of entropy. But sometimes the Stupid is just so ludicrously headdeskingly perfect that there’s nothing you can do but laugh until you gag on your own puke. All the while, marveling at the “mysteries of the universe”.

For example, consider the following. While working on something, I once came across the following block of code on a production website:

$rss_feeds = "";
echo $rss_feeds;

Now, even if you’re code-illiterate, you can probably figure out what this does. It sets a variable to nothing and then prints… nothing.

Why? No reason. The only thing I can figure is that someone hired a contractor and paid them based on the sheer number of lines of code they produced.

Now, before I lose all the non-coders in the audience, here are a couple examples where people chose to demonstrate their mastery of their native language. For example, take this headline that appeared in a second-level heading on one page:

Private vs. Gevernment

Or this major announcement:

Without further adieu [...]

Or this favorite job listing of mine:

[...] is currently seeking a Senior FrontEnd Web Developer with 710 years of professional experience

Working our way into the code doesn’t have to be painful, though. How about this one: Need to name a file? Why not name it after your own awesome self?

$fileExt = 'markrules';

Another one that is easy for non-coders is this one:

<div id="left_content" class="right">

Yup. In the Stupid Universe, left is right and right is left.

Now how much would you pay? But wait: there’s more!

<?php //    include('ad_med_rectangle.inc.php'); ?>
<?php include('ad_med_rectangle.inc.php'); ?>

In PHP, two slashes are used to comment something out. So here we have a line of code carefully commented out. And then the exact same line, not commented out. Um… huh?

Speaking of comments, try figuring out what this one does:

$form->addElement('hidden', 'xzdf', 'A3104', array('id' => 'xzdf'));

Using names or key values with self-evident meanings is really overrated. The Law of Stupid instructs us to use completely nonsensical names, and make sure you don’t leave any comments in the code that might explain to the people maintaining your code what those random numbers and strings of characters actually mean!

And then there’s this mystery of the universe, a perennial favorite:

$term = ereg_replace("hero", "elongated sandwich", $term);

I can’t tell you why this site has such a strong aversion to heroes, but it’s clear that any time we find the word “hero”, we replace it with our preferred term “elongated sandwich”. No reason; we just do. No hero worship allowed here!

Here’s a fun one!

.blue_button {
    background: none repeat scroll 0 0 #ED8D1E;
}

Blue_button, huh? You might be forgiven if you thought that might actually show a button that was blue. But that background color of #ED8D1E? That’s dark orange. OF COURSE!

For some reason, “switch” statements seem beyond the grasp of many well-compensated “engineering professionals”. I’m not sure why it’s so difficult to do different things depending on whether a variable has a value of 1 or 2 or 3, etc. Is that so hard? Apparently it is. Here’s a nice example:

case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;

That’s a double dose of Stupid! Here, all the cases do exactly the same thing! But that’s okay, because they all test against the same value, too!

In plain English, it translates thus: if it’s a 1 you do this; but if it’s a 1 you still do this; or if it’s actually a 1 you would also do this; and if 1 you do the same thing too; and so on. That’s seventeen lines of code to do what requires only one. See what I mean about someone being paid per line of code?

Of course, that only works if you want to do something. Truly masterful Stupid code does nothing, like this switch statement:

switch($page[subnav]) {
}

Huh. Only outside of the Stupid Universe is it customary to write code to actually *do something*.

Of course, junior developers often aren’t wise enough yet to disguise the fact that they’re doing nothing. Consider this:

Yes, that’s nothing. That’s the whole contents of a file I found called small.css. Small, indeed! Perhaps they thought they weren’t leaving any evidence of their stupidity behind.

Here’s some additional CSS-flavored fun:

<div style="clear: left;"> </div>
<div style="clear: right;"> </div>

More from the Planet of the Confused: why not just do “clear:both”? Oh yeah, it’s because YOU HAVE NO IDEA WHAT YOU’RE DOING!!!

ttable tr td.odd {
     border-left: 0;
     border-right: 1px solid #fff;
}

Did the W3C create a new HTML tag (ttable) and I missed the news?

p.margin-left {margin-left: 15px; padding-right: 15px;}

So let me get this right: a paragraph called “margin-left” actually has equal margin on both sides? But on the left it’s a margin, and on the right it’s padding? That makes perfect sense, especially if you don’t understand basic HTML page layout!

Here’s an exemplary 12 lines of masterful coding:

if (isset($page_close)) {
$page_close .= <<<EOD
</body>
</html>
EOD;
} else {
$page_close = <<<EOD2
</body>
</html>
EOD2;
}
echo $page_close;

That’s just another example of how these guys clearly were getting paid per line of code. No matter what $page_close is set to, what those 12 lines of code really do is this:

</body>
</html>

No need for complex logic or any dynamic behavior. Good thing they inserted an extraneous IF/ELSE block, two “here quotes”, and echoing a variable, because how else would one know they were such masters of PHP syntax?

if (test_it_counter == 0) {
   computeForm(entry.form);
}
computeForm(entry.form);
test_it_counter++;

So the first time through this program, computeForm() get run twice in a row, just for kicks. I’m sure that works just great! I wonder why they didn’t run it twice every time?

<div id="nav" onmouseover="Tip('#nav { <br /> <var>float:</var> left; <br /> <var>width:</var> 788px; <br /> <var>height:</var> 36px; <br /> <var>margin:</var> 0; <br /> <var>padding:</var> 0; <br /> <var>background:</var> #fff url(images/navbg3.gif) no-repeat; <br /> <var>text-align:</var> center; <br /> } <br /><br /><cite>Note the hover action. </cite>')">

I have absolutely no idea what the coder was thinking here. If you hover over a nav, it displays a tooltip with a bunch of CSS code (which actually doesn’t get used and doesn’t appear anywhere in the page) and the message “note the hover action”. Glad that has been running out on the production web site for four or five years…

My final example is a solve-it-yourself problem. Are you ready for a developer challenge? How long does it take you to spot the Stupid in this statement?

<?php if ($isForm = false) {

This one’s an all-time classic and a personal favorite. When comparing a variable to a literal, professional software engineers always put the literal first. Do you know why? Well, the above is a perfect illustration why. The reason why will be left as an exercise for the reader.

Another gem from work.

We’re looking to hire a senior frontend developer. I was given a resume that came in via a headhunter and was asked to comment on it. After eyeballing it, I went to the candidate’s portfolio site.

The third item on his web portfolio looked kind of familiar. In fact, it was one of my company’s primary sites. Wow, that’s quite a coincidence!

The accompanying writeup stated that “Working as an Independent Contractor and given a visual design and graphic file, I hand coded the following Web page mock-up using XHTML and CSS for a newly designed Web site’s home page.”

Naturally, that piqued my curiosity, so I did some investigation. The page he produced “as an Independent Contractor” was actually nothing more than a tech test we used to give to prospective frontend candidates.

That’s right: candidates. This was not work that he was ever paid for, there was never any pretense it would be put into production, nor was his work good enough to earn a job offer the first time around.

And clearly he has no chance in hell of landing the same job a year later, based on (1) his willingness to lie about his experience, and (2) the fact that one of his highest accomplishments is completing a tech test from a job interview.

Come on buddy… Get a job.

Just a quick note to observe the 25th anniversary of both the Space Shuttle Challenger disaster… and my professional career.

The Challenger disaster is one of the few news events where I recall exactly where I was. At twenty minutes before noon on January 28 1986, I was at work.

Although I hadn’t finished my undergrad at UMaine, I had just begun working as a software engineer for the university’s parking, police, and fire departments, which were all housed in one old farmhouse on the edge of campus.

My Televideo 925 mainframe terminal was located just outside the police chief’s office, and when the news broke about the shuttle’s disintegration one minute into its flight, the chief called everyone into his office to watch the event on the television that he usually used for videotapes or presentations.

Three months earlier, in October of 1985, I had been fired from a job slinging sandwiches at 7-Eleven because I had actually read the manual on how to operate the cash registers. My buddy Mike Dow was doing database work for the parking department and brought me in to assist, since he and I had already done some volunteer work together on CSNEWS, one of the internet’s earliest information services. But the Public Safety gig was my very first paid programming job.

For that reason, the Challenger disaster is inextricably linked with the beginning of my professional programming career. A career which has now officially spanned twenty-five years.

It’s been quite a ride, but I won’t indulge in reminiscing about all the good and bad times along the way. I’ll simply say that I’ve learned a lot, developed valuable skills, had a lot of satisfying successes, made so many great friends, and had a ton of fun. It’s enough to make an unemployed guy want to go back to work!

But today isn’t about all those things. It’s really more about just taking a minute to say: Wow, twenty-five years!