Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building for the 99% Developers

future.a16z.com

Post reply on HN
Print view View original

281–290 of 310 posts

Re: Building for the 99% Developers

#281

Post by falcolas »

themacguffinman wrote: post #279
falcolas wrote: post #246

Earlier quoted context omitted.

Those are usually business decisions. Pay an extra $$$ for an outage scenario that occurs once a month, and doesn't materially impact our users? Hell no. Spend XXX developer hours and/or $$$ on hardware to make the site 50% faster, instead of adding new features our users pay for? Hell no. And let's be honest, for touting speed, Google's awfully slow and bloated these days.

A hug of death when your product has peak user interest...doesn't materially impact users? Your users don't care about multi-hour or even multi-day downtimes in "99%" industries like...healthcare and banking? What a perfect demonstration of "Those scenarios are rare if you have gotten used to what 99% can and can't do and therefore just dismiss many solutions without thinking since you know the 99% can't do those thi…

> Your users don't care about multi-hour or even multi-day downtimes

Should ask Reddit.

And yes, it's a sad state of affairs, but an hour of downtime in healthcare isn't all that uncommon. Convincing administrators to ~triple their hosting costs to avoid the occasional outage is pretty hard to do.

I mean, I recently watched a documentary on the 2003 east coast power outage, and one of the primary causes was the single computer in charge of issuing alerts (in an alert-based workflow system) going down.

Re: Building for the 99% Developers

#282

Post by DerArzt »

rzzzt wrote: post #105
urthor wrote: 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…

Immediately reminded of https://yourdatafitsinram.net/

I took a look at that and holy cow!

TIL there are machines out there that have 64TB of RAM!

Re: Building for the 99% Developers

#283

Post by armchairhacker »

AceJohnny2 wrote: post #108

In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…

Honestly i think more than 1% of developers code for fun, understand at least basic unix, and can clearly see when a system is shoddy and dumbed down.

Maybe a majority don’t, and my experience is definitely biased. But i’ve met many programmers of diverse backgrounds, and a lot are very passionate and research the newest and best technologies on their own. They probably don’t read Hacker News, but I think “hacker” programmers are more common than you realize.

Re: Building for the 99% Developers

#284

Post by trasz »

TameAntelope wrote: post #274
trasz wrote: post #182

Earlier quoted context omitted.

Quite the opposite: the simpler the stack is, the easier to debug it is; also fewer moving parts means fewer things that break.

I disagree; you add complexity to a stack for a reason, usually to provide functionality that would be difficult to reproduce otherwise. Hand-building a reactive (lowercase r) table with sorting, filtering, etc. that's performant at large data volumes to keep your stack "simple", would be a nightmare to maintain and wouldn't allow other developers to bring prior experience with them when they later have to maintain t…

I agree, but what you are describing is a different thing: it's reinventing the wheel, not avoiding additional complexity. Avoiding additional complexity would be not having that reactive table. (And that of course would probably result in worse user experience, so it's really not a good example of what I've meant.)

Re: Building for the 99% Developers

#285

Post by drekipus »

ignoramous wrote: post #184
AceJohnny2 wrote: post #108

In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…

Reminds me of: > Here's my point: yes, the whole Internet runs on Unix philosophy. But businesses sure don't. The big problem comes up in my description of pipelines up above: they only parse about 99% correctly, which is fine for your idiotic comments about YouTube videos, but pretty nasty when you mangle critical business data. And when the business dudes get involved, they'd rather do anything than mangle their cr…

> but Windows works consistently. So does SOAP. But not Unix or microformats or REST.

I have no idea that windows works consistently (?!) where unix (linux) or REST (?) doesn't.

I like the idea of what they're trying to get to, but sometimes it helps to cite examples.

imo, LARGELY the reason that "windows=business" is from historical lock-in effects. I, as a linux developer, still get ".xsl" files on the regular, who have each gone through 4-5 different business people before me.

windows is largely a "suite" of software, from OS, to Office, to even Internet Explorer. Business types often didn't (and perhaps still don't?) know what separates Word from calc.exe - it's the entire computer interface, it works, and it's what others are using. Only a big "everything-in-one-package" could hope to upset them, and even then might have a hard time doing it.

