5 ms·

It is and has always been immensely helpful to understand what you are doing in any context. There are some programmers who treat the job as just plumbing toge

It is and has always been immensely helpful to understand what you are doing in any context. There are some programmers who treat the job as just plumbing together what is to them completely incomprehensible black boxes, who treat the computer as a mystery machine that just does things "somehow", but these programmers will almost always be hacks that spend their entire career producing mediocre code. There are things such a programmer can build, but they are very limited by their lack of in depth understanding, and it is only a tiny fraction of what a more competent programmer can put together. To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth. You don't have to be an expert at these things by any means, but you do need to understand them and be comfortable treating them as transparent boxes that you may have to go in and fiddle with at some point to get where you need to go. Sometimes you need to vendor a dependency and change it. Sometimes you need to drop it entirely and replace it with something more fit for purpose you built yourself.

lo_zamoyski 5mo ago
That's a little simplistic and lacking in nuance. > To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth. I think maybe you overestimate your own knowledge here. It's one thing to understand general principles and design or to understand a contextually-relevant vertical or whatever. It's another to demand comprehensive (even if not expert) familiarity in non-trivial projects, especially those created by many developers over long time spans. It's not just a question of intelligence or dedication or even just time spend working on a project. The amount of software even your typical piece of code relies on is staggering and shifting, and it's only getting more complicated. A good chunk of software engineering and programming language research has been focused on making it practical to operate in such an complex environment - an environment that nobody fully understands - which is a major part of why modularity exists. Making software like "plumbing together [...] black boxes" is exactly what such research aspired to accomplish, because it allows different developers to focus on different scopes and focus on the domain they're working on. Software engineering is a practical field, and any system that requires full knowledge to operate, modify, and extend is either relatively small (maybe greenfield and written by a sole developer) or impractical to work with. So I would say there's a wide gap between "lazy guy who doesn't give a shit" and "guy who thinks he can understand everything". Both lack the humility and wisdom needed to know the limits of their knowledge, to circumscribe what he needs to understand, and to operate within the space these afford. (Both extremes remind me of cocky junior devs. On the one hand, you have the junior dev who carelessly churns out "hot shit" garbage code by plumbing things together with no grasp or appreciation of sound design; on the other you have the dev who makes a big show about "rigor" completely detached from the actual realities and needs of the project. In each case, the dev is failing to engage intelligently with the subject matter.)
- marginalia_nu 5mo ago
  Well I mean I've built an internet search engine from scratch[1] and I'm making a living off this successfully enough to have completely left the wagie existence for the foreseeable future, so I think I at least kinda walk the talk. I'm far from the best at anything and make no claims toward knowing everything, but I do think I have reasonable breadth in my experience and work, and I don't think I could have built something like this otherwise. [1] ... which is something that does not decompose neatly into black boxes and must to a large degree be built from first principles as goddamn nothing off the shelves scales well enough to deal with multi-terabyte workloads at the even a fraction of the speed a bespoke solution can.
  - baddash 5mo ago
    dude... I need to break free from the wagie existence too. any advice? besides the points you've made already :P
    - marginalia_nu 5mo ago
      Build something people want. Tired point, but it really is true. People will throw money at you if you do.
      - baddash 5mo ago
        ok, I kind of knew that already LOL, but I don't have any questions that are more specific so I can't really complain. just gotta get after it i guess.
        marginalia_nu 5mo ago
        Yeah I don't know if there is such a thing as good advice in this regard, except the stuff that everyone is saying. I guess "build something you want", the Temu-bought knockoff of the previous advice. It's not quite as bad advice as it sounds, as it's at least some validation of an idea, and much easier than playing 17D chess trying to predict the zeitgeist. The luck surface area[1] also isn't quite as talked about as it should, but a good mental model if you're seeking serendipitous life-changing outcomes that I can get behind. [1] https://www.codusoperandi.com/posts/increasing-your-luck-surface-area https://www.codusoperandi.com/posts/increasing-your-luck-sur...

lo_zamoyski 5mo ago

That's a little simplistic and lacking in nuance. > To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth. I think maybe you overestimate your own knowledge here. It's one thing to understand general principles and design or to understand a contextually-relevant vertical or whatever. It's another to demand comprehensive (even if not expert) familiarity in non-trivial projects, especially those created by many developers over long time spans. It's not just a question of intelligence or dedication or even just time spend working on a project. The amount of software even your typical piece of code relies on is staggering and shifting, and it's only getting more complicated. A good chunk of software engineering and programming language research has been focused on making it practical to operate in such an complex environment - an environment that nobody fully understands - which is a major part of why modularity exists. Making software like "plumbing together [...] black boxes" is exactly what such research aspired to accomplish, because it allows different developers to focus on different scopes and focus on the domain they're working on. Software engineering is a practical field, and any system that requires full knowledge to operate, modify, and extend is either relatively small (maybe greenfield and written by a sole developer) or impractical to work with. So I would say there's a wide gap between "lazy guy who doesn't give a shit" and "guy who thinks he can understand everything". Both lack the humility and wisdom needed to know the limits of their knowledge, to circumscribe what he needs to understand, and to operate within the space these afford. (Both extremes remind me of cocky junior devs. On the one hand, you have the junior dev who carelessly churns out "hot shit" garbage code by plumbing things together with no grasp or appreciation of sound design; on the other you have the dev who makes a big show about "rigor" completely detached from the actual realities and needs of the project. In each case, the dev is failing to engage intelligently with the subject matter.)

marginalia_nu 5mo ago
Well I mean I've built an internet search engine from scratch[1] and I'm making a living off this successfully enough to have completely left the wagie existence for the foreseeable future, so I think I at least kinda walk the talk. I'm far from the best at anything and make no claims toward knowing everything, but I do think I have reasonable breadth in my experience and work, and I don't think I could have built something like this otherwise. [1] ... which is something that does not decompose neatly into black boxes and must to a large degree be built from first principles as goddamn nothing off the shelves scales well enough to deal with multi-terabyte workloads at the even a fraction of the speed a bespoke solution can.
- baddash 5mo ago
  dude... I need to break free from the wagie existence too. any advice? besides the points you've made already :P
  - marginalia_nu 5mo ago
    Build something people want. Tired point, but it really is true. People will throw money at you if you do.
    - baddash 5mo ago
      ok, I kind of knew that already LOL, but I don't have any questions that are more specific so I can't really complain. just gotta get after it i guess.
      - marginalia_nu 5mo ago
        Yeah I don't know if there is such a thing as good advice in this regard, except the stuff that everyone is saying. I guess "build something you want", the Temu-bought knockoff of the previous advice. It's not quite as bad advice as it sounds, as it's at least some validation of an idea, and much easier than playing 17D chess trying to predict the zeitgeist. The luck surface area[1] also isn't quite as talked about as it should, but a good mental model if you're seeking serendipitous life-changing outcomes that I can get behind. [1] https://www.codusoperandi.com/posts/increasing-your-luck-surface-area https://www.codusoperandi.com/posts/increasing-your-luck-sur...