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

11–20 of 132 posts

Re: Your tech stack is not the product

#11

Post by bcrosby95 »

> Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will.

It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone in AWS, which is all many people resort to. And maybe we've just gotten lucky, but in general our very simple 20 machine colo center setup has been more reliable than our single region AWS setup.

But yeah, if you literally put Joe's computer in a closet it isn't gonna be too reliable for all sorts of reasons completely unrelated to the reliability of modern computer hardware.

Re: Your tech stack is not the product

#12

Post by AnIdiotOnTheNet »

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.

Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.

Re: Your tech stack is not the product

#13

Post by alfalfasprout »

AnIdiotOnTheNet wrote: post #12
quanticle wrote: post #7

Earlier quoted context omitted.

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.

Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.

I think the point still stands but in a different way. The architecture was designed to be quite reliable.

Re: Your tech stack is not the product

#14

Post by nfRfqX5n »

AnIdiotOnTheNet wrote: post #12
quanticle wrote: post #7

Earlier quoted context omitted.

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.

Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.

AWS uptime is pretty insane

Re: Your tech stack is not the product

#15

Post by pickledish »

I have to say I agree very much with his point, though not really the way he communicates it:

> Let’s riff. I’ve had my “macho engineer” days, I’ve built that stuff. Take me deep, I’m ready.

or

> No; customers are not paying for, nor give a shit about, these things. Sorry.

Just feels to me a bit condescending for no reason

Re: Your tech stack is not the product

#16

Post by iLoveOncall »

habitue wrote: post #9

> customers are not paying for, nor give a shit about, these things. Yes, but they do give a shit if: - your product is slow, so they assume it's crap and leave your site - your product breaks, no one notices or fixes it - your product is bad, because your wrote it in a safe boring technology like cobol and therefore couldn't access the best developers. (exaggeration, but variations on this are true) My point isn't t…

> - your product is slow, so they assume it's crap and leave your site

I don't think there any tech stack that will have any significant (or even just measurable) impact the speed of the product, for 99% of the startups.

> - your product breaks, no one notices or fixes it

This has nothing to do with the tech stack. You can setup monitoring, alarms and metrics for any tech stack.

> - your product is bad, because your wrote it in a boring technology like cobol and therefore couldn't access the best developers.

99% of startups won't be able to afford the best developers anyway. 99% of startups don't need the best developers. Average developers can make great products.

---

You are taking "your tech stack does not matter" and twist it into "You will have problems if you have the worst tech stack and the worst developers!". Cool, but that's not what the article is about.

Re: Your tech stack is not the product

#18

Post by themitigating »

bcrosby95 wrote: post #11

> Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will. It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone in AWS, which is all many people resort to. And maybe we've just gotten lucky, but in general our very simple 20 machine colo center…

"It's kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone"

I think that depends on the colo honestly. What is so unreliable about a single EC2 instance in a zone?

Re: Your tech stack is not the product

#19

Post by discussDev »

AnIdiotOnTheNet wrote: post #12
quanticle wrote: post #7

Earlier quoted context omitted.

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.

Forgive me if I'm wrong about this, but it would seem to me that the FAA NOTAM system had orders of magnitude more uptime than literally any product produced by so called "professional" "engineers" at big software companies.

If it wasn't then who built it? Or is it the quotes we should focus on.

Re: Your tech stack is not the product

#20

Post by tshaddox »

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. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That's it.

Isn't this sneakily hiding the assumption that what your code and architecture looks like has no effect on how good/fast your product is? That's a pretty common implicit sentiment these days, especially as part of the (valid) sentiment that chasing fad languages/frameworks/tools is not a good idea. But it's pretty clearly not true in general.

Post reply on HN