Ornoth

Twenty-two years ago, I was just minding my own business.

At the consulting company where I worked, I had just finished developing BankBoston’s HomeLink & OfficeLink banking applications, and was about to roll onto a new project for a local startup.

I received an email from some new hire who was moving our (land-line!) telephones to the new team area. As you might expect, she ended by saying that anyone having concerns should call her at extension 1366.

Just one problem there: x1366 was my phone number!

I immediately emailed her back and discovered that she’d accidentally typed my extension (1366) by transposing the digits of her own (1633). Not an auspicious first impression for a new hire fresh out of college, whom I was going to have to work with on my next project!

And that’s how I met your mother...

Despite starting off in decidedly bizarre fashion, once I met Inna in person, I decided to cultivate a friendship. At work I orchestrated time together under the pretenses of tutoring her on web design and speaking to my coworkers individually about team morale.

I charmed her with hair down to my hips and bizarre boyish antics. I ran the team’s junk food fund—known as “SnackLand”—and wrote a web app so the team could vote on what they wanted to buy. When I ordered a new bicycle, I had it shipped to work in a box, assembled it, and rode it around the office space in my consultant’s white shirt & tie, despite bikes not being allowed inside the building. The security guards freaked out when I eventually brought it down to the ground floor to ride home!

But with Inna, the deal was sealed when I persuaded her to come to my place after work to meet my cat Puggle: the fluffiest longhaired creamsicle you could ever meet. From that point forward, we were an item.

Not a public one, mind you. We kept our romantic involvement strictly a secret at work for some time, only exchanging furtive kisses when we were alone in the elevator between floors. It wasn’t something we wanted people to know at first, but we’d eventually let the proverbial cat out of the bag.

In the meantime, we spent a lot of time together. I was still into Boston’s local music scene, and we went to countless live music shows.

One of our early dates will always stand out in particular. We were having dinner at Brown Sugar Cafe, a neighborhood Thai place, looking for something to do for the evening. I was lamenting that there were no good bands playing, only some stupid punk band calling themselves “The Damned”.

Little did I know, but The Damned were Inna’s teenage idol band, an aging English group whom she’d been following for more than a decade, but had never seen live. It was as if I’d waved a magic wand and made her dreams come true by turning three Fenway rats into her favorite brooding goth heartthrob singer Dave Vanian, drunk buttocks-exhibiting glam guitarist “Captain Sensible”, and (perhaps least of a transformation) a back-alley waste product drummer called “Rat Scabies”.

Needless to say, within a couple hours we were off to Axis for an evening of noise, profanity, and unsolicited exposure to middle-aged man-butt.

In those early days, neither of us made particularly desirable partners, and our relationship was very off-and-on for the next seven years, until Inna moved back to Pittsburgh. We remained best friends—with occasional benefits—for another ten years while we both matured into adults capable of tolerance, compromise, and forgiveness.

When the obscene Hell-spawned winter of 2014-2015 prompted me to leave my beloved Boston, Inna suggested I come to Pittsburgh to see if we could stand living with one another.

With four years of cohab now under our belts, we’ve settled in to a stable, lasting partnership. The future’s a bit up in the air right now due to the Corona virus, but we’re confident and comfortable facing whatever comes up together.

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…

Say you’re a happy little introvert, spending most of your time alone. Sometimes you might feel a little isolated and wonder whether the nice, safe life you’ve built is worth enduring the occasional bout of loneliness, or whether you should reach out and try to bring a loving relationship into your life.

Self-styled “normal” humans have probably accosted you with threatening phrases like “open up to love” as encouragement to change. But if it were that simple, no one would choose loneliness over love, would they? I’m here to tell you the truth.

When you leave the safety of your home, the first thing you find out is that—no matter how open you are to it—love is not guaranteed. Love is capricious, unpredictable, and unforeseeable. Whether you have success or not is largely out of your control. So at best, what all those well-intended friends are actually telling you is to open up to the mere *possibility* of love.

And because love is so rare and fickle, it’s pretty likely that you’ll waste your time and energy (and emotional vulnerability) and still come up empty-handed at the end of the day.

So realistically, what you’re actually being asked to open up to is the likelihood of rejection and heartbreak. And if you’re like most men, you’ll experience a whole lot of rejection and heartbreak before you ever find someone who will love you.

And trust me: experiencing a little loneliness once in a while is a walk in the park when compared to the pain of a broken heart.

So when your friends push you to “choose love”, remind them that it’s not a choice between loneliness and love, but between loneliness and the likelihood of repeated rejections and heartbreak, which are vastly more painful. Maybe then they’ll understand that avoiding romantic entanglements might seem like a sensible course of action to some of us.

And when they talk about dating being a growth experience, you should remind them that a growth is something painful that has to be surgically removed and excised before it kills you!

Answers to the “interview me” meme, with questions posed by lothie. Actually, I didn’t ask to be interviewed, but since she took the time to come up with questions, I figure I orta answer.

I passed on this meme the first time it came around, so I’m not looking to ask anyone else any questions, but if you insist, I’ll do.

What's your opinion on the Tao?

Not much, actually. It’s kinda orthogonal to Buddhism, or at least the southeast Asian Theravadan Buddhism from Thailand and Sri Lanka that I’m most familiar with. The Tibetan, Chinese, Korean, and Japanese forms of Buddhism might have been more influenced by it. But aside from that, I’m nt sure I fully agree in the whole balance idea, although there are aspects of it that do appear in the concept of the “Middle Way”.
 

If you could have dinner with a famous dead person, what would you eat?

Well, they’d probably turn my stomach, being dead and all, so maybe something very light. And they’d probably smell really bad, so something aromatic. Dead people aren’t the greatest companions, or at least so I believe, never having supped with one.
 

What is your least favorite thing about Boston?

Hmmm. Corruption. How hard it is to get some obvious things done. The barriers that people put up and how difficult it is to meet people. The whole car culture; there are several areas of town that should simply be closed to motor traffic, period. The lack of light in the winter and its duration. Those are probably the big things.
 

Spam: evil or food of the gods? Discuss. Give examples.

Spam is pretty useless. It’s 82% fat, and one slab is 750mg of sodium, so it’s basically a death bomb. Fried, it’s really not very appealling. I seem to recall my mother maybe putting it in ham salad back in the 70s, when I actually ate such things. On the other hand, it’s mostly pork, and pork is the food of the gods; it’s just that there are much healthier and tasty ways to get your piggy on than Spam.
 

Any do-overs you'd like to have?

Not many, but a few. I would like to have treated most of my SOs better. I would like to have been more sexually active when I was younger. Those are really my only significant regrets.

snudge, noun ('sn&j)
1: a muddy or slushy mass, deposit, or sediment produced as a by-product of snuggles and/or hugs.