[fennecfoxen]

You are by all means welcome to remain ignorant of how computers and frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack that affect you. Build a career filling in the boilerplate that Spring or Rails or whatever generates, and when the system doesn't perform as you expected it to, throw up your hands and say "I don't know what it's doing," and end the matter there. This is, presumably, a quite ordinary and common approach to software development.

But if you do so, then I must ask: what are you doing on this site? What can you possibly get out of it?

[cudgy]

Your first paragraph is dead on. When I first encountered Ruby on rails after developing in C++ for years, it was very difficult to accept the black box of ruby on rails. In fact, my instincts are to fear tools like that. The sheer number of dependencies on third parties when using tools like Ruby on rails is downright frightening. Good luck making sure that all of the libraries your linking to are secure and that you can fix any issues that come up.

[konart]

>>frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack...

What does any of this has to do with C?

>What can you possibly get out of it?

I hope you realise that many of commenters here are not even software engineers. HN covers more topics than just 'another arrogant software dev lectures someone on topic X'

[whynaut]

> 'another arrogant software dev lectures someone on topic X'

Not GP. But this is explicitly a software thread.

> >>frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack...

Pretty sure they are implying that C/C++ lies somewhere in most software stacks.

[konart]

>Pretty sure they are implying that C/C++ lies somewhere in most software stacks.

So do many other things. It's nice to know every bit of tech behind the scenes but one has only this much time.

[jgwil2]

Well, one doesn't have time to learn everything, so it's entirely reasonable to do a cost-benefit analysis (in terms of employability or personal interest) before investing.

[pdpi]

The OP's statement makes the context clear though: It's not about knowing everything. It's about knowing a couple of abstraction layers under you (and, as I argued elsewhere, above you too).

It's useful to understand a few classic networking problems that a backend engineer might face — e.g. weird latency issues caused by Nagle's algorithm, or TCP CLOSE_WAIT leading to ephemeral port exhaustion between a proxy and an application node. It's useful to understand why we mostly moved to event loop-based servers instead of thread-per-connection servers as a way to handle c10k.

A backend engineer doesn't necessarily have to be an expert on any of these things, but they should be able to follow along if an expert explains that sort of problem.

[jgwil2]

OP was responding to a comment specifically about debugging C. Someone questioned the value of this to employability and then the comment I responded to laid into him/her, suggesting no one on HN should ask that. I am defending that question.