Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidentally Load Bearing

jefftk.com

Post reply on HN
Print view View original

111–120 of 204 posts

Re: Accidentally Load Bearing

#111

Post by dventimihasura »

> I could easily tell why it was there: it was part of a partition for a closet.

> Except that over time it had become accidentally load bearing

> through other (ill conceived) changes to the structure this stud was now helping hold up the second floor of the house

Evidently, you couldn't easily tell why it was there. Moreover, I'm not persuaded that it accidentally became load bearing. It seems quite plausible that it deliberately became load bearing, for reasons which are ill conceived to you but not to the people who had them.

Re: Accidentally Load Bearing

#112

Post by mostlylurks »

MrBuddyCasino wrote: post #83
bamfly wrote: post #46

Earlier quoted context omitted.

This is why I comment a "why" for any line of code that's not incredibly obvious. And 100% of the time when it's due to interaction with something outside the codebase, whether that's an OS, filesystem, database, HTTP endpoint, hardware, whatever, if it's not some straightforward call to some API or library. Sleep due to rate limiting from another service? COMMENT. Who's requiring it, the limits if I know exactly wha…

You're doing the lords work. I often get pushback on doing this with some variation of "comments bad, code should be self-documenting". This is unwise, because there are "what code does" and "why code does" comments, but this turns out to be to nuanced to battle the meme.

Self-documenting code is perfectly capable of expressing the "why" in addition to the "what". It's just that often the extra effort and/or complexity required to express the "why" through code is not worth it when a simple comment would suffice.

Re: Accidentally Load Bearing

#114

Post by csours »

bamfly wrote: post #46
TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

This is why I comment a "why" for any line of code that's not incredibly obvious. And 100% of the time when it's due to interaction with something outside the codebase, whether that's an OS, filesystem, database, HTTP endpoint, hardware, whatever, if it's not some straightforward call to some API or library. Sleep due to rate limiting from another service? COMMENT. Who's requiring it, the limits if I know exactly wha…

There was some inscrutable code that had sleep 10 [seconds] in the middle.

It took several hours to figure it out, but the sleep was there in case a file had not finished downloading

Re: Accidentally Load Bearing

#115

Post by eschneider »

csours wrote: post #114
bamfly wrote: post #46

Earlier quoted context omitted.

This is why I comment a "why" for any line of code that's not incredibly obvious. And 100% of the time when it's due to interaction with something outside the codebase, whether that's an OS, filesystem, database, HTTP endpoint, hardware, whatever, if it's not some straightforward call to some API or library. Sleep due to rate limiting from another service? COMMENT. Who's requiring it, the limits if I know exactly wha…

There was some inscrutable code that had sleep 10 [seconds] in the middle. It took several hours to figure it out, but the sleep was there in case a file had not finished downloading

shudder

Re: Accidentally Load Bearing

#116

Post by alex-robbins »

TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

> "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born"

I'm definitely going to use this, and I think there's a more general statement: "Every time software is used to fix a problem in a lower layer (which may also be software), a gremlin is born."

Re: Accidentally Load Bearing

#117

Post by hinkley »

> Figuring out something's designed purpose can be helpful in evaluating changes, but a risk is that it puts you in a frame of mind where what matters is the role the original builders intended.

One of the biggest challenges I find in refactoring/rearchitecting is getting people to separate why something was done from whether it still needs to exist.

Too many times someone has insisted that a weird piece of code needs to exist because we never would have shipped without it. They treat every piece of the structure as intrinsic, and can't conceive of any part of it being scaffolding, which can now be removed to replace with something more elegant and just as functional.

When you put a doorway through a loadbearing wall, contractors and smart people place a temporary jack to brace the wall until a lintel can be substituted for the missing vertical members. Some developers behave as if the jack is now a permanent fixture, and I have many theories why but don't know which ones are the real reasons.

Re: Accidentally Load Bearing

#118

Post by hinkley »

w10-1 wrote: post #84

This article and every other comment seems to miss the real issue: the lack of testing. Software differs from all other means of production in that we can in fact test any change we make before realizing it in the world. With good tests, I don't care what the intent was, or whether this feature has grown new uses or or new users. I "fix" it and run the tests, and they indicate whether the fix is good. With good tests…

Probably the most shocking revelation I've had in my time as a developer has been that testers are never paid the correct salary (some too high, most too low), and that if you have someone who is good at testing and is becoming proficient at coding, their smartest move is not to become a FT developer, but to skip right over developing and go into security consulting. Instead of making 75% more money by switching careers, you can make 150% more.

Software needs people with the suspicious minds of good testers, but security people make more money for the same skillset.

Re: Accidentally Load Bearing

#119

Post by hinkley »

bcrosby95 wrote: post #54
irisgrunn wrote: post #27

I had something similar. A couple of years ago I bought on old house. The previous owners did most of the work themselves from the 1960s on. The zinc gutter had leaked for probably decades and it destroyed part of the roof structure. The roof was held up by the wooden paneling the used to cover it on the inside (70s). So the wooden paneling was actually load bearing Actually I've found way more stuff in this house. F…

I had a house that had really bad termite damage and the contractor called it "structural stucco".

PSA: houses don't 'get termites'. They get water damage, and then the water damage gets termites.

Most problems with houses come back to managing water, air, or some other infiltration. But mostly it's water.

Re: Accidentally Load Bearing

#120

Post by glonq »

TheCapn wrote: post #28

Huh. Finally a name for it. I do a lot of support work for Control Systems. It isn't unheard to find a chunk of PLC code that treats some sort of physical equipment in a unique way that unintentionally creates problems. I like to parrot a line I heard elsewhere: "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born". But often enough when I find a root cause of a bug, or some sort o…

> "Every time Software is used to fix a [Electrical/Mechanical] problem, a Gremlin is born"

Early in my career, I was confused by seemingly-crazy questions in the Hacker Test (https://www-users.york.ac.uk/~ss44/joke/hacker.htm) like...

> 0133 Ever fix a hardware problem in software?

> 0134 ... Vice versa?

But after spending years developing embedded systems, I don't even blink at such questions. Yes, of course I have committed such necessarily evils!

Post reply on HN