5 ms·
Ask HN: How can I work on simpler things, closer to the machine?
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?
- icedchai 8y agoHave you considered embedded programming? Less bloat...
- davelnewton 8y agoDepends 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.
- davelnewton 8y agoSmall 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.
- craftsman 8y agoI'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!
- davelnewton 8y agoLanguages: 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.)
- joezydeco 8y agoI'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-FreeRTOS/dp/B077S1Q5TV https://www.amazon.com/NXP-LPC54018-based-Module-Amazon-Free...
- projectramo 8y agoThree 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.
- mabynogy 8y agoThe 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.