zemo

I've worked at two game companies and both used both of them. And I went to grad school for game design and used Perforce. So yeah I've ... had the experience.

> Basically, we're hoping to address this concern by building a separate sustainable commercial product rather than monetizing our open source tools.

jfrog artifactory suddenly very scared for its safety

I used GitHub for years in the tech industry, then went into the games industry and used BitBucket and hated it, thought it was such a downgrade. Now I'm back in the tech industry and using GitHub, and I miss BitBucket.

> GitHub employees are quite political (master branch rename, ICE protest resignations, etc).

ah ok so the politics of power aren't of interest to you

> LLMs trained on public and private code without consent or opting in.

ah ok so the politics of power ARE of interest to you

what's goin on here man

> Apple has nothing

I always hear this but people use Siri all the time, and I think outside of talking to programmers, a lot of consumers probably consider that the level of AI they care about using. "is Siri really AI" seems like a real "is a hotdog a sandwich" question. Who cares? People eat hot dogs and talk to Siri.

It seems what Apple has less of is LLM products that cost enormous sums of money to make that people don't like using. Sure, they have a little of it, they fell flat on their faces with their news summaries thing last year and AppleVision was a nothingburger, but when it comes to "sinking huge amounts of money into deeply unpopular ventures", it seems to me that Apple's reluctance to deploy its largess here might be prudent. It seems like they're less exposed on the hype.

There was a time when I hated livecoding interviews, but anyone who has ever participated in an interview process that lacks a livecoding interview and wound up hiring someone that literally could not code knows that a bad hire is incredibly painful and expensive. For most employers, missing out on a good candidate is a less expensive mistake than hire a bad candidate.

The post describes what candidates can do, but there's a lot of responsibility on the end of the interviewer. Most of the responsibility, if not all of the responsibility here, is on the interviewer. If you're seeing 75% of your candidate bomb your livecoding interview, your process is very, very broken.

- Never spring a livecoding question on someone as a surprise. Candidates should know well in advance which portion of an interview has a livecoding question in it.

- Interviewers are responsible for helping the candidate feel comfortable. I always chat a bit with candidates, explain the schedule of the timeslot up front, read through the problem with them, answer any questions about the problem they have to make sure they understand what is being asked, etc.

- Always give more than enough time. A question that you expect to take 10-15 minutes to solve requires an hour long interview slot. For candidates that finish very early, have a bonus question lined up in advance, or use the time to talk and answer candidate questions. E.g., for a 10-15 minute problem, you could do a 5 minutes intro, 40-45 or minutes coding, and a 10-15 minute outro for candidate questions.

- Don't make the problem too small. If it's too small, you're quizzing them on knowing a single thing and not gathering any signal on whether or not they can break a problem down. One medium problem that breaks down into two smaller subproblems is better than two small problems that have nothing to do with one another.

- I tell candidates they can pick what language they want and I also tell them what languages I know.

- Frame it more as a pair programming exercise. If the candidate wants to do something that requires a lot of typing, I'll pitch in. If they make a typo in a variable name, an indentation error in python, or drop a parenthesis, I just tell them. It's not a typing test.

- I tell people they can look stuff up. I even tell people they can ask me. If someone asks me a question about the Python or Go standard library I just answer it. It's not a test of your memory of the layout of the Python standard library. If you vaguely know "the standard library has this thing that I need" and can name it, I'll just tell you where it is.

- I tell people they can run the code as many times as they want; if they want to run their code a bunch of times and solve it in an iterative fashion that's totally normal. Without this instruction, sometimes candidates think they are expected to get it right on the first run, or in as few runs as possible. We're not golfing here.

etc. Things like that. Sometimes people tell me what they're going to do and ask me if it will work and I'll say "ah I think that's giving too much away", so there are limits. Obviously don't solve the problem for people, but making sure the candidate is comfortable is something the interviewer must actively engage in and manage, and when candidates are getting stressed out, it is the interviewer's job to do their best to help lower the stress level of the situation. And yes, sometimes you'll still get people who bomb, but if you're seeing that happen 75% of the time, that's likely signaling that your process is not working.

I don't really think that's accurate. In my last interview cycle, I aced the livecoding portion at each interview and didn't practice any leetcode problems at all. In my normal workflow I write utility scripts in Python using only the standard library pretty regularly. If you know how to write complete, small programs using only the standard library of some language, you'll do fine on livecoding interviews. A lot of people struggle to do this because they only know how to work inside of a framework.

That sounds terrible for all parties. You have to conduct the entire interview experience twice, the candidate has to conduct their job search twice, they may have declined another offer to accept yours, they may have had to relocate to accept your offer, if you're in the US they may have gone off health insurance and their new health insurance didn't start yet, etc.

it's almost like Grok takes "politically incorrect" to be synonymous with racist.

I think this narrative gets recycled because it's the shallow depth of reasoning afforded by thinking about technology only by thinking about the instruments of that technology and one's own personal experience with them, which is the perspective that is prioritized on HN.

art to them is a commodity, not a facet of expression or cultural participation.

not in the US

