Live data from Hacker News

Building for the 99% Developers

future.a16z.com

91–100 of 310 posts

Re: Building for the 99% Developers

#91
post #19

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup sellin…

The point the article raises is whether those "non-FAANG engineers" should be using serverless at all. Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?

> Will their requirements ever scale to a point where it actually makes sense

And even that. Let’s treat scaling issues latter. Create something that can be scaled horizontally dumbly, like a monolith you can run on n servers so you can scale without loosing money and then scaling can become your problem.

And that’s probably never if you are b2b like a majority of companies, since your usage depends and can be predicted from your sales team performance.

Re: Building for the 99% Developers

#92
post #77

Earlier quoted context omitted.

Would you be willing to share some of the languages/frameworks that have made the cut or washed out for you based on the rubric you’ve given. I’m honestly curious.

I specifically avoided mentioning examples as that'll stir up a lang-war.

Your rules are so vague that I have no idea which languages/frameworks would qualify and which ones wouldn't.

Does React specifically mention big companies, have a young developer base and is a "kitchen sink"? I have no idea.

Is Python a "bad" language? What about Go? C++ kind of seems like a kitchen sink, is it "bad"?

I really have no idea how to figure out if these rules apply to any languages/frameworks.

Re: Building for the 99% Developers

#93
post #46
post #38

Earlier quoted context omitted.

It's also that, in the past, the capacity of our monoliths to scale was far lower. There's many apps that need say, a 100GB database in 2022. Those apps also needed 100GB database in 2007, when horizontal scaling was the hottest thing around. Nowadays however, Moore's law has steadily overtaken an order of magnitude of use cases from 2007. Maybe 1/10th of the 2007 use cases still need that kind of enormous, big tech…

Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers. Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usu…

> Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers.

How fatal[1]? Not all outages are fatal. Scale vertically and you'll have some downtime if any node between (and in) your user and your system goes down. For 999 out of a thousand businesses, it won't be fatal.

If your business is so fragile that the first 24 hour outage kills it, then it would have been killed anyway in the near future.

[1] I know, this is liking asking "how pregnant?"...

Re: Building for the 99% Developers

#94
post #62

Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. -…

Another thing, never be the biggest users of a framework. Then you will encounter all the edge cases. Let others find/fix it first.

Re: Building for the 99% Developers

#95
post #31

Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 > a lot of what most “developer influencers” say is fairly aspirational. Their own companies don’t necessarily do things as smoothly as they preach to others. There's a pride element there: developers don't want to admit that they work in less-than-stellar conditions. Some developer talks also do…

One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to rele…

I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further.

But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.

Re: Building for the 99% Developers

#96
post #94
post #62

Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. -…

Another thing, never be the biggest users of a framework. Then you will encounter all the edge cases. Let others find/fix it first.

OK, so don’t use a tool/framework that companies bigger than you are using, but also don’t be the biggest user of a given tool/framework, got it.

(Edit: For the record I think msh is the correct one, it’s GP’s reasoning that is bananas)

Re: Building for the 99% Developers

#97
post #62

Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. -…

[deleted]

Re: Building for the 99% Developers

#98
post #97
post #62

Here are my rules for picking framework/languages: - Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen. -…

[deleted]

[deleted]

Re: Building for the 99% Developers

#99
post #24

IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy

I'm literally running 5 sites and $40k MRR on a $5 linode

Wow! What kind of sites are these to generate $40k MRR and fit on a $5 linode? I can think of one or the other but not put both together

Re: Building for the 99% Developers

#100
post #22
post #20

Earlier quoted context omitted.

I would just think of it as 1 global static SQLiteConnection instance. There's really not a whole lot to it. Like 4 lines in a class file to set this up.

How do you implement this using a stateless stack (eg PHP)?

I think what bob1029 meant was just that opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example). With PHP you have one "process" per request, so you'd just need to make sure you only open a single SQLite connection per request (using the singleton pattern for example).
Post reply on HN