Clay Tech

"clay-works make things real"

translated from clazytech.com

Software Guys Or Hardware Guys, Who Really Has It Better

original Teams & Careers

By the way, I’m a hardware guy.

The hardware perspective, the software perspective

Among colleagues and friends, this sometimes turns into something like a debate — or really just an exchange of grumbling. On the surface it goes “Software guys really have it better, don’t they~” “No no, it’s hardware guys who have it better” That’s the exchange, but underneath it “Hardware guys are losing out. Just look at the job listings for mid-career hires these days. It’s all software.” or “Software guys are losing out. They have to keep endlessly learning new languages and algorithms that keep popping up one after another.” That kind of grumbling peeks through.

Both sides seem worth listening to, to me. (It’s not someone else’s problem for me either.) Let me try to sort this out a bit.

On defining “software guy” and “hardware guy”

By the way, “software guy” and “hardware guy” here mean “software engineer” and “hardware engineer,”

and interpreted plainly,

software guy = someone who makes programs hardware guy = someone who makes hardware (some kind of physical thing)

that’s the meaning, but that scope is far too broad, so to avoid giving unnecessary misunderstanding, let me define both terms.

That said, I can only speak with authority about the areas I have experience in, so:

Software guy

Hardware guy

I’m defining things this way for my own convenience. Obviously there are hardware guys and software guys in many other domains too, but for this discussion those people are sitting this one out.

Let me start by stating one fundamental difference between the two. It’s this:

Who made the rules?

That’s the question.

The rules of hardware

The work of a hardware guy is, at bottom, always built on the physical laws of the natural world.

The composition of matter, the properties of electricity, the properties of magnetism, weight, materials, mechanics, and so on.

The base stance is: how do you arrange the fruits of natural science research to make something useful? When you run into a question, you often go back to the fundamentals — physics — and new ideas are often pulled from theories established in the past, sometimes literally centuries ago.

No matter how hard you rack your brain, you can’t stop current from flowing from higher voltage to lower voltage, and no matter how much you argue, you can’t bend a thick steel plate without large machinery.

Nature decides all the rules.

The rules of software

By contrast, the work of a software guy basically requires skillfully using rules someone else decided. That’s because software itself is something humans created.

Of course, if you flip over the very foundation of software, you find mathematics underneath. But in C, for example, when you include a header file, there’s no logical reason why <> reads it from a library and "" reads it from the current directory, and while i = 0 still makes sense, what is i++ even supposed to mean? Questions like that never end.

It’s simply that someone decided it should be that way, so that’s how you use it.

In other words, as long as you keep being a software guy, you have to keep repeating the act of “someone decided it this way, so this is how it’s used” and “now it’s decided this new way, so it’s changed to this.” But more often than not, that’s “an act that makes things more convenient,” so you have no choice but to accept it. For example, a complicated feature that in an older language required writing about 1000 lines scattered across the code can now be achieved with just one line in a newer language. Roughly speaking, it’s that kind of thing.

Summarizing the above difference in abstract terms

This might get a little sentimental (lol).

Hardware guys work on top of unshakeable, absolute, singular logic.

Software guys can freely build the future according to their own ideas.

Hardware guys can’t escape the laws of nature.

Software guys are, in the end, beings forever pushed around by someone else.

So, what do you think?

On the philosophical side it’s about fifty-fifty — I suppose it could just be called a difference in taste.

Digging into the advantages and disadvantages

Next let’s dig into the murkier part. The question stated in the title: which side has it better?

Let’s look at it from a few earthy angles. Specifically:

Let’s go through these themes.

The perspective of skill acquisition

To put it bluntly, hardware guys mature slowly. Software guys mature quickly.

As stated above, hardware guys must build up from fundamental technology. Even a fairly narrow, specialized job — say, “designing the wiring on an electrical PCB” — wiring isn’t just something you can “connect and be done with.” Doing wiring so that a product doesn’t run into trouble requires a lot of knowledge: radio waves, discharge, capacitance between conductors, the relationship between trace width and impedance, and so on. Unless you train under someone with abundant knowledge and experience for three to five years, you probably can’t become a decent engineer.

But suppose a newcomer software guy is put in charge of some part of a feature — say, the UI portion of an app, or handling window display or screen transitions. If they’ve dabbled a bit in some object-oriented programming language like C++, they’ll probably be sufficiently useful within a month or two.

