4 ms·
The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad p
by m00x 3y ago
The craft is not the code, but the product.
You can have beautiful code and garbage product, and great code and a garbage product.
If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.
- majikandy 3y agoCan’t it be both?
- m00x 3y agoIt absolutely can! I'm not saying that you should disregard your code, just that it's not what you should put at the top of your list. You can build amazing products with amazing code, and they will often raise each other up. A great example is Redis, that codebase taught me how to write C code, and I also use Redis everywhere.
- dlisboa 3y agoThat’s not a great way to look at it. You can be passionate about the craft and not passionate about the product. You can usually find interesting problems relating to craftsmanship even when doing things you’re not thrilled to do. Let’s be honest: sometimes you’re not “changing the world” like many founders like to think, just building yet another shopping cart. If you lose love for your craft there’s no product that’ll cure it.
- 000ooo000 3y agoWell said. I am certainly not in this game because I love building forms. Mastering my tools of choice grants me satisfaction. It's hard to find a place working on a product that is truly interesting, but fortunately at least, finding a place working with tools I like is easier.
- m00x 3y agoBut you're trying to build a damn good shopping cart, which is the product. The code analogy here would be nerding out on how to use a hammer in spectacular ways, but not really do anything interesting with it. You can still really love your tools, but you shouldn't focus on them as much as what you're building with them.
- AdieuToLogic 3y ago> The craft is not the code, but the product. These two are not disjoint, but instead quite related. > Your job is to deliver good product, not good code. If your job is software engineering, then "good code" is what facilitates "good product." It boils down to maximizing the "abilities": - Understandability - Applicability - Testability - Maintainability - Flexibility - Durability
- m00x 3y agoYup, good code helps to deliver a good product, but you should not focus on the code, rather focus on how the code influences the product. Better to have hacky code that delivers value than to deliver nothing.
- AdieuToLogic 3y agoThis is a false dichotomy IMHO. "Hacky code" is most often a result of those responsible for delivery having gaps in their understanding of the product need. When engineers have a deep understanding of what is needed, there is rarely a need for hacks. Of course, the obvious exception to this is when libraries and/or external services mandate them.
- Mawr 3y agoIt's true that the product should take priority over the code, but there's a limit to by how much. If the code is bad enough, its low performance, bugginess, and slow feature development will eventually be reflected in the product.
- m00x 3y agoPerformance and bugs are product features, not code features. Who cares if it slows down feature development if you never have to change it. If it does impact the product, it then becomes part of the product value you're delivering. This is the time you should be investing in better code.