Principal Engineer for Accumulate

  • 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle



  • If I’ve been working in the same language for at least a year or two, I don’t have to look up any of that. Copilot might be actually helpful if I’m working in a language I’m not used to, but it’s been a long time since I’ve had to look up syntax or functions (excluding 3rd party packages) for the language I work in.


  • I won’t say copilot is completely useless for code. I will say that it’s near useless for me. The kind of code that it’s good at writing is the kind of code that I can write in my sleep. When I write a for-loop to iterate over an array and print it out (for example), it takes near zero brain power. I’m on autopilot, like driving to work. On the other hand, when I was trialing copilot I’d have to check each suggestion it made to verify that it wasn’t giving me garbage. Verifying copilot’s suggestions takes a lot more brain power than just writing it myself. And the difference in time is minimal. It doesn’t take me much longer to write it myself than it does to validate copilot’s work.



  • That’s a hot take. If you want your code to be maintainable at all, it needs comments. If you’re part of a team, write comments for them. If someone else may take over your project after you move on, leave comments for them. And have you ever tried to read uncommented code you wrote a year ago? Leave comments for yourself.




  • Of course, but OOP is typically about putting methods on classes, inheritance of behaviour etc.

    You’re referring to one subtype of OOP. That may be what most people mean when they say OOP, but that doesn’t make it correct. Object-oriented programming is programming with objects, which does not require inheritance or classes.


  • I’ve done a little bit of Python in the past, the biggest thing being an automation task that borderline became an app. I certainly can imagine using it for scripts, though I default to bash because that’s almost always available but TBH mostly because inertia. Beyond that my default is Go because inertia (and I love Go). I watched a video by the Primeagen (on YT) - in his view, Rust is better for text/data pipelines and CLI tools. Being very familiar with Go and not at all familiar with Rust, that’s an interesting take because honestly writing a CLI in Go is kind of meh.



  • For references within a scope, you’re probably right. For references that cross scope boundaries (i.e. function parameters), they necessarily must consume memory (or a register). Passing a parameter to a function call consumes memory or a register by definition. If a function call is inlined, that means its instructions are copy-pasted to the call location so there’s no actual call in the compiled code.


  • Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.

    It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.


  • I’m a cishet white dude so I experience effectively zero discrimination directed at me, but I am on the spectrum.

    I guess basically everyone I regularly interact with either is also on the spectrum or has intense interests regardless, or is used to people like that. Though TBF I have learned to not get intense if I’m in public talking to random strangers. But if someone asks me a question like, “how do computers work”, I will answer at great length.