ikerino

I mask as a coping mechanism for ADHD and Social Anxiety. This masking causes me harm. I learned it in the way you describe.

The most helpful learning I've gotten through years of therapy has been to: (1) recognize what I'm doing (2) not beat myself up about it (3) try small steps to change my behavior so that I can feel good about it.

I'm the only person who can unlearn this for myself. I don't blame anyone who masks, and have nothing but empathy for the experience, but I'm proposing they can find a different way.

I still think it's important to (1) notice what's causing the problem, bring it into consciousness (2) understand the behavior (in this case: masking) and reckon with it if if's causing a bad outcome (burnout.)

Easier said than done. For me, therapy has been life-changing for helping me notice and understand unintentional behaviors.

What helps:

- Challenging the idea that you need to mask to be successful. If masking is a recipe for burnout, then it actually seems like it's a strategy that will lower your chance for success. How much of the need here is self-imposed?

- Owning your calendar and timing for meetings to better suit your energy.

- Regular therapy and reflection, honestly.

- Regular exercise, doesn't matter who you are or what form, this is essential.

I can respect that this "simulation" fosters empathy, but worry that it also awfulizes/catastrophizes solvable problems. Figuring out functional routines and managing burnout is just as big a part of the job as writing code. It's very much a personal responsibility, maybe not in the job description, maybe harder for some than others, but it is our responsibility.

Repeat that a few hundred times and you'll have some strong intuitions and sensibilities.

They are entering the job market with sensibilities for a higher-level of abstraction. They will be the first generation of devs that went through high-school + college building with AI.

Have completed around a dozen chats with o3-pro so far. Can't say I'm impressed, output feels qualitatively very similar to regular o3.

Tried feeding in loads of context as suggested in the article but generally feels like a miss.

Not sure how I feel about it, but the the blog post seems very clearly LLM-written to me. Nobody writes like this:

> Revolutionary? No. Life-changing? Absolutely.

I think there's something to be said for efficiency/no wasted bytes, but better for the environment feels like a major stretch/beside the point...

It's like saying "if we all cut out unnecessary adjectives from our speech, it would save 100k gallons of water per day." Could that be true, maybe? But that's not the thing that makes brevity meaningful/important.

(or: Tongue-in-cheek joke that went over my <head>?)

Thought it was a weird bug.

Would love to read a perspective examining "what is the slowest reasonable pace of development we could expect." This feels to me like the fastest (unreasonable) trajectory we could expect.

> People who aren’t programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think “oh, gosh, how much harder could it be to make it actually work?“

If you lose 8 hrs to weirdness, but save 10 hrs somewhere else, then yeah it does pay for itself.

My argument is that it doesn't need to improve overall productivity much to have positive ROI. Whether you agree that these tools improve productivity or not is another question.

$100,000 / (50 weeks * 40 hours) => ~$50 per hour.

Extremely conservatively, if this saves a developer ~30 minutes per day, it pays for itself. If you spent $100 per day, it would still be worth it.

It also warns me it will auto-updates the software 1-2 times a month. My TV was perfect out of the box--it doesn't need an update. When I disable Wi-Fi, I get notifications that my TV is disconnected. Can't win.

I'm thinking back to various promises self-driving would be widespread by 2016. These set a certain expectation for how our roads would look that I don't think has been realized a decade later (even as I've ridden in Waymos/FSD Teslas.)

> This is slightly worse than last September, when Waymo estimated an 84 percent reduction in airbag crashes over Waymo’s first 21 million miles.

nitpick: Is it really slightly worse, or is it "effectively unchanged" with such sparse numbers? At a glance, the sentence is misleading even though it might be correct on paper. Could've said: "This improvement holds from last September..."

I'm using Cursor mostly for exploratory/weekend projects. I usually opt for stacks/libraries I'm less familiar with, so I think there's some optimism/uncertainty to account for there.

I think there's another aspect to progress involving learning/becoming fluent in a codebase. When I build something from scratch, I become the expert, so familiar that later features become very easy/obvious to implement.

I haven't had this experience when I take a heavily agent-driven approach. I'm steering, but I'm not learning much. The more I progress, the harder new features feel to implement.

I don't think this is unique to working with AI. I guess the takeaway is that attention and familiarity matter.

1. It feels like my AI agents are stuck somewhere circa ~2021. If I install newer packages or more recent versions, Claude will often revert to outdated packages/implementations that were popular four years ago. This is incredibly frustrating to watch and constantly correct for. Linking newer documentation or providing explicit instructions can mitigate the problem, but it doesn't solve it.

2. The unpredictability of these missteps makes them particularly challenging. A few months ago, I used Claude to "one-shot" a genuinely useful web app—fully featured and surprisingly polished—that would otherwise have taken a couple weeks to build. But, when I asked it to update the favicon using a provided file, it spun uselessly for an hour (I eventually did it myself in three minutes). This week, I tried to spin up another similarly scoped web app, and after ~4 hours of agent wrangling I'm ready to ditch the code entirely.

3. This approach gives me the brazenness to pursue projects that I wouldn't have the time, expertise, or motivation to attempt otherwise. Lower friction is exciting, but building something meaningful is still hard. Producing a polished MVP still demands significant effort.

4. I keep thinking about The Tortoise and The Hare. Trusting the AI agent is tempting because progress initially feels so much faster. At the end of the day, though, I'm usually left with the feeling I'd have made more solid progress with slower, closer attention. When building by hand, I rarely find myself backtracking or scrapping entire approaches. With an AI-driven approach, I might move 10x faster but throw away ~70% of the work along the way.

> These experiences mean that by no stretch of my personal imagination will we have AI that writes 90% of our code autonomously in a year. Will it assist in writing 90% of the code? Maybe.

Spot on. Feels like the self-driving car hype cycle where there are a lot of bold promises (and genuine advances), but I don't see a world in the next 5 years where AI writes useful software by itself.

Developers should aim to be resourceful and respect others time, but I expect my reports to seek out help if they get genuinely stuck for more than 15 minutes (no clue what to do.)

It's much better than waiting around for your manager to find out you were working on the wrong problems (or nothing, waiting for instructions.)