Live data from Hacker News

Building for the 99% Developers

future.a16z.com

301–310 of 310 posts

Re: Building for the 99% Developers

#301

Earlier quoted context omitted.

In other words, does a16z ask for startups to attack MS on their home turf? There can be a niche for the product creation stage. But how does a company scale in MS's market? Sooner or later, it's a Slack vs MS Teams situation.

To be fair, slack kinda messed up themselves. I am still astonished that they never built video calling. Like MS did use their existing sales channels to stop slack growing, but if slack at least had feature parity with Teams then it would have been a harder sell.

Microsoft also tried to M&A Slack before building Teams. As far as exits go, Slack may go down in history as a particularly not-smart one: they were allegedly quite rude in refusing the M&A offer for what might have been a "golden" exit, encouraging Microsoft to build a competitor in a hustle, and then their later exit to Salesforce was a lot less "golden" and at a lesser valuation due in part to the competitor they helped create through their alleged rudeness.

(ETA: Of course, easy to spin things the other direction and read Microsoft's offer as a bully move "join us or we'll build a better you without you". The reality is somewhere in the middle of the two extreme perspectives.)

Re: Building for the 99% Developers

#302

Earlier quoted context omitted.

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 singl…

I'm not entirely sure you're responding to my main point. The point is that tripling hosting costs is the "99%" naive solution to avoiding outages. The point is that smart people invent cost effective solutions to outage issues that don't involve tripling hosting costs. The point is that "99%" are ignoring these smart technical solutions because they can't do it, but they are still problems nonetheless. The point is that these smart inventors are not "circus jugglers" as derisively described by a parent comment, they provide real value that the "99%" reflexively dismiss because apparently the best solution to outages they can muster is to triple hosting costs, real value that you don't get by just stapling useful shit together.

The point is that when someone asks "As one of the 99%. What are some of these problems exactly, that me and my extremely large toolkit of cool things I can curl from Github can't solve?", the answer is "so you can build a cost effective system that doesn't take down the east coast power grid because a single computer goes down".

Yeah, reddit is notorious for its downtime issues. They're notorious because it's actually rather unusual in the consumer space to be so bad, they kind of suck compared to the majority of their high tech competitors.

Re: Building for the 99% Developers

#303
post #80

Earlier quoted context omitted.

You're not the only commenter saying this, so I gotta ask: whatever VM that SQLite DB is on, is your business cool with a business disruption, dataloss, or both when that VM goes down, when that AZ goes down, or that disk fails? Or am I missing something? If you have some sort of fail-over-to-last-backup plan, is that not just a distributed database with more steps, and why not something like RDS, or CockroachDB? (Fr…

> is your business cool with a business disruption Every few years in Seattle, there's a big snowstorm, and everything just shuts down. We live. If a service goes down once in a blue moon, I could catch up my email, spend some time morale building with my team, or, god forbid, just go home because work isn't that important.

I mean … perhaps. But it's not my call, and of the places I've worked … that's not been the business decision that gets made.

Re: Building for the 99% Developers

#304

Earlier quoted context omitted.

… I'm in a small company, and we "use" serverless. I've never once asked myself "Should I move to serverless?" It's just whether, for some application, it's the right tool. We run a few Github bots & a function that updates a Route 53 record on serverless. (Security didn't want to give permission to R53; "too much, too broad"; a lambda that exposed only the necessary action to the service that required it was the com…

You have to have a VM to run a _single_ service? You have no multi-application VMs?

> You have to have a VM to run a _single_ service?

This is extremely common, in my experience. (Like it's a default tendency of nature.)

So, the VMs example was my previous employer. An yep, not really any multi-app VMs. There were some that did do a couple of things, but it wasn't great: it meant the deployment and dependencies of anything sharing a VM were all interdependent … and often under specified. Painful.

It's why Kubernetes exists, really. (Which is funny how much hate it & Docker seem to get on HN.) In my current employ, we do use k8s, and while much runs on it, and it's nice, we still haves some single-service VMs. I'd like to move them all into k8s if at all possible, but it is not always possible. Or it's not always that time gets dedicated to it.

Re: Building for the 99% Developers

#305

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…

Yep the world is full of in-experienced, arrogant, self-congratulating developers who thinks they know it all while having zero clue on what is really going on. They are easy to identify. The moment they say things like “all X developers are crap” or “all software developed by super successful company X is crap” or “developers using technology X are stupid” or “smart developers who gets it use X” you know you have identified one. Run (don’t walk) away from them. They are toxic and should be avoided at all cost.

Re: Building for the 99% Developers

#306

Earlier quoted context omitted.

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.

The games market for Linux is tiny. Usually not worth the cost for developers.

Re: Building for the 99% Developers

#307
post #296
post #291

Earlier quoted context omitted.

That's the thing, I think a lot of those are, if not solved, problems where there's a lot of really well established good solutions that exist. I could, I guess, tackle them. But I've got an appreciation that what's already there is already pretty great. I suppose that's maybe the answer to my question. You don't need to be 1% to solve a problem as well as the solutions that already exist. You need to be the 1% to im…

For various reasons (usually control, but frequently spun as "needing to be cutting edge"), some groups or companies do reinvent those wheels and in some lucky cases we get progress. For example Google has recreated several of those things and especially in the data storage field they've probably moved things forward. But in general I agree with you, the crushing majority of developers out there won't work on those t…

Elitism is driven by ego and self actualization though.

I think there's a lot of people who are highly, highly motivated to work on tough problems with competent co-workers.

Those emotions are less driven by the domain itself, and more about the fact that those people have succeeded in finding meaningful work with co-workers of appreciable worth.

The tricky thing I find is finding that. Far too many regular projects are focused on mobilizing the dumbest blocks of wood towards a goal. Without actually investing in the human beings doing the work.

I think once we regain a culture of actually investing in people who aren't in the top 10% in their field, things can change. Currently though we do not have that culture.

Re: Building for the 99% Developers

#308
post #105

Earlier quoted context omitted.

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!

It's more that they've cheated a bit.

8 socket NUMA is a bit of a silly one, but it has been around in enterprise tech for a LONG time.

Re: Building for the 99% Developers

#309
post #297

Earlier quoted context omitted.

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…

I've seen more sloppy code being kept and built upon, than any code being thrown away. Once it is sloppy, it does not get easier to make code unsloppy as time goes by. Of course, "not sloppy" does not mean perfect; but it does mean understandable, testable, maintainable and extensible.

I agree on the importance of always striving to write not sloppy code. It is especially critical if you are building a system which must scale and must be maintained over a long time. Trying to avoid sloppy code is one of the things that can make programming a rewarding if challenging experience.

> understandable, testable, maintainable and extensible.

Those are all adjectives, just like "sloppy" is. So we must each make the decision as to how much effort we will invest in making code MORE understandable, MORE testable, MORE maintainable and MORE extensible.

If the value of any of those properties is 0, then the code is definitely sloppy.

Re: Building for the 99% Developers

#310

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…

The latest Microsoft stack is easily one of the most productive development ecosystems that exists today. Just look at the default contents of .NET6 vs everything else out there and it doesn't even seem fair anymore. We build a product for financial institutions that serves interfaces to multiple classes of devices and integrates with 15+ different 3rd party systems. It has to address concerns of multiple lines of bu…

What do you mean by "default contents"?
Post reply on HN