... And then there's embedded programming, which flips this whole thing on its head, and a programmer's skill seems to be measured in how much smaller (more efficient) you can make your code while also keeping and improving clarity, security, maintainability, etc.
Good embedded programmers are good programmers, period. They have to be. Today, we're seeing that even embedded programmers are getting lazy, because 32-bit ARM core parts and plentiful RAM allow wasteful and error-prone approaches to programming.
Well, "good embedded programmers" are a subset of "good programmers" so yes. The point I'm making is that as embedded programmers get more experienced, we are able to do more with less. And so the hallmark of a good embedded programmer is not only writing less code that is more efficient than sub-good embedded programmers, but then doing so without sacrificing any of the code clarity and maintainability and secure patterns that all good programmers strive for regardless of what kind of programmer they are. It's the same concept the article talks about, just flipped on its head because of the environment.
Also incidentally, in my experience, good embedded programmers are less prone to "get lazy" on devices with sprawling amounts of resources than less experienced embedded programmers. Hungry dogs run faster, yes, but for example just because we've been given a generous 32KB of program space doesn't mean we're going to use it all up in a fit of laziness or start cramming in the features.
That is exactly why I got into embedded programming, and then back out again: it seemed like one of the few areas of software development which still offered a real challenge, but it quickly became obvious that Moore's Law was catching up, and that I had arrived near the end of the party.
Phone software as in, like, smartphone software? The phone in my pocket is literally more powerful than the PS4 I bought last year. 8GB of RAM, 128GB of flash storage, 8-core 2.45GHz 64-bit ARM processor.
Meanwhile, a couple of weeks ago, I had to add a new feature to firmware that was already using just under 900 of the total available 1024 bytes of program space.
Agreed. Assuming you're talking about phone apps (as opposed to baseband or sensor control etc); software for phones has much more in common with desktop software than it does with the embedded world, you just have to be a little bit more conscious about your power and data usage.
In my embedded work I pushed a few years back to upgrade the microcontrollers we used from 2kB to 16kB RAM and 16kB to 128kB flash devices (at a grand total extra cost of $2) so I could stop worrying about how we would fit all the new features in.
My personal line for "embedded" at the point where you take responsibility for the OS functionality too. IMHO that's currently somewhere around Raspberry Pi etc devices, which on one level have computing power in line with the smartphone world, but on the other you're still mucking around with the OS yourself. I know it's pure snobbery on my behalf, but I still cringe to think about Node.js running on them... (even though I'm doing it myself for hobbyist level stuff).
Ah! You know, that makes me feel a little better, knowing I'm not the only one sort of balking at the idea of Node.js running on those little dev boards... Even though I've also done it in the past haha! Very funny. :)
Yeah, historically I have tended to agree with the parent's posts on HN, but here I couldn't disagree more. Our phones are definitely closer to small workstations than embedded devices. Not only because of the available resources, but because of things like application portability. I can take an apk for my phone and run it on every other Android device on the market running a compatible API. The fact that it runs Android in the first place makes it too general purpose to be an embedded device. Now, if the parent had said our old-style brick phones were embedded devices, I would agree with him there. But not smartphones.
