Bug fixing and preparation for code release mostly. Making notes about future features and refactoring. Experimenting with embedded Lua.
I’ve tried this approach. It’s great if you don’t mind the small (but sometimes annoying) delay, and if you want to format your own contributions. But one problem is that if your are collaborating, the hooks don’t get cloned, and so the other team members may not be also doing this. You’ll be the one doing all the corrective formatting. What you thought was a one-line fix, isn’t.
But worse than not knowing if the other folks are doing this, is whether they are using the same formatting configuration. If that differs from yours, you’ll end up in a format fight with elevated churn.
There are no formatting configurations. All Go files are formatted identically; it’s a feature.
Ah, then that negates my second point. Did not know that.
I use Dart at work, which also has a formatter (though it IS configurable). We have our CI run a check to ensure the formatter has been run and the build fails otherwise. This means that master is always correctly formatted, which is nice.
Have people used this and/or taskwarrior? I’ve considered using it, but never tried.
I used taskwarrior in the past at previous $work to help me grok the amount of management bullshit I had to track while being team leader. It has built-in burn down charts and a ton of features that come in handy while remaining a normal CLI app. It’s a similar feeling you have when you start using ‘ledger’. Suddenly you have a pretty versatile, flexible tool that is there to just this specific task without a fancy GUI that slows you down.
Taskwarrior and org-mode are pretty much at the top of my todo management utilities.
Not many are using this yet, partly because it has not been released, and partly because no one knows about it. It should be released around the end of the month, at which point it should be stable enough to recommend. But not yet.
Disclaimer: I wrote it.
I agree with the README-driven approach. As soon as you start imagining interactions, all kinds of questions arise, and the high level design can adapt to changes very quickly - much more quickly than code. Taken a little further, the longer you defer writing code at all, the better the result tends to be.
I like to start with a set of text files. Describe what the project is, and is not. One might contain data format, another some objects I think are needed, another with some process flow and so on. If I can keep all those consistent with each other while incorporating various ideas, the result is a specification, or as close as I want to get to one.
You’ve described a process that is eerily close to something I’m trying right now.
Worst case, if I get bored of this project, I can shelve it and come back to it later and the docs will help me onboard myself again.
I usually write out a design on paper (I love paper) with lots of lists and diagrams/flows. Then I do classic test driven development. Then I write out a readme based on what the API now is, that is the step I hardly ever/never get to in my personal projects (Good luck to people trying to use my projects and sorry!).