You can always use your own code however you want. However, if your project starts to get contributions from other people, that’s where it can start to become more muddy.

Oh layoffs are definitely happening. I’m just not sure if it’s caused by AI productivity gains, or if it’s just the latest excuse (the pandemic, then soft layoffs of “back to office” enforcement, and now AI). Esp since the companies most talking about AI productivity gains are the same companies that benefit from AI adoption…

What I wanted to explain is just that the skills to program actually translate pretty well. At my old company, we used to say “you know someone’s a staff engineer, because they only make PowerPoint presentations and diagrams, and don’t actually write any code”. And those skills directly translate to directing an AI to build the thing you need. The abstracted architect role will probably increase in value, as the typing value decreases.

My biggest concern is probably that AI is currently eating junior dev jobs, since what it excels at is typically the kind of work you’d give to a junior engineer. And I think that more gruntwork kinda tasks are the way that someone develops the higher level skills that are important later; you start to see the kinds of edge cases first hand, so it makes them memorable. But I feel like that might just be a transition thing; many developers these days don’t know bare code down to the 1s and 0s. The abstraction might just move up another level, and people will build more things. At least, this is the optimistic view. 🤷 But I’m an optimistic guy.

mmm so I’ve only used the online models for agent coding, since I’m on a laptop and lack the hardware, but my understanding is that local models like devstral and llama are relatively competitive and can be used on like… a gaming rig? I don’t think they’d be able to push the price that much.

But I don’t disagree that big companies will try their darnedest to.

I think the biggest difference between this and blue-collars workers losing their jobs, though, is that the same people losing their jobs are also placed very to benefit from the technology. Blue collared workers losing manufacturing jobs couldn’t, because they were priced out of obtaining that mafacturing hardware themselves, but programmers can use AI on an individual basis to augment their production. Not sure what the industry will look like in 10 years, but I feel like there will be plenty of opportunities for people who build digital things.

That being said, people who were looking to be junior developers exactly right now… uhhh… that’s some extrememly unlucky timing. I wish you luck.

So this is *mathematically correct, but practically not really. Let me give you a longer (but still simplified) answer. There’s essentially two things here that are different:

1. Does a longer password make your password more difficult to guess? (always yes)
2. Does a longer password make accessing the content it protects more difficult (yes, to a certain point).

The reason for #2 in digital systems is because of hashing, which is used to protect your password in the case of a data breach. Essentially, you can think of a hashing algorithm as a one-way algorithm that takes an input, and then always returns the same output for that input. One-way here means that you can’t use the hashed output to reverse-engineer the originally inputted password (you can’t unhash a hashbrown into the original potato 🥔). This is why if someone hacks Facebook, they don’t necessarily have your Facebook password; Facebook never saves your actual password anywhere. To login, the website hashes your password input, and compares it against the hash that they saved from your original password creation.

Usually, the result of these algorithms is saved as a fixed-length string of characters. And so your data is mathematically not more safe if you exceed this length, since a random password combination can theoretically resolve to the same value as your super-long-password. This would depend on the algorithm being used / data being stored, but for example, bcrypt outputs a 184-bit hash (often represented as a 60-character string). So mathematically, your password is not more secure beyond 60 characters.

However in practice, this is a non-issue, because I think that basically the only way that collisions like this are useful are for brute-forcing a password? And the chance of a password collision in this way is something like 10^27-or-28 (being hit by lightning every day for 10,000 years)? The much easier solution for gaining access is to get your actual password. So if your password being longer makes it harder for people to guess, I’d say that adding security by way of #1 is still extremely valid.

tbf, I don’t know how feasible it is to remove asbestos without employing 4 year olds.

Or Majora’s Mask but with wave dashing

I don’t know what I expected when I started scrolling through comments, but I certainly didn’t expect "how long humanity has survived depends on how you define ‘people’ "

Mmm it sounds like you’re using it in a very different way to me; by the time I’m using an LLM, I generally have way more than a general feel for what I’m looking for. People rag on ai for being a “fancy autocomplete”, but that’s literally what I like to use it for. I’ll feed it a detailed spec for what I need, give it a skeleton function with type definitions, and tell the ai to fill it in. It generally fills in basic functions pretty well with that level of definition (ymmv depending on the scope of the function).

This lets me focus more on the code design/structure and validation, while the ai handles a decent amount of grunt work. And if it does a bad job, I would have written the spec and skeleton anyways, so it’s more like bonus if it works. It’s also very good at imitation, so it can help to avoid double-work with similar functionalities.

