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

171–180 of 310 posts

Re: Building for the 99% Developers

#171

Post by pjmlp »

bjterry wrote: post #19

99% feels like an exaggeration. I've talked to many developers from non-FAANG companies, and it isn't at all uncommon for them to be using GraphQL or serverless. I guess there is some selection bias since they are usually applying to a unicorn, so they are probably more likely to come from environments that fit the "1%". Whether this distinction is relevant to you depends on where you sit. If you are a startup sellin…

As one that usually works in the 99% developer space, when we adopt stuff like GraphQL or serverless, is mostly because we are forced into it by new products, or they were the sales pitch to get new consulting gigs.

Re: Building for the 99% Developers

#172

Post by pjmlp »

ju-st wrote: post #106
lumost wrote: post #45

Earlier quoted context omitted.

50/50 It's what employers look for in Senior Engineers, but junior engineers are often hired on pure tech. Historically there was a high amount of BS where people would take credit for deliveries that they were only tangentially a part of, or get ridiculously lucky on their first big project. It's next to impossible to hold an engineering team together to even KTLO if you don't have some project which grow's their ca…

The number one requirement for Senior Engineers is their extensive experience with the company's tech stack. At least that is what is written in job ads outside of FAANG. You're probably not passing the HR stage when you have experience in Java but the company is looking for a senior .NET developer.

Kind of, yes you are right, however sometimes it is possible to balance it wiht other senior skills that are technology agnostic.

So one might not get in due to lacking .NET skills, but the other enterprise architecture and soft skills will be just as relevant.

Then it is up to the person to sell themselves.

Source, I have been jumping across .NET, Java, C++, native and Web for almost 30 years now.

Re: Building for the 99% Developers

#173

Post by Dudeman112 »

Jensson wrote: post #139
jl6 wrote: post #131

Earlier quoted context omitted.

99% programmers need to pick up stuff, carry stuff, and throw stuff. 1% programmers are like circus jugglers - the same basic thing, but taken to a breathtaking extreme. They are skilful and impressive, but the scenarios where you need them are rare.

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…

>can't do and therefore just dismiss many solutions without thinking since you know the 99% can't do those thing

Is that assessment accurate to reality? How would we know if the bottleneck for most business is "my employees aren't good enough to solve hard technical problems" or "most of our problems aren't hard technical problems"?

Re: Building for the 99% Developers

#174

Post by [deleted] »

mro_name wrote: post #140
just-tom wrote: post #134

Earlier quoted context omitted.

I'd argue the opposite. All Microsoft did was understand what the world needed. Were they successful because of their great marketing or their flawless coding? No. Was Windows spread like a wildfire because it solved real world problems? Yes. Is it one of the most, if not the most, influencial software ever made? Yes, no matter how dull and incompetent people might say it is. For the accountants out there, school tea…

it was the only thing they could get. No wonder it looked magic.

[deleted]

Re: Building for the 99% Developers

#175

Post by sdevonoes »

pcstl wrote: post #21
dham wrote: post #14

Earlier quoted context omitted.

Unfortunately a lot of companies right now. Although the smart ones have already done the switch and are now trying to switch off. I've seen a lot of suspect technologies in my career but GraphQL is definitely the worst

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)

Re: Building for the 99% Developers

#176

Post by disgruntledphd2 »

randomsilence wrote: post #154
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…

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.

Re: Building for the 99% Developers

#177

Post by mschuster91 »

> For instance, companies with legacy systems that can’t afford to migrate to the newest architectures need to adopt new tools differently than newer companies, or companies that can dedicate a team to a large migration.

Not to mention, this sort of company needs to do a careful evaluation if the chosen product and especially support for it is likely to be around for a while. Many got bitten hard by Angular's demise - and now imagine this for something like a database that's supposed to hold your entire corporate data.

Re: Building for the 99% Developers

#178

Post by rad_gruchalski »

olalonde wrote: post #159
bob1029 wrote: post #158

Earlier quoted context omitted.

The traditional pattern of one connection per transaction is actually a strong anti-pattern when working with SQLite in particular. This is because SQLite is just a file, not a network connection or named pipe. Obtaining and releasing file handles is a non-trivial task that takes significantly longer than reusing the same one.

That's what I meant with "opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example)". I was suggesting to only use a single connection for the entire request and NOT to use a connection pooling library. Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests. That's just a sad fact a…

> I don't think there's a reasonable way around it other than not using PHP.

Or not using SQLite for this task?

Re: Building for the 99% Developers

#179

Post by juliendorra »

mro_name wrote: post #167
js8 wrote: post #166

Earlier quoted context omitted.

Macintosh, OS/2, WordPerfect, WordStar, Ami Pro, Quattro Pro.. to name just a few alternatives.

you don't believe accountants care about anything but the market leader, do you?

Microsoft wasn’t the clear market leader in the 70s and 80s. Look for example at the spreadsheet. Multiplan was loosing against Lotus 123. (123 being the VisiCalc killer itself) Microsoft first launched Multiplan as its spreadsheet software on Macintosh (1984), it was something like the 22th or 23rd port of Multiplan! Then in 1985 very first version of Excel (Macintosh only) It was an incredible step up from text-screen spreadsheet softwares, but only on Macintosh so Lotus didn’t cared. Then Excel 2.0 got released (1 year before windows, using the windows window manager underneath!) and as people who saw it at the time remember thinking: "lotus was toast"

I studied the spreadsheet applications design history to Create my class History of Tech Design [0] and got a totally new perspective on how good the excel team was at getting things right.

[0] https://workflowy.com/s/strate-history-of-te/a4ID6kKtznLwQC7...

Re: Building for the 99% Developers

#180

Post by mschuster91 »

olalonde wrote: post #159
bob1029 wrote: post #158

Earlier quoted context omitted.

The traditional pattern of one connection per transaction is actually a strong anti-pattern when working with SQLite in particular. This is because SQLite is just a file, not a network connection or named pipe. Obtaining and releasing file handles is a non-trivial task that takes significantly longer than reusing the same one.

That's what I meant with "opening multiple connections doesn't increase concurrency so don't do it unnecessarily (by using a connection pooling library for example)". I was suggesting to only use a single connection for the entire request and NOT to use a connection pooling library. Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests. That's just a sad fact a…

> Now, PHP doesn't share memory between requests so there's no way to re-use the same connection across requests.

That depends on the execution model/PHP SAPI. mod_php and php-fpm use long-lived PHP processes and so can support persistent database connections depending on the configuration.

Post reply on HN