That's interesting and actually the opposite of mine. I wonder if it's stack or methodology dependant? For reference I'm usually using cursor and opus4.6 and for a bigger piece of work:
- Start in ask mode - "I'm planning on doing X to achieve Y; are there any alternative approaches? What problems might I run into?"
- Chat for a bit and get the high level approach, switch to plan mode and ask for a nicely formatted plan
- What's kicked out is already in the rough shape of the discussion so far, so it's a case of following a nicely formatted doc through and highlighting sections of text and asking for clarification or changes
- Hitting "build" and then reviewing what's been done
For a new service I might spend an hour in ask/plan mode - but then it gets 95% of the build itself right first time.
Do you do the same with different results, or is there a different stack/methodology you go through?
I think the specific case of having a long conversation with an agent about what you're trying to achieve and why, and then have it update a README or a skill based on that conversation is a useful thing to do. Captured the context of the conversation without having to essentially write the same thing again.
That's usually because the system that runs those things is independent of the timing of the main game loop. And then when someone finally gets around to implementing the pause screen, they still run even with the main game time stopped. And you look at it and think "eh, you know what - looks cool - we'll leave it".
The reintroduction of Red Kites to the UK has been a huge success. I don't get particularly excited by birds normally, but regularly seeing such large creatures (almost 2m wingspans) curving through the sky is nothing short of majestic. They're almost reminiscent of dragons.
I wonder if I'll get to feel the same about golden eagles soon too.
It's fine, just not stellar. It was terrible (UX, speed, consistency) ten years ago. It's better now - mostly gets out of people's way and just works. It doesn't delight me.
I think there's definite scope for that being true; not because you can start doing stuff before you understand it (you can), but because you can ask questions of a codebase your unfamiliar with to learn about it faster.
Serious question: what are those things from windows 95/98 I might miss?
Rose tinted glasses perhaps, but I remember it as a very straightforward and consistent UI that provided great feedback, was snappy and did everything I needed. Up to and including little hints for power users like underlining shortcut letters for the & key.
Could you give a few examples? I'd lean towards adjusting tooling if you can.
My spelling is often horrendous and I know it - but almost every dev I know of prefers to copy and paste anything that might be misspelled just because it's easier than taking the risk.
Similarly - how does does this get anywhere near causing a production outage?
I'd be tempted to view this as a blessing in disguise; this person sounds like they'll trip up more often than the rest, but if one individual can cause a production outage with spelling mistakes something's gone awry with your processes elsewhere. You have an opportunity to fix whatever that is now.
Actually reaching a level of team culture where you can be as brief, blunt and to the point as possible is a wonderful thing.
There is no offence to be taken, because the deeply held respect for each other as team mates is already there and taken as a given. You trust each other to know that any comments are addressed directly to the code, rather than to the person behind them. All input is valued because everyone knows the goal is just to make the code better and help each other out, rather than criticise an individual. Discussion can be frank, open, unbiased and non-confrontational.
However, because that takes a long time to develop and is somewhat of a rarity, I've had quite good luck with the phrasing:
"Have you considered X here?"
It has a number of advantages:
* It doesn't imply that an author should have done it a different way
* It doesn't imply that an author has missed something you think they should have covered
* It's a good starter for a conversation, rather than a conflict
* If the answer is "no", it provides a good prompt for an author to come up with a suggestion first
* If the answer is "yes", they can explain why they ended up with the solution they did, which is visible to everyone who wants to look at the PR. That can also be a good prompt to add a comment
- Start in ask mode - "I'm planning on doing X to achieve Y; are there any alternative approaches? What problems might I run into?"
- Chat for a bit and get the high level approach, switch to plan mode and ask for a nicely formatted plan
- What's kicked out is already in the rough shape of the discussion so far, so it's a case of following a nicely formatted doc through and highlighting sections of text and asking for clarification or changes
- Hitting "build" and then reviewing what's been done
For a new service I might spend an hour in ask/plan mode - but then it gets 95% of the build itself right first time.
Do you do the same with different results, or is there a different stack/methodology you go through?