5 ms·

"As if these skills are special and inherently more difficult to pick up by developers without them" It's because they are.

by gdy 7y ago

saagarjha 7y ago
Source?
- whateveracct 7y ago
  There isn't one. The only source is the hivemind of systems programming elitism. I've seen it permeate every systems engineering shop I've encountered.
  - gdy 7y ago
    If you are saying it is happening everywhere you come, maybe it's you who is doing something wrong socially?
    - whateveracct 7y ago
      I get where you're coming from, but I don't see how me joining a company could cause its leaders and employees to exhibit the sort of arrogance and gatekeeping I'm describing.
      - gdy 7y ago
        You haven't described it, actually.
pkolaczk 7y ago
My limited experience with bare metal programming tells me they are not. This is just a different abstraction layer to learn. Often low level abstractions are much simpler and less broken than high level programming. Even if something goes wrong, you can plug in a logic recorder / oscilloscope / led (!) and in minutes you know what's wrong. But this doesn't work if you have 10 semi-broken layers below. I have 15+ years of experience in hl programming and almost none in low level, yet I feel like at home with bare metal stuff. And it is a lot of fun as well.
- gdy 7y ago
  I wholeheartedly agree with you, it surely is fun, especially when it is a toy project! As for the systems programming please see my answer to a sibling comment.
  - whateveracct 7y ago
    This comment is a lil passive aggressive. "Toy project"
    - gdy 7y ago
      It isn't, I meant it. And you misuse this word, try googling what it really means.
- ClumsyPilot 7y ago
  If I take your statement at face value, it would appear that all the levels of abstraction we have introduced have made life worse?
  - pkolaczk 7y ago
    To some degree, yes. They allow to write software much faster, but in order to be truly proficient, you need to know a lot of what's in the layers below anyway. And when writing in a high level language, there are many more layers below you than when you write a device driver. So overall you have more things to keep in your head, and more things to learn. But if you do, you gain ability to move faster. So it is not necessarily worse, but just a trade-off. Also, at a high level, you typically solve different, bigger/harder problems. Someone may use Python to build a statistical model, but using a simple language that even kids use at school, doesn't mean the task would be easy. This is also reflected in salaries here where I live - embedded devs don't earn more than application devs.
whateveracct 7y ago
Hah no they aren't. There isn't anything inherently harder about low-level software than webdev or web services. I'm pretty confident people from those domains could pick up systems engineering on the job if the employer is committed to basic teaching and onboarding (which you should be regardless of domain.)
- gdy 7y ago
  Let me quote a quote from TFA: Bjarne Stroustrup: "Systems programming came out of the field where you had to deal with hardware, and then the applications became more complicated. You need to deal with complexity. If you have any issues of significant resource constraints, you’re in the systems programming domain. If you need finer grained control, then you’re also in the systems programming domain. It’s the constraints that determine whether it’s systems programming. Are you running out of memory? Are you running out of time?" These constraints lead to the level of complexity which many programmers are unable to deal with. Another source of the complexity is hardware itself -- it is asynchronous and opaque.
  - whateveracct 7y ago
    By that definition, you can end up doing systems programming in any domain. Optimizing browser performance, optimizing Postgres throughput. All of that is dealing with constraints and synthesizing knowledge from the layers of abstraction your problem is built on. Hardware is just a different set of constraints and lower level programming runs into these problems more often. But there's literally _nothing_ inherently special or impressive about low-level systems programming or programmers :) I'm pretty confident good problem solvers from the domains I mention above could learn to work on it as easily as anything else. And my original comment was about a common _attitude_ I've observed that is the opposite of what I'm saying. And you aren't really making any points against that haha
    - gdy 7y ago
      That is exactly what article was arguing for. I'm not in the business of discussing semantics. My point is that the bar in the 'systems programming' is indeed set higher than in many other domains. I'm not a systems programmer, but I've seen competent in their own domain programmers taking on tasks in more complex domains and failing where I didn't and I've been myself on the failing side. And please refrain from personal attacks, I myself love sharing knowledge with colleagues.

