nthj

> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply)

This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.

I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.

It's fascinating: because Factorio is deterministic, I always build out one massive, consolidated chip factory and distribute chips to other factories from there. But as we see here, in the real world, with droughts and pandemics, this is a risky strategy.

Adobe could spend a billion dollars on R&D to optimize their web apps and still not get it. It's not an engineering problem, it's a corporate structure problem.

The only way to solve web app performance is to put 5-7 engineers in a room and say "we want it fast. As fast as possible. Get to work."

But no, they have the front end team, who has to run everything by the compliance committee, and the architecture committee, and the API committee, and the back-end team, that has to run everything by all the committees and the front-end team, and they also have to wait on the infrastructure team before they can test any of their stuff, and before you know it 12 weeks have gone by before an engineer has written an actual line of code.

And none of this corporate structure can be fixed because the CEO doesn't understand it, and all the management he hires to fix it are financially incentivized to continue holding their little fiefdoms.

If this were true, humanity would have stopped inventing new games to play the day that dice were discovered.

My team could professionally and empathetically discuss each of the issues you outlined, but that doesn't mean I raise discussions about whether voting for certain candidates is a case for the-end-justifies-the-means. I don't understand how a good-faith reading of an "activism on your own platforms" policy leads to "we can't discuss the data modeling for people's names anymore." This strikes me as a case of false equivalence.

Oh please. Intel may not be the legend it once was but that hardly invalidates a value first forged some 40 years ago.

Then you shouldn’t have an Android device. This isn’t complicated.

I don’t mean to stick my nose in, but seeing as we are on HN: I keep hearing the market is pretty good for capital lately, have you explored raising a round to accelerate dropping the 9-5?

Yes, put it in terms of churn mitigation, compliance, security, and data integrity and you can absolutely sell maintenance at your performance review

I like factorio because I don't have to have 17 meetings to get alignment on changing 3 lines of code. "I objectively need more electricity, so I will refactor the nuclear reactor" is the only agreement needed

A code comment saying “Here’s a potential pitfall we could discuss addressing” is often more valuable than a solution. Every software project has more problems than it has people-hours available. Every team has the engineer who spends a week fixing an edge case in their ticket that no customer cares about. Demonstrating awareness of this makes you an attractive candidate.

B2B customers generally have it spelled into the contracts that engineers outside of the US may not access customer data. The value of an engineer who can remediate a customer problem end-to-end for a thousand $500K ARR contracts is far greater than saving $200K/year on salary.

More complicated functionality has moved to integrations/APIs in the past 8 years.

When you’re trying to ship an extensive application and building out features that few customers may ever use, types absolutely slow you down. When you’re integrating with a 3rd-party API, you have two differences:

1. relatively high confidence the API won’t change much, which makes implementing typed code lower risk and higher ROI

2. a slower feedback loop over the “reload the page” of rolling your own, so types catching issues earlier than heavy integration tests is much more valuable

I use untyped Ruby/Rails code for all of the CRUD, and golang AWS lambdas for anything integrating with SDKs/APIs. Best of both worlds, in my experience.

We’re asking people to stay home to help mitigate the collapse of health care systems, at which point the young will find that car crashes, heart attacks and strokes that they may have otherwise survive now become far more deadly.

To try to clarify: none of my 3 points above are fixed by rust, golang, or any other language, because they are not caused by Rails. Uncharitably, in my experience, these 3 bottlenecks are usually accidental consequences of decisions made by software developers who do not fully understand the whole lifecycle of a web application request/response.

I usually run Rails on two servers for redundancy. Any features that are CPU expensive I will spin off into a separate service (I’m partial to golang.) This is all on the order of $10s of dollars a month on AWS. 90% of most products’ landscapes are CRUD, and bottlenecked on IO to the database, not expensive CPU calculations.

Stripe primarily interfaces with 3rd party payment systems. Anytime a request has dependencies outside of the database, you’re “off the Rails” and should investigate additional options.

Shopify is a great example. Last I checked, Shopify is doing great still using Rails for 90% of CRUD and are optimizing just the 10% that they see ROI from.

Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons.

Swapping out ruby for golang won’t fix any of those.

I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.

> a single service having multiple data layers for different things isn't really a big operational or organizational problem.

Your statement is true, and I’d like to consider the product/feature side as well. Enterprise SAAS customers expect their Single Source of Truth to be, well, a single source. They want reports across all of the data they have put into a product. A feature that should be a couple of JOINs can quickly become pretty dicey when data is sliced across multiple data stores.

