jvisick @ jvisick @programming.dev

Posts

0

Comments

57

Joined

2 yr. ago

"To get a base salary of $170k you know you need to work hard as an Engineer, this sucks."

As someone who has worked as a UPS driver and now as a software developer, I can say that the UPS drivers definitely work harder than your average engineer.

That quote is also deftly ignoring the fact that you’re generally paid for the value you generate, not how hard to you work.

GitHub Copilot is just intellisense that can complete longer code blocks.

I’ve found that it can somewhat regularly predict a couple lines of code that generally resemble what I was going to type, but it very rarely gives me correct completions. By a fairly wide margin, I end up needing to correct a piece or two. To your point, it can absolutely be detrimental to juniors or new learners by introducing bugs that are sometimes nastily subtle. I also find it getting in the way only a bit less frequently than it helps.

I do recommend that experienced developers give it a shot because it has been a helpful tool. But to be clear - it’s really only a tool that helps me type faster. By no means does it help me produce better code, and I don’t ever see it full on replacing developers like the doomsayers like to preach. That being said, I think it’s $20 well spent for a company in that it easily saves more than $20 worth of time from my salary each month.

Out of all the modern browsers, it’s always Safari that I end up needing to write compatibility code for. I’m sure the app works fine on Firefox, they just haven’t tested it.

No problem! It is a lot of information at once but I’ve been having a great time playing it so I’d really recommend it to anyone who thinks it could be interesting.

The combat is fairly challenging - it’s easy for one or two bad moves (or bad luck) to kill your whole party in a battle. It also takes a bit to learn the combat system if you haven’t played D&D.

That being said, I love it. Once you get the basics of combat down and get used to playing carefully, it’s a lot of fun and you get to build out the character that you think is both effective and just cool - and there’s probably a way for you to succeed with whatever build you end up making.

If you don’t love turn based combat I’ll say that it will probably feel very dense at first. You end up with 4 different characters with different strengths and weaknesses and each with a bunch of different abilities that have different rules for when and how often you can use them. Turn based means you get the time to make an educated decision about what you want to do next, but it’s a lot of information to juggle.

It’s not just because of nonsense, it’s more that it doesn’t really matter what you do - the only thing stopping someone with physical access to your machine is their level of determination.

At some point, there’s no stopping the laws of physics. Your data is physically stored there. You can do a lot to make it really difficult to access it, but the best you can do is full disk encryption with a sufficiently strong key, and only store that key on external hardware that isn’t accessible to the attacker.

Even then, you better make sure that your encryption key wasn’t hanging around cached anywhere in memory before you shut down your computer.

I like to draw my pages out on graph paper, then just use position: absolute and tons of media queries to place everything with x and y coordinates. It’s the ultimate grid system.

By necessity, when you’re in the debugger your code has already been compiled either way, no? Or am I missing something here?

This isn’t executing your code as you’re writing it (though it does support Edit & Continue), this is preemptively executing the next lines in your code when you’re already paused in the debugger - which means it’s been compiled and already running.

“Self-documenting” just means “(I thought) I understood it when I wrote it, so you should too”. In other words, it really means “I don’t want to document my code”

I would absolutely consider shipping non-minified bootstrap doing something wrong

Grid is just flexbox but worse

My favorite approach I’ve seen is just units of time -“this task will take a few [days/weeks/months/years]”.

No specific number. Instead, the scale of the task is measured in one of those units and I can give you an estimate but it’s just a guess.

If it’s task that might take “a few days”, it could be done tomorrow or it could take 5 days. If it’s one that takes “a few weeks”, it might be done next week or maybe next month.

The choice between Linux and Windows is not just about ideologically choosing open vs closed source software.

If you don’t want to use closed source software, don’t use VS Code - but if you want to use Linux, and you want to use VS Code, those two choices are totally compatible and perfectly valid

What are they going to do if they don’t pay? Evict them?

What bike do you use and would you recommend it? I’ve been looking for an e-bike recently since I work so close to home, but I haven’t found any that seem reputable and a good value. I’m definitely looking for one that’s easily repairable and not paired to a specific brand’s software or proprietary parts.

Granted, I’ve only been passively looking (I.e. when I see an ad or doing a quick google search sometimes), but from what I can tell most of the advertised bikes are just the same handful of models with a different logo slapped on it and dubious claims about its performance.

You’ll never understand why people want to check out the latest app from a major tech company?

I get it if you aren’t interested personally, but it seems strange to not understand why people would want to try it.

There’s nothing to stop an admin from hosting a static front end for their Lemmy instance if they’d rather, but it’s clear that SSR is a goal here - and I think the default UI for Lemmy really should include SSR for plenty of reasons. And, if you’re already hosting a Lemmy instance, you definitely already have a host that can support Rust (at the very least, in a container).

TypeScript is essentially the “measure twice, cut once” approach to JavaScript.

Yeah, anything can be anything in JS and the type declarations don’t make it into the compiled JS, but allowing anything to be anything starts to become fairly dangerous when the size of your projects starts to grow and especially when you’re working with a team.

Rather than writing functions and just hoping they always get called with a parameter that has the properties you expect to use, TypeScript helps you make sure that you always are calling that function with the right object in the arguments. You don’t need to debug some runtime error up and down 8 frames in the call stack because this week you named a property “maxValue” but last week you used “maxVal” or you forgot to parseInt some string because you thought it would be coerced - you just need to make sure your types match and eliminate that type of debugging altogether.

All in all, TS really just enforces a bit of sanity to the foot gun that is vanilla JS.

“Dependency injection” is just a term for providing a function or method with its dependencies rather than making the function go and gather them itself.

It’s (typically) done through parameters, but it’s still more specific than just invoking a function. It describes how that function was written and the reasoning for certain parameters. To the other commenter’s point, you’ll have a hard time communicating about your code with other developers if you refuse to use the term dependency injection just because you don’t like OOP.