• 0 Posts
  • 15 Comments
Joined 11 months ago
cake
Cake day: November 27th, 2023

help-circle

  • I’m glad you agree. Honestly, as someone who has also struggled with this question, I wish I’d done this earlier, because there’s a lot of advantages to it.

    It takes a lot less planning and upfront time investment before you get to see your work make a difference in the world. It’s not immediate gratification, mind you, because pull requests can sometimes sit there for days or weeks before someone has the time to review them, but when they get merged, and you get to see the feature you worked on in an app you actually use, it’s still a great feeling.

    Most projects will also give you contributor credit, so your name and/or GitHub handle will show up on their repo, website, or in the app’s “about” page, and you can claim that on any job application you might submit in the future.

    I honestly think it’s a great way to scratch your own itch (because you can pick what issues you want to work on and build features you’d actually want to use) while also helping other people and benefitting open source as a whole. Any reasonably popular project generally has a massive backlog of open issues, so if you’re at a loss where to even start, you can just look through there and pick something that seems doable.


  • Yeah, I think you’re already on the right path with that, those are good basics for anything computer science related (and usually required classes if you take CS in college). Perhaps add Numerical Analysis to that list.

    Also, Operations Research has some interesting optimization algorithms, and Statistics is useful for anything related to Machine Learning.


  • I’m a mathematician by training who has worked extensively (and exclusively) in the software field. While I realize I’m probably biased here, I think I write very solid code and have rarely received any complaints from trained software engineers about it.

    I did however also take quite a few computer science classes in college and have spent a lot of time learning how to write better, more readable and maintainable code. Having had quite a few jobs at the start of my career where I was the only programmer on a project and therefore forced to eat my own dog food has certainly also helped.




  • IDK, virus scanners and malware detectors could do these things before AI.

    You could search for stuff like directly accessing the ~.ssh directory, or any invocations of wget or curl to download external scripts and run them through an interpreter and flag those for closer inspection.

    If you want to get fancier, automate installing packages in an isolated environment (like a container or VM) and keep track of every file system access and network request they make.

    Sure, eventually they’ll figure out ways to obfuscate those things, too, but it could at least prevent people from doing things in such blatantly obvious ways.



  • You mean these? Does it use them internally, because I haven’t really seen them in any Svelte code.

    If so, what does it matter what the compiler does in order to make your code work, so long as it’s legal? It’s perfectly valid JS, that’s all that counts.

    I wouldn’t say Svelte is weird as much as it’s different. That’s the whole point after all. Instead of adding a bunch of library bloat and keeping an entire copy of the DOM to constantly compare to and derive changes from, it compiles your components down to native JS that manipulates the DOM directly, like you would by hand. Except of course the compiler uses different ways to achieve that than you would, but that’s because it doesn’t have to care about readability, as long as it creates valid and efficient code.







  • How do you calculate those numbers though?

    It’s not like your colleagues will be keeping track of how much time they’ve wasted writing ineffective code. If anything, they’ll try to hide that by arbitrarily inflating sprint points etc.

    I’ve worked in environments like that and the issue almost always isn’t that people wouldn’t LIKE it if there were tests, it’s that they

    1. Don’t want to have to learn something new in order to do the same job they’re already comfortable with
    2. Are worried that if they convince management to let them invest X amount of time into doing something that will improve productivity, they’ll be expected to be more productive in the future

    And of course, all of this for no extra money. Unless you work at a place where management prioritzes developer happiness over how many sprint points the team can knock out every week (and those are rare), the sad truth is that it’ll likely be about as popular as leftover food growing mold in the community fridge.