4 ms·

It is wasteful to spend time doing something that benefits nobody, or where the benefits outweigh the cost. Your time is worth something.

by usea 13y ago

logicchains 13y ago
The point I was trying to make is that if you spend your time to make something that works really efficiently, and you take pride in it, then you haven't wasted your time. It doesn't benefit nobody, it benefits yourself, because you can take pride in your work. At least, I believe this idea is part of what's implied in the traditional notion of 'craftsmanship'. An example might be working nine hours per day rather than eight to produce something that only uses 10% of the resources (and that extra hour is unpaid). For some people, that extra hour would be a waste, but for others, it would bring them greater satisfaction knowing they'd delivered a more efficient product, even if it brought them no extra revenue.
- dagw 13y ago
  Except the difference at the margin is never just an extra hour of a day. It's almost always weeks instead of days or years instead of month. And that is fine when you are doing things for yourself and have no other requirements on your time, but when you're being paid spending two month on something instead of week just pisses everybody around you off. I mean don't get me wrong, I'm working on a project right now that I'd love to do 'right'. Spend weeks doing a literature study to catch up on and really understand the current state of the art, then implement three or four different approaches to really get a feel how they work under real world conditions. After that I would try to pick the best aspects of those algorithms and try to write some really smart code that analyses the input and picks the best algorithm based on the data. Then I would tune that code until it is as fast, stable and memory efficient as possible and finally put a really slick UI on top of it. Trust me, nothing would give me greater satisfaction. Unfortunately I got the project late last week, deadline is in less than two weeks and I have two other projects I'm working on in parallel. So I'm going to end up grabbing some off the shelf solution, tweaking it until it works well enough, wrapping it in up in some hacky shell script and make up for inefficiency by throwing more hardware at the problem. It's not optimal, but deadlines are deadlines, and I'll have a contend myself with the satisfaction of getting a job done well enough on time, rather than a job done perfectly.
  - logicchains 13y ago
    > Except the difference at the margin is never just an extra hour of a day. It's almost ways weeks instead of days or years instead of month. Maybe we're thinking of different things here. What I had in mind was more along the lines of for instance choosing Go or Scala instead of Rails or *.js and getting a 10x speedup at the cost of simply adding a few type declarations. There are situations like yours where deadlines leave little choice, but there are also situations where a bit more leeway is available.
    - nostrademons 13y ago
      I think both situations are highly context-sensitive. If you're founding a startup in an emerging consumer market, you'd be making a mistake to use something like Go or Scala rather than Rails or Node.js, because your whole success is dependent upon finding out what particular combination of design, features, and experience emotionally resonates with fickle consumers' minds. That takes a lot of trial and error; anything that slows down that experimentation process is going to cost you the market. Once you've found the market you can get VC and hire experienced technologists to curse out your technology choices and rewrite it in Go or Scala or Java or C++ or whatever. If you're CloudFlare and billing yourself as "the web performance and security company", however, building out your architecture in a performant and reliable language makes a lot of sense. You know your value proposition: you want to use whichever technology stack lets you execute against that value proposition most effectively. Twitter got a lot of flack for being built on a "dumb" Rails architecture, but I'm also certain they would not have succeeded had they done anything else. Remember the context of their founding: Twitter grew out of an idea lab that grew out of Odeo, and at the time of their founding they were an idea that was so marginal that nobody would've bothered with it had it taken more than a weekend or so to prototype. When it turned out that people liked it, then they could afford to hire people to rewrite the software into something scalable - but those people would not have jobs had the initial concept not been proven out first.
      - logicchains 13y ago
        You're right I suppose. I think as someone who's not a webdev I just have trouble imagining the productivity benefits of something like Rails or Node.js. I assumed that nowadays there'd be frameworks in statically typed languages with type inferences that were almost as productive as Node and Rails, and hence could provide both fast development speed and efficient executables.
srean 13y ago
I think the "just good enough for business" attitude contributed to the demise of the American car and the rise of the Japanese ones. The American tradition was to use engineering tolerances that would maximize throughput under the constraint that it produced a pretty functional car. The Japanese tradition on the other hand was to use tighter tolerances, well because there was room for tightening the tolerance. At the surface level, or the MBA level it seems that the Japanese way is just dumb. It does not make monetary sense when measured in sales per year. But it turns out that the benefits express themselves at a different timescale: better brand and a culture of devotion to improvement, rather than to being "just good enough to work so that I can move to the next thing". Part of this applies to the craft of software too. One can be sloppy and churn out functional websites by the dozens. At the superficial level, the goal to extract the most from a 500MHX Pentium-III might seem brain dead, with little or no pay off. But it pays back by instilling an attitude of deeply learning your craft, that learning does pay back although that specific well tuned web server might not. You dont have to build all your servers that way, but if it doesnt hurt you a little when you know exactly what you could have done to extract some more juice out of it, you will not reach that level of understanding. If you are impatient or sloppy, you will build impatience into your product, and it will show. Besides it is always easy to over value ones time, it sometimes correlates with conceit. @sitkack what makes you think I was talking about the 50s. Going by the downvote I seem to have touched a nerve. You are right Japanese products around that time were synonymous with bad quality, not just in US. Much water has flowed under the bridge since then.
- sitkack 13y ago
  Your recollection of Japanese manufacturing is clouded by mythology. Japanese quality sucked in the 1950s, they had a horrible world wide reputation for shoddy goods.
  - logicchains 13y ago
    Maybe German manufacturing would be a better example?
    - 13y ago

