Yep, great write-up . I spent so many years in companies that were perpetually behind the times and rarely catching up. I now work for a large scale SAAS offering trying to sell to these developers. It's consistently an up hill battle trying to sell my peers on the realities outside their bubble, but it seems pretty fruitless.
Building for the 99% Developers
41–50 of 310 posts
Re: Building for the 99% Developers
#4299% 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…
The point the article raises is whether those "non-FAANG engineers" should be using serverless at all.
Will their requirements ever scale to a point where it actually makes sense for them to be deployed as serverless services?
Re: Building for the 99% Developers
#43IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy
It'd be a nightmare to support for anything more than trivially simple, though.
Re: Building for the 99% Developers
#44We way over complicate things. SQLite can be used for 95% of real world use cases. And whenever WAL2 + BEGIN CONCURRENT get merged into main, it will be able to handle 99% use cases. And don’t fool yourself into believing you’re not in that 1%.
> WAL2 + BEGIN CONCURRENT
Woah. There are some gotchas. It still won't support as much concurrency as row-level MVCC. But it'll still be a big improvement.
https://www.sqlite.org/cgi/src/doc/wal2/doc/wal2.md
https://www.sqlite.org/src/doc/begin-concurrent/doc/begin_co...
Re: Building for the 99% Developers
#45Earlier quoted context omitted.
Strongly disagree about it being (successful) resume driven development mostly. Most developer's resumes would be vastly enhanced by delivering a lean, technically successful product to end users, or 5. A lot of developers think playing with cool technology makes them better developers for some reason. Which isn't true. What makes them better developers is knowing what that technology does , and choosing the appropri…
Yeah, that is not what recruiters seem to care about. Nor what is tested in interviews.
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 careers.
Re: Building for the 99% Developers
#46You'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'…
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…
Scale vertically and you're still a single point of failure away from a big, potentially fatal outage. The coding and architecture can often be trivial though. Definitely good for internal systems and more green programmers.
Scale horizontally and you're often constraining and or complicating your design/architecture, but you can handle outages far better, if not seamlessly. It's much harder to get right, so it's usually best for more senior teams that have specific need for it.
Re: Building for the 99% Developers
#47This article didn’t resonate with me as much as I was expecting. While the insights on developer influencers was sharp, the article itself felt like more of a reaction than an evaluation. I’ve worked in many legacy companies. The rationale for staying on the tech stack they have, and the approach they take to DevOps, is not particularly well reasoned. Often they are experiencing painful consequences due to their adhe…
I think the point that should be well taken is that if you're hoping to service the greater programming community, you can't do so in your ivory tower solutions on a community Ill equipped to utilize them. From experience, DevOps done poorly is terrible and demoralizing. Agile done poorly (often) is terrible and slow. Take any best practice and try to apply it to any organization and you'll get a lot of flaming wreckage. Ideally those companies will have some pragmatic people that can nudge their people in the right direction gradually.
Re: Building for the 99% Developers
#48IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy
Strongly disagree about it being (successful) resume driven development mostly. Most developer's resumes would be vastly enhanced by delivering a lean, technically successful product to end users, or 5. A lot of developers think playing with cool technology makes them better developers for some reason. Which isn't true. What makes them better developers is knowing what that technology does , and choosing the appropri…
In a past life, we were reading from twitter firehose and the offshore implemented a solution that spawns a large spark cluster to read from twitter, dumps it to kinesis, then has a cloud function that writes it to dynamo, then merged it into redshift.
It worked poorly, took months to build, and lost data. I implemented a python script that read from twitter firehose and wrote directly to redshift. It was about 50 lines long and did the same thing, and I deployed it to two existing prod servers that were not network bound.
There was a few more cases like the on-shore database identity reconciliation being inefficient, so the company wanted to leverage cloud auto scaling. Well, if you have an exponential time algorithm and you put it into the cloud, it will still be exponential time and cloud auto-scaling will be extremely expensive, and also introduce latency between distributed system components, and indeed it was. The offshore teams initial logic was only that, cloud is auto scaling so can accommodate any performance the business logic needed.
Sometimes people just view tech/cloud as lego blocks to glue together, based on the product sheet marketing, and do not have enough basic understanding of computer science to understand performance, or understand what a simple solution would look like
Re: Building for the 99% Developers
#49IME most small software companies could be run off SQLite, a $5 linux VPS, vanilla JS, and a single line deploy script. (Pieter Levels seems like the master at this) I'd never bother suggesting it though: - no one likes being told they're small when they think they're big - it's bad for devs careers (Resume-Driven Development) - as TFA points out - it's not what FAANG are doing so I'd lack legitimacy
[deleted]
Re: Building for the 99% Developers
#50a16z invested to Replay, "The Time Travel Debugger for Web Development". Go read about it here https://medium.com/replay-io/launching-replay-the-time-trave... and read this again. It all makes sense.
Are you implying that a16z wants websites to be as difficult as possible to maintain that a tool like this is necessary?