I don't think I'll ever try to purposely run much windows software again, but I do give them kudos for what they've achieved and continue (for now) to achieve.

but to say it works consistently!!?

Re: Building for the 99% Developers

#286

Post by drekipus »

akhosravian wrote: post #271
Nextgrid wrote: post #258

Earlier quoted context omitted.

Do they prefer or are they not given a choice?

As someone who has worked in large budget games for much of my career (where windows is everywhere) most of them prefer it.

> large budget games

no linux support on those games right? then there would be no option to use linux.

Re: Building for the 99% Developers

#287

Post by drekipus »

goodpoint wrote: post #266
AceJohnny2 wrote: post #108

In the 90s-00s, when I was a younger, (even) more arrogant nerd, I looked down on Microsoft and their stupid technologies: Visual Basic, Access, Word, and more. Simple, limited tools that I only saw ugly, half-broken systems built with. Until I saw a something by Steve Ballmer (I think), explaining that their strategy was to provide tools for those "99% developers". The ones who don't read HN, the ones who don't code…

If you think Microsoft produces user-centric and pain-free tools for developers you clearly don't have experience around Microsoft stuff. Most companies, not just FAANGs, use Linux extensively and this is not out of masochism.

don't worry, the Microsoft brigade will relax soon :P

Re: Building for the 99% Developers

#288

Post by finiteseries »

H1Supreme wrote: post #261
bikamonki wrote: post #212

I never jumped into the React wagon, just as I never took the Wordpress train. You do not hire an 18-wheeler to deliver a pizza. Engineers on any subject have one job: design the optimal solution, be it a bridge or an SPA to take online orders. React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. Even vanilla JS does the job in most cases. 99% developer feels com…

> React makes sense for FB's bloated, complex web app. Your CRUD app will do fine with far simpler dev tools. And that would be what? Exactly? I did a personal project last year that was vanilla HTML/CSS/Js, with some templating in Go (I know it's templating isn't the best, comparatively). By the end, I wish I would have done it in React. I ended up re-inventing the wheel for a lot of things, and ended up with someth…

Tools actually intended for building non bloated, non complex CRUD apps. Django, Rails, Laravel, .NET, Spring, I can go on.

Instead Go was selected, templating HTML by hand, and assumedly doing nearly everything else by hand well. That is not the optimal solution for a simple CRUD app’s implementation, and isn’t reflective of anything but poor engineering.

Re: Building for the 99% Developers

#289

Post by pcstl »

sdevonoes wrote: post #175
pcstl wrote: post #21

Earlier quoted context omitted.

Out of sincere curiosity: Why do you think GraphQL is so bad? I've been using GraphQL for a little while now and I've had nothing but good experiences (although my use case might not be the most common) so I'm interested in knowing what makes you think so poorly of it.

> Why do you think GraphQL is so bad? It is relatively bad compared to the alternatives (plain good old http apis)

Guess it depends on use case. When it's not very clear what your client wants to consume and your product is evolving rapidly, HTTP APIs tend to turn into a mess and lead to a gigantic amount of requests just to start the app (which, to be fair, is less of a problem now with HTTP/3).

GraphQL has allowed my company to keep our network traffic very lean while evolving a product very quickly and to have very few issues in communicating between our mobile application and backend teams. But once again, I can see how our requirements are not everyone else's.

Re: Building for the 99% Developers

#290

Post by pcstl »

oleg_antonyan wrote: post #34
pcstl wrote: post #21

Earlier quoted context omitted.

Out of sincere curiosity: Why do you think GraphQL is so bad? I've been using GraphQL for a little while now and I've had nothing but good experiences (although my use case might not be the most common) so I'm interested in knowing what makes you think so poorly of it.

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…

In my case, it feels like GraphQL has allowed me to handle a product with very rapidly changing needs without turning our network communication into a gigantic mess with dozens of requests happening for every little thing - which is my previous experience with REST APIs.
Post reply on HN