Looking for a bit of guidance..regarding getting into professional systems programming (perhaps in Rust).
I increasingly find myself frustrated because I'd like to create tools for other developers instead of just customer facing products. I would like to learn about lower level considerations such as memory and performance in an environment where failure has more severe consequences. In other words, I'd like to be more of an engineer than a "programmer," and I'm particularly interested in tooling. I am a bit older with lots of other financial responsibilities so going back to school for CS is not an option for me.
I am currently working through some algorithm books. I'm trying to see the best way forward. Seems to the next thing would be to start contributing to an open-source project either in either Rust or C (not so interested in getting into C++)...even if it's something like writing tests or docs. I have also considered trying to learn about OSs by trying to contribute to Linux, but I wonder if that's reaching too high.
Any advice for this frustrated developer is appreciated. I realize Rust isn't the most used systems programming language, but I figure enough people here have both C/C++ Rust and systems programming experience to offer some insights.
Hopefully you'll get some practical advice from someone actually working in the field (I'm not), but just a few comments that come to mind:
Perhaps for others answering you could clarify what your frustration is -- is it your current area of work, or rather your attempts to get into (or learn) Rust / systems programming that frustrate? Different answers might ensue.
If you don't actively hate the work you're already in, you may not be in a hurry, so why not just follow your interests for a while? Finding a specific area/project/topic that really grabs you might be the most motivating thing to do. Rust seems to be used in so many really interesting areas you'd be spoilt for choice.
Finding germane open-source projects to contribute to strikes me as a fruitful course of action. Not only will you develop skills, there's a non-trivial chance it will lead to contacts that might help you find work using related tech. See, for example, this recent HN thread: Ask HN: Anyone joined a company after contributing to their OSS projects?
I don't hate my work. My frustration is that most web work (even backend work) is basically gluing things together. On top of that there seems to be a culture of getting it done as soon as possible without concern for maintainability, testability (often one and the same), or performance.
I wonder if in the systems programming, where the consequences are often more severe, if there's more of a focus on design and processes.
A tough question.
I have to ask: What is your concept of "systems programming"?
For most of my career I would have interpreted "systems programming" as working in assembler or some low level language like C on embedded systems where there was no operating system. Or perhaps working on some real-time operating system required to support the above.
But then I find writing an OS kernel like Linux is "systems programming". And then of course creating the essential user space programs to make that kernel useful is "systems programming"
Fast forward I find writing a web browser is "systems programming". After all it is essentially the operating system for many things. But then so is creating something like node.js.
Another view of "systems programming" is pretty much anything that requires the use of a compiled language. Rather than some interpreted language. Be it to achieve performance or fit in the available space.
In short "what is a system?".
In my old age I have come to the conclusion that everything we write is a system or part of a system. If it's important and you have pride in your work you will care about correctness and reliability. As such Rust is the best tool we have today to achieve that.
On the other hand, if it is not important, if correctness and reliability are not a concern, then why are you doing it? I don't want to be doing it.
Where I am going with my rambling is that you have expertise in web development. Front end, back end, so called "full stack" as you say. That is "systems programming" as far as I'm concerned. So rather than throw that expertise out the window and try and move over to some other kind of systems programming how about looking for ways you can use Rust to create correct and reliable code in that area?
That may not be possible in your current work environment but I feel sure there will be others who welcome the idea. I have read of quite a few cases where "web stuff" has been re-implemented in Rust already.
True "Systems programming" is pretty fuzzy now-a-days. I'd say that the core of my discontent is that web programming seems to have become more of a case of blindly pasting existing tools together without much algorithmic thinking, nor much thought about resources and maintenance. I'd say the majority of the code I've seen is really just thrown together without much review or thought. Of course it depends on the company, the team etc. And the fact that there are existing tools to do everything is not necessarily a bad thing, but it seems to encourage an intellectual laziness among many (but not all) "web programmers." This is, of course, a generalization, but nonetheless generalizations are sometimes partly true, that's why they are generalizations.
But perhaps I am wrong.
No not wrong. Perhaps a generalisation. I don't have much experience of web development outside of my little company but I have seen what you describe around and you are not the first to point it out. It's the reason I promised my self never to do anymore web development after working for a web start up back in 1999. Of course I found I could not avoid it many years later.
My take on it though is that even a humble web. page is part of a system. A complex, distributed system. As such it should be subject to as much rigour and attention to detail and performance as any other systems programming. Or what I call just "programming". Lack of performance is an issue. Erroneous behaviour is an issue. For whatever reason these issues seem to get down played in a lot of web world.
Well there's a fine balance...a start-up web company for example can't justify the up-front costs of design and systematic practices that, say, a producer of a pace maker can...unless perhaps the start-up is dealing in a business whose primary focus is performance, security, robustness etc (the vast minority).
The problem is that often times today's prototype, is tomorrow's production product. That's the rub. And once you've built yourself a sea of objects, and a rats nest, well that eats into reliability and velocity. I've seen it over and over again.
Anyway, I think the answer for me is to focus a bit on essentials that make a programmer stand apart from the crowd (beyond soft skills), which are a good grounding in algorithms/data structures. Then it's simply to move in to an area (web related or not) where, as I said, the business model doesn't allow for failure. In many cases, that may be what we call "systems programming," but it could be any area where correctness, security, robustness etc. is not an option.
Maybe getting into low-level programming on embedded systems (microcontrollers, etc.) could be interesting for you? I never used Rust for that, but I think it's a great language for such platforms. (I only did AVR 8-bit microcontroller programming in assembler and C for fun.)
Yes I've seriously considered that. I bought a discovery board and played around a bit with C on it, not much.
All that said, the most important parts of being professional and rigorous about being a programmer don't have much to do with the coding tools you use: it's about being able to plan and prioritize work, communicating with other team members (including documentation!) and establishing procedures for catching or preventing issues. Rust in an environment that doesn't care about any of that is likely to just take heat for "getting in the way".
On the other hand, depending on the context, they might be right! Shipping value very quickly, even if it's low quality, and getting feedback immediately is often far better than spending a long time getting everything right, then finding out you built the wrong thing. Nobody said this job was easy.
All agreed. I am talking about tendencies here, though to be fair I've never worked in anything but web programming, so maybe it's the same everywhere, or maybe just many of the programmers that I've come in contact with (though, of course, not all).
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.