mystickphoenix

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!"

For this use-case, maybe compression and then encoding would get more data into the URL before you hit a limit (or before users complain)?

I.e. .md -> gzip -> base64

for me it's Liquid DnB, anything by Liquicity is amazing, especially their year mixes and the couple that Maduk did on youtube during the pandemic

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

https://github.com/bryan-lott/logprox

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!

The concept of "learning styles" has a pretty large mountain of evidence disproving its validity. Just a quick sample from wikipedia: https://en.wikipedia.org/wiki/Learning_styles#Criticism

While it may be a marketing gimmick, it immediately turned me off.

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.

Something that I've been struggling to wrap my brain around is:

1. Can I use jj inside a repo that was already initialized with git? I think the answer is yes, but I haven't found a tl;dr for it.

2. What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for?

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!!

Currently use markdown files + dropbox for sync. I can't seem to stick with a single notes app for any appreciable length of time but having files in plain text makes it easier to switch.

Currently using:

- Obsidian: this one has stuck the longest

- iA Writer: really pretty, seems to be more useful for longform

- NeoVim: I live it in anyway... may as well

- rlg: my own "dump thought to single file w/ timestamp" rust app), very janky, written specifically for my own use-case, standard "there may be dragons here, might eat your computer just for fun, etc" - https://github.com/bryan-lott/rust-lab-log

Taking the opportunity to plug my favorite blog post ever:

"the truth is everything is breaking all the time, everywhere, for everyone"

https://www.stilldrinking.org/programming-sucks

Add another vote for mise. For me it replaced asdf, pyenv, poetry, and direnv. Biggest thing for me is it _just works_:tm:.

Someone else already mentioned Autism and ADHD, possibly a combination. Those would be my first guesses. Another one is potentially migraines. They aren't always "a bad headache" as they tend to be portrayed but can run the gamut of symptoms. From nausea, to sound/light sensitivity, to temporary blindness, or actual pain.

Definitely sounds like something you'll want to investigate with a doc, assuming you have access to one. Biggest thing is if possible, shop around until you find someone who actually seems interested in what you're experiencing and doesn't dismiss your symptoms.

I use Amethyst https://github.com/ianyh/Amethyst in my day to day. Slightly different management philosophy but one that works well for me.

Reminded me of a tool that I created and use daily (and that I need to get back to adding some functionality to!) Among the things I need to do are... add a readme! But it's a low friction (for me) way to keep a log of what I've done. Basically just a digital notebook, inspired by the lab notebooks I saw whenever I went to my dad's chem lab when I was young and what we like software to do when it changes something. Keeping a record of what you've done has been incredibly helpful for me and I've gone back and referenced it many many times.

I happen to write in an obsidian-friendly markdown syntax but it's not enforced. Day and year headers are added automatically and each entry is timestamped.

https://github.com/bryan-lott/rust-lab-log

I reread this every so often to remind myself as a software engineer that yes, we're all crazy, we're all driving ourselves a bit more crazy all the time, so give myself (and my coworkers) some grace.

https://www.stilldrinking.org/programming-sucks

For me learning Rust isn't about "OMG this is my #forever-language", it's more about presenting me with a new way of thinking about and through problems. I code 99% in Python at my day job and when I made the effort/struggle to learn Clojure a few years ago it fundamentally altered how I think about problems. This is the same result I'm looking for from Rust. Basically just adding more tools to the mental toolbox.

If you haven't already, I'd add Nonviolent Communication to that already very good list!

As someone newly diagnosed with ADHD (and likely/suggested, but not formally-diagnosed ASD), I'm digging into both to understand how my experience differs from others. This includes things like strengths, weaknesses, the usual stuff, but I'm interested in the common ground between "neurodiverse" and "neurotypical" brains (talking in general terms here) as well as how both "sides" can better work together. Use strengths to fill in the weaknesses, that sort of thing. Eventually I may start writing some of this down more formally, but as of right now, I'm just a guy trying to understand his own brain.

I found that https://endel.io/ worked better for me than brain.fm. YMMV of course, but it's worth a try if brain.fm isn't your jam.

Always good to remember "what gets measured gets managed". I.e., every single one of these metrics can easily be gamed in a way that would be hard for a non-technical manager or "bean counter" to determine.

Ex: oh, you're measuring number of commits, well, I'll stop squashing and start breaking commits down to single lines. Boom, I'm a 100x software engineer.

Does anyone have a decent list of individual contributor KPI's that are actually useful or insightful? I've, so far (~20 years of experience), never run into individual KPI's that weren't able to be gamed and were actually meaningful.

Definitely an interesting terminal. What bugs me is I can't switch the autocomplete command from <enter> to <tab>. Muscle memory keeps doing the wrong thing and in a terminal, that's potentially catastrophic.