I only use opus 4.7 and am on the 100$/mo plan. I usually make sure the context does not grow beyond 30-40% of the 1m tokens. On heavy coding days where I do something pretty similar to this, I would occasionally run into the five hour limit, but that happens like once per week and then it wouldn't take too long to reset. Note that I use caveman, but I'm not sure to what extent that really helps.
Before the cloud, people were trying to reduce the mean time between failure (MTBF) essentially trying to prevent a thing from failing. With cloud, people are trying to recover as quickly as possible (mean time to recovery) accepting that things will fail —- it’s about how fast you can react to it.
Also note that even though you get a warning about an unknown config key, the value is actually set so you're future-proof. Check `grep telemetry ~/.config/gh/config.yml`
> As of 07:55 UTC, we are experiencing issues with the Dashboard, Express Dashboard on all platforms and Mobile surfaces. We’re continuing to investigate and will post further updates. API requests and payment processing are unaffected by this issue.
Shout out to Blogtrottr[1], which allows you to subscribe to RSS feeds and have the posts sent to you via email. Great service I've been using for years.
This is great advice. Unfortunately, all these AI tools make it far too easy for beginners to not follow it. I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..
We cannot forget that we also loose something with working remotely (say more than 75% of the time) and that is the occasional bumping into each other at the water cooler or in the morning when coming in. These are situations you can artificially create by scheduling calls to socialize etc, but that is still not comparable with being in an actual office.
By categorically saying no to quick calls, you're isolating yourself even more. While it can be distracting to jump on a call while you actually meant to focus on some coding, it can also be great to have a quick chat and brainstorm about an idea rather than let the other person work out the solution in isolation only for me to then suggest a totally different approach in the PR review (yay! asynchronous!).
I like the jetbrains products a lot and have been using IntelliJ as my main IDE for years.
What I don’t like is their pricing with regards to multiple products. I use IntelliJ 95% of the time and pay for it. Sometimes, I’m writing some Python or C and would like to have a decent IDE as well, but then I immediately need to purchase the „all products pack“. I wish there was a cheaper option for occasional use of other IDEs. Right now I use the PyCharm community edition, but this feels a bit silly :)
> I've also found that interviews don't tell you much about reality.
Always ask to see code and talk to engineers about what their days look like. I believe there are very few legitimate reasons they won't show you their code, but more likely if they're refusing, it's because they're hiding something. When talking to an engineer, ask them how their code goes from idea to production and have it explained in detail. This will tell you what type of management they have, what testing/review/deployment practices, etc.. As a bonus, I also like to ask my future peers what they don't like about their job or what they'd like to change.
I agree most jobs are some form of shite, but there are good ones. Being more picky during the interview phase should hopefully allow you to find some of those while weeding out the bad quicker.