Where does this difference come from? The keyword is:

Modularization

That’s what I’d say.

In the domain of software, historically, the work of modularization has been pushed forward extremely aggressively. In proper software terminology, this is the “library.”

You could even say the history of modularization is the history of software itself.

Have you heard the term machine language?

As the name suggests, it’s the general term for the language that the machine (the device, the computer) itself uses to operate — something that spells out every single sequence, every single port and internal state change, one by one. Here, I want you to understand it not in the strict technical sense, but roughly at the level of hardware drivers. (It’s binarized rather than written in language form, but let’s not get bogged down in that detail.)

Now, all software ultimately gets reduced down to machine language to run.

For example

Suppose some Web application on a PC performs the action of “displaying a ◯ on the browser.” Of course it’s written in some Web language. Maybe Flash, maybe PHP. But that command gets interpreted by the OS, and an instruction is sent to the display IC. That display IC interprets the instruction, controls the display, produces the color, and the ”◯” appears. Partway through this process, it’s practically machine language.

And yet,

what percentage of Web app designers actually understand machine language? I’d say with confidence that the figure doesn’t exceed 1%. (There are some real software geeks out there. But clearly a minority.)

And here’s the point: if you asked “isn’t a Web app designer who doesn’t understand machine language actually excellent?” I’d want to answer with everything I’ve got: “No, no, that’s a completely separate matter.”

Now let’s go back to the earlier point.

Suppose there’s a PCB designer who barely understands EMC theory or the skin effect. I would think, “I don’t want this person designing anything.”

There’s clearly a huge gap here. It’s the benefit of modularization.

In the domain of software, all sorts of knowledge and know-how has been wrapped up and turned into libraries, and past sages have smilingly sent us off saying, “You all don’t need to worry about that anymore.”

Another way to say modularization is “abstraction.”

Turn it into an abstraction, and even if you don’t know the concrete details — well, fine!

Abstraction in hardware

Hardware once had a similar example, in the domain of the PC — the personal computer.

Have you ever built your own PC?

That’s actually not that difficult. You just buy the parts and assemble them. And the reason it’s so easy is because each function is properly “modularized.”

First you buy a motherboard. Then, since there’s a range of compatible CPUs and memory specs, you buy accordingly. Same with the hard drive and the power supply unit.

At this point, just doing that much and it basically already works. Because each function stands alone independently, you just buy the parts, plug them into the appropriate connectors, and it works.

If you want more, you buy a Blu-ray drive, or a sound card, or a USB expansion board, and again, you just plug it into the appropriate connector.

You need a bit of knowledge, but you don’t need any deep understanding of how the CPU actually works, what the connectors mean, how signals are exchanged with memory, or what this particular component on the motherboard is for. You can still get it running properly.

A splendid example of modularization.

That benefit supported the explosive evolution of computers and the internet in the ’90s.

In other words, modularization lowers the technical barrier at the individual level, which raises productivity as an industry. The software industry is exactly in that state.

So why hasn’t modularization progressed in the hardware industry?

Well, saying it that way is a bit misleading.

There is, in fact, a history of modularization in the hardware domain too.

Screws, springs, ICs, for example. Or the function boards that came up in the PC example earlier.

Each of these is a proper module built to realize some hardware function.

But hardware has two major problems.

One of them is optimization.

In hardware, optimization always matters. Hardware is clearly more severe about this than software.

For example, a common case: say you decide to just reuse a “proven” PCB from somewhere else as-is. In that case, you end up with a lot of waste in component and board size, cost, and other factors.

There are almost no exceptions to this.

What about software? The same kind of thing gets said about “code size,” “processing load,” “processing speed” — “we need to optimize.” But it doesn’t come with the same severity as hardware.

That’s because the foundation software runs on — hardware specs — keeps improving by leaps and bounds. The price of high-performance ICs keeps dropping too, and processing that once needed two or three DSPs can now be handled by a tiny DSP tucked as an extra inside an SoC. In other words, thanks to hardware’s support, software tends not to need to worry much about optimization.

Of course there are software guys placed in positions where code size matters a lot. But they’re clearly a minority.

So software can turn a blind eye to some waste and duplication, aggressively turn things into libraries, and just keep pouring its brainpower into the next idea.

Modularizing hardware is, in fact, not easy

