Hacker News Reader

Comment by tekstar | Hacker News Reader

C and how to debug it.

If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes.

I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.

View on HN

Also, learn Javascript and browser tech in general. One of the keys to high-performance systems is figuring out how to make the layer above and the layer below talk to each other while removing yourself from the process as much as possible.

I would think that most front end developers already know JavaScript. It might make sense to look at some other approaches like Go (and maybe Rust/C/C++), which is designed for back-end work unlike JavaScript which was basically shoehorned into back-end work in order to leverage all the JavaScript developers in many companies.

sounds very niche from an employability PoV.

These skills have helped me at every single job I've had, including my current one, where I've employed the skill a couple of times to discover bugs or unintended side-effects in third-party library code. For context I've worked in the industry for about 15 years now, in roles ranging from low-level programming on real-time systems to (currently) high level machine learning work.

It might be niche, but it can also be a differentiator--even if I'm not the fastest coder or the best architect I have these other skills that make me valuable at critical times. That's worth something anywhere.

And it's not even knowledge of C or C++, or syscalls or whatever: it's just basic "use a debugger" (not merely pantomime the commands, but understand what's going on) skills that can be the real game changer.

Totally agree with this. I have never written C or C++ in a professional manner but just knowing how to debug and compile it has proved to be an invaluable skill. Lots of software ecosystems often have some underlying C/C++ code that they are calling out to and being able to dive into that when there is an issue is an incredible skill to have.

Make, Ninja etc. are fairly straightforward compared to something like Gradle and just knowing my way around that and Clang/GnuCC has gotten me a lot farther in my career.

It doesn't make you "employable". It does make you incredibly valuable once you're inside. Being able to debug systems and being able to talk to other teams working on different levels of abstraction are both incredibly important skills.

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?

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.

>>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'

> '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.

>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.

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.

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.

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.

Yeah it's the complete opposite of niche. It's the fundamental understanding of processes, signals, syscalls, memory that every modern computing system is based upon.

So much for being language agnostic

Reply on news.ycombinator.com