> we do need ways to stay mentally sharp in the age of AI.
Here's my advice: if there's someone around you who can teach you, learn from them. But if there isn't anyone around you who can teach you, find someone around you who can learn from you and mentor them. You'll actually grow more from the latter than from the former, if you can believe that.
I think there's a broad blindness in industry to the benefits of mentorship for the mentors. Mentoring has sharpened my thinking and pushed me to articulate why things are true in a way I never would have gone to the effort of otherwise.
If there are no juniors around to teach, seniors will forever be less senior than they might have been had they been getting reps at mentorship along the way.
I haven't heard this benefit for mentors clearly articulated before (probably just missed it), but definitely felt it - I guess it's a deeper version of how writing/other communication forces clarity/organization of thoughts because mentorship conversations are so focused on extracting the why as well as the what.
Interesting and semi-related idea: use LLMs to flag when comments/docs have come out of sync with the code.
The big problem with documentation is that if it was accurate when it was written, it's just a matter of time before it goes stale compared to the code it's documenting. And while compilers can tell you if your types and your implementation have come out of sync, before now there's been nothing automated that can check whether your comments are still telling the truth.
I once had a mad idea of creating an automated documentation-driven paradigm where every directory/module/class/function has to have a DocString/JSDoc, with the higher level ones (directory/module) essentially being the documentation of features and architecture.
A ticket starts by someone opening a PR with suggested changes to the docs, the idea being that a non-technical person like a PM or tester could do it. The PR then passes to a dev who changes the code to match the doc changes.
Before merging, the tool shows the doc next to every modified piece of code and the reviewer must explicitly check a box to say it's still valid.
And docstrings would be able to link to other docstrings, so you could find out what other bits of code are connected to what you're working on (as that link doesn't always exist in code, e.g. across APIs) and read their docs to find the larger context and gotchas.
Thanks for the pointer. That looks more to me like it's totally synthesizing the docs for me. I can see someone somewhere wanting that. I would want a UX more like a compiler warning. "Comment on line 447 may no longer be accurate." And then I go fix it my own dang self.
Ha, this is funny (also sad for me because I failed to explain on website clearly) because you have described exactly what it does as an example of what it can't do.
The core loop is more like a truffle-hunting pig than a ghostwriter. Promptless watches for signal that your product is behaving differently from the live documentation. It watches PRs opened/merging, Slack threads, support tickets. Then like a pig alerting on a truffle it shows up like "hey, this section over here doesn't match what the code/product does anymore."
Now of course we'll also generate a first draft of a suggested fix, but I want to say 40% of tech writers just like knowing when things changed.
Its a proper union find algorithm, where every suggestion links back to the source that triggered it, but multiple source do get linked up to just a single canonical suggestion. So you don't get duplicate alerts if people keep talking for weeks about a fix going out in the next release.
Obviously I've got some more work to do on the website again but c'est la vie.
"That's not true" is too strong a statement on your part.
The statistic you cite does not necessarily contradict what the parent comment is saying. "Up 29% since February 2020" is an absolute change since a specific point. The parent comment is saying prices have "come down" i.e. since their peak. It can still be up overall, so long as it's not up as high as it was at one point.
EDIT: To be clear, the parent comment might still be wrong, or might be right only within a biased sample (i.e. their own experience). I'm only making the point that the statistic you're referencing does not outright disprove what they're saying. Prices can be up since six years ago AND down since two years ago (random time periods chosen for illustration only).
Of course this is talking about the overall price level. The prices in specific sectors can fluctuate independently of that. Food and energy in particular are excluded from core inflation because they're especially volatile.
It's entertaining to me to imagine future historians arguing with one another, writing dissertations, publishing virtual reality eyeBooks, explaining to one another all about the ancient etymological connection between "claws" and "webhooks".
No need to defend yourself, I share this sentiment as well. If I'm going to spend time writing and reading a lot of code in a new learning language, I want my previous knowledge to be somewhat reusable.
For this reason I was able to get into Odin as opposed to Zig because of some similarities with Swift Syntax as well how easy it is to parse.
The less I need to rewire my brain to use xyz language, the greater the chance of me getting into it.
If my life depended on it, I could get over such a shallow reason to dismiss a language but fortunately it doesn't and that's why I write Swift rather than Rust.
When I was a kid learning BASIC, a lot of beginner examples in books used the (purely decorative) keyword LET for every assignment. Consequently I associate it with "coding like a baby who understands nothing" and still hate to write let to this day.
I am an S-exp enjoyer, and more for practical reasons than aesthetic ones—I really like the editor tooling that's possible with S-expressions. So I will absolutely choose a Lisp or a lisp if given the option, even at some level of inconvenience when it comes to the maturity of the language itself. I will always write Hy[0] rather than Python, for example.
The most machine-friendly syntax - and the least appropriate for our LLM overlords which get confused by parenthesis because they don’t see the structure.
This is an awesome project. Props to y'all for just making something you want to exist!
I have a Tizen-based Samsung watch (Gear Sport, 2017). It's served me faithfully but I'm starting to notice the battery degrading. I'd be interested in trying AsteroidOS with it, if Tizen support ever lands.
I really enjoyed this article—I meant to just read the first few paragraphs and skim the rest. I ended up reading every word.
The core thesis sticks with me: existing tooling that helps programmers think about and enforce correctness (linters, compilers, type systems, test suites) operate primarily (and often exclusively) on one snapshot of a project, as it exists at a particular point in time. This makes those tools, as powerful as they can be, unable to help us think about and enforce correctness across horizons that are not visible from the standpoint of a single project at a single point in time (systems distributed across time, across network, across version history).
I feel like the issue of semantic drift is a bigger topic that probably has roots beyond systems architecture/computer engineering.
Also I found the writing style very clear. It helpfully repeats the core ideas, but (IMHO, this is subjective) doesn't do so ad nauseum.
I'm interested in reading other writing from the same author.
> This makes those tools, as powerful as they can be, unable to help us think about and enforce correctness across horizons that are not visible from the standpoint of a single project at a single point in time (systems distributed across time, across network, across version history).
Eh?
I don't think there's something preventing you from constructing guardrails with type system & tests enforcing correctness that handles versioning.
I'm not buying the "unable to help us to think about" part. I argue that Rust's `Option`/`Result`/sum-type + exhaustive match/switch very valuable for proper error handling. You could define your own error type and exhaustively handle each case gracefully, with the bonus that now your compiler is also able to check it.
Here's my advice: if there's someone around you who can teach you, learn from them. But if there isn't anyone around you who can teach you, find someone around you who can learn from you and mentor them. You'll actually grow more from the latter than from the former, if you can believe that.
I think there's a broad blindness in industry to the benefits of mentorship for the mentors. Mentoring has sharpened my thinking and pushed me to articulate why things are true in a way I never would have gone to the effort of otherwise.
If there are no juniors around to teach, seniors will forever be less senior than they might have been had they been getting reps at mentorship along the way.
reply