It is wasteful to spend time doing something that benefits nobody, or where the benefits outweigh the cost. Your time is worth something.

by usea 13y ago

It is wasteful to spend time doing something that benefits nobody, or where the benefits outweigh the cost. Your time is worth something.

logicchains 13y ago

The point I was trying to make is that if you spend your time to make something that works really efficiently, and you take pride in it, then you haven't wasted your time. It doesn't benefit nobody, it benefits yourself, because you can take pride in your work. At least, I believe this idea is part of what's implied in the traditional notion of 'craftsmanship'. An example might be working nine hours per day rather than eight to produce something that only uses 10% of the resources (and that extra hour is unpaid). For some people, that extra hour would be a waste, but for others, it would bring them greater satisfaction knowing they'd delivered a more efficient product, even if it brought them no extra revenue.

dagw 13y ago
Except the difference at the margin is never just an extra hour of a day. It's almost always weeks instead of days or years instead of month. And that is fine when you are doing things for yourself and have no other requirements on your time, but when you're being paid spending two month on something instead of week just pisses everybody around you off. I mean don't get me wrong, I'm working on a project right now that I'd love to do 'right'. Spend weeks doing a literature study to catch up on and really understand the current state of the art, then implement three or four different approaches to really get a feel how they work under real world conditions. After that I would try to pick the best aspects of those algorithms and try to write some really smart code that analyses the input and picks the best algorithm based on the data. Then I would tune that code until it is as fast, stable and memory efficient as possible and finally put a really slick UI on top of it. Trust me, nothing would give me greater satisfaction. Unfortunately I got the project late last week, deadline is in less than two weeks and I have two other projects I'm working on in parallel. So I'm going to end up grabbing some off the shelf solution, tweaking it until it works well enough, wrapping it in up in some hacky shell script and make up for inefficiency by throwing more hardware at the problem. It's not optimal, but deadlines are deadlines, and I'll have a contend myself with the satisfaction of getting a job done well enough on time, rather than a job done perfectly.
- logicchains 13y ago
  > Except the difference at the margin is never just an extra hour of a day. It's almost ways weeks instead of days or years instead of month. Maybe we're thinking of different things here. What I had in mind was more along the lines of for instance choosing Go or Scala instead of Rails or *.js and getting a 10x speedup at the cost of simply adding a few type declarations. There are situations like yours where deadlines leave little choice, but there are also situations where a bit more leeway is available.
  - nostrademons 13y ago
    I think both situations are highly context-sensitive. If you're founding a startup in an emerging consumer market, you'd be making a mistake to use something like Go or Scala rather than Rails or Node.js, because your whole success is dependent upon finding out what particular combination of design, features, and experience emotionally resonates with fickle consumers' minds. That takes a lot of trial and error; anything that slows down that experimentation process is going to cost you the market. Once you've found the market you can get VC and hire experienced technologists to curse out your technology choices and rewrite it in Go or Scala or Java or C++ or whatever. If you're CloudFlare and billing yourself as "the web performance and security company", however, building out your architecture in a performant and reliable language makes a lot of sense. You know your value proposition: you want to use whichever technology stack lets you execute against that value proposition most effectively. Twitter got a lot of flack for being built on a "dumb" Rails architecture, but I'm also certain they would not have succeeded had they done anything else. Remember the context of their founding: Twitter grew out of an idea lab that grew out of Odeo, and at the time of their founding they were an idea that was so marginal that nobody would've bothered with it had it taken more than a weekend or so to prototype. When it turned out that people liked it, then they could afford to hire people to rewrite the software into something scalable - but those people would not have jobs had the initial concept not been proven out first.
    - logicchains 13y ago
      You're right I suppose. I think as someone who's not a webdev I just have trouble imagining the productivity benefits of something like Rails or Node.js. I assumed that nowadays there'd be frameworks in statically typed languages with type inferences that were almost as productive as Node and Rails, and hence could provide both fast development speed and efficient executables.

srean 13y ago

I think the "just good enough for business" attitude contributed to the demise of the American car and the rise of the Japanese ones. The American tradition was to use engineering tolerances that would maximize throughput under the constraint that it produced a pretty functional car. The Japanese tradition on the other hand was to use tighter tolerances, well because there was room for tightening the tolerance. At the surface level, or the MBA level it seems that the Japanese way is just dumb. It does not make monetary sense when measured in sales per year. But it turns out that the benefits express themselves at a different timescale: better brand and a culture of devotion to improvement, rather than to being "just good enough to work so that I can move to the next thing". Part of this applies to the craft of software too. One can be sloppy and churn out functional websites by the dozens. At the superficial level, the goal to extract the most from a 500MHX Pentium-III might seem brain dead, with little or no pay off. But it pays back by instilling an attitude of deeply learning your craft, that learning does pay back although that specific well tuned web server might not. You dont have to build all your servers that way, but if it doesnt hurt you a little when you know exactly what you could have done to extract some more juice out of it, you will not reach that level of understanding. If you are impatient or sloppy, you will build impatience into your product, and it will show. Besides it is always easy to over value ones time, it sometimes correlates with conceit. @sitkack what makes you think I was talking about the 50s. Going by the downvote I seem to have touched a nerve. You are right Japanese products around that time were synonymous with bad quality, not just in US. Much water has flowed under the bridge since then.

sitkack 13y ago
Your recollection of Japanese manufacturing is clouded by mythology. Japanese quality sucked in the 1950s, they had a horrible world wide reputation for shoddy goods.
- logicchains 13y ago
  Maybe German manufacturing would be a better example?
  - 13y ago