Hey, author here. You should definitely share your experience!! We really need to study more success stories so we could figure out what makes them successful.

If it's possible I would highly encourage your company to publish something about how you work and what you think you're doing right.

I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.

Or put differently: code as a means to an end vs code as the end. You need both types, the ratio changes as things change, neither is The Way.

While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them.

I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers.

And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here.

Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that.

Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.

That's a pretty good frame and makes me hopeful. Now it's even more important to figure out how on Earth we can promote expertise formation in the age of AI

I'm fairly certain a lot of people do this. They don't literally take a day off, but just work fewer hours or less hard. And this makes sense, there is a strong incentive to not give away all the productivity gains to your employer.

I'm fairly sure that if a compiler stops working or has a bug, the expectation is that an engineer is capable of handling it in some way. I don't think any stakeholder will have much sympathy for "compiler stopped working, we can't do our jobs now" argument.

this is beautiful

these are all surprisingly specific questions that can actually be answered!

1. It's dynamic 2. It's compiled 3. Elixir script is just a file with Elixir code that compiles and runs right away 4. I've been writing Elixir for 7 years and barely know any Erlang. I even submitted bugs to OTP team with reproductions in Elixir, they're chill. 5. Preemptive scheduler, immutable data

Yeah I’ve been doing elixir professionally for maybe 10 years and have barely written any Erlang, maybe a dozen lines.

> If it’s slop or they have incorrect information in the message, then my bad, stop reading here.

"my bad" and what next? The reader just wasted time and focus on reading, it doesn't sound like a fair exchange.

That’s on them, I said what I wanted to.

Most of the time people just like getting triggered that someone sent them a —— in their message and blame AI instead of adopting it into their workflows and moving faster.

That mentality is exactly what is reflected in AI messages: "not my problem I just need to get this over with".

Those types of coworkers tend to be a drain on not just productivity, but entire team morale. Someone who can't take responsibility or in worst cases have any sort of empathy. And tools are a force multiplier. It amplifies productivity, but that also means it amplifies this anchor behavior as well.

So I'm ESL btw... maybe I should have run my message through AI lol.

I was replying to THAT person, and my message was that IF the person they're dealing with who uses AI happens to be giving them constant slop (not ME!!! not my message) THEN ignore what I have to say in that message THEREAFTER.

So if that person is dealing with others who are giving them slop, and not just being triggered that it reads like GPT..

I can see the similarity yes! Although I do feel like the distance between handwritten letter and an email is shorter than between email and LLM generated email. There's some line it crossed. Maybe it's that email provided some benefit to the reader too. Yes, there's less character, but you receive it faster, you can easily save it, copy it, attach a link or a picture. You may even get lucky and receive an .exe file as a bonus! LLM does not provide any benefit for the reader though, it just wastes their resources on yapping that no human cared to write.

This feature predates LLMs though, right? Funnily enough, I actually find it hilarious! In my mind, once they introduced it, it immediately became "a list of things NOT to reply if you want to be polite" and I was used it like that. With one exception. If I came across an update from someone who's a really good friend, I would unleash full power of AI comments on them! We had amazing AI generated comment threads with friends that looked goofy as hell.

> This feature predates LLMs though, right?

LLM dates back to 2017, Google added that to internal gmail back then. Not sure when linkedin added it so you might be right, but the tech is much older than most thinks.