4 ms·

I don't understand the point of the whole "shipping" fetish and the "maker" culture that goes with it. Even when I'm probably considered part of it! Specifical

by tnolet 9y ago

I don't understand the point of the whole "shipping" fetish and the "maker" culture that goes with it. Even when I'm probably considered part of it! Specifically the focus on the quantity of shipping, not so much the quality. I'm afraid it might set a weird example for new comers. And the use of the word "shipping" also has changed quite a bit over the last two years. You used to ship a release. That is what I would call "shipping", but now people are updating texts and tweeting and moving a picture 3px and call that "shipping". The OP luckily doesn't fall into that trap. I'm probably too old/jaded/cynical or just not the target audience. I'll write the "I shipped one thing in three year" blog post...

k__ 9y ago
yes. I made like 100 such projects in my life and only "shipped" less than 10, still I wouldn't consider the rest failed. I learned much from it :)
hamandcheese 9y ago
It mostly makes sense in the context of showcasing your work, be it for jobs or just because. Quality means basically nothing if you can't show it off, and obsessing over quality will prevent you from shipping. Furthermore, who could ever be proud of a half finished project? If its cool enough to tell people about, you might as well finish a MVP.
- keypress 9y ago
  Yup it's the finishing that is hard. I started a fun project before xmas just for kicks. But I've yet to fire up the editor and get back into the zone, and finish it. So like much of my code, it will sit around in a half finished state and that's not really that much use to anyone else. Not that in this example it really was for anyone else. I'm always impressed and enthusiastic when people ship an MVP, even if it does have a few warts - as it shows staying power!
strken 9y ago
It's probably about avoiding the cycle where you polish something for two years in obscurity, only to find that nobody wants it, then repeat.
- tnolet 9y ago
  Yes, I get that and it's a trap many people probably fall into. But why is this such a movement now? It seems common sense to me. I could be completely wrong though...
  - keypress 9y ago
    Which movement are you referring to?
- ThePadawan 9y ago
  We need more posts about how every side project during which you learn new ways to work, new technologies, etc., no matter if you launch them or not, are valuable to you as an engineer. I get where you are coming from, but that road without at least some reflection just leads to burnout and depression.
  - GFischer 9y ago
    If no one else sees it, I'm not sure if you're learning. Maybe it doesn't have to ship, but at least SOMEONE has to see it (colleagues, friends, whatever)
laurent123456 9y ago
This quality vs quantity thing is why it's hard to find any bug free node.js package on GitHub. Every time I hit obvious bugs that will never get fixed because the owner has moved on to shipping more projects. In my view, shipping a project that only works at 95% is like shipping nothing, because the value and hard work is in this last 5%.
- dentemple 9y ago
  Fork it, fix it, then ship it. Open source developers don't have an obligation to provide free support for the rest of their lives. But if the code is easily viewable, then that's a perfect opportunity to either: 1) build upon it, or 2) pay someone else to build upon it for you Option #2 would still be faster and cheaper than recreating the whole implementation from scratch.
  - laurent123456 9y ago
    My approach has been to keep everything as modular as possible, to create wrappers around major packages, so that I can switch to a different package once a major bug is found. Unfortunately fixing unmaintained open source packages is often a waste of time since your improvements won't be merged to upstream (since the owner is gone), and it's unlikely that your fork will take off. Even if the owner add contributors to the repo, the changes still won't make it to npm. Maybe for very large projects it makes sense since then a group of multiple dev can start a fork, and it's more likely to get some traction.
    - dentemple 9y ago
      Presumably there was a reason why you were searching for the package in the first place? A challenge that you were trying to overcome? If there's no perfect solution that exists (which there never is)--and if bringing in someone else's partial implementation "as is" doesn't work--then the only other options available are to write 100% of the solution yourself or to write (100-x)% of the solution yourself. Also, presumably, that you're not in the business to write library tools. So unless the broken OSS package is written in complete greek, why wouldn't it be more efficient to use it as a template for your solution?
hobs 9y ago
I would say that the healthy version of why is summed up fairly well by an apocryphal story from the "Art & Fear: Observations On the Perils (and Rewards) of Artmaking" - https://blog.codinghorror.com/quantity-always-trumps-quality/ https://blog.codinghorror.com/quantity-always-trumps-quality... The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
- adrianN 9y ago
  The quantity group clearly lacked people who understood the grading scale. They should have just delivered big lumps of clay, possibly with a small indentation somewhere, and called them pots.
- pjc50 9y ago
  Reminds me of the old joke about the Soviet nail factory: https://skeptics.stackexchange.com/questions/22375/did-a-soviet-nail-factory-produce-useless-nails-to-improve-metrics https://skeptics.stackexchange.com/questions/22375/did-a-sov...
