4 ms·

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:

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 to support. Now? I see things differently. I look at the problem and evaluate existing solutions. 90% of the time, there's a battle-tested open-source (or cheap) solution which fits our requirements that I can quickly integrate without burning piles of company cash building and supporting my custom crap. Yes, it's not minimalist. But it's overwhelmingly a better decision most of the time. (Mind, I suspect one's experience is highly dependent on the developer ecosystem one is in. Just my 2c.)

vendiddy 7y ago
This can be considered minimalist. For example: We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We use Postgres instead of a custom We are minimalist in the sense that we minimize the code we have to maintain in house.
- sanderjd 7y ago
  That there are two opposite interpretations of "minimalist" in the article and thread with respect to build-new vs. use-existing decisions probably suggests that it isn't a very meaningful metric. It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.
  - lazyasciiart 7y ago
    Minimalism isn’t a metric, because as you say, there is no object or method of measurement given. Might as well say that your metric is “betterness”. Better what?
  - vendiddy 7y ago
    It's best handled case by case as with most decisions. Should one build their own database? Probably not. That introduces more complexity. What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency. Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria. So seems like we're in agreement :)
anderspitman 7y ago
I've followed a similar trajectory over the years, but I'm currently back to minimalism. Perhaps the pendulum will swing again. In any case I'm not as extreme about NIH as I used to be. I try to make the decision for pragmatic reasons, not emotional ones. What pushed me back was the current JavaScript landscape, with endless breaking changes to the major UI frameworks and constant security vulnerabilities being reported in our code bases by GitHub (they're even doing auto pull requests now). In my experience, updating any decently sized web app project is a huge pain, and very time consuming. Everything is constantly moving. Libraries, frameworks, build tools, node, etc etc. These are all dependencies.
yiyus 7y ago
It looks like yours was a case of NIH syndrome. That has nothing to do with minimalism.
- pbreit 7y ago
  NIH is absolutely relevant here since article showed 3 (out of 3) examples of it.
  - yiyus 7y ago
    The comment was relevant, and welcomed. Sorry if my response gave other impression. I just don't agree with that premise of the article. There is extremely bloated software that can be replaced by a few lines of code but, in general, minimalism is hard to get right and requires a high level of expertise.
war1025 7y ago
I've found that, to some extent, the reason that I tend to roll my own implementation of various things is that I don't have the authority to add dependencies to our codebase. 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.

vendiddy 7y ago

This can be considered minimalist. For example: We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We use Postgres instead of a custom We are minimalist in the sense that we minimize the code we have to maintain in house.

sanderjd 7y ago
That there are two opposite interpretations of "minimalist" in the article and thread with respect to build-new vs. use-existing decisions probably suggests that it isn't a very meaningful metric. It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.
- lazyasciiart 7y ago
  Minimalism isn’t a metric, because as you say, there is no object or method of measurement given. Might as well say that your metric is “betterness”. Better what?
- vendiddy 7y ago
  It's best handled case by case as with most decisions. Should one build their own database? Probably not. That introduces more complexity. What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency. Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria. So seems like we're in agreement :)

anderspitman 7y ago

I've followed a similar trajectory over the years, but I'm currently back to minimalism. Perhaps the pendulum will swing again. In any case I'm not as extreme about NIH as I used to be. I try to make the decision for pragmatic reasons, not emotional ones. What pushed me back was the current JavaScript landscape, with endless breaking changes to the major UI frameworks and constant security vulnerabilities being reported in our code bases by GitHub (they're even doing auto pull requests now). In my experience, updating any decently sized web app project is a huge pain, and very time consuming. Everything is constantly moving. Libraries, frameworks, build tools, node, etc etc. These are all dependencies.

yiyus 7y ago

It looks like yours was a case of NIH syndrome. That has nothing to do with minimalism.

pbreit 7y ago
NIH is absolutely relevant here since article showed 3 (out of 3) examples of it.
- yiyus 7y ago
  The comment was relevant, and welcomed. Sorry if my response gave other impression. I just don't agree with that premise of the article. There is extremely bloated software that can be replaced by a few lines of code but, in general, minimalism is hard to get right and requires a high level of expertise.

war1025 7y ago

I've found that, to some extent, the reason that I tend to roll my own implementation of various things is that I don't have the authority to add dependencies to our codebase. 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.