Brendan Gregg's website has a lot of useful content on system performance analysis
Ask HN: What should a systems/low-level software engineer know?
61–70 of 231 posts
Re: Ask HN: What should a systems/low-level software engineer know?
#62If by low level you mean embedded systems programming, you will definetly need to be proficient in C. The other knowledge depends on the product that you will make. For example I work in the automotive industry, where you need to be interested in cars and how the different parts work. Knowledge of electrical engineering and control theory is also valuable. There is a good book about it if you wat to learn how cars wo…
What if -and I'm sorry to hijack- by low-level OP means a position as a C/C++ developer (asking for ~a friend~ me)? I've always been insanely attracted to the C variants and messed around with them to minor extents, but what might someone _need_ to know to be competitive if they're trying to make a move to that area of SE?
Re: Ask HN: What should a systems/low-level software engineer know?
#63System isn't necessarily low-level. System code is and can be quite high level, the distinction to just calling it "application" or "application level code" is that it caters mostly to system (no direct user interface) or applications (such as system libraries) instead of end users. Then you can have "low level" as in close to the metal, for example drivers that talk to a hardware. That being said even these are (and…
> System isn't necessarily low-level. System code is and can be quite high level, the distinction to just calling it "application" or "application level code" is that it caters mostly to system (no direct user interface) or applications (such as system libraries) instead of end users.
That's exactly my point as well. Well said - ha at least better than I would be able to explain myself.
Re: Ask HN: What should a systems/low-level software engineer know?
#64Signal Analysis, Electrical Engineering, Failure Mode Analysis.
The things you talk to will fail, you should be prepared to deal with those failures.
Re: Ask HN: What should a systems/low-level software engineer know?
#65Signal Analysis, Electrical Engineering, Failure Mode Analysis. The things you talk to will fail, you should be prepared to deal with those failures.
After doing embedded work, YES! THIS!
Electrical Engineering is basically being able to read drawings and choose components for your application.
Signals I found fun, but I can imagine doing a digital application and this being difficult.
FMEA comes with the job IMO, but a good tool to have.
Re: Ask HN: What should a systems/low-level software engineer know?
#66Assuming that you want to move into embedded. Focus on C and follow up with an understanding of the underlying assembler code. Haven't played with Rust for about 1 year, so I don't how how mature it is these days. Also have an idea of how to debug the code. Debugging on embedded is very different to debugging a web/js app.
Linux Device Drivers 3rd Edition is a bit dated but is still a wonderful introduction to systems programming in C. It's for Linux, but it presents information that is useful when working with any system. Low-level systems programming is hard and can be a bit boring at times. I agree that debugging is very different from debugging on higher level systems. Most of the time an oscilloscope or an LED is the best debuggin…
> Linux Device Drivers 3rd Edition is a bit dated but is still a wonderful introduction to systems programming in C. It's for Linux, but it presents information that is useful when working with any system.
[edit] I have the LDD and https://www.amazon.com/Linux-Kernel-Development-Robert-Love book. I got confused about the authors name :)
The author Robert Love has done a tremendous job on Linux Kernel Development book. Every aspiring "In-betweeners and Low-Low Level engineers" [0] should read this book. It's awwwwespiring.
And please read LDD too!
Re: Ask HN: What should a systems/low-level software engineer know?
#67Low-level software often moves quite slowly and backwards compatibility is important. Embedded systems have to be maintained for decades. So knowing how do handle legacy code, proper dependency management, release management, and requirement management is quite important. Similarly the cost of bugs is usually quite high, because updates are hard. So writing testable code, testing and other QA activities are more impo…
All of that stuff is changing though. I would never ship a product today without remote signed upgrade ability. All devices that plugs into a windows PC can use Windows Update for example to upgrade firmware. Any device that sits at a remote location probably ought to have a GSM modem in (adding only $1 to the cost of the device) for tracking uptime and firmware updates. Any device which offers an API to other device…
Where can I get a GSM modem and support components for $1 in BOM costs, let alone $1 for finished product cost (inc intentional radiator cert and distribution/channel markup)?
What about the $1-2/mo network charge? Or battery life considerations? I've got sensors that run for 2-3 years on a CR123a battery. That power profile isn't going to support a GSM connection.
Re: Ask HN: What should a systems/low-level software engineer know?
#68Earlier quoted context omitted.
I don't do embedded systems, but as a self-respecting software engineer, I am intending to develop proficiency in C/C++ over this next year. Does anybody have any recommended books/courses/projects?
I learned it with "Advanced Programming in the UNIX Environment". > as a self-respecting software engineer Then you probably already know more about C than you realise: if, while, for, etc. all work the same as most other languages. What you're probably not used to is needing to define functions in advance, pointers, and memory (de)allocation. If you learn by doing, then with google and github, you can create a few s…
> I learned it with "Advanced Programming in the UNIX Environment".
Agreed. APUE is perhaps one of the best book available covering SUS, POSIX layer in detail.
Re: Ask HN: What should a systems/low-level software engineer know?
#69Earlier quoted context omitted.
Not able to edit! But i meant NOT worth the switch.
Are the jobs still there or are they disappearing? I am bored of the churn associated with stuff higher up the stack. I would prefer to master a craft rather than chase new fads every few years.
Maybe look into mainframes such as the i series. You won't experience churn there. And there will be an increasing need for younger developers in this area in the near future as many of the current developers will be retiring.
Also, you won't be required to work on pet side projects, push them to Github, blog about them and post Show HN comments to build up street cred for future job interviews.
But I have no idea how one breaks into this field. Maybe that's worth an Ask HN or a Stack Exchange post.
Re: Ask HN: What should a systems/low-level software engineer know?
#70Earlier quoted context omitted.
Huh. I always perceived C to be a subset of C++.
FWIW I think he's wrong. Basically, when writing C, you should write code the same as if you'd write it in C++, except that you're using C. Because sometimes that's annoying, things can get less type safe, but in your head, there's a C++ program that you're representing.
Programs written in this mindset might be the number one reason why C has a bad reputation. Of course, if you just emulate what other languages automate for you, you should better write in these languages.
But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow never fits after a couple thousand LOC.