20 pointsby BinaryIgor4 days ago5 comments
  • Nab4433 days ago
    Interesting, my path is a bit like the opposite. I tend to avoid categories of tools that abstract too much the problem in a "magic" way for the same reason: you can't easily understand what's going on behind the scene, and you have to dive in each time you enter a corner case. If you can't control what it is doing on each step, then you can't be sure it will be doing what you expect and this can become a mental effort that outweight the tool benefits.
    • BinaryIgor3 days ago
      True; in the same vain, tools that have more implicit and declarative philosophy - React, Kubernetes, most ORMs, Spring Boot - are also harder to understand and reason about for the same cause - you have to know exactly how the given tool works (new abstraction, magic) to understand what might happen at runtime.

      We replace verbosity - since these tools are usually way more expressive than the thing they abstract away - with a new abstraction layer that allows us to type much less stuff but at the same time introduces a completely new cognitive complexity layer.

      As always; sometimes they give more than they take, sometimes not ;)

  • bashmelek4 days ago
    I do often feel like a Lost Programmer.

    C# is my Blub. I use Visual Studio (and not Visual Studio Code). I also use some T-SQL and JavaScript, and sometimes C++ on the weekends. In all of these, my understanding is still rather shallow. And for my day job, and most of my hobbies, it works.

    But there is a definite next level I haven’t pierced, the level of “real programmers”. I want to understand the code I see on GitHub, even contribute. I want to be capable of more. But it is hard when I can’t even tell what I’m seeing, when I’m just trying to Make It.

    • BinaryIgor4 days ago
      Keep the curiousity up and learn your Fundamentals - things that do not change that often and on which most of our tools and frameworks are built. Dive deep into OSes, networks - build your own TCP and/or HTTP server, assembly and the machine code - how the CPU and memory works? As well as some algos and data structures for sure. These few things cover most of it ;)
  • mfro4 days ago
    I think this correlates more to individual culture and interest in general computing than anything else. As you said yourself, the 'lost programmer' isn't curious, isn't interested in the details. They are interested in getting their specific tasks done and collecting a paycheck. Many may have ended up in a field they are not excited about. That's not something you can fix.

    As an aside, it will only get worse as the technical implementations get easier. Probably a lot of AI generated SQL queries being put into prod nowadays.

    • BinaryIgor4 days ago
      True; but I would argue that even if you don't care that much, when things don't work as expected - you pretty much always need to understand your tools and/or the layers of abstractions that are below. If you don't, not only you're going to feel lost, but you will not be able to solve certain set of problems
  • cadamsdotcom3 days ago
    This is a case of the “everyone except me is an idiot” fallacy.

    What actually happens with these people is they are pragmatically cargo-culting - because it helps them achieve some other aim, like delivering business value - until their abstractions leak and they have to go uncover the truth.

    People grow and learn when they need to :)

    • BinaryIgor3 days ago
      It depends; sometimes yes, sometimes not. In my experience, described phenomena certainly exists.

      Nothing wrong with delivering business value - that's what mostly software is about after all; here, I am talking about pure incompetence and a certain approach that only reinforces it

      • cadamsdotcom3 days ago
        You are assuming people are a still photograph of what you see in the fraction of a moment that it takes you to judge them, and they never ever change, not even after you’ve left and stopped paying attention.

        That’s not how you work and it’s not how people work. It’s not how anyone works. Give others some credit.

  • djoldman4 days ago
    Similar to Chesterton's Fence.

    We should probably learn CS from the least abstraction to the highest.

    So that when the abstraction breaks, we know where to look to understand why.

    • BinaryIgor4 days ago
      Exactly; but, if you started from higher levels, it's never too late to go lower, step by step. I did exactly that and I highly, highly recommend doing it
      • MarsIronPI4 days ago
        On the other hand, if you have a 10-year-old who expresses interest in "computers", you probably don't want to teach him conditionals by showing him conditional jump instructions in x86 assembler. Maybe teach him BASIC instead of the latest trend in Javascript, but I think he would not be too comfortable or happy with assembler.
        • 17186274402 days ago
          Why not? You can also teach electronics first, that's way more hands-on than writing code on the computer.
          • MarsIronPIa day ago
            Electronics at a 10-year-old's level isn't very close to computing IMO. And as to why BASIC over JS as a first language: BASIC has a very simple syntax and very simple execution model. No need to teach functions or recursion to a 10-year-old who's just getting started IMO.