Your tech stack is not the product
1–10 of 132 posts
Re: Your tech stack is not the product
#2Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product/service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems.
Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring "old-school" tech.
The product is paramount, not the tech.
Re: Your tech stack is not the product
#3[flagged]
Re: Your tech stack is not the product
#4This is why myopic technical founders need a balanced partner to help recognize the blending of company mission and company implementation.
However, it is natural for a myopic technical person to want to leverage their existing skillset, as this knowledge represents to them the key value that they bring to the organization. Unfortunately, blind loyalty to technical stacks is not likely to be an advantage, long-term. The ability to balance the need to leverage existing skills and taking advantage of new skills is critical.
Re: Your tech stack is not the product
#5This 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 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. If you did your job right they'll forget that software helped them do their job or complete their task faster / better because the experience was so seamless they spent the entire time focused on their own goal, and not how to navigate your software to get there. How you get there is irrelevant. 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.
Re: Your tech stack is not the product
#6[deleted]
Re: Your tech stack is not the product
#7This 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.
Re: Your tech stack is not the product
#8This 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…
The next engineer working on the code will care about what it looks like.
Re: Your tech stack is not the product
#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 that you must use the newest shiniest tech and infra to do everything, my point is that when people write blog posts like this, they want to make it seem like there's a clear line between what's "cool shiny tech" and what's "hard nosed business focused shipping".
In reality, it's a lot fuzzier and these things feed back into each other. For example, you shipped bad code early on to get velocity, but it turned out to be foundational and hard to replace, so your best developers leave as your codebase becomes a ball of mud that it's become clear will never be fixed. So now your worst developers are working on a ball of mud and making it worse... etc etc.
As always, the answer is that this stuff is hard, and you can't make a technology decision by just considering things a user wants to buy and saying everything else is navel gazing and messing around.
Re: Your tech stack is not the product
#10This 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 architecture looks like.
This isn't an absolute. Yes, people using your thing don't care about the architecture. But developers sure do. If your system is built in COBOL, you will have a smaller pool of developers who will have an interest in working on it.