Anecdotally I'm using the superpowers[1] skills and am absolutely blown away by the quality increase. Working on a large python codebase shared by ~200 engineers for context, and have never been more stoked on claude code ouput.
This just feels like the whole complicated TODO workflows and MCP servers that were the hot thing for awhile. I really don't believe this level of abstraction and detailed workflows are where things are headed.
Agreed, as a software engineer of ~8 years now Mac is actually my _preferred_ environment -- I find it an extremely productive OS for development whether I'm working on full stack or Unity game dev in my free time.
I don't agree with OP's sentiment that macOS is a bad dev environment, but surely I prefer Linux+KDE as an overall dev environment. I find that all the tools I need are there but that I'm fighting the UI/UX enough to make it a hassle relative to KDE.
> I don't agree with OP's sentiment that macOS is a bad dev environment, but surely I prefer Linux+KDE as an overall dev environment. I find that all the tools I need are there but that I'm fighting the UI/UX enough to make it a hassle relative to KDE.
This sounds like you think macOS is a good dev environment, but that you personally don't like the UI/UX (always safer to make UI/UX judgements subjective ["I don't like"] rather than objective ["it's bad"], since it's so difficult to evaluate objectively, e.g., compared to saying something like Docker doesn't run natively on macOS, which is just an objective fact).
I feel like it's more often a result of suffering from success that leads to these situations, rather than a lack of foresight to begin with.
For example I work on a python codebase shared by 300+ engineers for a popular unicorn. Typing is an extremely important part of enforcing our contracts between teams within the same repository. For better or for worse, python will likely remain the primary language of the company stack.
Should the founder have chosen a better language during their pre-revenue days? Maybe, but at the same time I think the founder chose wisely -- they just needed something that was _quick_ (Django) and capable of slapping features / ecosystem packages on top of to get the job done.
For every successful company built on a shaky dynamic language, there's probably x10 more companies that failed on top of a perfect and scalable stack using static languages.
This resonates with me this so much. I feel like half the comments in this thread are missing the value typing, but maybe they've never had the misfortune of working with hundreds of other developers on a project with no defined contracts on aggregates / value objects outside of code comments and wishful thinking.
I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.
Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.
No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.
Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.
TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.
Yep 100% agreed here. I run a member management platform[1] for small clubs which generally use PP to fundraise and collect member dues.
Works perfectly well for us, we don't handle any PI or CC details and clubs can connect their PP account to our platform for their registration / event management needs.
I had a period of time at my last job where the product org was so dysfunctional engineers did in fact run out of work.
Initially I didn’t mind it because my team focused on technical debt, but it pretty quickly turned sour. Having to scrape up “work” for the team of 6 engineers each morning to appear productive to management was dreadful
I allowed Claude to debug an ingress rule issue on my cluster last week for a membership platform I run.
Not really the same since Claude didn’t deploy anything — but I WAS surprised at how well it tracked down the ingress issue to a cron job accidentally labeled as a web pod (and attempting to service http requests).
It actually prompted me to patch the cron itself but I don’t think I’m that bullish yet to let CC patch my cluster.
oh yeah we had claude diagnose a production k8s redis outage last week (figured out that we needed to launch a new instance in a new AZ to pick up the previous redis' AZ-scoped EBS PVC after a cluster upgrade).
Attribution revenue is what I would consider the gold standard for these types of services.
It makes sense on paper, if the service helps confirm legitimate reviews for you and convinces you to purchase said product, they should receive attribution revenue for helping generate the purchase.
The reality is much much messier though, because often times the people who award attribution revenue have a conflict of interest against any service that could even potentially expose bad practices happening on their marketplace.
I once worked for a popular deal site that developed a price tracking extension, a certain marketplace threatened to completely ban us from attribution revenue and we had to kill the extension over night despite our users loving it.
That does not help me understand why I should pay for this service. I personally have zero concern for why this service should make money beyond operating costs. “Why should I should pay for it” is the question I asked.
In my experience the problem it proposes to solve isn’t something I consider so problematic that a subscription would improve things. My experience may not be the norm, and that’s definitely a consideration I’m aware of. Still, I can’t see a reason to subscribe as such.
For one, the trees used here are mostly the desert variety that can withstand the hash conditions of our summers and infrequent waterings [1] -- they're actually quite beautiful too!
Secondly, LV is one of the most water efficient cities in the world. We recycle nearly all of our indoor water back into Lake Mead, and despite the city growing by 800K over the last 20 years we've reduced per-capita water consumption by 55% [2]
Our water crisis is a symptom of the water rights debate between the four states, not our over-consumption of water. You could actually eliminate the state of Nevada from the water crisis debate over the Colorado river and we wouldn't even make a _dent_ in the impact, it's the irrigated deserts of AZ and water intensive farming in CA that's the unsustainable piece (coming from a proud local who grew up in LV).
[1] https://github.com/obra/superpowers