Most tech stacks are a liability, it's not talked about enough.
Your tech stack is not the product
71–80 of 132 posts
Re: Your tech stack is not the product
#72This 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 isn’t wrong, but I also think it’s not wrong for engineers to overcorrect a bit. It’s a balance.
Pretty much every other incentive in an organization is for product. Its really easy to build things as fast and cheap as possible until you literally can’t anymore because no one understands the code.
Re: Your tech stack is not the product
#73I don’t disagree with the sentiment and point of the article.
That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion dollar companies out there dealing with the consequences of a tech decision a founder made in the first month of development while being focused on finding product market fit.
Re: Your tech stack is not the product
#74Earlier quoted context omitted.
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.
You're comparing database to a service. NOTAM is real-time, google.com is not.
By that standard google.com is always down.
Re: Your tech stack is not the product
#75Earlier 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.
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.
Re: Your tech stack is not the product
#76I don’t disagree with the sentiment and point of the article. That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion doll…
Sure. I think I'd maybe go one step further than the headline and say that for startups, unless it is what you are explicitly building from scratch and selling, your tech stack should never be the product.
Laying the right technical foundations shouldn't be difficult -- it should be generally be picking the most boring[1], dependable choices that you've been able to rely upon in the past.
Re: Your tech stack is not the product
#77Earlier 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.
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 completely invisible to customer and manager alike. Gross inefficiencies, evil hacks, everything entangled with everything? No one can see it. “Why does it take 3 months for a tiny feature?” “Technical debt”, “ok, you can have 5% of your time budget to sort that out”…
If people could really see the software, viscerally, they would approve budgets to fix it.
Re: Your tech stack is not the product
#78Counterpoint: Slack
How is it a counterpoint? I don't know what technology(ies) Slack uses (except maybe the desktop client, which is obviously Electron) and I don't care.
Re: Your tech stack is not the product
#79It'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.
Blessed comment! :D
Re: Your tech stack is not the product
#80It'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…
And then you leave and everyone has to deal with your homegrown framework.