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

121–130 of 132 posts

Re: Your tech stack is not the product

#121

Post by ChrisMarshallNY »

throwaway09432 wrote: post #103
ChrisMarshallNY wrote: post #44

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?

It was really a joke. I was sort of making fun of myself.

In retrospect, it seems to have fallen flat.

Re: Your tech stack is not the product

#122

Post by saurik »

ChrisMarshallNY wrote: post #121
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?

It was really a joke. I was sort of making fun of myself. In retrospect, it seems to have fallen flat.

FWIW, I got it the way I am pretty sure you had intended it <3.

Re: Your tech stack is not the product

#123

Post by acdha »

karmakaze wrote: post #109
acdha wrote: post #64

Earlier quoted context omitted.

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.

If people were experiencing significant downtime they’d leave us-east-1 or AWS. There’s no sign of that happening so I’d suggest that there’s a tendency to over-weight the degree to which people complaining in forums constitutes representative data.

Re: Your tech stack is not the product

#124

Post by disgruntledphd2 »

8n4vidtmkvmk wrote: post #118
lll-o-lll wrote: post #77

Earlier quoted context omitted.

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.

Yeah the best way to understand software (maybe even the only way) is to try to do something with it.

Re: Your tech stack is not the product

#125

Post by karmakaze »

acdha wrote: post #123
karmakaze wrote: post #109

Earlier quoted context omitted.

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.

If people were experiencing significant downtime they’d leave us-east-1 or AWS. There’s no sign of that happening so I’d suggest that there’s a tendency to over-weight the degree to which people complaining in forums constitutes representative data.

The discussion started as us-east-1 being less reliable than other regions and has strayed far from that into guessing about human behaviour.

Re: Your tech stack is not the product

#126

Post by neilv »

ParetoOptimal wrote: post #100
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…

I've seen this happen with Haskell for web backends for instance.

It's also been known to happen with Common Lisp and Scheme.

Re: Your tech stack is not the product

#127

Post by themitigating »

mrkurt wrote: post #32
arcturus17 wrote: post #23

Earlier quoted context omitted.

Yea I’m left scratching my head too. Is there really a difference in reliability between an EC2 instance and colocated hardware?

Yes. In my experience, it's substantial. 200 servers in colo == maybe 1 failure every 6 months. 200 EC2 instances, one per month. These are different things, though. If you're using AWS, you would build to account for this.

your personal experience has no value when discussing reliability as a whole

Re: Your tech stack is not the product

#128

Post by PaybackTony »

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.

My point on this isn't that you should write ugly, unmaintainable code because who cares. It's that, if you're an experienced and intelligent engineer, you're going to do just fine. There's no need to complicate it, get lost in analysis paralysis and so forth. I have seen top engineering teams make software that's hard to maintain with questionable performance as a _result_ of some of the things this article brings up. Often times too much engineering is just as bad as not enough.

Here is how I personally define good software engineering:

- Does it do the job? - Is there low cognitive load in regards to following the code? (Can you jump back in the code in 6 months and get your feet quickly... AKA: Don't over-abstract). - Is it performant? - Can you easily make changes?

If those 4 things are true, the rest doesn't matter from my experience.

Re: Your tech stack is not the product

#129

Post by decafninja »

ChrisMarshallNY wrote: post #44

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…

My worry over a case like this would be if your boss, or more likely, the nontechnical middle management stakeholders up the food chain, start asking “so what have you been doing the past few months (to justify your continued employment or bonus)?”

This would depend on your company culture of course.

Re: Your tech stack is not the product

#130

Post by migf »

I think this is really misguided.

While it's true that the stack just enables you build something for people, if you just chase market you have a good chance of piling up technical debt and slowing down before you get there.

I have seen far too many projects take twice or five times as much budget as needed because people didn't know what they were doing from the get go.

Greenfield applications should start with a rough idea of what the technical requirements will be (what ordr of magnitude of users / transactions per second) and start by cloning a reference implementation that does what's needed. Otherwise you will never get ahead of product.

Post reply on HN