I'd argue that is a better foundation for coding big projects. Since you weren't doing the coding, you could focus on what can be and should be, instead of what is easy.
I've struggled to learn how to specify things, since I started just kinda coding by the seat of my pants. It served me well when I was young. I could hold more in my head at once and my projects were small.
But now I code in circles. I work on part A until I realize that I can't finish till part B is fully specified so I switch to working on part B, but that needs part C which needs D but D depends on A.
By the time I come full circle the code I had for A no longer makes sense.
The up shot is that I've stopped coding altogether, to try and learn some of the skills you have. I am not even using a computer most of the time. I am writing specs by hand.
I make sketches on paper. Use case diagrams and state cycles and stuff. Really high-level. And then I type out user stories and then Gherkin scenarios.
And then I give the Gherkin to AI and have it code it and then I spend a week crawling through the code and straightening it out and torturing nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn with code reviews because he's like Svelte AI. 😂
The end result, from the application logic, is very good, but the coding phase is a shitshow. Unless it's PHP. Only language I can just type out.
Most of the logic is already in the diagrams.
It's interesting to watch application logic and the code logic drift apart, over time.
I knew it should do that, if you're any good, but I've never watched it happen.
Thread collapsed
Hmm, I need to figure out this "user stories thing" I always sounded like crappy rationalization for things the party making the application wants and have nothing to do with the customer.
I've never actually seen a user story but from the results I imagine they go something like.
"As a user first arriving at the website, I'd like to see a bunch of platitude laden marketing gobblty-gook that is as inoffensive as possible."
Or
"As a user, I'd like a sales rep to contact me some day to determine how much I can afford to pay for whatever it is that you actually do."
It always seems that the customer stories they invented serve the interest of the business.
Here's a quite complex user story, with a second user story packed into the same ticket (naughty, but made sense, in this case). You can see the Gherkin feature, following that.
https://onedev.gitcitadel.eu/Alexandria/gc-alexandria/~issues/248
For the Great Unwashed, who don't have access to our OneDev:
> As an event publisher, I would like to have the ability to delete events that I have written , so that my feed isn't full of test events or incorrect events or outdated events.
> As an event publisher, I would like to be able to delete my entire Nostr presence persistently, so that I can take npubs I want to retire out of circulation.
Thread collapsed
Thread collapsed
Thread collapsed
yeah, i find when i ask junie to write code to change things it often just piles on more crap instead of changing stuff. very often i wind up rewriting parts of the code and if it fails to actually debug shit and make tests pass, after 3 times i just usually end up writing the code that was needed by hand. and then, of course, the tests pass because it was written the right way.
they can sometimes save a lot of work but sometimes make more work. learning how to avoid those potholes they fall into is a key part of making the work more efficient.
Half of it is frequent commits, so that you can quickly revert and start a new chat. Never spend more than 5 minutes on one solution.
yeah, absolutely, when i am writing the code, i might pack more into one commit, but generally best to avoid big commits. the bugs >_<... wasted quite a bit of time yesterday on big commits with new bugs or regressions.
Thread collapsed
Thread collapsed
Thread collapsed
As I see it, we're in a period of "just ship it". We gotta get stuff out the door, and Stella, armed with AI, can do that very rapidly.
Once we get the application to behave the way we want, we can start writing tests to lock in the behavior, then refactor the internals to make it more maintainable and more efficient.
Regarding Svelte, I've spent about a year now reading those docs over and over again...it's all in my 🧠
I'm like that with the NIPs. 😂
Thread collapsed
Thread collapsed
Thread collapsed
