Claude logs the conversation to ~/.claude/projects, so you can write a tool to view them. I made a quick tool that has been valuable the last few weeks: https://github.com/panozzaj/cc-tail
I enjoyed this game! I have the ][ and played it on the "The Apple At Play" [1] disk (both are in the closet right behind me.) I think it actually might have been a different version than the one you have.
I made a handful of GPT "games" a couple of months ago, one of which was a Lemonade Stand clone. Can try it out at [2].
It does some interesting things around rolling random numbers in Python for the weather and it's nice that you can put in free-form text to say what you want to do for your actions. It's definitely more hackable than the original (good prompt security test.)
@jacquesm: I am curious how you approached charging for this project due to the uncertainty of what was wrong and how long it might take to fix it, and of the importance of this to the company. As you say, this may have saved the company. Did you work on an hourly / weekly / project basis? If you can talk about this, that is. Thanks for the writeup, this seemed like a great challenge!
Since you normally do due-diligence: at what level of information about the project would you be willing to enter into a no-cure, no-pay contract?
That seems like an insanely risky proposition on top of the risk you already assume through consulting, failing company, hiring colleagues as temp workers etc.
This was one on one three hour interview + some email follow up. Having done a lot of DD really helps though, it makes it easier to get the bigger picture clear in a hurry.
That said, there were quite a few details that made this project harder than it should have been.
Given that they were pretty desperate and had been referred to you on personal references, why did you agree to no-cure, no-pay?
Is it something they proposed or you? Seems like you could lose a lot and win little - and for them, the biggest risk was not your fee, but whether or not the system got up and running, so why bother?
It's a point of honour with me. Why send an invoice if it doesn't save their bacon? Better to align my goals with theirs. Make money with the customer, not off the customer is one of my mottos and that has worked well for me over the years.
Depending on the perceived risks and the degree to which things have gone to pot already, how realistic the deadline is and so on I'll be happy to adjust (both ways). In the end what matters is that they get value for their money and that I am compensated relative to value created (or saved).
Given that he works off reputation and recommendation, he probably won't want the reputation of getting paid for not fixing a system. The odd loss on a project now and then is probably worth less than the loss of recommendation, it creates a good feeling with the client, and I'm sure his risk analysis / due diligence before a project minimises the risk.
How detailed do you have to be on the 'cure' part? I can easily imagine some previous clients arguing the toss on something not being "fixed" to their satisfaction, and refusing to pay.
That's a really good question. If I feel that there may be a dispute over this then I'll ask for an escrow and detailed release instructions.
In all the years that I've been doing stuff like this professionally I've had one customer that didn't want to pay the full amount (they asked for a discount after the work was already done) and I told them to tear up the invoice but never call again. Everybody else was more than happy to pay. Maybe I've been lucky in that respect but I think that it's more of a way business is conducted here than anything else. You stand by your agreements, it's a small scene and word really does get around.
Personally, I want to do more stuff like this - I thrive in these sorts of projects, but haven't been able to find too many. How did you get connected in that 'small scene' to start with?
I'm working on a book talking about how to write effectively using Vim ("Writing With Vim"), sign up for updates at: https://leanpub.com/vim-for-writers. I need a few more weekends and it should be good to go. It's at about fifty pages right now and covers philosophy, basic customizations, things that are built into Vim as well as plugins, and will cover some publishing workflows.
Actually, I appreciate your comment. I (tell myself I) was not able to commit to publishing previously because I could not make much time to provide updates. However, I think 1) this was probably a cop-out 2) the next couple of months will be more open. I am going to remove some interim text and/or comment it out and then publish for half price or something like that. Thanks for the push!
Thanks rauljara and automach. I agree that the pie charts were probably not the best way to represent the data that was gathered. The questions could all take multiple answers, and I just summed the results to figure out how big of a piece of the pie each section would get. I made a quick edit to the post to clarify this. Thanks for taking the time to write that up, would appreciate any tips on how to better represent multiple answers per person per question.
True. I would like to have used a nice JS library or something so you could drill down better. Putting numbers on the charts would have been nice to get a sense of the actual sizes (especially on the ones with very small slivers.) Will keep this in mind for next time!
