> Interviews are useful, but the ability to ship, maintain and improve real projects should probably carry more weight.
But how do you assess this? Maybe we should get them to write a document that details what they've done, and then invite them to a conversation to discuss it.
The best thing I learned about SQL is that it can do an awful lot of clever stuff but that the vast majority of the time you really don't need it. Learn the basics. Shrug the rest off.
This is the correct way. Much like any other kind of code, if you find yourself doing something "clever" it's time to think about whether you're really going down the right path.
You don't have to get very clever. Once you get beyond inner join it starts to stick out like a sore thumb that SQL isn't relational and that you should have chosen a relational engine instead. SQL shines when you have an ORM and need a reliable backing store, though. Tradeoffs, as always.
Postgres was relational for the first decade of its life, until the infamous '95 release when it sold its soul to the devil. You could dig up on old version, perhaps. But, yes, the tradeoff for real-world use was already mentioned.
The relational model is superior as complexity grows (although arguably the deductive model is even better), but the tablational model is superior for simple line-of-business stuff, so pick your poison. Like with all things engineering, there is never one perfect solution that satisfies everything. If, like the earlier comment suggested, you keep your SQL simple then you'll be fine.
I actually hung out in their IRC for a while hoping to maybe form a social connection and then get an invite, but somehow it just never materialized, and the chat wasn't engaging, so I stopped coming back...
It's a good point, but I think the counter is that if the only people writing anything available via Gemini would have written nice simple HTML anyway, then not an awful lot is gained.
Sure, authors can adopt Gemini-like restrictions on their own simple HTML pages to gain some of the benefits of publishing with Gemini.
But this ignores the benefit for readers. Simple HTML pages are one link, search, or change of management away from a sea of enshittified internet slop. But Gemini capsules never have banners, unwanted sounds, intrusive ads, popups, etc, making browsing gemspace a qualitatively different experience.
To use a metaphor, a gardener can plant the same flowers alongside a loud, busy, trash-strewn highway as they can in a quiet garden. Many more people will see the flowers along the highway and it's a wonderful contribution. But wandering amongst the flowers in a peaceful garden is a qualitatively different experience than doing so alongside a busy highway.
You could defintiely argue abductions and crime have reduced because there are fewer opportunities (because we keep the kids safe). But that still doesn't mean you can conclude the world is MORE dangerous.
Well, you could conclude the world is now more dangerous for any kid let wander - even if fewer do, and even if the observed average risk to any kid is lower (given they are allowed wander a lot less).
I don't want to be on the 'overprotect kids' side of the argument, but I'm not sure the numbers argur cleanly in one direction or the other.
I also often think of selection bias whenever anyone says "I was allowed do a lot more and we were fine" in the context of child safeguarding; because it also sounds like a lot of kids were abused in the past, who don't speak up in that conversation.
I don't know. I worry I overprotect my kids, but I also am not sure how to price in small risks of massively negative events. I think that's the crux of it for parents - trying to weigh hard tradeoffs.
Software development is expensive. Like eye-wateringly expensive. A team of developers, product, designers, testers on a new app costs a big amount of money so its a gamble each time.
Without a large audience, spending money on porting to AVP is either money down the drain or a bet on a large audience coming along soon.
> Part of the reason, may be that I am a much better Swift programmer, than PHP programmer
Hard not to think that's a major part of it. IME you make loads more corrections in languages you're more opinionated about (and opinionated usually follows more experience & confidence).
I correct AI Python all the time. When it cranks out TypeScript I just check it works.
Yes and no. I have been working with PHP for over 25 years, but I've never loved the language. It's always been a "necessary evil." I know it fairly well. I've only been writing Swift for half that time, but I like the language, and play with it more.
I feel that the reason posited by another poster is more likely. There's a ton of mature, well-written, shipping, PHP out there, due to the open nature of most PHP, as opposed to Swift; where the more robust and mature implementation is likely behind proprietary walls. Most of the public Swift that I see, tends to be folks showing off its fancier features, in relatively small code samples.
The friction they should have probably had here is: did this employee need access to 3,800 internal repos?
I'm with the poster above in believing restricting what you can install makes a lot of things more difficult, but if you're going to take the risk you should be limiting the blast radius.
But how do you assess this? Maybe we should get them to write a document that details what they've done, and then invite them to a conversation to discuss it.
Oh wait...
reply