Right. I’ve been known to open an issue and move on with my life. That’s not nothing, as far as contributing to FOSS.

Only the time I took to play around with FOSS options, which is fine for a hobby. There are actually really good options out there, they just don’t match my needs.

In concept, absolutely, but I tried and didn’t like.

I’d say the desktop offering is the main thing, but moving further into the cloud could be an interesting move on the subscription journey. Not interesting for me, as a user, but as a concept and an investment for the company.

[raises hand] I’ve used MatLab instead of Photoshop, I guess.

Seriously though, as an amateur photographer, working on a new engine instead of just adding more gen AI features to every pixel sounds like a good move. I’ll be sticking with my buy-once option, either way.

As a developer I also found this interesting:

Can make steady progress even when a problem is ambiguous or not fully prioritized yet

That’s a super important skill a lot of people don’t even want to develop.

Surely through an intermediate - real - language?

I’ve said this before only to hear “we don’t have time to set that up and agree on a common style” and “that’s team B’s responsibility since we’re contributing to their code base.” Guess what kind of issue we kept wasting time on?

There are a couple of takeaways here. I think the main one is acknowledging that many technical problems are deeply human problems and the existence of a technical solution doesn’t mean we shouldn’t apply the human solution as well.

Common criticisms here would be that these endeavors stifle creativity and show the adoption of modern solutions. That said, I find conducting “code archeology” to figure out the idiomatic way of doing something in an old project very rewarding. Because computer programs exist in people’s mind’s, doing that with the support of original developers or subject matter experts is some of the most effective knowledge transfer I’ve ever witnessed.

That totally threw me off. “Literally unplayable,” as they say.

Sounds like you may be interested in a certain manifesto.

Don’t mind me, I’m just picking the very best grains of sand to make my own silicon, like a real programmer (xkcd).

There’s a lot to talk about from this point alone, but I’ll be brief: having gone through university courses on processor design and cutting my teeth on fighting people for a single bit in memory, I’m probably a lot more comfortable with that minutia than most; having written my first few lines of C in 10 years to demo a basic memory safety bug just an hour ago, you’re way way ahead of me.

There are different ways to learn and gain experience and each path will train us in different skills. Then we build teams around that diversity.

We’ve all read this post multiple times. Isn’t it just the “young people are lazy” that’s been going around for thousands of years?

https://historyhustle.com/2500-years-of-people-complaining-about-the-younger-generation/

At most it’s a tangent on it…

I’m shocked and appalled! Isn’t the whole point of using Rust to prove you’re a better developer by using an extra hard language? At least that’s what I like about it.

I’m kidding, of course. Whoever has never copied and pasted code they didn’t understand from Stack Overflow can go ahead and complain about using a local LLVM.

Ultimately, what makes a good developer includes understanding and being really good with the tools they use, but the biggest impact comes from identifying problems and asking the right questions to solve them.

If you’re interested in learning more about SQL, throwing EXPLAIN at your query and the AI’s version may be really interesting.

I’m usually perfectly happy trusting my ORM, but even then it’s really helpful to dig a little deeper to figure things out, both in development and in production.

I’m inferring based on the deprecation of YEAR(4) and the conversion time window that obviously needs to be updated at some point.

To answer the part of your question I think is most fun, there is a standard for SQL. There are many dialects of SQL, but you’ll often hear of “ANSI SQL.” The latest version is SQL:2023.

Looking at the MySQL manual entry for the YEAR type, I think we can conclude two things:

1. The developers consider the possibility of deprecating and removing support for time data type features;

2. They use “reasonable defaults” for conversions of 2 digit years, based on the current year.

The good news is it sounds like this issue is being taken into account. I’m sure the conversion window will be adjusted in future version and the data type may be changed or deprecated altogether. I wouldn’t be surprised if they added a YEAR2 though. T-SQL has a datetime2, after all.