4 ms·

Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - Skip low level and go as high as you can. Ditch C, assembly, hardware. Ta

by wruza 2y ago

Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - 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. - 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. - Read sicp, htdp, taoup, but don’t take them to heart. Seriously, extensively test any idea you learn against reality, cause ideas may sound excellent out of context. - Pragmatic is the only way. Don’t listen to industry peasants jumping through imaginary hoops, they are crazy. Religion in programming is worse than religion irl. There’s insane amount of it in programming. Don’t argue, let them be. It’s actually easy to test approaches by yourself and learn your own ways. Most of these are just habits making no difference once learned. - Doing something together only turns out faster if you’re very good communicators. Good communicators are rare and you are not the one.

93po 2y ago
> 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.
juangacovas 2y ago
>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.
- nottorp 2y ago
  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.
- wruza 2y ago
  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.
Panzer04 2y ago
Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?
- wruza 2y ago
  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.
  - PaulRobinson 2y ago
    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.
alfiedotwtf 2y ago
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 :(

by wruza 2y ago

93po 2y ago

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

juangacovas 2y ago

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

nottorp 2y ago
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.
wruza 2y ago
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.

Panzer04 2y ago

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

wruza 2y ago
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.
- PaulRobinson 2y ago
  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.

alfiedotwtf 2y ago

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 :(