The other problem is that in the world of hardware, “modules” mostly don’t work well if you just simply combine them.

For example, in mechanical design there’s something called “tolerance” — variation in error. With a design that doesn’t control that well, you end up with something embarrassing like “three of the four corner screws tighten fine, but the last one just won’t tighten no matter what.”

This isn’t a joke.

Similarly, for an IC to run properly, you need to pay attention to supply voltage, power consumption, access speed, and various other parameters. If you don’t keep to those properly, it may fail to work at all under certain conditions, or behave unexpectedly, becoming a source of problems.

You often hear people talk about “compatibility” issues with PC memory. What that really means is that it’s actually unclear whether both sides fully cover the characteristics required of each other, and that vague expression is used to paper over the fact that sometimes it just doesn’t work.

In other words, hardware has too many attached conditions.

And the process of learning how to interpret and work around those conditions is exactly what “skill acquisition” means for a hardware guy. That’s not something that comes together overnight.

So, as I stated at the outset, hardware has a high barrier for skill acquisition, while software, conversely, is easy for anyone to get into.

I think it’s fair to state this almost as a flat assertion.

Following on from this, let’s move to the next theme:

Supply and demand for engineers

Let’s talk about that.

Look around and pose this question.

Among people in society who call themselves “software guys,” how many actually came from a background in computer science? In reality, people with all kinds of careers — to the point where it’s almost chaotic — are flowing into software.

That’s clearly because of demand.

Given that society has found value in software services and customers are willing to spend money on them, that’s only natural.

While there are people who spend hundreds of thousands of yen on online games, fewer people find value in high-end audio equipment worth several hundred thousand yen. That, too, is a sign of the times, I suppose.

So there is demand for software guys. But the problem is that “supply is also plentiful.” That’s because, as stated above, the entry barrier into software is very low.

Because the initial hurdle is low

Not many people these days think of assembling a soldering iron kit and starting to build things themselves, but plenty of people think about giving iPhone app development a try. In fact, even a complete beginner can build a reasonably decent app within a month. That in itself is quite something.

But that’s also all it takes to get in. That’s all it takes for a rival who threatens your position to be born.

Tying back to the earlier question — “how many software people actually came from computer science?” — let me pose this question: “Are people from computer science backgrounds really the only excellent talents in software?” There may be differing opinions, but I want to say NO with everything I’ve got.

If anything, people who spent years in the wild, casually writing source code as a hobby, are probably a hundred times more useful than someone who graduated with excellent grades from an excellent computer science department at an excellent university, learned the theory, and then says, “Well, actually, I don’t write much code.”

Software is something you can challenge with just one computer, and as long as you have internet access, you don’t even need a textbook.

In the software industry, you constantly have to keep sharpening your skills, constantly keep studying — otherwise you never know “when” or “by whom” you’ll get stabbed in the back.

Now, the flip side — hardware.

About ten years ago, an old guy who was nearly 50 at the time told me, “If you master high frequency, you’ll be able to make a living forever.” The so-called “a skill that never goes stale” type of thing.

Certainly, right now is the heyday of smartphones. It’s said that Apple hired dozens of high-frequency engineers when building the iPhone lineup, and from experience, high-frequency knowledge is quite specialized and difficult to handle.

I think that’s actually pretty accurate.

By contrast, software is no longer “a skill that never goes stale.” It only looks that way now because demand currently exceeds supply — you can be sure that a gradual culling will begin.

In fact, here’s a real example.

Feature phones lost to the rise of smartphones. That, at this point, just can’t be helped.

We hear about companies that went under, or shrank their operations (i.e., restructured/laid off).

Engineers who belonged to those companies. Imagine, if you can, a veteran engineer — someone who spent 20 straight years on feature phones.

Now, at this point, between hardware guys and software guys, who survives? This is a genuinely cruel question. And the answer is obvious.

The hardware guy survives.

((Note)) I hesitate to say this because it’s almost too obvious, but of course this depends on the individual’s aptitude. So please understand that what I’m discussing here is a general tendency.

The difference between feature phones and smartphones is bigger than you’d think.

The design philosophy itself is different, and a large portion of the components used are different too. The assumed communication volume and the amount of internal information processing inside the phone are also different.

Crossing that huge gap and smoothly sliding into a smartphone development team is quite difficult.

