Ornoth

With the help of the Duolingo app, I’ve been learning Japanese since December. Inspired by my example, Inna began refreshing her Hebrew in March.

So we’ve had a little time to hear one another’s practice as well as compare notes on what we’re being taught. And the results are more than a little bit interesting.

To amuse my captain, I’ve included a few screen shots of the everyday phrases we’re learning. Let’s start with my newly-acquired Japanese language skills:

And now let’s compare my Japanese phrases to the vocabulary that Inna is picking up in Hebrew:

I’m sure no further elaboration is necessary.

Meditation teachers will often refer to scientific studies on the effects of meditation, such as the Dalai Lama’s well-publicized cooperation with western neuroscientists, which goes back more than 30 years.

As a garden-variety practitioner, I never imagined my brainwaves would be of interest to the scientific community.

However, when our Wednesday evening meditation group leader forwarded an email from the CMU Brain-Computer Interaction lab recruiting experienced meditators as subjects, I decided to sign up. After all, I had the requisite background, ample free time, a modicum of curiosity, and willingness to pocket some easy cash.

The experiment’s primary question: “Does meditation help you learn how to control a computer with just your mind?”

This is part of their larger investigation into decoding a user’s mental intent solely through neural signals, to enable patients with a variety of neurological dysfunctions, such as stroke, ALS, and spinal cord injuries to control devices such as robotic arms, quadcopters, and so forth. There are explanatory videos on the lab’s web page.

And we won’t mention the obvious military and espionage applications of this technology, except perhaps to highlight its applicability for control of huge Gundam-style mecha-robots!

Over the past month, I went to the lab for five identical two-hour sessions. Each session began with the lengthy task of fitting and wiring up an EEG cap with about six dozen electrodes. Then the actual experiment, followed by calibrating the cap and washing gobs of electro-conductive gel out of my hair.

The experiment comprised a series of tasks wherein I controlled the movement of a dot on a computer screen on one axis (left/right), then another axis (up/down), and then both dimensions at once. To move the dot required only that I think about moving my left hand, my right hand, both hands, or neither.

That “neither” is a “gotcha” for most people, because how do you go from concentrating on your hands to not thinking about them? It’s a direct example of psychology’s “ironic rebound”, whereby deliberate attempts to suppress a thought actually makes it more likely (e.g. don’t think about a pink elephant).

It was wondrous seeing such thought processes play out on screen. I’d move my attention from right hand to left, but if the subtlest attempt to not think about the right hand crept into my mind, the cursor would stubbornly swerve in that direction.

However, an experienced meditator knows that we have only crude control over our minds, and quickly recognizes that “gotcha” because they've experienced it thousands of times. They’ve learned strategies for sidestepping it, such as dropping all thought by focusing on other sense input, or redirection (e.g. mentally reciting the list of prime numbers). So a meditative background was very beneficial for me.

After starting at a modest level, over time my accuracy and performance improved. And importantly for me, the amount of mental strain and fatigue I experienced fell away, too.

The experiments also confirmed my perceived pattern of learning and proficiency. In nearly any new field (with a few well-known exceptions), I’ll display remarkable initial aptitude, then gain basic proficiency steadily and quickly. However, not long after, I become complacent and my skill level plateaus, while others who started at a lower level of proficiency catch up and potentially surpass me. That was my experience in graphic design school, and it was confirmed by the lead researcher in these brain-computer interface experiments.

The CMU study called for six visits doing the same experiment, followed by a seventh that would feature a different set of tasks. Unfortunately, this was taking place while the COVID-19 pandemic was spreading into the US, causing universities like CMU to send students home; so out of an abundance of caution I regretfully cancelled the final two experiments. I was kinda looking forward to that final session, and the extra $160 that I forwent.

But now I can officially say that my brain was the subject of scientific inquiry and experimentation, and that I’ve contributed to the growing body of scientific knowledge about the effectiveness of meditation. And having done a proof-of-concept that I can control a computer with my mind, the next step will be total world domination!

Although due to concern over the spread of COVID-19, right now I’m focusing all my efforts on opening doorknobs using my mind, rather than my hands...

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…

