[Translation Layer] Volume 1, Issue #1
The Task of This Translator
WELCOME to Translation Layer.
Please accept my sincere thanks on becoming a founding subscriber. I'm grateful for your confidence.
This newsletter is an experiment intended to accomplish a few simple things: staying in closer contact with folks whose opinions I value while assisting people in need. By virtue of a private network, Translation Layer endeavors to provide good advice and access to opportunities, investors, and connections.
In passing, I hope to offer a few thoughts of potential value, but as always, your mileage may vary.
These thoughts are offered as a form of translation. And that's a curious thing. An old Italian proverb suggests: “tradditore, traduttore.” The translator is a traitor. Or as Umberto Eco puts it, “Translation is the art of failure.”
I hope your experience here is more than that. My inspiration is the philosopher Walter Benjamin, by way of Friend of Translation Layer (FoTL) Todd Hasak-Lowy, whose short story collection evokes the spirit of what I'm trying to accomplish:
“It is the task of the translator to release in his own language that pure language that is under the spell of another, to liberate the language imprisoned in a work in his re-creation of that work.”
More succinctly: my goal, as is that of all translators, is to make it possible for people in different cultures or epistemic communities) to communicate with one another by increasing their mutual understanding.
One of the fringe benefits—or side effects—of my professional arc in Technology has been the privilege and burden of translation. Explaining the logic of automation, the mental models inherent in software, the intersection of finance and technology, helping people respond to technological change—these things comprise, for better or worse, the body of my work.
Seasoned with the wisdom of friends and colleagues spanning several different disciplines and domains, I hope to take the language of my 'source' material—technology, startups, growth-stage private equity, software, product development, user experience, design, marketing, media, writing and music—and make it a bit more comprehensible, whatever your native tongue may be.
Inbound Help Requests
Let's start with a little helping people.
Over the last few weeks, I've received multiple requests for two types of service providers.
-
Software Product Development. These requests have come from (non-technical) founders, advisors, and product folks looking for an organization (not freelancers) to augment, supplement or just straight-up play the role of a product development team. Some of these requests have expected 'product' and 'UX' skills as part of the solution, while others were just looking for teams of product-focused software engineers.
-
Web Site Design. I still get a kick out of the fact that there's a market for these services that sits between DIY off-the-shelf solutions + talented freelancer and the sorts of high-end digital marketing provided by agencies. It's downright heartening, in fact. These requests, coming from small and medium-sized organizations expect a combination of branding, visual and UX design, content development, and a lightweight technical execution.
If you have recommendations for either of these types of service providers, drop me a line and I'll connect you to the requesters
Outbound Help Requests
Job Seekers
Several (founding) subscribers to Translation Layer have reached out to offer their services to employers. These folks have included:
- Mid-Level Engineering Managers
- Digital Advertising Specialists
- Product Managers
These folks are more comfortable in start-ups and scaling organizations but also open to certain types of larger companies. Reach out; I'd be happy to make a connection.
Technology Due Diligence
I'm also in contact with a number of senior, highly-experienced folks providing technology due diligence services for angel, venture capital, and private equity investors.
Over the last few years, I've seen an increasing demand for these services outside of the traditional high-end consulting shops. Certainly, some of this is pricing, but I think it reflects a desire for a more pragmatic approach investors are taking to really understand what's happening under the hood. Less box-checking, more action.
Having been on both sides of the table many times, I like the idea of a leaner, practitioner-led (vs. consultant-led) way of doing technical diligence. It's less stressful, more likely to be transparent, and seems to produce more efficient outcomes. (Yes, I'm a due diligence nerd.)
If you are an investor looking for technical due diligence services, please reach out. And if you're a founder or technical person in need of some advice on how to prepare, I can help you there too.
Featured Translation: Software Dependencies
Most of my work involves significant amounts of typing and I’m an unrepentant nerd with virtuous laziness. So I use a piece of software called TextExpander to automate the production of text snippets: things like dates, long words or phrases, and templates for note-taking. This is a category of software I’ve kept an eye on for some time.
I used to use the more intimidating and powerful Keyboard Maestro, which is too much for me, most of the time. Recently, I found Espanso, an open source text expander, written in the Rust programming language. As a supporter and strategic beneficiary of Free and Open Source software, it was immediately attractive.
Checking out Espanso made me dig into—for the second time in the last six months—the Rust ecosystem. In this context, an ecosystem means the intersection of people, built software, open source projects, and approaches that make it possible to build working software in a given programming language. Rust began in 2006 as a personal project and blossomed with the sponsorship of the Mozilla Foundation in 2009.
Here is a technical explanation of why Rust has become so popular of late, but the rough translation is that it’s perceived to be more secure, more performant, and has a much easier ecosystem for managing dependencies between a given project and other software projects it employs.
Let’s unpack those for the non-technical. When we talk about a programming language being ’secure,’ we mean that its basic building blocks, the way it processes instructions to produce an outcome, are less susceptible to being used in ways that allow unwanted intrusion into the resulting software. And when we talk about being ‘performant,’ we mean the extent to which the program is not wasteful in using the resources (chiefly; memory and storage) of the computer on which it runs.
But it’s the last point about managing dependencies which is fascinating, in an old software nerd way, and bears further translation.
The first language I used for commercial purposes, working what's called a side hustle today while still in college, was dBase III. But I like to joke that the first computer language I used ‘in anger’ was Perl. Perl, as a programming language, was unique and pivotal in many ways but the most important, in my humble opinion, was the creation of CPAN, the Comprehensive Perl Archive Network.
CPAN allowed Perl developers to make use of a broad collection of 'software packages.' Think of these as pre-configured bits of code that perform a very specific and (hopefully) well-defined purpose. For example, there are packages for performing date calculations, or building a graph from a data set, or converting files from one format to another.
Like many critical advances in computing, packages were based on ideas about data abstraction created by an insufficiently recognized technology leader—who unsurprisingly happens to be an insufficiently recognized woman in technology—named Barbara Liskov. She came up with the idea of code modules upon which packages are based. (True; she did receive a Turing Award, but how many code bros are aware of Barabara's contributions? I digress.)
So software packages existed long before CPAN, but what made the Perl + CPAN setup unique was the sheer number and variety of package contributions it enjoyed, and the relative ease by which programmers could plug these packages into their software. The 'physical' distribution of software packages, which was a fairly arcane craft, was much more easily handled within the code. It became possible to snap together packages like Lego™ blocks for making surprisingly complex forms.
Successive popular programming languages did not fail to notice the benefits of CPAN in this regard. Perl's 'successor' language, PHP, built essentially the same thing in PEAR. The next generation of popular languages, Ruby and Python, took packages a step further with gems/bundler and pip/PyPi. In addition to the large repository of software Lego™ blocks, they took a page out of the operating systems world and connected the package repository to a package manager. Think of a package manager like a piece of software that automatically makes sure your Legos™ fit together, even when new blocks or new versions of existing blocks come out. And if you need some other Legos™ to make yours work, it'll grab the right versions of them, too.
It's not possible to overstate the extent to which this is a complex and time-consuming problem, largely because unlike real Legos™, software packages are constantly changing. Software packages may be running on different types of computers with different versions of different operating systems and other different packages installed, which themselves expect other software packages to be installed—sometimes with specific versions or combinations of versions required to function. Not only do they not always work together, but figuring out why they do not work together, or worse, why they work together in unexpected ways is a fractal problem. And that problem is: dependency.
There's a price technical people pay for the ease of all of the Lego™ block-snapping we perform to power the software underpinning our lives. It's that we are—all of us and all of the software we write—utterly dependent upon one another. I hope the irony of a bunch of mostly introverted people building a massive system of interpersonal dependency as the basis for our current civilization is not lost on anyone. The size of this irony is only dwarfed by the amazing fact that all of these dependencies are—for the most part—managed through automation without obvious catastrophe for most users of the software, most of the time. We take this for granted and get frustrated when something takes too long to load.
Which brings us back to the Rust programming language. Rust is in the process, perhaps, of supplanting in technical esteem the pre-eminent programming language of the moment (for the moment): Javascript. One of the main reasons for this is that Javascript's package management ecosystem is, to put it mildly, difficult to navigate. After a long hiatus from being directly involved in writing production code, I helped architect and build a set of medium-complex Javascript applications this year. I can tell you from painful, personal experience that the Lego™ Dependency Tax in the Land of Javascript is very, very high. More importantly, there is certain anarchic unpredictably in the dependencies, as demonstrated by an infamous incident in which the deletion of a single package 'broke' the Internet back in 2016. Rust's package management system, cargoand crates.io appear to have devised a better solution to dependency management. Here's a technical but non-esoteric explanation, if you're interested in further detail.
Those who've worked with me before know I'm a True Believer in the Theory of Constraints. My particular implementation, a game called "Find the Constraint," argues that the greatest leverage in improving a human/technology system comes from the ruthless identification of the single largest constraint in the system and running constant experiments targeted at its elimination. If the constraint on software development in the dawn of the Internet Age was the widespread availability of reusable software components, the solution to that constraint developed over the ensuing twenty years—package repositories and managers—swallowed its own tail and created the next constraint.
The meta-translation here is that the choices we make as individuals in a system with dependencies—both in software and the wider world—affect the collective outcomes whether we see them or not. Choices have ramifications, whether we try to manage them, externalize them, or choose to ignore them. And software dependencies in critical systems, like any other dependency, are dangerous when either overly centralized overly distributed. You get hydraulic despotism in the case of the former. And in the case of the latter, you get, as William S. Burroughs put it, "inept, frightened pilots at the controls of a vast machine they cannot understand, calling in experts to tell them which buttons to push."
Something to consider.
Translation ends.
Two Tools
I'm a big believer in having the right tool for the job. For each issue, I'll include two; one for work (broadly defined) and one for play.
Getting Names Right - Work
There are few things more important, especially when meeting people for the first time, than the correct pronunciation of their name. With its near-universality, native English speakers sometimes forget this, but when I lived in Tokyo many years ago, it was indelibly marked upon me even though Japanese folks were excruciatingly polite in attempting correct pronunciations I always make sure to get names right; it's a simple gesture of respect. It's easy to search YouTube. I've started using Montréal-based Nameshouts for this essential tool.
Finding Book Inspiration - Play
I'm a big re-reader. Opinions differ on this subject in a dramatic fashion, but I'll spare you the argument. Given the fact I haven't changed my illustrious partner's opinion in twenty years of marriage, it's doubtful I'll convince you. That said, I associate books with particular places. Whenever I revisit a book—or the place I read it—a mental calculation is performed; the output is the delta between my mind-state on previous reads/visits and the current one. That's why I've enjoyed the Book Trail so much. It allows you to search for books based on their geographical (e.g. Chicago) or experiential (e.g. an old house setting.
Parting Gifts
I'll close each edition of this newsletter with a spot of art. This inaugural edition features music and words, and I hope you'll forgive me for beating the dead thematic horse a bit.
This last month I've been listening to a lot of music from the 1970s Japanese band, Happy End (はっぴいえんど). They were true translators, acknowledged as the first Japanese rock band to sing in Japanese. You might be familiar with them from their song "Kaze wo Atsumete" (風をあつめて, "Gather the Wind") which closed the movie Lost in Translation. As the weather has shifted from summer to fall, a particular song of theirs seems to hit the spot. Enjoy it here: Natsu Nandesu (夏なんです, "'Tis the Summer")
Finally, I leave you with these words:
“[...] whatever has been lost in translation in the long journey of my thoughts through the maze of civilization to your mind, I think you do understand me, and you think you do understand me. Our minds managed to touch, if but briefly and imperfectly. Does that thought not make the universe seem just a bit kinder, a bit brighter, a bit warmer and more human? We live for such miracles.”
― Ken Liu, The Paper Menagerie and Other Stories
Administrivia
If you found Translation Layer useful, please feel free to forward to others. If you did not, please drop me a line and let me know how it could be improved. I'd like to hear from you either way.
Until next time.
Yours in translation,
j.
