Ornoth

Of all the places I’ve worked, the one I’m most proud of was Sapient, one of the first and most successful Internet consulting agencies of the Dot-Com Bubble.

And probably the thing that I’m most proud of about Sapient is the list of amazing and noteworthy clients I got to work with, including National Geographic Magazine, Verizon, JP Morgan, Staples, Vanguard, WorldCom, Wells Fargo, Cardinal Health, and many others.

But one client and project will always stand out in my memory: HomeLink and OfficeLink, BankBoston’s first Web-based banking sites for individual consumers and small businesses respectively. And because of that, I’ve retained a not-small pile of memorabilia.

Why does that client stand out? Because I was already a HomeLink user! I had been using the first iteration of HomeLink for a few years already, back when “online banking” meant installing the bank’s dedicated software, which used your modem and public telephone lines to connect directly to the bank’s systems!

In 1997, the bank wanted to scrap the old dialup system and create secure, online banking websites for home and business use. They came to Sapient to design and build it, and Sapient assigned me to the project, since I had already accumulated fifteen years of experience programming Internet-based information services.

Before I go on, don’t let the company names confuse you. When I first started using HomeLink, I was a customer of BayBank, who had licensed the dedicated dialup software from Citicorp. But in 1996, BayBank merged with the Bank of Boston to become BankBoston, who wanted to offer HomeLink via the Internet. They were in turn bought out by Fleet Financial, which became FleetBoston; which was in turn acquired by Bank of America in 2004. But unlike the company name, HomeLink survived all those mergers.

Now let me share some of my archaeological exhibits, beginning with the old BayBank days, back when I was a dialup modem customer, years before Sapient got involved. First there’s this branded mousepad and 3½” HomeLink install diskette (version 1.0c)!

Tho my favorite memorabile from the old BayBank system is this screen capture from the installation program, where a really mediocre drawing of the greatest Boston Bruins player of all time says, “Let’s log on,” while a huge disclaimer reads, “This is a fictional situation. In real life, Bobby Orr is not authorized to view your account information under any circumstances.” Effin’ priceless!

Moving on to Sapient’s design and development of the new HomeLink, here’s a couple of Sapient “design center” signs. We used these to direct client staff where to go when they arrived for design sessions and development checkpoints, and I kept dozens of these from my old projects. Note how the eventual OfficeLink site was originally named “BusinessLink”.

Finally, here’s some marketing materials that BankBoston produced for the new HomeLink rollout, along with a demo CD-ROM.

The client engagement began with the design of the consumer banking site. As that transitioned into the development phase, the design of the small business site kicked off. I joined the latter team, and did requirements gathering and user interface design for OfficeLink, but once those plans were signed off, we all rolled into a single, unified development team. I was on the project for about a year.

This was the best example of doing development on a product where I was already the intended end-user. As such, I was immensely proud of my contribution, the site’s rollout, and its long-running success in the marketplace. And it still stands out in my memory, even amongst all the other prestigious clients and projects I worked on.

Who is the best foosball player in the company? This question has followed me through three of my last four employers, ever since I spun my first rod back in 2005.

I’m happy to say that I’ve been able to provide my coworkers with an answer to that eternal question, through FRank, the foosball ranking site I first developed nearly ten years ago. If you’re interested in ancient history and FRank’s inception, you can read more about it in this blogpost from 2007.

A year after I wrote that post I left Optaros, and my foosball ranking site languished, nearly forgotten. After wasting a couple years at a sad little company that didn’t even have a foosball table, last December I found myself interviewing at Buildium, whose kitchen included not one but *two* tables! During the interview process, I made sure they knew that hiring me meant access to my foosball ranking site, too!

Naturally, after years of neglect, I wanted to clean things up a bit (and size up the foosball culture) before I opened the app up for public use. So over the past few weeks I put a few hours into a bit of a refresh. And I’m pretty happy with the result.

Here are some of my favorite new features:

First, I rewrote everything using Google’s Angular javascript framework. For non-techies that probably doesn’t mean much, but it’s cool new technology that I really need to learn anyways. And it allows me to easily do some cool things like providing predictions of the score of any given combination of players.

I also made it a single-page app, which means everything happens on one page, kinda like Google Docs, without any page refreshes because all that data comes from behind-the-scenes API calls. It feels more like a native application and less like a website.

Next, I redesigned it to have a mobile-friendly user interface, so that it would be simple and easy to use, whether you were on a desktop, laptop, tablet, or smartphone. It even has its own little icon so that its bookmark looks just like any other app on your phone.

I even added the Web Speech API, which allows anyone using Google Chrome to enter a set of players by saying aloud something like “Jordan and Matt versus Dave Owens and Ben”, rather than having to manually navigate four cumbersome drop-down lists.

In the first two weeks of public availability, the adoption rate among players here has been great. This week I added a user-suggested feature: when someone logs a game, a message is automatically broadcast in our company’s foosball chat room (from “FRank Foosbot”), summarizing the result for all to see.

Needless to say, I’m pretty happy with how I was able to bring it up to date with how the web has evolved. It’s been a fun coding exercise, while contributing something unique to the company culture.

The biggest irony, however, was when Buildium hired my old friend Dave. I worked with him at both Sapient as well as Business Innovation, where he wrote (and then lost the source code for) his original Microsoft .Net foosball application that inspired me to create FRank. And years later, we’re working together again, and I get to show him what his old foosball ranking system has evolved into.

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…

Call me a revolutionary, but I don’t see any reason why we should use an operating system that was intentionally designed to be user-unfriendly, and which was designed 40 years ago, back when 8-track tapes were the state of the art and the two-byte difference between “copy” and “cp” was really, really important.

I still marvel as my Linux weenie coworkers have to kill hours rebuilding their entire file system because they powered Unix down without going through the formal shutdown process. Oh yeah, and don’t forget that it allows users to create a file called “~”. Just don’t ever try deleting it, because the tilde is also a shorthand notation for your home directory! Now ain’t that intuitive? And don’t forget the Windows Find post I made last year at this time…

Unix is a fossil, and running Linux is like making your Twenty-First Century laptop backwards-compatible with rocks. I’m not saying Windows is especially great, but I am saying that Unix is not a serious platform for anyone who wants to actually get work done, as opposed to dicking around with obscure incantations.

That was what I was thinking when the following exchange occurred at work:

Orn: Why don’t my Windows keys work?
Jay: Install Linux
Orn: Yeah, like I want to type Ctrl-Alt-Shift-T-Backspace-U to login.

I think that kind of key combination is pretty typical of Unix. I just made up a completely random and undocumented sequence of keys on the spot to poke fun at Unix’s patently stupid fixation on arcane and unintuitive escape sequences. Jay thought it was funny and used that exchange as his instant messenger away message for a while.

Ironically, one of our senior technical architects noticed Jay’s away message. He runs Linux, and out of curiosity and sheer stupidity, actually typed it into his Linux box.

What did it do? It killed his X Windows. Brilliant! Gotta love a system that’ll let you type a random key combination and crash your whole windowing system.

You may now picture all the Unix weenies who read this post doing the same thing, just to see what happens…

There is only one Stupid Unix Trick, and that’s ever installing that shit.