A couple weeks ago I discovered a Buddhist book club being run by the owner of Trident Booksellers. I promptly snatched the current book from the BPL and read through it. I took a few notes to bring to the discussion, and I thought I’d post them here, as well. So here’s my notes on Pema Chödrön’s “Start Where You Are: A Guide to Compassionate Living”.

This was the first Chödrön book I’ve read, and I can’t say it lived up to her popularity. Her writing style didn’t come across as particularly noteworthy, and what she had to say… Well, the book is focused mostly on particular practices—tonglen and lojong—which might be useful to some, but which would raise a bunch of questions for beginners. So I found the book overall of limited value. Despite that, there were a few interesting things I could pick and choose from.

One thought pertained to the defensive barriers that we establish around ourselves. Those mental and emotional barriers keep our tender bits safe, but they also distance us and alienate us from other people, as well. But the thing Pema wrote that I found interesting was that this armor we surround ourselves with, which seems so solid, so trustworthy, is really just made of thoughts that we churn out. There’s nothing to them but what we think they are. I know, it’s one of those things that is kind of patently obvious, but it’s also something that we tend to forget on a daily basis.

The next point follows a similar vein. All your past: it’s just an idea. It has no real existence. Worse yet, it’s an idea that only you hold. For example, no one I know remembers the Jimmy Castor Bunch, or their 1974 album “Butt of Course”, featuring the “Bertha Butt Boogie”. Even people who shared your life with you—your first girl- or boyfriend—have a completely different image of that “shared” past than you. You think the past is a fixed thing that defines you, but ultimately it’s just a series of ideas that absolutely nobody but you holds. So is it really all that important?

Pema also stated one of the major themes of Buddhism fairly succinctly. I’ll paraphrase it here, but the basic idea is that helping others is one of the most effective methods of self-improvement, while improving yourself simultaneously helps others. It’s kind of a feedback loop of sorts, where helping others—something that’s all but forgotten in our competitive, acquisitive society—helps ourselves much more than our secular selfishness ever could.

Buddhism encourages its adherents to give of what they have to others, in part to reduce one’s attachment to material things. Even in western cultures we think of sharing as a good thing; however, Pema suggests we go further, being willing to give away things we might really value that would make others’ lives happier. While we can all relate to sharing, giving valued things away is much more difficult because it challenges our ideas of security and possession and attachment. If you’re serious about losing your attachment to material goods, you might well consider practicing this kind of “giving until it hurts”. According to Pema, it won’t actually hurt, but give you an enduring sense of happiness.

The lojong practice includes a number of pithy sayings that one is meant to contemplate. The one that seemed most interesting to me instructs you to “Always meditate on whatever provokes resentment”. That’s a very interesting instruction, because it asks us to step back whenever we feel hatred, anger, jealousy, or fear and analyze the origins of those feelings. Its at those points when we can work with the root causes of careless speech and action and overcome the unconscious behaviors that cause tension and conflict with the people around us.

The other saying that I found especially revelatory was “Don’t expect applause”. Even the best practices and living as the embodiment of lovingkindness and compassion will not guarantee others’ gratitude. Even that internal sense of satisfaction you get at having taken the moral high ground isn’t predictable. This can be incredibly frustrating, and is another emotional reaction which is worth studying. Perhaps the best orientation is to expect the unexpected and approach each situation with curiosity, rather than a sense that if you “do the right thing” you’ll be rewarded somehow.

One final topic that came up during the group discussion that I found interesting was the assertion that there’s limited value in reading about Buddhism. Buddhism is extremely practically focused, and the measure of one’s success is in how one lives, not in what doctrines one understands or agrees with or how frequently or long one sits in meditation. Most books on Buddhism echo a surprisingly small number of core tenets, and once you’ve heard them, there’s little point in further study. The real practice is in learning how to apply those beliefs to Real Life, and that’s where the real learning and growth happens. Buddhism isn’t about the books or the ideas, but about your mind, your heart, and your actions, and bringing them all into alignment.