First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?
If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?
Do teams slow down in new features because the API must be the stress test of a public api?
I'm fine with unsupported frontends but an external API will be very difficult to keep static.
The last company I worked for before going into consulting full time was a startup where I was the then new CTOs first technical hire. The company before then outsourced the actual technical work to a third party consulting company until they found product market fit.
His primary mandate was API and micro service first.
Our customers were large health care systems.
We had a customer facing website that was built on top of the same APIs that we sold our customers.
Our customers paid for the features they wanted and those features were available on our website, they were used for their website and mobile apps and the ETL process was either via a file they sent us and we ran through the same APIs or they could use our APIs directly for both online and batch processes.
This is no different from the API mandate Bezos made at Amazon back in 2000.
You don’t have to keep an API static - that’s what versioning is for.
I think the talking point is maintaining a well versioned and solid API as product is way harder than shipping a few screens that can change whenever you need them to. (behind those screens being a bunch of duct tape to a clusterF of internal APIs). no guarantees.
what you're saying is that you were at a company that did that hard thing of shipping APIs as product.
That was a bad acquisition and their parent company is now in a bind, but I don't see a world where they can't sell it somewhere. Hopefully it doesn't end up in private equity hell because the 600/650 line is legendary and the HDB 630 is a true leap forward.
> Hopefully it doesn't end up in private equity hell
By this time next year we'd be seeing some Chinese owned company producing "Sennheiser HD9000000000+ Pro" headphones that are leftover Shrek themed earbuds that smoke when you turn the volume up too high.
I think that's unfair - if HiFiMAN, Moondrop, or even KZ bought up the Sennheiser assets there would be very little difference. (HiFiMAN had QC concerns 7-8 years back but as far as I've heard they have been much better over the last 5 years.
Yes, of course, I'm wasn't trying to claim the music/graphics was stolen by the cracker, or vice-versa, just that "show off the skills of whoever cracked a piece of software" isn't really accurately representing how the team's composition was, since they were different people.
These are a group that used outside signal chats to discuss war plans. What odds do you have that he didn't use a personal email to avoid future accountability?
One of the products my employer builds is used twice a year. People pay tens of thousands of dollars for the privilege of using it twice a year. It's tremendously valuable to be used twice a year.
I think the supply shocks is the part of the pro-natalist view that is hardest for me to accept.
My counter-argument: the full expression of human achievement is not genetic; it depends on the resources given to the human; If we accept that someone cannot reach their entire potential if living in poverty, and we accept that a lot of the advantages of rich children are due to the environment and opportunities that wealth provides, then it naturally concludes that we could get all of the advantages that pro-natalists look for by creating a higher standard living for all existing children.
Only when we can provide the sustainable resources for all people on the planet can we accept the idea that we have room for more.
I guess I'm pro-natalist. I do agree with you on the goal of eradicating poverty, although to me that's a goal in itself that does not need to be justified.
But I don't agree that all people on earth are fungible, and a birth in Mongolia is the same as a birth is Sydney, Australia.
Your "human achievement" viewpoint is highly reductive. The culture of a place is maintained by it's local population. When you have a low birth rate situation to the point that you need to supplement the workforce with immigrants, that signifies that the local culture is slowly dying. While some mixing of cultures is beneficial, we should also try to perserve our local cultures. We should not turn every city in the developed world into a little NYC.
Because you see the IC side of the Atlassian toolkit. The management side is much more expansive and this starts mattering when you are coordinating larger projects.
That said, if you are a smaller company, you absolutely could kill Jira pretty quick.
The frustrating thing is I also thought about this as a natural conclusion - but as a natural workflow that corporations will do when they see AGPL dependencies they want to use. (I also think there's a world where we start tightening our software bill of materials anyway.)
I do not believe it will ever again make sense to build open source for business. the era of OSS as a business model will be very limited going forward. As sad and frustrating as it is, we did it to ourselves.
I mean, this is a task board and not a Kanban board - Kanban implies things like Work In Progress limits, continuous improvement, and measuring flow to get rid of blockers.
But you're right - you can visualize your workflow without using Kanban - I think it's weird how the term gets appropriated here.
First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?
If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?
Do teams slow down in new features because the API must be the stress test of a public api?
I'm fine with unsupported frontends but an external API will be very difficult to keep static.
reply