5 ms·

Nicely written, but I don't fully understand your logic here. The bricklayer's wall in your comparison is precisely analogous to an "update" a developer has to

by samhuk 4y ago

Nicely written, but I don't fully understand your logic here. The bricklayer's wall in your comparison is precisely analogous to an "update" a developer has to do. The work is not complete for a bricklayer nor a software developer. Just as there is "one more revision or update" as you put it, there is always one more house to build walls for. What I think you may be feeling though, is that working on software sometimes feels "endless", but that's really what happens when a project is poorly managed and no "strategic milestones" are reached. This is particularly severe in web dev, less so in the game dev scene where there are more of those "definite walls" to reach.

bombcar 4y ago
There's a satisfaction you get when you finish a house - there is something you can point to and say "that is done". There's even a satisfaction with mopping a floor, it is clean now even though it will dirty again. Most programming doesn't have the first and only sometimes do you get the second. It'd be like building a house and finishing and immediately changing something on it, or fixing something that broke, forever. Programming is like being a contractor building the Winchester mansion.
- drdec 4y ago
  > It'd be like building a house and finishing and immediately changing something on it, or fixing something that broke, forever So it would be like owning a house?
- samhuk 4y ago
  As sibling comment implies, constructing things physically can often have the "forever needing to be built upon" aspect just like software. The difference that you are probably feeling here, at least from what i can see, is that once a house is built by a construction company, it is "handed over" pretty much completely, whereas with software there is almost never such a handover, but instead a "support period". This I suppose can lead to fatigue as you end up never reaching a "final final" product per se like the house. Personally, i have always found it helpful to plan by milestones/major versions, such that it, in a "hack the human brain" kind of way, provides a synthetic almost-copy of that " ah, all done, time to move on" that the human brain gets when a house is built, or a mountain is climbed. Interesting philosophies hidden within all this, particularly for team leads and such of dev teams.
- pas 4y ago
  waterfall, well definied requirements, release every few months, have regression tests. have a few days to celebrate the release. sure, business needs and software/IT complexity explosion means that only a small fraction of the problem-design space gets properly covered pushed the majority of the industry toward more agility

by samhuk 4y ago

bombcar 4y ago

There's a satisfaction you get when you finish a house - there is something you can point to and say "that is done". There's even a satisfaction with mopping a floor, it is clean now even though it will dirty again. Most programming doesn't have the first and only sometimes do you get the second. It'd be like building a house and finishing and immediately changing something on it, or fixing something that broke, forever. Programming is like being a contractor building the Winchester mansion.

drdec 4y ago
> It'd be like building a house and finishing and immediately changing something on it, or fixing something that broke, forever So it would be like owning a house?
samhuk 4y ago
As sibling comment implies, constructing things physically can often have the "forever needing to be built upon" aspect just like software. The difference that you are probably feeling here, at least from what i can see, is that once a house is built by a construction company, it is "handed over" pretty much completely, whereas with software there is almost never such a handover, but instead a "support period". This I suppose can lead to fatigue as you end up never reaching a "final final" product per se like the house. Personally, i have always found it helpful to plan by milestones/major versions, such that it, in a "hack the human brain" kind of way, provides a synthetic almost-copy of that " ah, all done, time to move on" that the human brain gets when a house is built, or a mountain is climbed. Interesting philosophies hidden within all this, particularly for team leads and such of dev teams.
pas 4y ago
waterfall, well definied requirements, release every few months, have regression tests. have a few days to celebrate the release. sure, business needs and software/IT complexity explosion means that only a small fraction of the problem-design space gets properly covered pushed the majority of the industry toward more agility