Ask HN: How can I work on simpler things, closer to the machine? | Hacker News Reader

Ask HN: How can I work on simpler things, closer to the machine?

8 pointscraftsman12 comments

Recently I've felt overwhelmed by the sheer complexity of the software stack most of us use.

I've been programming professionally for almost 30 years. I started out as a kid on a Heathkit 8-bit computer and now work for a research organization doing Python, JavaScript (w/ TypeScript), and I build single-page web apps using React as well as backend data processing apps in Python using NumPy, Pandas, etc. I've always kept up because I've always been curious about how things work and I enjoy what I do.

But I have an ever-growing feeling that 'the whole thing' is just too complex and has too many security holes. Yesterday I found that the Slack app on my Linux machine was using 670MB of memory. And Chrome with two tabs open, one on Office 365 and the other on JIRA, was taking 850MB. Keeping an eye on CVEs and other security and privacy related issues is enough to make me realize how fragile the whole thing is.

I know there is amazing engineering in most of the tools we use, I don't want to diminish that. But maybe we've "dug too deep, too fast?" I miss the days of being able to read K&R from cover-to-cover and being able to understand what my programs are doing.

So my question: what career paths exist for someone who wants to "get back to their roots?" I.e., what might I do to work in an area of software that is simpler, closer to the machine, and one which isn't built on so many layers of abstraction? Or is this mere nostalgia?

Small embedded systems.

I have to admit I'm not quite sure why you don't already know that, considering our history is similar, which makes me suspect the question was just poorly-expressed.

Any software you write on any system that's already running a mainstream OS will have multiple layers of abstraction by default. Add anything web-related to that, particularly on the client, and you have another dense layer of abstractions, because browsers are just VMs.

The only way to escape that is to work on small (here, by small, I mean bare-metal or small RTOS systems) in a non-VM language. (I add the last because many small systems are now running JS or Python, e.g., NodeMCU/CircuitPython/etc. and as soon as you get in to that, while you're still quite close to the machine, there's a fairly opaque layer unless you decide to dive in.)

It is the nature of systems to increase in complexity. In many ways this makes our lives easier, at the expense of being able to understand each layer individually. It's only when we cross layer boundaries, by design or by accident, that we need to understand more deeply.

I'll admit to it being poorly worded. :)

So yes, I know that small, embedded systems exist, so let me be more concrete in my questions, some of which you started to answer:

* What languages are used on these systems?

* What RTOSs would be interesting to learn?

* What processors are typically used?

* What hardware should I get to start learning?

* What organizations and companies do a lot of small embedded systems?

I think I know the answer to _some_ of these, but I'm interested to hear what you think. And thanks for the answer!

Languages: Pretty much anything, but still mostly C/C++, moving towards JS/Python for some. Once you're in JS/Python territory it's tough to call them "small" since you're looking at 0.5-1M RAM, 4M flash, etc. but relatively speaking, small.

* FreeRTOS is a good place to start, but there are many, both OS and commercial. Most are similar in scope and application. Larger systems may also use Linux or Android, but that's further away from what you're looking for.

* Atmel, Arm, PIC, ESP8266/ESP32 are probably the strongest current players. Procs like the Cortex M series are popular on the Arm side, Atmels are what the non-Arm-based Arduinos run, and the ESPs exploded on to the scene as a dirt-cheap way to get WiFi.

* shrug Arduinos, ESPs, and RPis. There are a million other boards like the Tiny series. Adafruit has the Feather series which I like quite a bit, and the Circuit Express which is an interesting proposition, but has a Python layer, which you may or may not want. Note that almost all of these boards can be developed for in different ways: the Arduino "IDE", command-line Arduino or bare-metal, JavaScript, etc.

* That you'd just have to search for--the embedded landscape is huge because almost everything has a processor in it now at some level. If it's a company that makes a physical product that does anything other than sit there, there's a processor in it. (More or less.)

I'd totally recommend FreeRTOS. It's a solid operating system for small systems, the ecosystem is growing again (Amazon is putting their weight behind it and there are older experienced shops out there like Future Designs), and there are a lot of EVKs out there that will run it out of the box.

Get one of the $35 NXP LPC5 boards. It's pretty nice.

https://www.amazon.com/NXP-LPC54018-based-Module-Amazon-Free...

If you are looking for processors that are intellectually challenging, consider looking at Analog Devices DSPs (blackfin) and Texas Instruments (MPS430).

They use mostly C/C++/asm.

Just curious what makes them any more "intellectually challenging" than any other processor/processor family. I can see that flipping to a DSP might be a little different, maybe, but the MPS series is just another MCU. Thoughts?

I meant because of the DSP functionality. Also in my (limited) experience, black fins are often used with lots of external devices, threading, processing, memory, etc so there are lots of challenges to consider. Whereas small MCUs are often just doing a few simple tasks with limited externals. There are certainly other “intellectually challenging” mcus just that these seem to be industry leaders.

I started experimenting with "hardware stuff" late last year, when I had a month of paternity leave. I bought an arduio starter-kit, and the quickly moved on to using ESP8266-based devices.

Both are programmed in "C++", and both are very easy to work with if you're already a programmer. Because the arduino, in particular, is aimed at beginners, you can get started by a process of almost lego-like construction. Plug some wirdes into the board, and attach the other end to a temperature-sensor.

As for jobs I'm not sure, but I have posted a bunch of projects online which lead to random emails from people - one of those ended up leading to me getting paid to write some IoT code for an existing project.

If you can work in the constraints of such a small device then other embedded stuff should be almost trivial. (most of the "embedded" stuff I've touched runs a complete operating system, rather than just a single program. So they're often still big. RTOS, etc, is "just" a matter of working with the OS API, and being aware of limits.)

The first step IMO is to refuse to use the tools that alienate you (typescript, react...). Develop a rationale around that. I can help if you want on that as I did that work.

Have you considered embedded programming? Less bloat...

Depends entirely on the domain, hardware, and environment. The typical "embedded systems" of today are orders of magnitude more complex than stuff I worked on twenty and thirty years ago. In order to get back to those days you need to focus on very, very small systems, and even then, you need to define terms carefully, e.g., Apple Watches are embedded systems, but they're non-trivial.

Three years into a job, I often feel I would love to move somewhere. Thailand, Sweden, India, South Africa etc.

I have actually moved quite a few times and found the new place to be very similar except I don't have my friends anymore, have to learn my way around, figure out the banking system, and figure out the new job.

Are you sure that the problem is the complexity of the domain? Are you sure its not the co-workers, or impossible feature requests, or short timelines?

I mean it may feel complex if you're asked to understand 1000s of lines of codes and debug them or something.

Having said that, I will add that every few years a new small platform comes out that needs new hardware. It is "simpler" in the sense you describe but much tougher because there is no tooling, and no guides, and you have to work much harder to figure things out.

tl;dr: mere nostalgia.

Reply on news.ycombinator.com