In search of "get better at writing about projects by writing about projects"...
I think, or I'm currently thinking, that my general aspiration in writing project log entries for HaD-hosted projects is to report a traceable evolution of how what is came to be. Maybe because I've enjoyed reading that kind of write-up by others about the things they do. As distinct from point-in-time description, to some greater or lesser depth, of ... something.
"Traceable evolution" looking something like:
{this}. because {that1}, and {that2}, and ..., and {thatn}.
where {that} can be
- sufficiently described, or
- insufficiently described, prompting "but why {that}?", or
- insufficiently described, because I know that {that} was the outcome of its own sub-adventure that seems like it should have a place in the story, and won't get in there if I don't write it, and no one will ever even know it was missing because the absence doesn't prompt "but why {that}?", or
- assertion fails
Then all the {that}s that were insufficiently described become new {this}s until all the {that}s are sufficiently described. Sometimes that's not too hard. Occasionally that can get to be a bigger tree than my meager writing proficiency can traverse, with no end of branches in sight. Or worse: a graph that isn't a tree. Of course reality never really fits that model but let's pretend for a moment.
In case you've read this far and it's not already obvious: I'm struggling to log some {this}s with large and interconnected {that} graphs. I've studied or worked with lots of people who could probably blow right through this. In other words, I'm trying to grow a new arm.
One "easy" answer is to just prune the tree. Especially the branches whose absence won't leave a self-evident hole in the canopy. But then if I've put some effort into working out some bit of history, I don't want to "waste" that effort. Because sunk cost.
It's also possible that I could use a broader view of what publishing work in progress is all about.
...
One concrete goal is to publish anything I'm doing that might be actually novel. Because "Publications obtained via the Wayback Machine® are prima facie deemed to be publicly accessible at the date and time provided in the time stamp" per USPTO. I get that "intellectual property" is complicated. In my narrow view of the world, I think too many patents are sought and granted for stuff that shouldn't be patentable. I don't expect to stop dumb patents but, to the extent that anything I'm doing is actually novel, maybe I can make it easier to defeat a future patent that shouldn't exist.
That's different from "story telling", but also motivates describing how a thing came to be, describing an idea more generally than the particular example, and describing solutions found but left behind.
Paul McClay
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
the link doesn’t work. it just opens discord it doesn’t invite me to the server
Are you sure? yes | no
Hi Mark. Is this the page you meant to ask about? The "USPTO" link here points to a static page of an external site.
Are you sure? yes | no
You're overthinking this. Decide what purpose your log will serve, whether it's to provide reproducible steps, relate a personal experience, or entertain the reader, but don't try to mix styles, or it'll be a mishmash. To forestall patents giving a sequence of steps is the best since that's what a patent discloses. Also, less is more. Let the reader discover things via hyperlinks if they care. You can also hive off digressions into other logs, just like when a software routine gets too long it deserves subroutines.
Are you sure? yes | no
Yes to all that! (maybe a little tolerance for mixed style/mishmash within an evolving project).
... And I'm well accustomed to watching peers do it better and/or more efficiently. [biography omitted] am here working from saying 'yes to all that' to, or toward, competence. And, indeed, using this project to 'hive off' whingeing about the process.
Are you sure? yes | no