Live data from Hacker News

Your tech stack is not the product

hoho.com

81–90 of 132 posts

Re: Your tech stack is not the product

#81

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.

Do I not count as somebody? ;)

> Now it's your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business / lives faster.

Quick and thoughtful are often in tension. Sometimes you really do need to take a step back and take the 10000 foot view and think about your systemic challenges. It may be worth investing in a new architecture that will allow you to iterate faster and make quicker, better decisions in the future. The first instinct should of course always be to try do the smallest thing within the limitations of the current system to deliver customer value, but there are times when you are spending so much time fighting the system, that it is a wise strategic investment to rearchitect. It takes significant maturity as a developer to recognize the difference between this type of investment and hype-driven churn.

There are always going to be the kind of developers (often quite smart and idealistic but relatively inexperienced) who are easily susceptible to hype, discover a shiny new toy and want to rewrite everything in its image. This type of developer can waste a huge amount of time, both their own and of their colleagues, engaging in fruitless technical debate.

Also, it is not just the customer who matters. You as the developer also matter. If you hate the system you are working with so much that you desperately want to rearchitect it, you either should find a way to do that or leave the project/company regardless of whether you are able to provide value for customer.

Re: Your tech stack is not the product

#82

Counterpoint: Slack

Counterpoint to what? Slack runs on PHP. I'm sure it has hosted innumerable discussions by typescript or ruby fanatics linking the fractal-of-bad-design article and patting themselves on the back while clicking the fuck out of that :fire: emoji in response.

Re: Your tech stack is not the product

#84
post #75
post #69

Earlier quoted context omitted.

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

> everything breaks at scale This is good advice. You should be aware of who you are building for. Designing your system to run on 100 containers orchestrated by Kubernetes is overkill for your average SaaS MVP, while counting on shell scripts is a recipe for disaster at FAANG scale. Scale matters.

Don't just look at the execution you are building for, but also the team that will be maintaining it. That is, there are several values for "who" that you are building for. Each will have cause for you to reach to more complicated seeming solutions, as you go.

Re: Your tech stack is not the product

#85

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…

[flagged]

Re: Your tech stack is not the product

#86

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

there are 3 circumstances in which i regularly look at open-source code:

a. i want to fix a bug or improve some rough UX.

b. i want to add new functionality.

c. i want to borrow something from it for use elsewhere.

you’re right that the better your code, the less likely i am to read it for reason (a). and the more sophisticated your code, the less likely i am to read it for (c), as i’ll be hunting for reusable libraries rather than cribbing directly from applications.

but consider that for any commercial product, i’m also less likely to read the code for reason (b) because of largely unwritten cultural norms (if i contribute code to a project that has paid devs and don’t get paid for that, it feels like i’ve been suckered).

this being an iOS app exacerbates all this because even if i find a bug and suspect a one-line fix that would be worth my time, i won’t pursue it because i have absolutely no idea how to deploy my patched version (i have to register with app store, maybe pay some licenses/fees, does Apple even allow me to distribute patched versions of someone else’s software?)

so, yeah, you’re not wrong, but you’re also working in a context that really amplifies what you witness around open source (and if you specifically want your beautiful code to be read by others maybe this shows which approaches are more/less likely to get that).

Re: Your tech stack is not the product

#87

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 look at open-source to learn new programming languages, especially their idioms.

Re: Your tech stack is not the product

#88

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…

The reaction to the post was ... interesting ... I didn't make the post as any kind of complaint. It was a fairly simple statement of fact. I don't actually require any validation. I'm pretty comfortable with what I can (and can't) do.

It's a closed-source app, and probably no one will ever see the source. I don't expect them to. I have plenty of other code that folks can look at, if they want. A lot of that code is actually integrated into the app (I use lots of dependencies; just mostly ones that I've written).

I was really mentioning that the stack doesn't matter to most of the stakeholders on the project, and I'm fine with that. It's the way that it's supposed to be.

Oh, and it's an SDK, not a framework. It happens to have most of the app operation embedded in it, but the framework is UIKit. Any Apple dev of reasonable skill would be able to take it and run. They should have some skill and experience, though, or they are likely to make a hash of things; with or without the SDK.

Re: Your tech stack is not the product

#90

> A mindset of technology being the means, not the end, is uncomfortable. Really? That's pretty funny. How could anyone miss this lesson who has ever used a computer to do things.

It is less funny once you've been exposed to these people frequently. I assure you they are out there, and yes they have used computers to do thing in the past, yet they behave this way still. This is kind of the point of the article.
Post reply on HN