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

121–130 of 204 posts

Re: Accidentally Load Bearing

#121

Post by sedev »

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.

Concurrence: the ability of the code to be self-documenting ends at the borders of the code itself. Factors outside of the code that impose requirements on the code must be documented more conventionally. The "sleep 10 seconds to (hopefully) ensure that a file has finished downloading" anecdote from upthread is a great example.

Re: Accidentally Load Bearing

#122

Post by overnight5349 »

liminalsunset wrote: post #57
ke88y wrote: post #51

Earlier quoted context omitted.

> 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 to fix a [Electrical/Mechanical] problem, a Gremlin is born". At least some of this is cultural. EEs and MEs have historically viewed software less seriously than…

I think one of the reasons I've seen this happen is because typically, EE and ME programs in university teach very little CS "enough to be dangerous", and the few coding projects you are required to do are often taught in a way that downplays the importance of the software. Software is often seen as simply a translation or manifestation of a classical mathematical model or control system ( or even directly generated…

Why should EEs also be software engineers? These are two distinct specializations.

No sane person would expect a programmer to just design a lithium battery charge circuit that goes in your user's pocket, that'd be reckless and dangerous. I likewise would never expect a programmer to break out an oscilloscope to debug a clock glitch, or characterize a power supply, or debug protocol communication one bit at a time. I wouldn't ask a programmer to do FCC pre-validation, or to even know what that means.

Why then do you want to rely on an EE to produce critical software?

As an EE, I know my limits and how to separate concerns. I keep my bad C++ restricted to firmware and I simply do not write code further up the stack. We have programmers for that. Where the app needs to talk to the device, I'll write an example implementation, document it, and pass it off to the programmer in charge. It's their job to write good code, my job is to keep the product from catching fire.

If you want good code, hire a programmer. If you want pretty firmware, hire a programmer to work with your EEs. If you expect an EE to write code, you get EE code because their specialization is in electronics.

Unless you really want an EE who is also a software engineer, but then you're paying someone very highly skilled to do two jobs at once.

Electronics and software are two different jobs requiring two differently specialized people. It just looks like they overlap.

Re: Accidentally Load Bearing

#123

Post by overnight5349 »

hef19898 wrote: post #90
ke88y wrote: post #60

Earlier quoted context omitted.

I don't follow. Did you accidentally reply to the wrong comment?

No, why? The point was EEs and MEs, or rather traditional engineering heavy culture produces bad software (never mind the first software devs tended to be EEs), so Juicero is good example of a software-leaning culture producing shitty hardware products.

Uh, the Juicero was spectacular hardware. The mechanical engineering in that beast was absolutely beautiful.

I don't recall what the software was like, but none of that is why it failed, it was simply a moronic business idea. An overpriced subscription for low quality fruit in a DRM-laden pouch. Nobody wanted it then or now.

Re: Accidentally Load Bearing

#124

Post by ericbarrett »

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.

Completely agree. I find this attitude toward (against?) comments is common in fields where code churn is the norm and time spent at a company rarely exceeds a year or two. When you have to work on something that lasts more than a few seasons, or are providing an API, comments are gold.

Re: Accidentally Load Bearing

#125

Post by praptak »

Let the system go long enough and everything becomes accidentally load bearing. See also "implementation becomes the specification" - people will come to rely on every single undocumented implementation detail regardless of what the official spec says.

That's why it is a good practice to have DiRT or similar exercises. Break things on purpose so that people don't rely on them when they shouldn't.

Re: Accidentally Load Bearing

#126

Post by overnight5349 »

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…

Hah, I did one of these just last week. There's some sort of silicon bug or incorrect documentation that causes this lithium battery charger to read the charge current at half of what it should be. This could cause the battery to literally explode, so I left a big comment with lots of warnings explaining why I'm sending "incorrect" config values to the charge controller.

It's absolutely imperative that the next guy knows what the fuck I'm doing by tampering with safety limits.

Re: Accidentally Load Bearing

#127

