Live data from Hacker News

Your tech stack is not the product

hoho.com

101–110 of 132 posts

Re: Your tech stack is not the product

#101

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…

> If people could really see the software, viscerally, they would approve budgets to fix it.

Tools for this exist; ex: https://semgrep.dev/docs/writing-rules/data-flow/data-flow-o...

I suspect the information overload for any substantially large code base would be such that, non-engineers would look right past the complexity after the enthusiasm wears off.

Re: Your tech stack is not the product

#102
> A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success.

I'm wary when I hear this sentiment. At the heart of very versatile companies is a definition of what makes them who they are, both in a product sense and a technical sense.

I've worked at very successful companies that wrote their own networking stacks, load balancers, cryptography, service catalogs, paging systems, etc... The stark views of fully embracing a Not Built Here mentality and the "build product and product only" are broken for me. I think executives make bets that authorizing a certain project will add to their direct and marginal gains. Direct gains being cost, performance, ease of use (UX/DX), etc... Marginal gains being the experiences that add up over time building custom things or being able to leverage the fully custom parts of your stack.

If all you care to have expertise in is the product people see you'll miss the products that make that product faster, more secure, and easier to maintain long term.

Re: Your tech stack is not the product

#103

It's funny. I'm working, right now, on a modular SDK that is the "heart" of an iOS app that we've been developing for a couple of years. I've taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a "kernel" that drastically improves the flexibility, quality, performance, and aesthetics of the app. It's a thing of beauty. And…

>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?

Re: Your tech stack is not the product

#104

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.

It would seem to me that the FAA NOTAM system had professional engineers working on it to produce that uptime.

Re: Your tech stack is not the product

#105

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.

yeah but that's borrowing trouble.

we can spend ages solving every theoretical.

and to be fair NOTAMs were rock solid until that happened, so if anything this failure was a good thing long-term

Re: Your tech stack is not the product

#106
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…

tbf how often did twitter and reddit break in the 2010s? how often does reddit STILL 503 under load?

if the product is really good compared to everyone else, people won't care (as much) that it's broken as long as it comes back up quickly

Re: Your tech stack is not the product

#107
this post reminds me of the dude that wrote plentyoffish, the worst's worst looking dating site, in like ASP.NET or something and was able to sell it for hundreds of millions because basically everyone used it

or craigslist

i like new tech quite a lot but so much of this stuff are solutions looking for problems

Re: Your tech stack is not the product

#108

It's funny. I'm working, right now, on a modular SDK that is the "heart" of an iOS app that we've been developing for a couple of years. I've taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a "kernel" that drastically improves the flexibility, quality, performance, and aesthetics of the app. It's a thing of beauty. And…

>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

Re: Your tech stack is not the product

#109
post #64

Earlier quoted context omitted.

It's well known that us-east-1 (the very first) is a pet among AWS's cattle regions. It has failure modes that none of the other regions have.

I’m aware, but my point was simply that people are prone to overstating the extent of those problems. If it was as bad as lore would have it, it’d be far less popular.

Why would you think it would be less popular? Most everyone that chooses us-east-1 chooses it because they're close to it and 1 is the first number. They don't research it before they start using it.

Re: Your tech stack is not the product

#110

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.

> … until it breaks.

My boss once told me, "[toast0], you can't have that kind of attitude if your shit doesn't work"

Rather than change my attitude, I made sure my shit worked.

Post reply on HN