But here is exactly where the earlier question — “who decided the rules?” — comes into play.

In the hardware domain, no matter how different the design philosophy, components, or materials are, the underlying logic — natural science — is the same. Absorbing new domain know-how and catching up with other engineers takes effort, but in practice it doesn’t take that long.

Software, on the other hand. The language changes, the platform changes, the OS changes — that means an absolute change of the rules. I’ve seen, more than once, seasoned software engineers get tossed around by exactly that kind of situation and end up “practically nullified” — someone who was confident in their skills, starting over from “Hello World.”

That said, most of the time various languages, platforms, and OSes maintain some compatibility with each other, or are somewhat similar, or partly pull from a shared common base. Still, that’s roughly the difference between “starting from zero” and “starting from one or two.”

During this kind of large-scale transition, there’s an overwhelming amount that a software guy has to newly learn.

And there’s an especially serious problem for software that surfaces whenever such a large-scale shift occurs.

It’s the fact that the young are stronger.

Feature-phone engineer survival simulation

Let’s imagine a hypothetical situation. A veteran senior engineer with 20 years of career on feature phones. A young person who joined the company, was assigned to that department, spent three years there, and is just about to graduate from being a junior engineer. Both get transferred to the smartphone division.

So how does it go?

On one side, someone in their mid-20s, still growing. Their phone is of course the latest smartphone, and in their free time they secretly build and sell smartphone apps. On the other side, someone in their late 40s whose eyes and shoulders get worse every year. Can the veteran survive? It’s honestly a very tough situation. Effort, individual aptitude, level of awareness — various factors come into play.

But again, it’s a very tough situation. (As someone with one foot already in “old guy” territory myself, I really do want people in that position to do their best…)

But this kind of thing is everyday business for software guys. Said coldly: those who can’t get over it just disappear.

Now, back to the keyword — software these days has very strong demand, but on the other hand, supply also has considerable fluid depth. New talent keeps popping up one after another. This wave of software service prosperity doesn’t seem likely to stop anytime soon, and demand may not just stay steady but keep increasing. But as already stated, the problem is that the composition of that demand keeps changing frequently. The absolute amount of demand is there, but you have to be prepared to be constantly placed in a tough position — that’s the resolve required of a software guy.

Hardware, on the other hand, has a problem on the supply side — young people turning away from hardware — but even more than that, it’s in a critical situation on the social-demand side.

Following this thread, let’s move to the final theme.

The paradigm of global industry

That’s the topic.

There was a time when Japan was called a manufacturing nation — and these days, having to add “was” to that sentence, it seems very likely that a considerable number of hardware guys in Japan will end up surplus going forward. The basis for that prediction is very simple: hardware-related companies and businesses of all sizes are uniformly trending toward contraction.

There’s various background to that, which I’d like to sort out on another occasion, but this trend isn’t something that can easily be stopped.

It’s not that simple.

Money is no longer flowing into hardware.

This might be because the advance of integrated devices like smartphones and laptops has reduced the absolute number of hardware items an individual owns, or it might simply be because the desire for material goods has declined among a younger generation raised in a prolonged recession.

That’s not my area of expertise, so I won’t go too deep into it. I’ll leave that to the economic commentators.

In any case, hardware guys are increasingly becoming unnecessary. That’s an undeniable fact.

As I briefly mentioned at the start, mid-career hiring for hardware guys, for example, has cooled off. Directly speaking, that’s because manufacturers’ wallets have gotten thinner.

And even when there are openings, well-paying ones are few. That could indirectly be said to reflect social status.

Young people would say hardware guys are outdated.

For them, the fact that the internet connects at 100Mbps, that their phone doesn’t lose signal even in the subway, that a laptop battery lasts five or six hours — all of that is now taken for granted, without a shred of doubt.

You could even call it mature, settled technology.

In the past, Japan built up a body of technology on its own to the point where it could proudly call itself a “technological superpower” without embarrassment. But nowadays many would say the center of manufacturing is China. A little before that, it was probably Taiwan.

Historically, the technology built up by Japan and the US was handed off to Taiwan and China for contract manufacturing, handed off to India for writing software, and by leaking out this way, the crown of “manufacturing” gradually slipped out of the hands of Japan and the US over the course of several decades.

This isn’t a matter of good or bad — it’s simply an undeniable fact at this point. There’s no flipping it back.

