Live data from Hacker News

Building for the 99% Developers

future.a16z.com

81–90 of 310 posts

Re: Building for the 99% Developers

#81
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. -…

Similar, but not exactly the same:

I've come to appreciate that the bleeding-edge really means you'll bleed over it. In the search for "magic" to make my job easier, it often falls apart of the edge cases. So to just get stuff done, I'll trend towards lower-level software even if it means more boilerplate.

Also, there's a great idea that seems very worthwhile. I don't recall the source or exact phrasing: you only have 1 innovation point for a project. Everything in your stack should be familiar to you (and you know the pros, cons, and issues) but you're allowed ONE new magic/helper/tool. That limits the blast radius of all this new-fangled stuff and gives you room to try out new tools.

Re: Building for the 99% Developers

#82

Earlier quoted context omitted.

Not the one you asked, but I'm also stuck with supporting graphql in relatively small project. Zoomers invented SOAP. It's a perfect example of adopting what FAANGS do just for the sake of it. It's probably great when you have dozens of consumers with very different needs and usage patterns. But for the single frontend it adds way too much complexity on the server-side. Debugging, testing, writing tons of boilerate c…

Zoomers invented SOAP? Are we thinking of the same Zoomers? Same SOAP?

GP means GraphQL is a Zoomer's version of SOAP (with all that implies)

Re: Building for the 99% Developers

#83
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…

This really depends. The majority of services out there that can get away with a single box for a scale perspective can probably afford just to take the downtime.

Re: Building for the 99% Developers

#84
post #81
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. -…

Similar, but not exactly the same: I've come to appreciate that the bleeding-edge really means you'll bleed over it. In the search for "magic" to make my job easier, it often falls apart of the edge cases. So to just get stuff done, I'll trend towards lower-level software even if it means more boilerplate. Also, there's a great idea that seems very worthwhile. I don't recall the source or exact phrasing: you only hav…

> I'll trend towards lower-level software even if it means more boilerplate

This is exactly what 90%+ of people working on frameworks/languages don't get. Somewhere in their education/career they learnt that repetition is bad. DRY everything. And then they follow that religiously. Pragmalism (minimal pragmatism) is sorely missing.

Re: Building for the 99% Developers

#85
post #54

Earlier quoted context omitted.

Mentioning RDS is an apples to oranges comparison. RDS is a fully managed service by a 3rd party. Nevertheless, checkout https://litestream.io - given that SQLite is just a file, it’s incredibly easy to replicate. Failover is coming in the next release, which is already beta. Also checkout this Expensify blog post on how they use SQLite. It’s scales amazingly well. https://blog.expensify.com/2018/01/08/scaling-sqlite…

I mention RDS because it mostly solves the failover/continuity problem. While failovers on RDS are typically outages, they're also typically quite short lived, no more than a few minutes. That can work for many people/business's requirements. That it is managed means you (in theory) can rely on AWS to manage the underlying infrastructure. You just worry about the SQL. It is a "boring technology" choice, as the articl…

"[Litestream] runs as a separate background process and continuously copies write-ahead log pages from disk to one or more replicas." - https://litestream.io/how-it-works

Re: Building for the 99% Developers

#86
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. -…

Google uses a ton of Java internally. Microsoft uses C# and .NET (obviously). Facebook uses PHP and C++. Are you really avoiding all those tech stacks? They're old, bulletproof, and nobody ever got fired for picking them as choices. Just because big companies use them doesn't mean they have to complicated or trendy.

Re: Building for the 99% Developers

#87
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 release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...

Re: Building for the 99% Developers

#88
post #81
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. -…

Similar, but not exactly the same: I've come to appreciate that the bleeding-edge really means you'll bleed over it. In the search for "magic" to make my job easier, it often falls apart of the edge cases. So to just get stuff done, I'll trend towards lower-level software even if it means more boilerplate. Also, there's a great idea that seems very worthwhile. I don't recall the source or exact phrasing: you only hav…

Sounds like this blog post: https://mcfunley.com/choose-boring-technology

Re: Building for the 99% Developers

#89
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. -…

Serious "get off my lawn" vibes.

These might be ok heuristics, but it's pretty limiting to not use some tech just because a big company uses it.

Re: Building for the 99% Developers

#90
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. -…

My rules:

- Does it work?

- Can it be explained to coworkers/usable?

- Does it solve the problems I'm having?

- Does it seem like it's going to be around in the next 5 years (weaker version: do I need to worry about it being around in the next 5 years?)

- Can I debug issues with it relatively easily?

Turns out that good rules of thumbs are ones that look at stuff on the merits, instead of trying to find catchy third-order effects that you see in projects that rub you the wrong way.

Post reply on HN