3 ms·

The perception of programming

35 points by transmit101 17y ago

samdk 17y ago
A very similar thing happens to me when I'm doing visual design. I can work on something for hours and hours and love it. And then I come back an hour later and finally see all of the problems.
- knieveltech 17y ago
  Unfortunately that's the nature of the creative process. When you're engaged in it time stops and you're totally absorbed in what you're doing. Once you're out of the zone it's easy to despise what you've created.
  - transmit101 17y ago
    I'm not as pessimistic. I believe that by understanding the process it is possible to make allowances for this. It's just one of many challenges one must face in the pursuit of real excellence
dasil003 17y ago
Brilliant observation. The only difference is that music needs to always stand on its own, so in that case he is always making a mistake. In code, sometimes you are overcooking, but often times you are just reflecting a growing understanding of the big picture. In this case the code may end up quite smelly for very good reason, only to be discovered when the next developer comes along to refactor and only realizes the ingenuity of the original code hours later.
spuz 17y ago
This is very true but fortunately for us, programming is a little more scientific and objective than making music. When I find myself unsure which route to take I try to fall back on principles such as DRY and coding at the right level of abstraction. At least with programming, you can go back and say "this is a load of rubbish because of X", or "this is and awesome design because of Y". In fact this is what I try to encourage in my fellow team mates. You shouldn't choose a particular design without knowing exactly why it is the better choice over any other.
silentbicycle 17y ago
That's why context switches can be very helpful. Sometimes, when I'm stumped, the best thing I can do is go for a bike ride, chat with my wife, etc. When I return, I might notice something that had been hiding in plain sight.
teeja 17y ago
In the first two years I made (short pieces of) music, the things people liked best were those I threw together in an hour or two. It was almost uncannily reverse-proportional to time spent. Probably because it was songwriting, not composing. Programs are like architecture ... each program is like a unique building. But in building, the architect designs and the workmen construct. Too often programs are constructed without design ... many times because you don't really understand the problem until you've worked at it. At which time, like musicians or writers, you have to be willing to throw away the first draft and start all over - this time with a solid architecture.

35 points by transmit101 17y ago

samdk 17y ago

A very similar thing happens to me when I'm doing visual design. I can work on something for hours and hours and love it. And then I come back an hour later and finally see all of the problems.

knieveltech 17y ago
Unfortunately that's the nature of the creative process. When you're engaged in it time stops and you're totally absorbed in what you're doing. Once you're out of the zone it's easy to despise what you've created.
- transmit101 17y ago
  I'm not as pessimistic. I believe that by understanding the process it is possible to make allowances for this. It's just one of many challenges one must face in the pursuit of real excellence

dasil003 17y ago

Brilliant observation. The only difference is that music needs to always stand on its own, so in that case he is always making a mistake. In code, sometimes you are overcooking, but often times you are just reflecting a growing understanding of the big picture. In this case the code may end up quite smelly for very good reason, only to be discovered when the next developer comes along to refactor and only realizes the ingenuity of the original code hours later.

spuz 17y ago

This is very true but fortunately for us, programming is a little more scientific and objective than making music. When I find myself unsure which route to take I try to fall back on principles such as DRY and coding at the right level of abstraction. At least with programming, you can go back and say "this is a load of rubbish because of X", or "this is and awesome design because of Y". In fact this is what I try to encourage in my fellow team mates. You shouldn't choose a particular design without knowing exactly why it is the better choice over any other.

silentbicycle 17y ago

That's why context switches can be very helpful. Sometimes, when I'm stumped, the best thing I can do is go for a bike ride, chat with my wife, etc. When I return, I might notice something that had been hiding in plain sight.

teeja 17y ago

In the first two years I made (short pieces of) music, the things people liked best were those I threw together in an hour or two. It was almost uncannily reverse-proportional to time spent. Probably because it was songwriting, not composing. Programs are like architecture ... each program is like a unique building. But in building, the architect designs and the workmen construct. Too often programs are constructed without design ... many times because you don't really understand the problem until you've worked at it. At which time, like musicians or writers, you have to be willing to throw away the first draft and start all over - this time with a solid architecture.