Engineers Need Not Always Chase The Latest Trendy Technology

I once wrote a blog post on the topic “Which is more advantageous, software or hardware?” I’ll skip the details of the argument, but here’s the conclusion: there are large differences in the nature of the technical systems that software engineers and hardware engineers work with, and these differences inevitably change what society expects from each of them. But neither field is inherently superior to the other, so you should just choose whichever you like. That difference in characteristics, concretely, comes down to what the engineering is based on.

Hardware-related engineering is based on natural science. Physics, electromagnetics, materials science — humans didn’t invent any of these. Hardware engineering means doing what humans can do without ever departing from the laws of nature, staying aligned with them. Plenty of people would say that software, too, is “fundamentally based on mathematics.” But most software engineers have no need to be conscious of this. Their main job is instead to work “on top of efficient, rational rules that someone else has already built.”

So while the latest technology matters for hardware engineers, most of what they do is impossible without knowledge and experience of the older technologies that form the foundation. Software engineers are different. Plenty of them develop applications in Java — which is built on top of C — without ever having written a line of C. Push it further down, and languages ultimately run on hardware as assembler (machine code), and engineers capable of touching that layer are probably about as rare now as COBOL engineers.

In the software domain, the ranking of what’s valuable versus not flips extremely rapidly. Before Google I/O in 2012, when AI was shown automatically recognizing cats, few people paid much attention to the value of machine learning engineers. Now they’re the poster child of high earners. When I was a university student, HTML was typed by hand. Perl was popular, and I remember building all kinds of things myself. Twenty years later, nobody does that anymore, and nobody even talks about it.

In the hardware domain, on the other hand, market value tends to accrue to people with deep know-how. Take “unwanted radiation,” for example. This refers to harmful radio waves emitted from electronic devices, and every country regulates it. The theoretical framework for reducing unwanted radiation has existed for a long time, and simulation technology keeps advancing day by day. And yet, problems still occur. The reasons vary case by case, but most trace back to the limits of what could be anticipated — things like “it’s fine on its own but doesn’t work when combined with something else” or “we can’t tell whether that extra part we added is causing the trouble.” Something similar happens in software too. But whereas a setback in software development might mean a week of stalled progress, or two or three all-nighters to fix something, in hardware the damage tends to be far larger — remaking a mold can delay the schedule by months and cost millions of yen. It’s usually veterans and others with deep experience and know-how who are sensitive to this “smell of trouble.” 3D printers have arrived and eaten into part of the market, but they haven’t destroyed it. The way electronic PCBs are made has stayed the same for several decades now. This kind of fundamental difference in the speed at which time flows also exists between the two fields.

So, as for the question in the title, let’s treat it as basically a question about software. My advice to hardware engineers would be: specialize as deeply as you can in your own area of expertise, rather than chasing trendy technology.

Let me share two episodes here.

The first happened about five years ago. A subordinate of mine at the time, an engineer in his mid-twenties whom I’ll call K, once startled me by saying, “PHP is the technology of the era now.” This came up during a discussion about what language to use for building the server side. Everyone else laughed it off, but I found myself curious about the reasoning behind his conclusion (in the end, we went with Scala). He declared, “The ideal in programming is code that completes in one line.” In other words, his argument was that what matters is deeply understanding the many frameworks that exist and using them as effectively as possible depending on the purpose. I felt there was certainly something to that. His reason for PHP specifically was that many PHP frameworks are used in China, and their commit counts are overwhelmingly higher than those of other languages, by an order of magnitude — meaning these frameworks have already been battered by huge numbers of people and are “more than sufficiently battle-tested.” Anyone who has run servers knows that among maintenance tasks, “responding to updates for languages, libraries, and SDKs” is one of the heaviest, and it’s the kind of thing that tends to get pushed off until it turns into a serious incident. So the standard approach is to choose tools that are as battle-tested as possible. From that point of view, PHP has come full circle and is now extremely useful.

PHP here is just one example, but the point is this: the purpose of development is to build something, and if the latest technology isn’t specifically required for that purpose, choosing something stable that sufficiently meets the need is entirely rational.

The other episode is from about two years ago. I want to share something I genuinely felt while working alongside several AI engineers at the time. They were remarkably diligent about studying. AI is still, in many fields, an early-stage domain. Because of that, a lot of the valuable insight comes out of university research and gets published as papers. So they read an enormous number of papers. Needless to say, almost all of it is in English. I don’t think people who merely use AI-related tools provided by Google or Amazon can be called “AI engineers.” As I mentioned, an early-stage industry like this needs “people who think up new algorithms and take on challenges” far more than “people who just ride along on top of existing tools.” Twenty years ago, wasn’t there some kind of specialist-sounding title for people who were skilled at building Excel macros? That work gradually got simplified and commoditized, until eventually anyone could do it. The only people who get to keep being called “engineers” are those who kept pursuing their own specialty with real depth — whether that’s the mechanics of spreadsheets, new methods of chart rendering, or UI/UX.

You should not “chase trendy technology.” But if there’s something you’re genuinely deeply interested in, I’d encourage you to evaluate your own feelings quite strictly — ask yourself things like, “Do I think about this constantly, whether asleep or awake?” and “Am I prepared to devote my career to pursuing this?”

The content of this post is an excerpt (original text) from the following book. If you’re interested, please pick up a copy.

The Shape of a Happy IoT Startup

The Shape of a Happy IoT Startup

Originally published in Japanese at https://clazytech.com/2022/08/1088/. Translated with LLM assistance and reviewed before publication.