4 ms·

If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more

by kragen 2y ago

If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more battles per day than someone who spends 1% of their time learning new things. Specifically for the examples at hand: - at 20%, you will be able to write a Makefile from scratch within the first day of picking up the manual, rather than two or three weeks if you only invest 1%. - if you don't know what the CPU registers are, the debugger won't be able to tell you why your C++ program dumped core, which will typically enable you to resolve the ticket in a few minutes (because most segfaults are stupid problems that are easy to fix when you see what the problem is, though the memorable ones are much hairier.) Without knowing how to use the disassembly in the debugger, you're often stuck debugging by printf or even binary search, incrementally tweaking the program until it stops crashing, incurring a dog-slow C++ build after every tweak. As often as not, a fix thus empirically derived will merely conceal the symptom of the bug, so you end up fixing it two or three times, taking several hours each time. Sometimes the source-level debugger works well enough that you can just print out C++-level variable values, but often it doesn't, especially in release builds. And for performance regression tickets, reading disassembly is even more valuable. (In C#, managed C++, or Python, the story is of course different. Until the Python interpreter is segfaulting.) How long does it take to learn enough assembly to use the debugger effectively on C and C++ programs? Tens of hours, I think, not hundreds. At 20% you get there after a few dozen day-long debugging sessions, maybe a month or two. At 1% you may take years. What's disturbing is how many programmers never get there. What's wrong with them? I don't understand it.

icameron 2y ago
That’s an insightful comment, but there is a whole universe of programmers who never have to directly work in C/C++ and are productive in safe languages that can’t segfault usually. Admittedly we are a little jealous of those elite bitcrashers who unlock the unbridled power of the computer with C++… but yeah a lot of day jobs pay the bills with C#, JavaScript, or Python and are considered programmers by the rest of the industry
- kragen 2y ago
  Yeah, I write most things in Python or JavaScript because it's much more practical.
  - bluGill 2y ago
    Both have strong limits for writing complex code. Typescript is one attempt of an answer because bad as javascript is for large programs the web forces it. I prefer a million lines of c++ to 100k lines of python - but if 5k lines of python sill do them c++ is way too much overhead. (rust likely plays better than c++ for large problems from scratch but most large probles have existing answers and throwing something else in would be hard)
    - kragen 2y ago
      I agree with all of this.
    - retros3x 2y ago
      Many devs are never even coming into challenging projects like that. For a large part of the dev community its just simple webapps for most of their professional life.
      - kragen 2y ago
        That was never a good strategy. Even before GPT-4 and Claude, those folks were losing their jobs to Wordpress, Google Sheets, Wix, SquareSpace, etc.
remus 2y ago
You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10% more, but again it's not obvious in advance that this will happen.
- kragen 2y ago
  I agree. And there's no infallible algorithm. I think there are some good heuristics, though: - invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful - invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the Lindy Effect - invest more of your time in skills that are broadly applicable (algorithms, software design, Python, JavaScript) rather than narrowly applicable (PARI/GP, Interactive Brokers) - invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff. - be willing to try things that may not turn out to be useful, and give them up if they don't - spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective
  - skydhash 2y ago
    > spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective That's the most useful point. Sometimes just a few why-s can give you a clearer view on your activities and a direction for your efforts.
  - moregrist 2y ago
    > invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff. The think you have a solid point with Postgres v Oracle and I haven’t followed game dev in a while, but your FreeCAD recommendation is so far from industry standard that I don’t think it’s good advice. If you need to touch CAD design in a professional setting, learn SolidWorks or OnShape. They’re what every MechE I’ve ever worked with knows and uses, and they integrate product lifecycle aspects that FreeCAD does not.

by kragen 2y ago

icameron 2y ago

That’s an insightful comment, but there is a whole universe of programmers who never have to directly work in C/C++ and are productive in safe languages that can’t segfault usually. Admittedly we are a little jealous of those elite bitcrashers who unlock the unbridled power of the computer with C++… but yeah a lot of day jobs pay the bills with C#, JavaScript, or Python and are considered programmers by the rest of the industry

kragen 2y ago
Yeah, I write most things in Python or JavaScript because it's much more practical.
- bluGill 2y ago
  Both have strong limits for writing complex code. Typescript is one attempt of an answer because bad as javascript is for large programs the web forces it. I prefer a million lines of c++ to 100k lines of python - but if 5k lines of python sill do them c++ is way too much overhead. (rust likely plays better than c++ for large problems from scratch but most large probles have existing answers and throwing something else in would be hard)
  - kragen 2y ago
    I agree with all of this.
  - retros3x 2y ago
    Many devs are never even coming into challenging projects like that. For a large part of the dev community its just simple webapps for most of their professional life.
    - kragen 2y ago
      That was never a good strategy. Even before GPT-4 and Claude, those folks were losing their jobs to Wordpress, Google Sheets, Wix, SquareSpace, etc.

remus 2y ago

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10% more, but again it's not obvious in advance that this will happen.

kragen 2y ago
I agree. And there's no infallible algorithm. I think there are some good heuristics, though: - invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful - invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the Lindy Effect - invest more of your time in skills that are broadly applicable (algorithms, software design, Python, JavaScript) rather than narrowly applicable (PARI/GP, Interactive Brokers) - invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff. - be willing to try things that may not turn out to be useful, and give them up if they don't - spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective
- skydhash 2y ago
  > spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective That's the most useful point. Sometimes just a few why-s can give you a clearer view on your activities and a direction for your efforts.
- moregrist 2y ago
  > invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff. The think you have a solid point with Postgres v Oracle and I haven’t followed game dev in a while, but your FreeCAD recommendation is so far from industry standard that I don’t think it’s good advice. If you need to touch CAD design in a professional setting, learn SolidWorks or OnShape. They’re what every MechE I’ve ever worked with knows and uses, and they integrate product lifecycle aspects that FreeCAD does not.