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

61–70 of 310 posts

Re: Building for the 99% Developers

#61

Post by scarface74 »

JimmyRuska wrote: post #48
urthor wrote: post #37

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

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

You wrote individual insert statements to RedShift?

Re: Building for the 99% Developers

#62

Post by oxplot »

Here are my rules for picking framework/languages:

- Avoid if specifically mentions big companies as users: Facebook, Twitter, Google, these have as many devs as needed to throw at the most trivial tasks, and then some. I am in a team of 3 that need to get shit done, not chase package manager and compiler throw-ups. Tell me your language is used by a one person show to serve millions of people and then I'll listen.

- Avoid if the developer base is mostly young people: They are energetic and they don't mind complicating the shit out of something, because they can figure it out now and probably down the road. I'm old, and I just want things to work and I want to understand how it all works without spending a week and wrestling with tooling. Not all out-of-college folks are the same but most are (and I used to be one, so there).

- Avoid kitchen sinks: borrowing ideas sparingly is fine - throwing in every new feature in another language you come across makes for a soup, not a tool. A good heuristics is the rate at which features are added. Look for logarithmic trend.

Re: Building for the 99% Developers

#63

Post by Yhippa »

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

The best part is when a company is building a line-of-business app which they know will get maybe a hundred users and end up throwing tools and processes at it that are complete overkill.

Re: Building for the 99% Developers

#64

Post by pm90 »

austincheney wrote: post #7

My personal recommendation is to do some self reflection on what things are most important to you when it comes to spinning up a new project and build your own kit. This is your tool bag as a developer. I have seen a lot of people try this and fail because they aren’t building a personalized kit, they are putting together popular dependencies. That is radically different. When you build your own kit it is tiny and ex…

What happens when you work at a company that uses a different stack though? Can’t force a Java shop to start using Golang just because I like it and have developed my experience around it.

Re: Building for the 99% Developers

#66

Post by fvold »

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…

For the last few days I've been rewriting one of the company's legacy WordPress plugins to work better with modern WooCommerce.

That's right: PHP, baby. Ugly, hacky, sticky, oozing PHP.

Oh woe is me, etc etc, but you know what? It makes the customers money, which makes the company money, which makes me money. I've gotten used to eating and living indoors, so this is a good thing.

It's not serverless, there is no GraphQL, it's not within a mile of the nearest Rust compiler and it could not be implemented in golang even in my wildest fever dreams, with or without generics. There isn't even any machine learning!

We need to keep in mind the trillions of lines of legacy code out there that is still being maintained, refactored and rewritten, every day, that is not a new product or a groundbreaking new paradigm. It's just the internet, and the hacky PHP and smooth perl5 that keeps it running.

So yeah, 99% might be an exaggeration, but if I was making a new IDE (or whatever) today, I'd sure as hell target WordPress before I started making up my own buzzwords. I can't say for sure if that's because of my perspective or because of some objective data, but I do know that it would be a product with a hell of a lot more customers.

Re: Building for the 99% Developers

#67

Post by strken »

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…

I've used graphql at a small company because it solved a specific problem we had, which was how to deduplicate all our kludgy page-specific views and let front end devs write new ones easily. I've also written runbooks and playbooks and used lambda functions to grab webhook payloads.

The given examples are really weird to me because they're some of the few things from gigantic companies that actually work properly.

Re: Building for the 99% Developers

#68

Post by cheriot »

In a lot of ways, large tech companies are living in the future. They have to invent things that later open source tools will imitate and then others start to use. Examples: map reduce, various rpc standards like graphql and grpc, and a whole mess of non-relational data stores. I work with kubernetes a lot right now and it's effectively a smaller, less featurefull version of what google runs on, but it's light years ahead of what we were using before.

A huge portion of the industry will be 10, 20, even 30 years behind and that's fine. I don't think there's any myths about this.

Re: Building for the 99% Developers

#69

Post by macintux »

pmarreck wrote: post #9

On the one hand, your MVP version 1.0 should probably be built in anything that is fast and works. On the other hand, you're gonna want to rebuild that ASAP in something that has legs for longevity's and paying down tech debt's sake. You won't potentially have an edge over any competitors by using their same tech stack.

I suspect that for most companies, the tech stack they run, the custom software on top of it, isn’t meant to be a competitive advantage. It’s just the cost of doing business.

Re: Building for the 99% Developers

#70

Post by macintux »

pm90 wrote: post #64
austincheney wrote: post #7

My personal recommendation is to do some self reflection on what things are most important to you when it comes to spinning up a new project and build your own kit. This is your tool bag as a developer. I have seen a lot of people try this and fail because they aren’t building a personalized kit, they are putting together popular dependencies. That is radically different. When you build your own kit it is tiny and ex…

What happens when you work at a company that uses a different stack though? Can’t force a Java shop to start using Golang just because I like it and have developed my experience around it.

Unless you’re a megalomaniac CTO. Amazing what companies will do (typically disastrously) when a new CTO arrives.
Post reply on HN