Post by dmvdoug »

TheCapn wrote: post #56
ke88y wrote: post #51

Earlier quoted context omitted.

> 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 to fix a [Electrical/Mechanical] problem, a Gremlin is born". At least some of this is cultural. EEs and MEs have historically viewed software less seriously than…

You're not wrong. It shows in the state of PLC/HMI Development tools. Even simple things like Revision Control is decades behind in some cases. I've basically found my niche in the industry as a Software Engineer though I can't say I see myself staying in the industry much longer. The amount of time's I've gotten my hands on code published by my EE coworkers only to rewrite it to work 10x faster at half the size with…

I have no clue, but I wonder how unique this attitude turns out to be among MEs/EEs versus, say, everyone dealing with electronics. Because the stories and complaints about mechanical and electrical engineers treating code (and programmers) as second-class, remind me very much of how front-end people complain about how they’re perceived by back-end people. And about how backend people complain about how they’re perceived by systems programming people. And so on up/down the line(s) of abstraction.

Re: Accidentally Load Bearing

#128

Post by hinkley »

jefftk wrote: post #95
hinkley wrote: post #76

Earlier quoted context omitted.

If you go back to the early 1900s, the cladding was installed on a diagonal, which helped greatly in preventing the building from racking. Now we rely on sheet rock and plywood to provide that protection in earthquakes and wind storms. If you ever see a house stripped down to the sticks for a rebuild, you will hopefully notice a few braces added. Not to keep the walls from falling down, but to keep them square and tr…

For what it's worth, in the Boston area traditional sheathing is boards parallel to the ground, not diagonal. (I've seen dozens of houses from ~1900-1920 in the process of full gut rebuilds, and none of them had diagonally installed sheathing.)

It might be more of a commercial building thing than a domestic construction one. I know I've seen it in a number of videos of renovations of larger buildings, including barns. I might have the time range off. Big cities are full of 1920's constructions especially on the West Coast, and they don't do that.

My old house (~1920) had diagonal shiplap under the floors instead of plywood (but parallel in the oldest walls). That's probably more for making hardwood floors easier to install than structural integrity.

Edit: The internet says 'start of the 20th century' phased out in 1950's (plywood), and 'sometimes diagonally'.

Re: Accidentally Load Bearing

#129

Post by praptak »

letitbeirie wrote: post #38
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…

The most haunting comment line I've ever seen was buried deep in an Allen Bradley PLC: > I don't know why this rung is needed but delete it and see what happens for yourself Did not fuck around; did not find out.

This has the "more magic" anecdote feel to it.

http://www.catb.org/jargon/html/magic-story.html

Re: Accidentally Load Bearing

#130

Post by bee_rider »

overnight5349 wrote: post #122
liminalsunset wrote: post #57

Earlier quoted context omitted.

I think one of the reasons I've seen this happen is because typically, EE and ME programs in university teach very little CS "enough to be dangerous", and the few coding projects you are required to do are often taught in a way that downplays the importance of the software. Software is often seen as simply a translation or manifestation of a classical mathematical model or control system ( or even directly generated…

Why should EEs also be software engineers? These are two distinct specializations. No sane person would expect a programmer to just design a lithium battery charge circuit that goes in your user's pocket, that'd be reckless and dangerous. I likewise would never expect a programmer to break out an oscilloscope to debug a clock glitch, or characterize a power supply, or debug protocol communication one bit at a time. I…

I think it is the result of how these things tend to be taught. At least in my school, all the EE’s and all the computer engineering students had the same first couple programming classes.

Lots of EE’s need to do some programming, and lots of people getting EE degrees end up in programming careers, so it would be a disservice not to teach them any programming at all. In particular, an engineer should be taught enough programming to put together a matlab or Numpy program, right?

Meanwhile, some of their classmates will go on to program microcontrollers as their job.

Writing programs and a product, and writing programs to help design a product, are two basically different types of jobs that happen to use similar tools, so it isn’t that surprising that people mix them up.

Post reply on HN