4 ms·

You often hear people in engineering teams say something to the effect of "I can't understand why this was built this way. It's been done stupidly", but invaria

You often hear people in engineering teams say something to the effect of "I can't understand why this was built this way. It's been done stupidly", but invariably there's some key piece of contextual information that's missing like, as you say, there simply wasn't enough time. I also wrote about this recently: https://timwhite.digital/building-software-sharing-knowledge https://timwhite.digital/building-software-sharing-knowledge

jaclaz 6y ago
Well, the "I can't understand why this was built this way. It's been done stupidly" can also be a case of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
- trwhite 6y ago
  Yes, exactly. The point I make in my article is that stupidity isn't at all as common a reason (for why something's been done a certain way) as we'd like to think it is. I think the true split is about 80/20. This is from someone who's had the [dis]pleasure of working on all manner of steaming piles of rubbish. If there are any Junior devs reading this, Chesterton's Fence is a great concept to understand and abide by!
- artsyca 6y ago
  When every comma and semi colon in a document of code can be a potential Chesterton's fence you have to wonder how any progress can ever be made
withinboredom 6y ago
> I can't understand why this was built this way. It's been done stupidly Or that the way to do it better simply didn't exist back then :)
pnw_hazor 6y ago
Even though I had plenty of experience in leadership roles, I preferred to join startups as a senior dev. Later, after I understood the lay of the land, I would move into leadership roles as needed. This helped me develop relationships with other devs, QA, ops, etc. Also, I could learn or discover the reasoning behind trade offs and compromises that were made before I proposed changes. One time I went direct into a director/manager lead role. It was a nightmare, some on the team thought I didn't know what I was talking about -- even though they were not using source control until I brought it up during my interview. They had not been exposed to professional software development before my arrival and took little stock in my advice/leadership.

jaclaz 6y ago

Well, the "I can't understand why this was built this way. It's been done stupidly" can also be a case of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

trwhite 6y ago
Yes, exactly. The point I make in my article is that stupidity isn't at all as common a reason (for why something's been done a certain way) as we'd like to think it is. I think the true split is about 80/20. This is from someone who's had the [dis]pleasure of working on all manner of steaming piles of rubbish. If there are any Junior devs reading this, Chesterton's Fence is a great concept to understand and abide by!
artsyca 6y ago
When every comma and semi colon in a document of code can be a potential Chesterton's fence you have to wonder how any progress can ever be made

withinboredom 6y ago

> I can't understand why this was built this way. It's been done stupidly Or that the way to do it better simply didn't exist back then :)

pnw_hazor 6y ago

Even though I had plenty of experience in leadership roles, I preferred to join startups as a senior dev. Later, after I understood the lay of the land, I would move into leadership roles as needed. This helped me develop relationships with other devs, QA, ops, etc. Also, I could learn or discover the reasoning behind trade offs and compromises that were made before I proposed changes. One time I went direct into a director/manager lead role. It was a nightmare, some on the team thought I didn't know what I was talking about -- even though they were not using source control until I brought it up during my interview. They had not been exposed to professional software development before my arrival and took little stock in my advice/leadership.