Kind of shortened/naive example of how I use:

/* Example of another db update function within the app */
/* UnifiedEventUpdate and UnifiedEvent type definitions */

Help me fill in this function

/// Updates event properties, and children:
///   - If `event.updated` is newer than existing, update as normal
///   - If `event.updated` is older than existing, error
///   - If no `event.updated` is provided, assume updated to be now()
/// For updating Content(s):
///   - If `content.id` exists, update the existing content
///   - If `content.id` does not exist, create a new content
///   - If an existing content isn't present, delete the content
pub fn update_event(
    conn: &mut Conn,
    event: UnifiedEventUpdate,
) -> Result<UnifiedEvent, Error> {

100%. As a solo dev who used to work corporate, I compare it to having a jr engineer who completes every task instantly. If you give it something well-documented and not too complex, it’ll be perfect. If you give it something more complex or newer tech, it could work, but may have some mistakes or unadvised shortcuts.

I’ve also found it pretty good for when a dependency I’m evaluating has shit documentation. Not always correct, but sometimes it’ll spit out some apis I didn’t notice.

Edit: Oh also I should mention, I’ve found TDD is pretty good with ai. Since I’m building the tests anyways, it can often give the ai a good description of what you’re looking for, and save some time.

Oh nonono don’t worry about me! I’m just exaggerating and making up a dramatic story. Started writing and got carried away a little bit 😂. Luckily for me, I was always on good teams. But I did work in big companies long enough that I’ve definitely seen variations of this kind of thing play out.

Anyone got store recs for non-english books? Or that mostly just gonna vary a ton by language?

Wish granted. Now management questions why everything “takes you so long”, and you were passed up for promotion in order to promote Jim (just last week, he did a presentation about his new feature that uses fancyAssDB).

Don’t worry, though. They’ll need your help soon, in order to make Jim’s fancyAssDB pet project sync with the oldAssDB legacy server (which is a completely different User/id structure. TBH might need to refactor most of Jim’s code to fit. Have fun extending all of Jim’s hardcoded features). He quit the company to join a crypto startup. Still no promotion though, since you finish stuff kinda slow (I mean, Jim built it in 2 weeks, so it can’t be too complicated).

EDIT:

So now I hear you thinking “well at some point, they’ll notice how much better my code works, and that features are much easier to integrate”.

But don’t worry, because the next month, your manager will be promoted to head of a new department and forget you exist. Meanwhile, the new head of your department doesn’t know you, and is thinking of promoting Frank.

While you were fixing Jim’s code, Frank added some features to your old project using fancyAssLib3 to save some time. He’s doing a presentation on it tomorrow, and management is very interested, because they haven’t heard about this code yet. It’s Frank’s codebase, right? I mean, he’s doing a presentation on it.

This is something I definitely needed to know about

Two. Depending on the situation, maybe two shots, two coffees, two decafs, or two hours.

But definitely not after 2pm. I need to sleep later.

fwiw I don’t think 4-6 shots is too far out of the norm if not daily. Double-shots are not uncommon, and 2-3 of those on occasion seems rather reasonable. I just would hope you drink a good amount of water the rest of the day. Now if you mean that you downing 6 double-shots… are you Dan Campbell?

I don’t ever use a dishwasher, so I have no idea what works in those things 😂

Fwiw, this was also on HN yesterday. Never tried it myself, though:

https://news.ycombinator.com/item?id=39941232

^ fwiw, I have one of these, prefer lighter roasts, and prefer the taste of paper filters. So checks out I guess. I do like the fabric filter, though.

I use something similar that I bought in Taiwan as a backup to paper filters, since I am often traveling and can’t always find v60-style filters. Some thoughts:

• It can be annoying to clean
• When I want more than a rinse, I wash it extra by boiling it in tea; that seems to work well.
• It does have a bit of a different flavor compared to paper. As a light-roast drinker who grinds with a Timemore C3, I prefer paper for taste. In the James Hoffman vid other people linked, he describes it as “extra richness and body” for light roasts, but I kinda describe it more as “clouding some of the bite and clarity”. It’s definitely still quite good, and I still prefer the cloth over French press.
• I do find it quite convenient for my use as a backup to paper filters in my “ultra-portable” setup.

Pictured here with small *PAT Tetradrip. A proper v60 is 100% better taste than the Tetradrip; but it’s a really convenient foldy-size.