[–] 13 points 1 week ago (4 children)

Is that salary estimate also from 2011?

There’s a more robust methodology here, which is to look at commit history, but that will only tell you how many lines were pushed and merged. That will be a greater number, by the way: say the kernel is 100 lines, somebody may have written 50, but they may have all been replaced by future patches, so The number of lines written is greater than the number of existing lines.

Regardless, I’m sure you already know lines of code is a bad metric of output, let alone effort and work.

  • source
  • [–] 2 points 1 week ago (1 child)

    Lie-to-children. See also “perfect is the enemy of good.”

    This was very hard for me to understand, particularly when the simple answer in school that was provided for the benefit of the rest of the class didn’t come with a deeper follow-up, but I now recognize the great value in meeting people where they are.

  • source
  • parent
  • context
  • [–] 3 points 1 week ago

    Yes, I agree completely, but we don’t have a bunch of Assembly diehards working on Linux, so the parallel - while accurate - feels out of scope.

    Ultimately, it comes down to thoughtful transitions over a reasonable period of time.

  • source
  • parent
  • context
  • [–] 9 points 1 week ago (2 children)

    I still understand the argument of the C greybeard to Rust knowledge gap though. Objectivity, it’s hard to argue for a spidey sense that took years or decades to develop vs a deterministic and strict compiler, but developer (and reviewer) experience often seems to be rooted in personal comfort* more than in language features.

    That said, we all have to deal with transitions and learning consistently leads to better outcomes. The argument is sound, but the pragmatic dynamics may take some time.

    *”personal comfort“ doesn’t mean the language or tools are somehow objectively comfortable, but that people feel good, confident, productive, and happy working with them. Just yesterday I was thinking that I like the Gir “is hard” - it stimulates my brain on a daily basis. Different people get that in different ways.

  • source
  • parent
  • context
  • [–] 2 points 1 month ago (2 children)

    You need to be able to pull or build the images on the other machine. At a company you would use a private container image registry on something like GitHub, GitLab or JFrog.

    Setting up a GitLab instance is a really cool homelab project that can also go on your portfolio.

    Develop on your workstation, push to the registry on machine B, pull from that and run on machine B

  • source
  • [–] 7 points 2 months ago

    I’ve taken to writing .http files which are runnable on a number of IDEs and plugins. I don’t need to know what anybody else is using to run them, they live with the code and I’m happy.

    That said, I’ve seen people on QA do really cool end-to-end tests at load via very approachable scripting on Postman.

    There’s lots of room for “to each their own” here.

  • source
  •  

    Occasionally I’ll find my computer slowing down dramatically only to realize a VS Code MCP server is using enough RAM to put me 50GB deep into Swap usage.

    The thing is VS Code isn’t even my main IDE, I just use it to browse projects and as a text editor. I don’t need or want it to run an MCP server and I don’t know why it’s doing it.

    I’m limited in my ability to provide more details, because I just killed the process last time, to move on with work, and didn’t take notes on what it was exactly. I’ll do that next time.

    Has anybody else experienced something like this? It’s a very hard problem to search for - everybody wants to run MCP servers, not stop them.

     

    I got to this from an email with the pretentiously more informative subject line “The data sharing model for your non-commercial license is changing.”

    TL;DR:

    • they will collect basically all IDE actions and code snippets
    • opt-out for free licenses
    • opt-in at admin level for organizations
    view more: next ›