"As if these skills are special and inherently more difficult to pick up by developers without them" It's because they are.

by gdy 7y ago

"As if these skills are special and inherently more difficult to pick up by developers without them" It's because they are.

saagarjha 7y ago

Source?

whateveracct 7y ago
There isn't one. The only source is the hivemind of systems programming elitism. I've seen it permeate every systems engineering shop I've encountered.
- gdy 7y ago
  If you are saying it is happening everywhere you come, maybe it's you who is doing something wrong socially?
  - whateveracct 7y ago
    I get where you're coming from, but I don't see how me joining a company could cause its leaders and employees to exhibit the sort of arrogance and gatekeeping I'm describing.
    - gdy 7y ago
      You haven't described it, actually.

pkolaczk 7y ago

My limited experience with bare metal programming tells me they are not. This is just a different abstraction layer to learn. Often low level abstractions are much simpler and less broken than high level programming. Even if something goes wrong, you can plug in a logic recorder / oscilloscope / led (!) and in minutes you know what's wrong. But this doesn't work if you have 10 semi-broken layers below. I have 15+ years of experience in hl programming and almost none in low level, yet I feel like at home with bare metal stuff. And it is a lot of fun as well.

gdy 7y ago
I wholeheartedly agree with you, it surely is fun, especially when it is a toy project! As for the systems programming please see my answer to a sibling comment.
- whateveracct 7y ago
  This comment is a lil passive aggressive. "Toy project"
  - gdy 7y ago
    It isn't, I meant it. And you misuse this word, try googling what it really means.
ClumsyPilot 7y ago
If I take your statement at face value, it would appear that all the levels of abstraction we have introduced have made life worse?
- pkolaczk 7y ago
  To some degree, yes. They allow to write software much faster, but in order to be truly proficient, you need to know a lot of what's in the layers below anyway. And when writing in a high level language, there are many more layers below you than when you write a device driver. So overall you have more things to keep in your head, and more things to learn. But if you do, you gain ability to move faster. So it is not necessarily worse, but just a trade-off. Also, at a high level, you typically solve different, bigger/harder problems. Someone may use Python to build a statistical model, but using a simple language that even kids use at school, doesn't mean the task would be easy. This is also reflected in salaries here where I live - embedded devs don't earn more than application devs.

whateveracct 7y ago

Hah no they aren't. There isn't anything inherently harder about low-level software than webdev or web services. I'm pretty confident people from those domains could pick up systems engineering on the job if the employer is committed to basic teaching and onboarding (which you should be regardless of domain.)

gdy 7y ago
Let me quote a quote from TFA: Bjarne Stroustrup: "Systems programming came out of the field where you had to deal with hardware, and then the applications became more complicated. You need to deal with complexity. If you have any issues of significant resource constraints, you’re in the systems programming domain. If you need finer grained control, then you’re also in the systems programming domain. It’s the constraints that determine whether it’s systems programming. Are you running out of memory? Are you running out of time?" These constraints lead to the level of complexity which many programmers are unable to deal with. Another source of the complexity is hardware itself -- it is asynchronous and opaque.
- whateveracct 7y ago
  By that definition, you can end up doing systems programming in any domain. Optimizing browser performance, optimizing Postgres throughput. All of that is dealing with constraints and synthesizing knowledge from the layers of abstraction your problem is built on. Hardware is just a different set of constraints and lower level programming runs into these problems more often. But there's literally _nothing_ inherently special or impressive about low-level systems programming or programmers :) I'm pretty confident good problem solvers from the domains I mention above could learn to work on it as easily as anything else. And my original comment was about a common _attitude_ I've observed that is the opposite of what I'm saying. And you aren't really making any points against that haha
  - gdy 7y ago
    That is exactly what article was arguing for. I'm not in the business of discussing semantics. My point is that the bar in the 'systems programming' is indeed set higher than in many other domains. I'm not a systems programmer, but I've seen competent in their own domain programmers taking on tasks in more complex domains and failing where I didn't and I've been myself on the failing side. And please refrain from personal attacks, I myself love sharing knowledge with colleagues.