I see this idea often, and it feels somewhat shortsighted for me. Company outcomes are primarily determined by product-market fit, yes, and: the tighter your feature release feedback loop, the more product-market-fit experiments you can run before you’re out of runway.

Many technology and process choices are just style and preference, absolutely. Others have a material impact on the effort and time to ship a feature. (I’ll leave examples as an exercise to the reader; I imagine any example I used could turn into discussion of “ah you’re doing $FOO wrong.” I suspect this tendency entangles with why these choices seemingly frequently impact business outcomes, from my perspective.)

I don’t object or argue against your point, but I find it interesting to note that as far as I understand, it’s near impossible to buy a PS5 right now, whereas Sony can sell tens of millions of copies of a software on the PS4-copying software is practically free, after all.

This argument seems to make sense on the surface, but California already has some of the highest income taxes in the country. To make an appeal to extremes, if California had a 40% income tax they wanted to raise to 45% asking, “show me how you have demonstrated good stewardship in what you are already taking” would be, I imagine, somewhat common. Reasonable people can of course debate that percentage, and can do so today based on California already having high income taxes.

edit: as tsimionescu kindly pointed out below, I misunderstood the 30M threshold. My reasoning seems correct to me but a key premise was wrong, and I agree the proposal is much less onerous than I have painted below:

I personally know multiple startup founders worth $10-$20M on paper who made $120K/year salary for years (or still are.) It’s hardly unusual, startup valuations are high these days, and VCs and the founders themselves want to reinvest in growth, not issuing distributions.

A founder owning 40% at a $50M valuation would feasibly have to double his salary to $240K to afford the $80K/year wealth tax, after paying income taxes on the salary increase in California.

That’s realistically one employee they no longer have the cash flow to hire. A $50M startup may have something like $2M ARR, so if they don’t want to burn investment funds, they could support maybe 8 employees at their ARR level. Knocking out one employee at that size is significant.

Or you could say they should get VC to support hiring more employees. Now the wealth tax is indirectly impacting the founder's equity—forcing you to sell your company.

We can argue whether they should be forced to liquidate a portion yearly for taxes, but let’s not pretend everyone worth $20M on paper can light $80K cash on fire yearly without consequences.

This is absolutely technically correct. Practically speaking, maybe not so much.

http://stockoptioncounsel.com/blog/standards-ownership-canth...

I didn’t miss any facts. I was deliberately cagey because this line of debate your comment enters is irrelevant to my larger point: the arguments may be wrong, or right, or any number of other conclusions, but they aren’t incongruent with each other.

Whoever is able to demonstrate the value of a sequence of work to the business will get their work prioritized. Product’s job is to shape and predict the value of adding new features. Customer complaints about slow reports help Customer Support justify performance optimizations.

If engineers want the business to pay them for simplifying maintenance, they can identify a collection of support tickets that have a compelling root cause, and propose refactoring that system to eliminate the bugs and maintenance issues.

What I usually see is us engineers calling it “tech debt” and complaining we never take time for it, which is about as effective as the bookkeeper complaining about the paperwork that debt payments create for him. Businesses love debt. It’s a useful financial tool. The business doesn’t get the issue.

This vaccine is like providing a machine learning model another website to read, after reading millions of websites.

It is absolutely not anything like merging a patch into the master branch.

It seems to me the subtle miscommunication between billionaires and the rest of us is the rest of us are asking “what ever will you do with a dynasty” and many billionaires, I think, have a mental model of “I have proven I can employ this wealth more effectively than bureaucrats, and I like to solve big problems, and wealth makes it easier to solve big problems.”

This is a huge generalization we could easily find counter-examples and counter-arguments for, but we could also probably find fair arguments FOR this view, like Bill Gates.

Anyway, I think it’s probably a fair summary of how someone like PG could simultaneously hold the two ideas “don’t start a startup for money” and “higher taxes are a bad idea” at the same time. Which is not to say that he’s right, but I don’t think he’s incongruent.

Lodging must meet specific rules, or the fair market value of the lodging must be declared as W2 income.

https://smallbusiness.chron.com/taxability-employerprovided-...

As another option, HAML lets you extract the attributes into a ruby helper method:

https://haml.info/docs/yardoc/file.REFERENCE.html#attribute-...

You offered up 3 examples of billionaires. Other examples might be:

* Tesla

* Twilio

* Stripe

Would you help me see how those 3 leveraged unjust laws? As a software developer, I feel Stripe and Twilio have added a lot of value to me, to small businesses, and the world.

Enterprise SaaS is “just an app” + a ton of integrations + SSO authentication with a bunch of systems + SOC2 level compliance (or better.)

Combining all of these things into one offering is very difficult, and highly valued by both customers and the stock market.