sure, that's "what people want" inasmuch as if you put every button through a statistical microscope, that's what the statistics will tell you, but if you give a rat cocaine-dispensing button and measure how many times it hits the "more cocaine" button you'll also come away with the conclusion "rats want cocaine", a thing they never encounter in nature and would never have encountered without you putting it in front of them, and you'll pat yourself on the back and say "now I understand rats: they are all vicious cocaine fiends", but you haven't really learned about rats' true nature, you'll have only conned yourself into a false narrative that confirms that your own actions are only "giving the rat what it wanted", and after it dies of an overdose, you declare yourself innocent. Anyway that's a/b testing and the tech industry.

> every applicable art school has enforced their student's output to be done in adobe's products

do instructors really require people submit PSDs or do students export their stuff to jpg/png/whatever and submit the export

> The issue is lying about your experiences

I think the point is that LLMs makes it easier and cheaper to produce a large volume of convincing lies. The candidate likely would not have been able to produce convincing-enough lies to get through the resume screen without LLMs.

on the contrary, they met after John went to one of Yoko's art shows and was intrigued by her artwork; it's probably unlikely that Yoko would have married John if it were not for Yoko's work.

https://en.wikipedia.org/wiki/Ceiling_Painting/Yes_Painting

people love to talk about a game being realistic or not realistic without asking whether more realism = more fun. Usually the answer is no. Doing collision detection on every bullet on every frame is a cost that may or may not be worth it, depending on the overall design of your game. "Games take shortcuts" is really flattening the discussion and acting like the game developers don't know these things that the very smart blogger knows, when in reality, game developers know this stuff and make conscious design decisions. Most games are not designed to be scientific modeling programs, they're entertainment products, governed by questions about entertainment value, not simulation accuracy. Plus in real life you're not going to receive a network packet that says "a bullet whose trajectory will hit you in the skull will reach you in 0.7 seconds" and give cheaters enough time to auto-duck with a script. Even if you can afford to do collision detection on every bullet on every frame, there are many other reasons why it might not be a good idea. Hitscan is a design option, not something that's "right" or "wrong".

critics say that, but its viewership is low compared to other dramas. Usually when I tell people that it's one of my favorite shows, their response is that they've never seen it.

https://en.wikipedia.org/wiki/List_of_The_Americans_episodes...

https://en.wikipedia.org/wiki/List_of_Prison_Break_episodes#...

https://en.wikipedia.org/wiki/List_of_Lost_episodes

https://en.wikipedia.org/wiki/List_of_Game_of_Thrones_episod...

https://en.wikipedia.org/wiki/The_Last_of_Us_(TV_series)#Rat...

^ compare the viewership. The Americans was getting fewer than a million viewers in its final seasons, Lost regularly got over ten million. You can't easily chalk it up to just the fact that Lost was on network; The Last of Us was getting more than 10x the viewership of The Americans and it was on HBO. While The Americans is very critically acclaimed, it is not as widely watched as it really should be.

Go doesn't have a ? operator today, and the ? operator being used for error handling has precedence in Rust and Zig, so it doesn't seem to be all that out of the ordinary or without precedent in other languages.

there's some precedent in the direction of adding predeclared identifiers for error handling: the identifier `error` was originally not predeclared, you had to import it from `io` (or maybe `os`?) and refer to it as `io.Error` everywhere.

> The idea of opening another bank or broker, despite how simple it is

I would wager that there are a lot of people that have money in Vanguard because Vanguard provides their employer's 401k, and their choice was "Vanguard or no 401k", not "Vanguard or something else of your choice".

The argument that you are making is that a single entity controlling the pricing of a good is bad. That's not a counter-argument, it's the same argument. It's bad when a government does it, it's bad when an oligopoly does it. More than one thing can be bad.

are you asking about this specific piece or about art in general? Either way yes I disagree.

I don't know the author of this work. I don't know what they intended, so I can't comment on their intentions. I don't know if there's an "intended interpretation" or not, I don't know what that intended interpretation is, I don't know if it lines up with the interpretation you described. If the author intended for a specific, singular interpretation, I would reject that; any interpretation is just one of many. Some interpretations make more sense than others, and how a piece is interpreted can easily change from person to person, or even over time for a single person. Whatever you get out of it: it's true that that's what you got out of it.

you're looking at it from a framework that there's a "right" way to interpret a given piece of art, or that a given piece of art has "a point" instead of "a set of ways in which people interpret it". You're describing one way of interpreting it and then leveling a charge against the piece when, in reality, that charge should be leveled at that interpretation.

> Automating this art piece probably also says ... something.

if you do that you're not really experiencing it

https://orel.li/games/feedback/ here you go

> Linkedin is by far the most respectable social platform.

huh, that is … definitely not my experience of LinkedIn. My experience of LinkedIn is that it is a wasteland of hustle grindcore fake-it-till-you-make-it dipshittery.

package.json is specific to node projects, just can be used for anything. Why learn the quirks of something you can only use with a single programming language? I'm also a fan of the shebang recipes: https://just.systems/man/en/shebang-recipes.html

I dunno man I worked on a landscaping truck and on a pumping truck for the parks department when I was younger and we had plenty of free time to dick around. This was before smartphones so usually we'd play Hearts at the truck dispatch or park at one of the town beaches and just watch the water and read magazines or books. Walk past any roadside construction site and half the guys are playing with their phones; anything with cops standing around half of them are playing with their phones. Not sure how to tell you this, but blue collar jobs have downtime same as white collar jobs and they have the internet on phones now.

The first time I heard about it was from an Onion headline about it: https://theonion.com/heres-why-i-decided-to-buy-infowars/