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

51–60 of 132 posts

Re: Your tech stack is not the product

#51

Post by Klonoar »

hbrn wrote: post #38
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…

Latter has a risk of attracting fanboys and detracting product engineers.

Not in my experience.

Re: Your tech stack is not the product

#52

Post by habitue »

mik3y wrote: post #28
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…

(author here - oh gee, hi hn!) Yes, those things are always important (if not critical); it's not meant as a defense of bad architecture, merely to try to make those decisions through a product/customers-first lens. (I did try to connect quality/reliablity, perhaps unsuccessfully, later in the post, e.g. in goals: "If the system is unreliable, we won’t ship as much product ... If we don’t replace this system, more an…

Maybe I was overly swayed by the rhetoric I see fairly frequently and you caveated it appropriately. I apologize if so

Re: Your tech stack is not the product

#53

Post by cratermoon »

I joined a somewhat troubled project a year after it's initiation. One of the things I learned is that early on, while the stakeholders were looking for visible progress, the tech lead decided to give them a presentation on the state of the system. What the stakeholders were concerned about was that they had not seen even a kernel of a working system. The tech lead, I'm told, focused on the tech stack, the implementation details, the integration points with existing systems, and a whole bunch of things that had the stakeholders dozing off within a short time. I think the only reason project wasn't cancelled there and then was because it was in a critical path for the business.

I 100% believe that the tech lead gave this presentation, because part of my onboarding, such as it was, went over pretty much all the technical details of how the system was built, but never did I really get a sense of what the goals were, what functionality was in place, or any overall understanding of what all the pieces were supposed to be doing. Yeah, ok, it's great that you created a bunch of code using gRPC to communicate internally and connected up to bunch of REST backend services sending and receiving JSON, but so what? How did any of that address the functional needs of the stakeholders?

Re: Your tech stack is not the product

#54

Post by asp_hornet »

> No; customers are not paying for, nor give a shit about, these things. Sorry. It’s still cool stuff. It’s just not what you’re selling

They sort of are if your bad architecture means features are slower to roll out than your competitors and each release introduces bugs and regressions.

Re: Your tech stack is not the product

#55

Post by makeitdouble »

pyrale wrote: post #49
tshaddox wrote: post #20

Earlier quoted context omitted.

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

I believe the author's point is that you should care about the relation between your technical decisions and actual benefits for the user. It is true that many technical people develop an appreciation for tech choices that is driven by aesthetics more than by actual impact. That being said, caring too much about customer success also has its pitfall, businesses can be driven by the present more than by the future, an…

The retort would be that your fellow engineers are also user/consumers of your code.

You’re building code that others will review, run, modify and rely on. They are people too and you should care about them and their needs.

Re: Your tech stack is not the product

#56

Post by mik3y »

habitue wrote: post #52
mik3y wrote: post #28

Earlier quoted context omitted.

(author here - oh gee, hi hn!) Yes, those things are always important (if not critical); it's not meant as a defense of bad architecture, merely to try to make those decisions through a product/customers-first lens. (I did try to connect quality/reliablity, perhaps unsuccessfully, later in the post, e.g. in goals: "If the system is unreliable, we won’t ship as much product ... If we don’t replace this system, more an…

Maybe I was overly swayed by the rhetoric I see fairly frequently and you caveated it appropriately. I apologize if so

Or maybe I just wrote too much - I always wish I could be more concise. It's all good!

Re: Your tech stack is not the product

#57

Post by iLoveOncall »

habitue wrote: post #34
iLoveOncall wrote: post #16

Earlier quoted context omitted.

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

> your tech stack does not matter > You will have problems if you have the worst tech stack Cool, so we've established that I'm saying the tech stack matters. All of the problems above have to do with the tech stack. Yes performance is part of your tech stack. Yes, how easily you can monitor it and is part of your tech stack. > 99% of startups won't be able to afford the best developers anyway. 99% of startups don't…

> Cool, so we've established that I'm saying the tech stack matters.

Yes, and I'm telling you that all the problems you've raised are not dependent on your tech stack.

To make it clearer, it doesn't matter if you use CloudWatch Metrics or if you publish your metrics manually in an Excel file, as long as you have metrics being looked at.

"Having metrics" is not a part of your technical stack.

Similarly for speed, it doesn't matter if you use C or Python, as long as you write efficient algorithms and choose the right datastructure.

"Writing efficient algorithms and choosing the right datastructure" is not a part of your technical stack.

Re: Your tech stack is not the product

#59

Post by marcosdumay »

tshaddox wrote: post #20
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…

The article is entire about the ways that your code and architecture affects the final product. Really, there is no other thing there than the complete opposite of your complaint.
Post reply on HN