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

61–70 of 132 posts

Re: Your tech stack is not the product

#61

Post by nullsense »

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…

We've never met and we probably never will, and it's a virtual certainty I'll never see the code of which you speak. But know this... I appreciate it. And I can imagine it. I certainly empathize with your plight. The feeling of a job well done is all the validation you need.

Re: Your tech stack is not the product

#62

Post by bluGill »

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.

Sure, but we do make intentional tradeoffs, at least sometimes.

Re: Your tech stack is not the product

#63

Post by e_i_pi_2 »

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…

> (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code)

I _really_ wish our company would open-source the code just as a way to make the team feel better and hold ourselves to a higher standard. I know no one will actually read it unless they're trying to find a vulnerability - and that would only improve the product! But even with a restrictive license the company is concerned about "trade secret"/"intellectual property" stuff.

Personally I feel like if we figured out some tricky problem other people have then we have an ethical duty to share it with the community

Re: Your tech stack is not the product

#64

Post by acdha »

karmakaze wrote: post #48
acdha wrote: post #45

Earlier quoted context omitted.

There’s also a lot of selection bias: that region is the most popular and people remember hearing about problems a lot more than the people who were unaffected but didn’t say anything about it. I’ve had plenty of instances in us-east-1 for over a decade without downtime other than the 17 minutes in 2011 where they had a network routing issue which kept the entire region running but off of the internet. I never had th…

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.

Re: Your tech stack is not the product

#65

Post by makeitdouble »

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’m curious about the hierarchy between crypto scams and gig economy bathroom cleaning apps.

That aside, finding warm bodies to fill a position is usually not the problem, they need to actually help your product grow.

Focusing on the technology prominently is like hiring security guards by touting the big guns they’ll get. You’ll be rolling the dice on the people that come to you for the position.

Re: Your tech stack is not the product

#66

Post by mardifoufs »

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.

More than google.com? Maybe, but it's close. Also, I'd be surprised if those behind NOTAM were all "professional engineers" since software PEs are pretty rare, relatively speaking. Especially in the US.

Re: Your tech stack is not the product

#67

Post by achairapart »

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 makes perfect sense for founders/c-level people, and owners in general.

But here is the employee paradox: He may sooner or later shift his main focus from customers to his own career. So he reinvents the wheel building the next level hot js framework, start measuring his goals in Github stars and conference bookings...

In short, his tech stack IS the product, again.

Re: Your tech stack is not the product

#69

Post by taeric »

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.

While not wrong, everything breaks at scale. Everything. Anyone that says otherwise is just not interested in talking about where what they built will break.

And note that this is more than just scale of use. It is also scale of development. Keep adding changes to something, and it will break. Stability of application requiring stability of development is just not something we care to admit, that often.

That is, don't hide when/why something will break. But also don't get blinded looking for how to avoid all breakage. If you can, find ways to isolate failures and block off entire sections.

Re: Your tech stack is not the product

#70

Post by adrianmonk »

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.

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 products to ship them out. If your warehouse is disorganized, and you can't find anything when you need it, then it matters.

The real trouble, I think, is when people have reasons to choose not to keep the warehouse organized and functioning smoothly (like workers who see it as drudgery or managers who want workers working on something else) and they try to excuse it by saying, "Our customers never visit."

(I don't think the person above is doing that, incidentally. I think they're just agreeing with the keep your eyes on the prize message.)

Post reply on HN