Ask HN: What should a systems/low-level software engineer know?

Post by barrkel » Fri, Jan 11, 2019, 1:57 PM UTC

Waterluvian wrote: post #43

tonysdg wrote: post #39

Earlier quoted context omitted.

A quick word of warning: be sure to treat C and C++ as two completely separate languages that just happen to have similar syntax. Yes, you can use C++ as "C with classes" (I and many others sure have at times), but you're doing yourself a disservice most of the time if you do.

Huh. I always perceived C to be a subset of C++.

    #include 
    
    typedef enum EFoo {
        FOO_A = 1,
        FOO_B = 2
    } TFoo;
    
    int main()
    {
        TFoo foo = FOO_A | FOO_B;
        printf("foo = %d\n", foo);
    }

Post by danesparza » Fri, Jan 11, 2019, 1:59 PM UTC

osivertsson wrote: post #18

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Post by smilesnd » Fri, Jan 11, 2019, 2:16 PM UTC

osivertsson wrote: post #18

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Post by Calloggs » Fri, Jan 11, 2019, 2:20 PM UTC

jm__87 wrote: post #56

osivertsson wrote: post #18

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Maybe it is just me, but I've seen this issue multiple times where a programmer used a regular expression thinking they were clever, only to have it backfire later when there was some corner case not covered by their regex (which likely would have obviously been caught if they had just taken the time to write out each case as an if statement). You're usually just gaining complexity in exchange for fewer lines of code…

Post by LeftTurnSignal » Fri, Jan 11, 2019, 2:24 PM UTC

0x445442 wrote: post #69

collyw wrote: post #21

Earlier quoted context omitted.

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 ho…