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

121–130 of 310 posts

Re: Building for the 99% Developers

#121

Post by gocartStatue »

AnotherGoodName wrote: post #8

You'd be surprised at how fast you can create something with an SQL database, a well used backend framework (eg. Rails) and a well used frontend framework. The things big tech companies do are usually to avoid scaling problems. In particular scaling on the engineering side. The above can scale to billions on the user side if needed but 10k engineers constantly updating and messing with a traditional SQL schema doesn'…

I would not be surprised, but it easily becomes a trap once you grow. With CRUDs / "Smart UI's" I'd always sign a contract in blood / note in ADR that we choose this to prototype quickly, but we'll stop and rebuild it before someone asks if he can "save his 20 fields grid filter he has to click through every day".

Or (another Greg Young reference) - optimize for the ability to delete your code.

Re: Building for the 99% Developers

#122

Post by vasco »

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…

Your argument suffers from the fact that Ballmer almost tanked the company, so perhaps this rosy look back isn't the whole story, and you need to focus a bit on "get things done" and a bit on "maintain it for the future", it's not as simple as FAANG=good or FAANG=bad.

Unless you're happy that all those 99% developers have created towers of COBOL that run the world and they can't touch or upgrade.

Re: Building for the 99% Developers

#124

Post by math-dev »

mro_name wrote: post #113
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…

I think it's much more profane - Microsoft didn't understand what the real world needed, they just leveraged a monopoly (that IBM let them establish) to frame what a computer looks and feels. They shaped the world to their liking and now it looks like a match. duh.

Basically this

Re: Building for the 99% Developers

#125

Post by lvice »

zhughes3 wrote: post #118
brunoborges wrote: post #117

Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…

So you can’t scale java horizontally?

I don't know java, but that's not the message I got from the comment. It looks like with java, 3 VMs with 2 cores are better than 6 VMs with 1 core, which may be forgotten when configuring equivalent kubernetes services.

Re: Building for the 99% Developers

#126

Post by hvidgaard »

zhughes3 wrote: post #118
brunoborges wrote: post #117

Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…

So you can’t scale java horizontally?

I don't think you quite understood what (s)he wrote.

The problem is using JVM without understanding some basic properties of it. Scaling is a matter of how you programmed it, not the language used.

Re: Building for the 99% Developers

#127

Post by dgb23 »

brunoborges wrote: post #117

Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…

I have amateur level JVM knowledge, but what you describe here seems intuitive. It feels like a waste to split a JVM application like this. I‘ve read a bit about new advancements in GC design, they’ve become highly parallel and layered. And then there are all sorts of JIT optimizations that may happen in a more comprehensive, larger service, right?

Re: Building for the 99% Developers

#128

Post by piokoch »

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…

Partially I agree, partially I don't. I would say the long list of failed operation systems versions (Vista, Windows 98 ME) that were causing a lot of issues for users hit in a unwanted way all those small companies. Not that there was anything better at that time, Linux on desktop is still very problematic, but releasing crappy software will cause issues one way or the other.

Re: Building for the 99% Developers

#129

Post by hvidgaard »

ryandrake wrote: post #87
muglug wrote: 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…

In a corporate environment I insist on treating warnings as errors. They are warnings for a reason and it will lead to hard to debug errors in a sufficiently large codebase/team. Enabling it after the fact is a chore, but once it working its not much extra work.

Linting I only use for adding/correcting a file header, order or methods or other things that it can fix automatically.

Re: Building for the 99% Developers

#130

Post by eklavya »

zhughes3 wrote: post #118
brunoborges wrote: post #117

Reminds me of a frequent problem I observe with developers and operations teams moving Java workloads to Kubernetes. They focus on scalability, but miss the whole point of how the runtime (and not exclusive to the JVM) behaves - and prefers - when given proper resources. Suddenly, you see Kubernetes clusters of 2 to 4 vCPUs VMs/Nodes and containers with limits to 1,000 milicore (or 1 vCPU), and then the team solves t…

So you can’t scale java horizontally?

Their point is that you can and probably even reduce cost, but you need to decide on the atomic resource unit and whether that makes sense (like having a measly single core, low ram instance/container).
Post reply on HN