Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your tech stack is not the product

hoho.com

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Your tech stack is not the product

#111

Post by ummonk »

yowlingcat wrote: post #76
ummonk wrote: post #73

I don’t disagree with the sentiment and point of the article. That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion doll…

Sure. I think I'd maybe go one step further than the headline and say that for startups, unless it is what you are explicitly building from scratch and selling, your tech stack should never be the product. Laying the right technical foundations shouldn't be difficult -- it should be generally be picking the most boring[1], dependable choices that you've been able to rely upon in the past. [1] https://mcfunley.com/cho…

I had a pretty negative reaction to that title but completely agree with the post (and largely with the example choices). I think I'd rephrase it more as "choose proven technology", cause "boring" to me conjures up images of Java hell.

Re: Your tech stack is not the product

#112

Post by ummonk »

dmitriid wrote: post #2

Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product/service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems. Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring "old-school" tech. The product is paramount, not the tech.

I mean, Facebook ended up forking PHP and writing their own type system and execution environment to make it work after they had scaled up...

Re: Your tech stack is not the product

#114

Post by dmitriid »

ummonk wrote: post #112
dmitriid wrote: post #2

Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product/service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems. Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring "old-school" tech. The product is paramount, not the tech.

I mean, Facebook ended up forking PHP and writing their own type system and execution environment to make it work after they had scaled up...

Keyword: after they scaled up. First they became Facebook :)

Re: Your tech stack is not the product

#115

Post by lll-o-lll »

escapedmoose wrote: post #108
throwaway09432 wrote: post #103

Earlier quoted context omitted.

>I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy That's life. Did you call up the bus company and thank them for engineering a bus to get you to work safely?

No, but some guy somewhere has dozens of model buses lined up in a basement where he lovingly paints tiny details on them while listening to Bus Stop Announcement ASMR

Not going to lie, that sounds completely awesome.

Re: Your tech stack is not the product

#116

Post by unity1001 »

PaybackTony wrote: post #5

This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_. Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experi…

This is one of the best comments ever in HN. Every engineer should understand this. Users don't care about what's behind. They care about whether it works and its easy. All the rest is irrelevant to them. We engineers tend to think 'but if this particular thing X happens in the code/stack and causes this particular problem Y, it will cause a Z% percentage problem and this will affect the user experience'. But in the end, for the overwhelming majority of the cases what ends up happening on the user side ends up being something unnoticeable to the user. Causing a lot of time to be spent for something that the users dont care about.

It feels more like we engineers use such logic of 'better code/application' to justify ourselves doing what we would like to do and build with the code than anything else that is related to the user.

Re: Your tech stack is not the product

#117

Post by unity1001 »

quanticle wrote: post #7
PaybackTony wrote: post #5

This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_. Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experi…

Nobody cares what your code looks like. Nobody cares what your architecture looks like. … until it breaks. Nobody cared how the FAA NOTAM database was implemented either, until it went down. Part of being a professional engineer is thinking about these things, so your users won't have to.

For each case like NOTAM database going down, there are tens of thousands of applications running on the web and outside the web without people obsessing about its architecture.

Re: Your tech stack is not the product

#118

Post by 8n4vidtmkvmk »

lll-o-lll wrote: post #77
adrianmonk wrote: post #70

Earlier quoted context omitted.

Nobody cares if your warehouse is neat and clean. Your customers never go in there. They just receive orders that are shipped out of it. But if your warehouse is a mess, if the aisles of your warehouse are blocked by crates strewn everywhere (that you've been meaning to put away for ages), then it does matter if your warehouse is neat and clean because it takes forever to maneuver your forklift in to retrieve product…

The difference between software and most other forms of engineering is that the internals of software are invisible to everyone but the developers. A manager walks in to the warehouse you describe above and goes “what in the literal hell? No one goes home until we clean this $&@$ up!”. A machine that has been poorly designed looks like a piece crap. Software, if the UI looks nice the massive tangled mess inside is co…

Technical managers do look at code...they often don't really "see" the problems until they try to implement something tho.

Re: Your tech stack is not the product

#119

Post by KronisLV »

escapedmoose wrote: post #108
throwaway09432 wrote: post #103

Earlier quoted context omitted.

>I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy That's life. Did you call up the bus company and thank them for engineering a bus to get you to work safely?

No, but some guy somewhere has dozens of model buses lined up in a basement where he lovingly paints tiny details on them while listening to Bus Stop Announcement ASMR

Hah, there are also various bus simulator games out there, trucking games and for some reason trains especially.

Not just tycoon games (like Transport Fever) but also ones that focus a lot on the details (Euro Truck Simulator seems to be a big one).

While we take lots of things for granted, there are always niche communities and people who like all of the details and whatnot.

It's very much the same how many might use languages without caring about how the GC works (where applicable) or use frameworks without caring about their internals, because they don't have to. And then there are those who do deep dives and sometimes come up with nice improvements or even just articles or videos about that stuff.

It's quite cool.

Re: Your tech stack is not the product

#120

Post by [deleted] »

neilv wrote: post #26

> If we pick exotic technology, it’ll be harder to hire (and we won’t ship as much product). If you need to do something that's not just generic CRUD app/site... picking an exotic technology that high-powered programmers love , might make it easier to hire. Compare: "We're building a gig economy app to clean gas station bathrooms, and we eat our own dogfood!" to: "We're USING RUST to build something (not a crypto sca…

[deleted]
Post reply on HN