Double_a_92 9y ago
Shipping probably stands for an "official" end of your project. Knowing that you concluded it in an useful state. That's the rewarding part, I guess. Even if it just means that you upload it to github with a nice readme and maybe a logo.
- yks 9y ago
  These days "ship" is literally used as "change in production"

by tnolet 9y ago

k__ 9y ago

yes. I made like 100 such projects in my life and only "shipped" less than 10, still I wouldn't consider the rest failed. I learned much from it :)

hamandcheese 9y ago

It mostly makes sense in the context of showcasing your work, be it for jobs or just because. Quality means basically nothing if you can't show it off, and obsessing over quality will prevent you from shipping. Furthermore, who could ever be proud of a half finished project? If its cool enough to tell people about, you might as well finish a MVP.

keypress 9y ago
Yup it's the finishing that is hard. I started a fun project before xmas just for kicks. But I've yet to fire up the editor and get back into the zone, and finish it. So like much of my code, it will sit around in a half finished state and that's not really that much use to anyone else. Not that in this example it really was for anyone else. I'm always impressed and enthusiastic when people ship an MVP, even if it does have a few warts - as it shows staying power!

strken 9y ago

It's probably about avoiding the cycle where you polish something for two years in obscurity, only to find that nobody wants it, then repeat.

tnolet 9y ago
Yes, I get that and it's a trap many people probably fall into. But why is this such a movement now? It seems common sense to me. I could be completely wrong though...
- keypress 9y ago
  Which movement are you referring to?
ThePadawan 9y ago
We need more posts about how every side project during which you learn new ways to work, new technologies, etc., no matter if you launch them or not, are valuable to you as an engineer. I get where you are coming from, but that road without at least some reflection just leads to burnout and depression.
- GFischer 9y ago
  If no one else sees it, I'm not sure if you're learning. Maybe it doesn't have to ship, but at least SOMEONE has to see it (colleagues, friends, whatever)

laurent123456 9y ago

This quality vs quantity thing is why it's hard to find any bug free node.js package on GitHub. Every time I hit obvious bugs that will never get fixed because the owner has moved on to shipping more projects. In my view, shipping a project that only works at 95% is like shipping nothing, because the value and hard work is in this last 5%.

dentemple 9y ago
Fork it, fix it, then ship it. Open source developers don't have an obligation to provide free support for the rest of their lives. But if the code is easily viewable, then that's a perfect opportunity to either: 1) build upon it, or 2) pay someone else to build upon it for you Option #2 would still be faster and cheaper than recreating the whole implementation from scratch.
- laurent123456 9y ago
  My approach has been to keep everything as modular as possible, to create wrappers around major packages, so that I can switch to a different package once a major bug is found. Unfortunately fixing unmaintained open source packages is often a waste of time since your improvements won't be merged to upstream (since the owner is gone), and it's unlikely that your fork will take off. Even if the owner add contributors to the repo, the changes still won't make it to npm. Maybe for very large projects it makes sense since then a group of multiple dev can start a fork, and it's more likely to get some traction.
  - dentemple 9y ago
    Presumably there was a reason why you were searching for the package in the first place? A challenge that you were trying to overcome? If there's no perfect solution that exists (which there never is)--and if bringing in someone else's partial implementation "as is" doesn't work--then the only other options available are to write 100% of the solution yourself or to write (100-x)% of the solution yourself. Also, presumably, that you're not in the business to write library tools. So unless the broken OSS package is written in complete greek, why wouldn't it be more efficient to use it as a template for your solution?

hobs 9y ago

I would say that the healthy version of why is summed up fairly well by an apocryphal story from the "Art & Fear: Observations On the Perils (and Rewards) of Artmaking" - https://blog.codinghorror.com/quantity-always-trumps-quality/ https://blog.codinghorror.com/quantity-always-trumps-quality... The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

adrianN 9y ago
The quantity group clearly lacked people who understood the grading scale. They should have just delivered big lumps of clay, possibly with a small indentation somewhere, and called them pots.
pjc50 9y ago
Reminds me of the old joke about the Soviet nail factory: https://skeptics.stackexchange.com/questions/22375/did-a-soviet-nail-factory-produce-useless-nails-to-improve-metrics https://skeptics.stackexchange.com/questions/22375/did-a-sov...

Double_a_92 9y ago

Shipping probably stands for an "official" end of your project. Knowing that you concluded it in an useful state. That's the rewarding part, I guess. Even if it just means that you upload it to github with a nice readme and maybe a logo.

yks 9y ago
These days "ship" is literally used as "change in production"