Live data from Hacker News

Building for the 99% Developers

future.a16z.com

231–240 of 310 posts

Re: Building for the 99% Developers

#231
post #12

>"Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability…

I am curious to know how you evaluate a new development product in respect to the ROI? What characteristics should a product have to satisfy your criteria for considering it?

Example - I have JSON based RPC so that systems from other vendors can talk to mine (enterprise backends written in C++). It works like a charm and has ben doing so for years. Here comes this architecture astronaut and tells ma that I should do GraphQL and proceeds to explain me how powerful and cool it is and how everybody and his cat uses it. So on the downside I will waste a gobbles of time and money, on upside - zilch because nobody gives a shit. The problem is already solved for us year ago so buzz off. And that guy could not give a single example of how it can help me. Just spreading FUD about existing things.

There are numerous opposite examples when I see that this new tech, lib, tool actually saves me time and money. I pay quite a few dollars for software tooling. Well if the tool does not offer perpetual license it is a no go for me then.

This is all that matters to me. On desktop for example I skipped moving to that .NET bandwagon and stayed with Delphi for my GUI desktop products. They worked 20 years ago and they work the same now. Single 10MB self updating exe with zero deployment issue. And free from numerous limitations imposed by UWP. Competitor is 1GB package with crapload of problems and every update turns a nightmare for customers. In my case all the time is spent creative stuff that brings me new customers / money instead of feeding someone else. Sure it costs me few hundred a year but that is peanuts.

Re: Building for the 99% Developers

#232

Earlier quoted context omitted.

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…

>why the vast majority of developers prefer to develop on Windows Was that ever true?

Now? Maybe not, even though it's hard to find exact numbers for that.

From 1995 until 2010, at least? For sure.

It was a crushing majority, even.

Re: Building for the 99% Developers

#233
post #228

Earlier quoted context omitted.

Windows is an ecosystem, linux is an OS... that's the difference. For the most part, Windows is far far easier to configure and maintain than linux based systems (and I say this as someone who runs a large enterprise system with Windows, Fedora, Debian, OpenBSD, FreeBSD, SoNIC, Dell OS10, MacOS, Azure... etc, all mixed together).

I would love for you to come work at my company when I was told I couldn't connect my Mac to the VPN "because the network can't support OSX" which is a sentence that doesn't even begin to make sense for me.

That's regular user speak.

The user won't care about intricacies, but they've heard of the words "network" and "support" and they'll understand the gist of the problem.

Re: Building for the 99% Developers

#234
post #189

Earlier quoted context omitted.

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 thing. Of course your competitors will do the same, you can't scale up an organization of top 1% professionals, so you don't really need them to compete in the market but you do really need them to solve a lot of problems. Just that today those…

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? Because I'm not a genius. But I'm real good at stapling together some useful crap.

You'll probably get a long list of stuff that includes things such as:

OSes, compilers, game engines, distributed process frameworks, etc.

Which as you'll note, are infrastructure things. Things which need 1/100th the manpower (at most!) to maintain.

While everyone else is busy churning user-facing apps.

You don't need to do that stuff, you career can be extremely successful without ever going near those things, especially if you are not interested in them.

Re: Building for the 99% Developers

#235

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…

> Everyone for whom coding is something that gets in the way of their real objective. While tech is (allegedly) evolving as fast as ever, the problems to be solved often do not. Sure, scale is always an issue and you want to reduce maintenance. But how many project do you have that have to scale to millions of users? > Visual Basic, Access Very true, but those tools have evolved as well. Sure, everyone laughs about p…

Can you hook Access up to SQL Server? If so, yeah, most of its problems go away and you give regular users a ton of power.

Re: Building for the 99% Developers

#236

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…

>Visual Basic, Access, Word, and more.

And Visual FoxPro. Perhaps the most underrated tools for SME. And possibly one of the reason why CRM and ERP have a hard time breaking into those market.

And this is going to be rant-ish..

Then somewhere along the line came Google. Yes I absolutely blame them ( In terms of mentality ). Instead of Microsoft which at the time was the ultimate evil company, providing tools ( not even programming or code, but "tools" ) to 99% of developers. We got Google, representing "real nerds" on the opposite side of spectrum telling you these technology are utter piece of crap and ours are the greatest. The proper way to do it. Embrace complexity to its maximum. And of course a lot of people were sold. Nerd could finally get rid of all the ugliness from computing. Visual Basic? Ugh. Learn a proper programming language. PHP? ROFL.

And of course there is Resume Driven Development. The actual technology in itself doesn't matter. What matter is if MAMAAN are using it. So you have a better chance or joining them.

There is no fun in computing anymore, not for the 99% developers, and even more so for those who only wants to be 99% developers.

Re: Building for the 99% Developers

#237
post #225

Earlier quoted context omitted.

>why the vast majority of developers prefer to develop on Windows Was that ever true?

It was true then and it's true today. Certainly not in HN or at 8-person startups nobody's ever heard of, but the vast majority of developers work on boring business software in Windows.

Why is it at every tech conference you see a vast preponderance of Mac's? Are conf goers not representative?

Re: Building for the 99% Developers

#238

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…

Isn't that called no-code or low-code these days? To make software for the generic public who does not have a CS/EE/Physics/Math degree?

Re: Building for the 99% Developers

#239
post #235

Earlier quoted context omitted.

> Everyone for whom coding is something that gets in the way of their real objective. While tech is (allegedly) evolving as fast as ever, the problems to be solved often do not. Sure, scale is always an issue and you want to reduce maintenance. But how many project do you have that have to scale to millions of users? > Visual Basic, Access Very true, but those tools have evolved as well. Sure, everyone laughs about p…

Can you hook Access up to SQL Server? If so, yeah, most of its problems go away and you give regular users a ton of power.

Yes, that is the usual way how it is used today. It is used as a frontend to quickly generate queries against a backend SQL server and make some fancy pivot tables.

Very rarely is the data stored in the Access file itself.

Re: Building for the 99% Developers

#240
post #189

Earlier quoted context omitted.

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 thing. Of course your competitors will do the same, you can't scale up an organization of top 1% professionals, so you don't really need them to compete in the market but you do really need them to solve a lot of problems. Just that today those…

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? Because I'm not a genius. But I'm real good at stapling together some useful crap.

Building a high availability system? The downtime (especially scheduled downtime) of many of these "99%" services is shocking compared to the cutting edge consumer services we're used to. The "hug of death" is an affectionate meme that basically describes the remarkably common scenario where a "99%" website goes down at the precise moment at where it's peaking in popularity and profitability.

Or how about high performance? Google famously knows that every millisecond of delay strongly impacts user retention and bounce rate, yet you wouldn't know it browsing many "99%" services. Achieving consistently low end-to-end latency is really hard regardless of scale, it's so easy for performance issues to creep in from every corner of your stack and accumulate.

These are hard problems and IMO they are rarely solved well by just stapling together some useful crap.

Post reply on HN