Hacker News Reader

>Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good.

In my personal experience, I think that having to work on different high AND more low level programming languages over time is what sets me apart from people/coworkers with low basic knowledge of computer foundations (the order in my case being Basic, Pascal, C, Perl, C/C++, PHP, JS, etc). Also it depends on the projects, but just my two cents.

I'd rephrase it as "know both high level and low level and use high level as much as possible".

Knowing the low level will prevent you from shooting yourself in the foot with the high level.

I think you’re right, I should have separated it in two parts. First is learning low-level “how it works, exactly” — that is useful. Second is writing actual low-level code — that I’d advise myself against.

So, I guess:

- Learn how sockets, filesystems and processes work, read apue, learn how jits/compilers work. But don’t write serious C, that’s a waste of time even if you’re smart enough.

This is the first time I’ve ever seen taoup ever recommended besides when I try to bring it up. It’s full of collective knowledge that’s foundational, along with Steven’s books, (if you want to work in Linux land), yet it’s never mentioned :(

> All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive you as a magic money generator. Go around them once you’re confident.

My better advice would be to avoid work that involves outside clients unless you own your own shop or freelance for yourself. They're always going to be price and deadline sensitive in a way that makes for shittier work conditions and lower pay. Working on well-funded internal projects that generate revenue is the way to go. Your work conditions are also going to be much nicer because a client being an asshole can't be used as an excuse for constant overtime or other BS.

Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?

Because I ended up doing “business” things that are far from low-level, and I sort of like it, never wanted to return to C/asm.

I’m glad you’ve found a happy place in your work, but maybe take some of your own advice, drop this bit of your religion and change this to “use the right tool for the job”.

If you’re doing business logic in a micro service, C is probably the wrong choice. Python, Ruby, whatever probably makes more sense.

But if we are trying to build a (very) high-performance trading engine, or a device driver for a new piece of hardware we are building, and you are on my team and you show up with something in TypeScript because “it’s better”, we are going to need a conversation about whether you’re in the right place. I love high level languages but I also know the problem sets when not to use it.

I also know that if I am going to be writing something very low level, it’s a conscious choice and I’m going to invest in the tooling and the time to make sure my code is safe and secure.

The more generic advice might be that if you love a particular language or approach you might want to work on problems where that language is a good fit. Likewise, if you like particular problems, you should learn the language others think are a good fit in that problem space.