81–90 of 179 posts
It’s easy to keep adding stuff (especially if your customers are requesting it) but you should evaluate if it’s truly necessary.
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
Minimalism without sacrafice in performance
Look at kx.com, shakti.com
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
I agree with you -- that's why I think clean code is less important than clear boundaries. All that messy code for matrix multiplication poses a lot less risk for consumers of it when the API is clear. eg. Pass in a 2D array of integers, receive an integer in return.
That's pretty obvious for me to say, I think, but you run into situations where an app, for some reason or another (the main culprit IMO being Not-invented-here-syndrome), couples code like these matrix calculations to constructs unique to the codebase (objects, database structure). That's when it turns to hell.
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
I've also gone the other direction from minimalism in codebases, and consider it a positive change as a developer. As a junior, I always wanted to roll my own: roll my own advanced multi-select autocomplete input, roll my own Modbus communication library, roll my own internal tool for the company to use rather than an existing product, etc. So what happened? Now we have a relatively buggy implementation that we have…
Some of the transition from rolling your own to just using something else probably comes naturally from gaining sway over a project to the point that you can actually make the call to import a new package.
This applies to everything I've worked on, from personal projects up to 10KLOC to 3MLOC commercial systems. It's just never a good idea from my experience.
The code [0] I write these days tends to be pretty raw, but every single line fills a fundamental purpose.
This page is completely empty on iOS. I guess the author should have made a minimalist static HTML page instead.
Is it HN's hug of death? I see the same on my PC.
I want to agree, but the story is incomplete. A lot of those products also started as MVPs, but accreted functionality in response either to customer demand or opportunities to monetize. The classic example of this is Word which started out as a small clone of Bravo but kept adding features that some subset of customers found indispensable until the whole codebase and UI became a mudball. I don’t really like MS softw…
But as a user of a SaaS, how many of those customers are your customers?
Or there's an address widget you used, but it kept being updated because even though you only serve the USA, other sites need support for various foreign countries...
I don't want to write everything, but sometimes indeed these 3P packages are a moment of convenience leading to a lifetime of regret.
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is…
I am still unsure of how I should have approached this, but I know I messed up because at the end it was just way too much effort to fix bugs and add features, but I didn’t have the time to refactor. If anyone has advice, I would be grateful.
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of…
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is…
> focus on building a few key features extremely well.
This. You nailed it.