jsherwani

He is getting a refund along with an additional $200 credit from what I can see.

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.

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

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.

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.

http://www.cs.cmu.edu/~jsherwan/pubs/orality-hcid-itid09.pdf

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.

[1] https://news.ycombinator.com/item?id=28230542

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).

In short: when you need to see anything outside the IDE (e.g. a debugger, or even just seeing the running app alongside the IDE), a tool like Pop is very helpful. But you can also use it in conjunction with those IDE features, as Elijah in the above thread said he does.

With Pop, you can minimize the control panel with 1 click. We'll soon also be adding the ability to remove the border around your shared screen entirely (some users have told us it gives them anxiety to not see something that clearly shows them that they're sharing their screen, but we've now heard the opposite perspective from enough people to realize we need to support both preferences).

And honestly, the feedback on Pop as a name has been overwhelmingly positive :)

I think one key piece worth emphasizing was: Screenhero's core strength was in its interactive screen sharing. Slack's main desire was in voice, then video, then screen sharing, then interactive screen sharing — and this "impedance mismatch" is somewhat responsible for where things ended up. By the time we got to the end of that roadmap, the appetite for the final feature was low, while the cost was very high.

The native module coupled with Electron could be a great solution to the performance issue: it would give native performance for the most critical part of the product, while still providing a cross-platform foundation for a shared user interface across 4 platforms (Mac, Windows, Linux & browsers).

Given the feedback today on performance and resource bloat, we're going to dive deeper into benchmarking our product against the competition, and will post an update on what we find.

Having said this, I think this discussion between Electron vs. Native is a false dichotomy. Performance and developer efficiency are both clearly important, and we don't have to maximize one dimension alone. I am confident we'll find a way to make Electron far more performant by switching off unnecessary features, such that it provides us just the surface area we need to be able to build great products that are indistinguishable from their native counterparts: except that they're quicker to build, easier to debug, are of higher quality (with fewer bugs), and cost less.

I know this sounds optimistic, but given the popularity of Electron, coupled with the issue of performance, this is an issue that is certainly going to improve over the coming months and years. Who knows, since ours is one of the more performance-hungry products, we may end up finding a solution that others can leverage as well.