In California, the maximum personal income tax rate is effectively closer to 50%, which is where my mind went, but you're right, it's different for companies.
In my example, the tax rate isn't the point though, it was used just to illustrate the math.
The main point is that it makes no sense to require amortization of software development expenses. The idea that this letter is an attempt to restore rationality in the tax code.
For folks that don't know the background on this, here's a layperson summary:
- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.
- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.
- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!
- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.
I am neither a lawyer nor an accountant, this is just my understanding of this issue.
Edit: Switched the tax rate to 20%. The logic is still the same.
I’ve been helping Omar on this and one of the hardest aspects of building this product has been finding users that can give actual feedback. Any ideas there would be super helpful
And, zooming out a little more, free market healthcare is just part of the problem.
We have a system where we’re only treating people once they have a disease, and not working to prevent the disease, so it would be helpful to look at the effects of for-profit companies on making healthy people sicker. Fast food, snacks, alcohol, there are so many industries that are incentivized to succeed by making people sick.
This is the system “working” according to the current rule set.
It’s time to look for a better algorithm than a purely profit maximizing one.
The app is doing an http(s?) request, which includes more round trips than a simple ping. Also, the web server may be more loaded than the ping response would indicate.
Yes, and I think what’s interesting is to consider is that the ability to use a terminal is a very recent (and from a certain perspective, strange) skill, considered from the perspective of the kind of hardware we have for information access, storage and transmission.
What’s far more “normal” is storytelling (with heroes and villains), rhythm & rhyme, and lots of repetition. But even simple conversational interfaces are way more normal (and fit our mental hardware well) than terminal-y interactions.
Yes, that’s it! An easier and shorter read may be the final paper I published in that domain, which talks more about the difference between literate and low/non-literate users:
My PhD thesis focused on voice interface design for people with limited literacy skills. One of the most surprising discoveries for me was that menus and even lists of items aren’t natural concepts that exist outside of a context of literacy. Even for voice interfaces, a touch tone menu (“for X press 1, for Y press 2...”) was a lot harder to navigate than an equivalent voice-based menu (“would you like X, Y, or Z?”). As a side project during my final year of my thesis research, I wrote an iPhone app that unexpectedly propelled me into the world of entrepreneurship, so I ended up pursuing the startup life after I graduated. But this space is still fascinating to me.
Pop’s performance is something we have spent significant time improving, and we’ll continue to do so. My only ask is for folks to try the product and judge its performance (or lack thereof) on its own merits, regardless of presumptions based on our use of Electron. We have thousands of daily active users that continue to use the product happily.
Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1].
Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance.
Agreed, it's quite an inspiration as to the best Electron can be. I think the trick for an app like ours is to offload the heaviest pieces to native code, and use Electron purely as a presentation layer. This is something we're now going to look into.
Based on the feedback today, we're going to look into how we can reduce memory usage overall (especially when idle), and CPU usage especially when screen sharing. We already modify Electron, so we may be able to work out a good middle ground that reduces the footprint significantly, while still giving us the advantages of a shared codebase across our 4 platforms (Mac, Windows, Linux, web).
He is getting a refund along with an additional $200 credit from what I can see.