A bit of a tangent, but —

I once saw the inside of a smartphone from a certain Taiwanese manufacturer. There was a particular component stuck on indiscriminately everywhere, and I couldn’t help but laugh.

There’s a certain expensive component used on a PCB for a specific purpose, and whether it’s “necessary” or “unnecessary” is actually quite hard to judge — it takes both knowledge and experience. But because it’s an expensive part, engineers usually verify it pretty seriously before deciding whether to include it or not. That’s the kind of component it is.

But that particular manufacturer had genuinely slapped it on indiscriminately everywhere. When I happened to meet a sales rep from the company that makes that component and mentioned this, he said, “Oh, we’re grateful they’re using it in bulk. Well, we’re giving them a fair discount too.”

Right. They’re solving this problem not through technology, but through business deals.

For a latecomer manufacturer to beat those ahead of them, what matters is speed above all. They always take an offensive stance, commit to buying large quantities of components, push for discounts, put a lid on technical issues that smell bad, and prioritize “getting it done” and “meeting the deadline” above all else, winning trust and market support that way.

As a business strategy, this is entirely correct.

But it does reveal that their engineering level still has a long way to go.

That said,

it’s hard to argue against the criticism that this is just sour grapes from a loser.

Because we live in a capitalist society, not an academic conference or a technology contest.

Now, shifting perspective a bit,

among today’s shining “growing companies” (excluding China and Taiwan), how many are actually doing hardware?

Thinking about that gives me a bit of a chill. This, too, is an extremely clear trend in modern society.

But once, drinking with the president of a certain hardware startup in San Francisco, he told me this:

“People say Amazon is an IT company, but you can’t forget that what really supports the foundation of Amazon’s business model is the robots doing inventory management and picking and packing orders in the warehouses, and the control technology behind them.”

By the way, he’s a robotics engineer.

Software can’t run without hardware.

This, too, is a fact.

Countless software services are built entirely on top of a hardware foundation, and the need that supports that clearly exists.

But its absolute numbers, left alone, will keep shrinking as time passes.

Because our powerful, hungry, business-savvy neighbors are rubbing their hands together, waiting.

Summary and outlook

The many hardware guys currently in Japan —

there will surely come a moment, not so far off, when they’ll need to reflect on themselves, and find the answer to how to make use of that “universal technology” with an eye toward the future.

Doing what can be done, in whatever modest range is possible, is one answer. Even in a shrinking industry, some amount of product still sells, and making the effort to keep that going as long as possible is a respectable stance too.

At the individual level, that’s fine. But that alone won’t be enough for many people to make a living.

New industries — and, further, the discovery and creation of new needs — are what’s required.

The needs of the world: the right answers are surely buried all over the ground somewhere. But finding them by dowsing, without digging, is quite difficult. And the stamina to pay the drilling costs needed to dig indiscriminately everywhere — before anyone noticed, every manufacturer had lost it.

Software, in that regard, has cheap, cheap drilling costs. It’s only natural that it looks enviable.

In this extremely tough situation,

will a savior actually appear?

If none appears, who’s going to make the hardware, I wonder. It’s bound to become a rather boring world.

This is where we need to hold the line.

Now,

as for the software guys who will surely keep increasing from here on,

the world will welcome them warmly. But only at first. There are many rivals. It’s a world where you have to keep programming basically every waking hour of the day, and even then it’s a question of whether you can manage to stand out even a little.

Let your guard down for a moment and, before you know it, you’re lumped together with everyone else and tossed aside.

But for those who face this with resolve and effort, the future will surely be bright. The protagonists of the era, so to speak.

That much is certain.

Closing

If you’ve read this far hoping for some slanted conclusion, I’m sorry, but this issue isn’t that simple.

Still, I’d like to think I’ve scattered a few “keys” along the way.

How you ride out a paradigm shift depends, first of all, on how accurately you assess “the situation.”

How do you see this situation? Which way is the era heading? What sacrifices and what losses come with it?

People have seen all sorts of things.

Including important things, lost, dropped by the passage of time.

“Riding the wave” isn’t automatically the right answer — “riding it well” is what matters.

The meaning and value of that is never something you can pin down easily, at any time.

Originally published in Japanese at https://clazytech.com/2013/01/75/. Translated with LLM assistance and reviewed before publication.