No dogs were harmed in the making of this app • Hacker News Board

Re: No dogs were harmed in the making of this app

#181

Post by Elucalidavah » Sat, Nov 04, 2023, 6:58 AM UTC

feintruled wrote: post #4

That's quite a tale, a parable almost about how software engineering differs from other jobs (I want to say 'real' jobs but tongue in cheek). I like this one too, it's even snappier. A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of co…

> and see if it happens again

The "re-run to reproduce" isn't even the most peculiar part of software engineering; it's "we don't look at what has been tried before".

In the OP story example, there's this part: "One time we added ventilation holes to reduce heat, but they were just big enough for wasps to nest in". In a ideal world, the hardware engineers are supposed to know to not have any holes larger than a few millimeters, and other such things. Whereas the software engineers are (yet) not supposed to know much of anything like that. The most prominent example I can think of is "remember to add an index to the database when adding a new type of query to the app", as load testing that would catch it tends not to be done on each and every release.

Re: No dogs were harmed in the making of this app

#182

Post by Elucalidavah » Sat, Nov 04, 2023, 7:33 AM UTC

sdrothrock wrote: post #175

city41 wrote: post #37

Several times throughout my career I've been hit with something erroring and it just being silent and completely stumping us. No error output, nothing. In a lot of these situations, we were able to track it down to some low level third party library doing `catch (e) {}`. The first one happened early in my career, and it was a good lesson. I don't take any error for granted, at the bare minimum I log it. You just neve…

This recently happened to me with DRF and JWTs -- the JWTs were invalid due to sporadic timing issues and we were unable to log in. There was no indication that anything was going on since DRF was swallowing the validation errors and returning a generic error, so I had to manually go down and add logging to find out what was even happening.

> DRF was swallowing the validation errors and returning a generic error

DRF assumes (for safety) that what you have is a public API. For JWT validation errors, you don't normally expect to have error-level logs, as it should be a problem of the API caller, not of the service.

However, if you are using DRF for an internal API, it is indeed useful to change the error handlers to, basically, add tracebacks to all the returned API errors.

Re: No dogs were harmed in the making of this app

#183

Post by 59nadir » Sat, Nov 04, 2023, 8:34 AM UTC

gwbas1c wrote: post #64

ryandrake wrote: post #35

I always like to see upstream corrective action after something like this. If there was adequate logging / error reporting, this wouldn't have taken a week to fix. Whatever library he sent the invalid "image/jpg" MIME type to should have thrown an exception, crashed, or at the very least, logged loudly. I wonder if OP filed a bug against it.

Yeah, at the end of the article I even wondered what kind of environment Shawn (author) works in where it would take so long to diagnose? Was Shawn able to access anything on the server that would confirm/deny that the image upload was coming through? Why did the image upload work in the test environment but not in the released version of the app? What was different about the test environment? In theory, Shawn should…

> Was Shawn able to access anything on the server that would confirm/deny that the image upload was coming through? Why did the image upload work in the test environment but not in the released version of the app? What was different about the test environment?

This reminds me of a product I worked on where several (in fact most) of the production-critical APIs (banking APIs, transfer APIs, etc.) had major undocumented differences between production and test instances to the point where if something was using them you just couldn't ever be sure that what you had was actually correct. Some of this stemmed from some of the APIs technically being mandated by law and there was no interest in actually making them good, but some of them were actual B2B solutions that just sucked for no apparent reason.

At points like these it's (IMO) quite defensible to build a very comprehensive adapter that basically does most of the surface work of the API you're using as best you know right now, i.e. almost pretends that it is the other system to a degree where you're re-implementing large parts of it.

Re: No dogs were harmed in the making of this app

#184

Post by 59nadir » Sat, Nov 04, 2023, 9:01 AM UTC

hasbot wrote: post #13

As a software engineer I always kinda enjoyed debugging. It allowed me to use a different skill and mind set than creating designs and implementing them. Not to say I didn't get stressed out debugging. I had one demo while developing software for AT&T's 5ESS telephone switch. We had only one phone line in the test lab configured for our feature. Attempt after attempt the software just wouldn't work. Knowing the softw…

I enjoy debugging when the tools are there, not so much when choices have been made to put everything too out of reach, either figuratively or literally. Debugging distributed systems in the cloud is exponentially more awful than debugging them when you can at least spin up all your services locally and that in turn is exponentially worse than when you can debug the problem in just one program.

An actual debugger also makes the act of debugging much nicer to me. I've never understood people who quibble about using either printf debugging or an actual debugger when using both is such a massive win. Arguably good tracing facilities should be highlighted here as well since they're much nicer than printf debugging when they're available.

> Not to say I didn't get stressed out debugging.

This is interesting because I remember very early in my programming journey I used to attach a lot of unnecessary things to not understanding why something was happening (or not happening) and gradually I just came to embrace the "Hang on, why is this so? I don't get it... Ohh, hang on... Wow, it really makes sense why this didn't work!" loop and internalize the fact that it feels really good when I get to the end of it.

The process of not knowing can only really get ruined by other people's expectations and behaviors for me at this point and I've learned over time that this can only be managed by being very assertive about how things are done (language choices, architectural choices, etc.) so as to make the process as easy and quick as possible. Ultimately it's a lot easier (at this point in my career) to convince someone that working with AWS lambda is a bad choice for performance, overall costs, debuggability and development speed (all to varying degrees) than it is to convince them later that there is a good reason that fixing that one problem is taking more time than it ought to.

