Waiting for a few days of design review is a pain that is easy to avoid: all we need is to be ready to spend a few months building a potentially useless system.
How long have you been tracking? Can you share an insight you've had from your data?
I've been weight lighting for ten years and initially tried to track things (down to how many reps I did of which exercise, with how much weight) and quickly came to the conclusion that is want worth it for me.
I initially came to the same conclusion. Though I lifted in accord with decent training principles regarding reps and sets, I didn't track for years. As I entered middle age, I started keeping a training log (just one big org file in emacs), mostly out of curiousity. As I entered my 50s, I experienced what Haruki Murakami references in "What I Talk About When I Talk About Running" --- Fat is easy to gain and hard to lose. Muscle is hard to gain and easy to lose.
Now I track a couple of critical metrics and it's working great. I weigh first thing every day, track all kcals (even if I overeat), plan and track workouts. I write my own plans pulled from principles in these books (don't work for the company, just a satisfied customer) https://muscleandstrengthpyramids.com/
I don't use the vast majority of the info in those books as I'm just a hobbyist who wants to be healthy and strong.
The biggest shift came from learning I was doing waaay too much training volume at the gym while trying to lose fat too quickly; a fine recipe for injury. Now, when I'm in a fat loss phase, I try to lose it as slowly as possible while still making progress. Strength training and fat loss is a very long very slow marathon, not a sprint.
Perhaps paradoxically, the awareness that's come from tracking has helped me relax. No need to major in the minors; pretty good is pretty good.
The tools I use are a scale, loseit, and org-mode.
The goal in bodybuilding during a gaining phase is to be in a very slight calories surplus (200-300 calories above maintenance, at most) to maximize the amount of time you're building muscle before you need to cut again (bring calories back to a deficit to shed body fat).
Tracking scale weight is difficult because shifts in water weight and hydration can swing the scale 5+ pounds in either direction without any change in body fat. So I pair scale weight with a 7-point skin caliper measurements taken on a weekly basis, along with waist circumference, in order to infer whether body fat is trending up or down. And also take weekly progress photos of 6 angles/poses with consistent lighting, which I share with a coach.
And then you pair that with weighing and logging everything you eat, and you can make small adjustments to your meal plan on a monthly basis to try to stay in that 200-300 calorie per day surplus for as long as possible. (Although most bodybuilding coaches adjust diet based purely on how your physique is changing in weekly check-in photos without the need for measurements, but I like extra data)
> down to how many reps I did of which exercise, with how much weight)
I also do this. Track every exercise, every weight, number of reps. It's necessary for knowing whether you're progressively overloading over long periods of time. Progressive overload becomes harder to measure once you're past newbie gains because you can't increase weight every week, so some weeks the goal is just to squeeze out an extra couple of reps. Which adds up over time
This is obviously excessive for 99% of people. But I enjoy doing it as a hobby. I would absolutely not recommend this level of tracking for health reasons (not necessary) - I find enjoyment in the process.
I track the reps weights of every exercise (in my own app). But the historical values are only useful up to last couple of weeks just to now if the general trends go up and what is stalled. Unless your goals are the numbers themselves and not health, I don’t think there is a reason to track everything. But it is fun.
Thank you for your comment. I like Vonnegut (my favorite is Hocus Pocus) but hadn't read Bluebeard. I only started it and I'm already enjoying it significantly.
Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance.
Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.
APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.
Agree, that was exactly my reaction. What a terrible introduction, wasting many words on such platitudes as telling me that the idea isn't new but it isn't old fashioned either, or that they want to provide "some respite for those who feel the internet has been disrupted enough already."
Jesus, god forbid someone share their motivation for a project for longer than it takes for a tiktok to play...
The link to the FAQ and spec is right there. If you have the attention span of a fruit fly (many such cases) I personally suggest trying to fix it, not feeling proud about it.
If this were an utterly pedestrian """deep dive""" about some AI thing it could have rambled as much as it liked that there wouldn't be this comment near the top, I assure you.
Reminds me of a commercial where an artist attempted to convince their friend in excited terms how amazing their new masterpiece was, only to reveal its a blank canvas and they ran out of paint.
Wonder if you've tried spec driven development (as opposed to just prompting)?
I used to create requirement-oriented prompts and I felt something similar to what you describe. However, I've switched to generating parts of my source code from my specs in a semi-automated way and it made the process much more pleasant (and efficient, I think).
I wrote a bit about my current state here: https://alejo.ch/3hi - for my Duende project I generate 8821 lines of code (2940 of implementation, 5881 of tests) from 1553 lines in specifications.
I also started building my own, it's fun and you get far quickly.
I'm now experimenting with letting the agent generate its own source code from a specification (currently generating 9K lines of Python code (3K of implementation, 6K of tests) from 1.5K lines in specifications (https://alejo.ch/3hi).
Disagree. If some small adjustments to your workflow or expectations enable you to use LLMs to produce good, working, high-quality code much faster than you could otherwise, at some point you should absolutely welcome this, not stubbornly refuse change.
I see no reason to believe LLMs can write working let alone good or high-quality code, nor that the adjustments to my workflow or expectations will be small. But sure, if such a thing happened, I would probably welcome it.
Meanwhile, there are people who write good and high-quality working code faster than me, and they all write as much as possible on one line with the most bare-bones of text editors, so I will continue to learn from them, rather than the people who say LLMs are helping them. Maybe you should reconsider.
Somehow I don't think writing verbose English to communicate with an LLM is ever going to beat a language purpose-built for its particular niche. Being terse is the point and what makes it so useful. If people wanted to use python with their LLM instead, they have that option.
reply