redsaz · HackerTrans

ปีที่แล้วdiscuss

Thankfully the episode's interpretation of a Good Samaritan Law is completely wrong, at least in many (most?) US states. They protect citizens acting in good faith to help somebody, not like it was interpreted in the episode to require somebody to help.

redsaz

ปีที่แล้วdiscuss

How should you conduct the interview, then, if:

... Classic interviewing techniques of "explain how X algo works" or "write code to solve Y" will unfairly bias against interviewees that don't test well under pressure, but would otherwise be a good coworker.

... "Teach me something interesting to you" or "tell me stories about past experiences" will unfairly bias against interviewees that are shy, soft spoken, or are mildly socially awkward, but would otherwise be a good coworker.

Given the above awareness of where bias can emerge, how should the interview be done in order to get a candidate that knows what they're doing, and works well with the rest of the team?

Other comments mention relying more on recruiters and referrals, but that isn't always an option.

redsaz

2 ปีที่แล้วdiscuss

tl;dr: Neanderthals needed to go clubbing more.

redsaz

2 ปีที่แล้วdiscuss

> The only thing missing is a game

I've seen this story of "I want to make a game" [proceeds to make a game engine instead] happen in my own life (my engines were never any good or complete though), and in countless other programmers lives.

It may be the trap of thinking that "If I get the hard part out of the way first (which is writing the engine code, right? Right? Anyone?), then the rest of the game making process will be easy" that gets me.

Or maybe it's finding out along the way that it was more fun to make the engine than the game itself: "check it out, I completely redid the particle effects and I can now do 100x more particles at 60fps, how cool is that?"

There's way more easier-to-see improvements in the making of the engine, than in the making of the game itself, and so we (ok, I) keep optimizing the engine because those are quick dopamine payoffs compared to the slower payoff of having a polished game that's actually fun for the target audience to play. Sure, I might tell myself that the game I want is only possible once I have the engine first, so I'd better concentrate on that before making the actual game, and there's some logic to it. But without a clear idea of what the game will actually be, it's easy to fall into the trap of endlessly adding and refining features, rather than actually try and use those features in anything beyond a slick demo.

To combat the tendency of only making an engine rather than a game in my latest hobby project, I picked an already existing engine (Phaser js) and tried to get something interactive on the screen ASAP "with the stupidest, least designed code possible", and it mostly worked to get me a playable (ish) game! Granted, it's a knockoff puzzle game but hey, I sometimes find myself "playtesting" it instead of what I should really be doing, which is refactoring the code for what I'd like to have it do next, so I'm marking it as a win.

redsaz

2 ปีที่แล้วdiscuss

[flagged]

redsaz

2 ปีที่แล้วdiscuss

> empirically measured that completing a task... is twice as fast in [Rust] than in [C++]

I have not read up on which tasks you're referring to that are empirically measured, apologies. The reason I'm curious on what the tasks are, is that depending on the task, navigability may not matter.

For example, if the task is "build a tool that does X", then navigability of the code does not matter. Once built, the tool does X, and there's no reason to revisit the code, and thus no reason to navigate the code.

But if the task is "Given a tool that already does W, X, Y, make the tool also do X', Y', and Z", then navigability of the code matters. This is because the coder must understand what the tool already does, and where the changes need to be made.

Most of my professional life, (and I'm willing to bet, most other coders here as well) I more often find myself in the second task than the first.

But, I'm not interested in Rust vs C++. I'd be more interested in the results of "given a version that makes high use of type inference vs not, how quickly can someone new to the project add X', Y', and Z." That would be a more appropriate test for what the author describes here. And I'd imagine that probably, those that are using sufficiently advanced IDEs would beat out those without, regardless of if type inference used or not, and would probably be slightly faster when given the highly type-inferenced version.

redsaz

2 ปีที่แล้วdiscuss

> This post can definitely be considered a “religious” opinion piece

The author certainly has that right, because the post steps on two programming religion landmines, from how I read it:

1. strict static typing (without type inference) is good. 2. code should be written to allow IDEs to enhance navigability, rather than written on the assumption that IDEs will be the sole provider for navigability.

I believe there is a point to be made in the "when we don't know what we're getting back, that harms navigability" camp. But as another commenter posted, there's a point to be made in the "when we overspecify what we're getting back every time, that can harm readability, too" camp.

I can't express where this balance is. It's somewhere between poetry and a legal document, the prose where you can really get into a good book and enjoy the world that the author presents. Some people really like the beauty of a short poem. Other people may require precise wording that leaves no room for enjoyment or interpretation. The rest of us can have the majority of fun somewhere in between.

Where that "in between" equivalent would be in my day-to-day programming, I'm not entirely sure, because what I'm writing could be a short script where brevity is vital (poetry-ish) vs some section of unfortunately highly complex code with lots of tests for edge cases (legalese), and all the other code where I'm still world-building and conveying ideas (prose). And I believe that complexity should be spelt out as precisely as it can in the code itself, rather than rely on the hope that somebody else is using the same IDEs and features as me. I've tried using type inference where it seems fine to use, and then spelling out the exact type that a variable wants where it isn't clear what might get returned, all in the same app, but it comes across as sloppily inconsistent in my mind. Ah well.

redsaz

2 ปีที่แล้วdiscuss

We have a similar saying: "You can lead a horse to water but you can't make 'em drink." At least, it seems similar to me.

redsaz

2 ปีที่แล้วdiscuss

Answer: because they don't want to be promoted to manager, they'd rather be coding.

redsaz

3 ปีที่แล้วdiscuss

I've not heard that version before, I like it. The way I usually hear it end:

So, he yells out "102!" and... Crickets.

"What'd I do wrong?"

"Ehh, you must not have told it right."

(...Or, in this case, "you're probably not using the right model GPU")