Re: No dogs were harmed in the making of this app

#185

Post by 59nadir » Sat, Nov 04, 2023, 9:14 AM UTC

civilitty wrote: post #22

yafbum wrote: post #19

A physicist friend used to quote Rutherford, all science is either physics or stamp collecting. By which my friend meant, physics has a way of being checked by physical reality in a way that math or computer science don't. His area of work was extreme magnetic fields. Experimenting meant building giant copper coils, running enough current in them to melt them in place, and then very quickly detonating explosive aroun…

> His area of work was extreme magnetic fields. Experimenting meant building giant copper coils, running enough current in them to melt them in place, and then very quickly detonating explosive around the coil so that, for a fraction of a second, the magnetic field at the center of the coil became the most intense ever built by mankind, before the whole setup was destroyed by the splattering of liquid copper thousand…

Thanks, this will shave years off of my post-retirement projects!

For real, though, I've always found things like these fascinating.

I used to be very interested in working with software for weapons (specifically for fighter aircraft) because they've got very interesting problems to solve that usually are very direct. The amount of irrelevant code paths you can add, the amount of really far-away external stuff seems very limited at least in theory, so it seems a very interesting field to work in.

I could never get over that it would feel very bad being part of a process that ultimately might end in killing someone, though, so it was a non-starter.

Re: No dogs were harmed in the making of this app

#186

Post by antod » Sat, Nov 04, 2023, 9:20 AM UTC

yen223 wrote: post #177

jerf wrote: post #87

I've developed a real distaste for the people whining about how we aren't real engineers and we "just" need to solve that by working more like real engineers and having all these massive up-front design meetings and making tons more plans, etc. etc. It betrays a profound misunderstanding of the situation. The other engineering disciplines don't work like that because they're just soooo much more professional than us.…

I think people who think software engineering isn't real engineering, will be shocked at how much "real" engineering is just people plugging numbers into software

Yeah, in my experience, the real world engineering was rushed, under funded, relied on gut feel, and could count on the humans on site building it to use their own judgement to make up for all the gaps in the designs, drawings or specs.

Although back then in the 90s it was plugging numbers into tables rather than software. Very little science involved in any of it.

Re: No dogs were harmed in the making of this app

#187

Post by sojournerc » Sat, Nov 04, 2023, 9:24 AM UTC

GrinningFool wrote: post #106

hathawsh wrote: post #54

Earlier quoted context omitted.

The relevant paragraph in the article bothers me a bit: "I re-uploaded a version with improved error handling, but image uploads were failing without any feedback. You see, normally code screams its errors at you in red text - silence is the goal. Here silence was the problem." Silence is not quite the goal. Too many developers think silence is the goal, but the goal is actually accuracy. If there's no error, yes, it…

I would say it should be a big red alert box with a simple error code that the end user can reference when trying to find help. The applications (CLIs, native, web, etc) I've seen that present me with non-actionable errors is a perpetual source of irritation. "Failed to open file" "File could not be uploaded" etc Not only are these useless to the user who can't do a thing about them except try the same thing again, t…

Related, the "oops, something went wrong" error messages absolutely infuriate me. Something about the tone, like a child spilling milk, and the uselessness of the message get under my skin.

Re: No dogs were harmed in the making of this app

#188

Post by sojournerc » Sat, Nov 04, 2023, 9:31 AM UTC

guhcampos wrote: post #155

While the low stakes can be seen as a privilege, I could also argue it can be seen as utterly detrimental. Many of us suffer from mental health issues up to burnout. Why do we burnout if we're not dealing with life or death? Something is psychologically wrong with this job. This is, obviously, a multidimensional issue, but one of the probable causes is Alienation. Ultimately, some software developers can, consciously…

Well put. After 10+ years in the industry I question how much value I've actually brought into the world, and it certainly did lead to major burnout, which I am only recovering from now after 8 months being funemployed. Only in hindsight do I see how bad it was for my sense of fulfillment in my life.

Re: No dogs were harmed in the making of this app

#189

Post by crvdgc » Sat, Nov 04, 2023, 9:32 AM UTC

> I sent a message to my friend, "Cracked it at last. It was the letter 'E'."

Enum types have saved me so many "typo"-related errors. Even in this case, it's not exactly a typo, but the encoding process should make you ask questions about the domain and the meaning of the strings you operate on.

Re: No dogs were harmed in the making of this app

#190

Post by fragmede » Sat, Nov 04, 2023, 9:57 AM UTC

RGamma wrote: post #157

organian wrote: post #130

Earlier quoted context omitted.

I think "software engineers aren't really engineers" is putting "real engineering" on a pedestal that is borne of ignorance. Hillel Wayne's engineer interviews were eye-opening on this: https://www.hillelwayne.com/post/are-we-really-engineers/

Programmers calling themselves software engineers suddenly is a very recent phenomenon (barely a decade). Dunno who pushed that, but it's mostly basically (cognitively difficult) Lego at this point. That said, it's also on the order of a hundred years younger a discipline and our theory is not so well developed.

> cognitively difficult Lego

Ah yes. Meanwhile, my friend who's a mech-e at a car company starts from scratch on every single last project, never reusing components, and also machines every component from scratch because there's no such thing as McMaster or any other vendor. When he works on a project, the physical parts never ever fit together like Lego. It's not like he'd use calipers or something to do what's called measuring (twice!) so that things fit together.

There are plenty of places to demand more rigor from people writing software before considering it engineering, but reuse of parts, and having them fit together nicely is a weird one.