The funny (not-so-funny?) thing is that reading this if I didn't know better, I'd figure we worked at the same company and I'm sure that most people reading this have a similar story. That's the sad state of the tech industry right now. The reins are controlled by a few at the top that seem to be exceptionally vulnerable to believing whatever AI slop is presented to them, whether it comes from AI or from their underlings.
It'll sure be interesting to see where this goes in the next year or so. The companies that have flamed out due to C* AI Psychosis. I'm sure the next set of "startup leadership" books will be around "how to avoid AI psychosis" and/or "how to use AI psychosis for fun and profit!"
Likely my own personal bias, but I have never once found git log/commit messages to be useful when debugging or understanding what happened. I'm sure that others do so I try to write useful commits (conventional commits syntax is helpful here) but I'd much rather spend my time and effort understanding the current state of the codebase instead of trying to diagnose how "fixed bug related to file naming" relates to a website going down.
I've been working on an idea for a logging proxy to track down where internal->external calls are coming from and optionally block them. Been using various AI tools as a way of both getting more comfortable with prompting and learning rust. It's been a fun project so far. Next steps are to figure out how to ease the integration/deployment process if someone wants to actually, you know, use the thing :D
Several things while I'm between full time gigs, working on learning rust for my own pleasure:
- Rust Lab Log (https://github.com/bryan-lott/rust-lab-log) a simple CLI to take down notes and timestamp them in a single markdown file. I was inspired by my dad's use of logbooks in chemistry labs growing up so that you can always look back and figure out what went right or what went wrong. Has come in very handy during a couple of incidents.
- LogProx (https://github.com/bryan-lott/logprox) a logging proxy with stupid-low added latency. We had an issue where we were accessing a deprecated version of an API and couldn't figure out where the calls were coming from. The API owner was threatening to turn off our access entirely (long story). The idea being LogProx is to send all traffic through it and create rules to log and/or block calls that match a ruleset. Added latency was so low that I had to drop down to measuring in tenths of a millisecond.
> you should probably take a step back and redefine what a PR is for your organization
I agree with this wholeheartedly if you are in a role that allows you to redefine what a PR is. In almost every organization that I've worked for, the PR is defined several levels above my pay grade and suggesting changes/updates/etc is usually seen as complaining.
May not be the most shiny/flashy thing, but I'm trying to figure out how to get out of burnout (adhd/autism/tech - all the varieties) without having to quit the world for six months.
Also, don't be afraid to revisit your favorite fiction and/or try young-adult fiction. IMO what you read matters less than building a habit or routine of reading.
I purchased the collection after reading this review. It was always a series that I wanted to read when I was younger but never did. Trying to get back into reading fiction again and this felt like a great place to start!
Just wanted to say thank you for working on this, I'm going to take another read-through of those 2 links and see if it makes more sense given the extra context of this thread. Either way, I look forward to reading the updates and seeing if they click better in my brainpan ;)
I suppose what I'm looking for is maybe a translation from git to jj from the perspective of working in a repo with other users that are using git. Something along the lines of:
1. init jj in an existing git repo
2. instead of branching, do x, y, z
3. instead of committing after changes are done, do x, y, z
4. when pushing, do x, y, z
5. if someone else pushes to the same branch, here's how to handle it
6. if someone rebases and force pushes the branch, here's how to handle it
7. if you have merge conflicts, here's how to handle that
I think I'm having a hard time trying to grok the jj "mental model" while simultaneously understanding how it translates to an existing git repo.
I suspect for jj to get traction outside of single devs or companies that use jj exclusively, some extra focus in the docs giving guidance in the liminal space between would be super helpful.
Not trying to hijack, but in addition, I'd love to know how we can fight back beyond just archiving data. HN tends to lean heavily into tech skills. How can we leverage those skills collectively or individually to prevent needing to archive this data in the first place?
Agree - in my 10+ year career, I've run into exactly 2 PM's that have provided enough value to a team or project to justify their inclusion in the team or project. Both were technical enough to understand what the engineers were working on and talking about and were able to offer genuinely good suggestions.
The rest? At best they were glorified QA/QC with a large stick to hit the engineers with when the spec wasn't met exactly. And when it was, and things still failed, they still hit the engineers with the large stick and were usually promoted for it.
Just wanted to say you've built an amazing product. So much so that I got my team hooked on it and am working on getting it out to the rest of the company that needs it. Well done!!
It'll sure be interesting to see where this goes in the next year or so. The companies that have flamed out due to C* AI Psychosis. I'm sure the next set of "startup leadership" books will be around "how to avoid AI psychosis" and/or "how to use AI psychosis for fun and profit!"