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

No dogs were harmed in the making of this app

shmck.substack.com

Post reply on HN
Print view View original

61–70 of 202 posts

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

#61

Post by ninju »

tialaramex wrote: post #44
harrymit907 wrote: post #34

Earlier quoted context omitted.

Cost to benefits probably. Vet X-rays are surprisingly expensive and then surgery had to be done anyway.

Even in human medicine some of the things on the "Do not do" guidance are diagnostic steps which are pointless because you will always do the same thing next regardless. A bunch of them are for infant minor injury where it's like don't do an X-ray. If you can see a break on the image you'd do A, but if you can't you'd figure the break might be too small to show up and do A anyway. Kids don't need more radiation, just…

Sorry to hear that...hope everything works out okay

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

#63

Post by kriro »

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…

Let me retell this tale...

"I know," said the department manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

Knowingly the hardware engineer and the software engineer looked at each other. "Actually the car is fine, but let's pick a driver that knows what they are doing this time. You simply don't know how to use the breaks and were randomly steering left and right while thinking you're on track, management guy."

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

#64

Post by gwbas1c »

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 have had enough access to the server environment (either by running the servers himself or asking someone to help him diagnose why an upload failed silently) that he should have had a reasonably quick answer to "why is this upload succeeding but not showing up?"

IMO, those lessons (why the upload worked in test but not in production) are significantly more important than "the image mime type was set to 'jpg' but should have been 'jpeg'" The bug is much more inconsequential to why the environment made it so hard to find the bug.

In my case, I had a situation where a desktop application was severely malfunctioning, but errors were not being logged. It took me multiple days to realize that the application was running out of file handles, and that log4net wouldn't log if it couldn't get a file handle. Even though the fix (reverting a very small bugfix) was simple; the real fix was to customize log4net to always keep the log file open. This way, if the application ran out of file handles, the error would be logged.

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

#65

Post by csours »

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…

Oh this function is totally obvious to everyone on the team, no need to comment it.

30 years later:

/* X systems I modul body I 14.09.1990 */

void xxvcda(int *addr, int sizeof)

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

#66

Post by philk10 »

shadowgovt wrote: post #7

I'm feeling the anecdote about the wasp nest. Landlord in our office complex installed a touchscreen interface on the outside of the building to dial the various front desks, all of which could buzz a person in. They did this because they had no front-desk receptionist who could see the door. The thing lasted six months and then started to malfunction badly. The culprit? The interface is running on essentially a big…

Which reminds me of he story of sun stopping trains - Services at Lewisham, south-east London, were disrupted because of the angle of the 'low winter' sun, train operator Southeastern said.

The rail firm posted on Twitter: 'We had severe congestion through Lewisham due to dispatching issues as a result of strong sunlight.'

It added: 'The low winter sun has been hitting the dispatch monitor which prevents the driver from being able to see.'

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

#68

Post by amelius »

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…

I think it is possible to end this story in three possible ways, where each will be in favor of one of the professions.

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

#69

Post by gwbas1c »

zoogeny wrote: post #41

This reminds me of a colleague I had that would often say "we aren't making air-traffic control systems here". The implication being that no lives were on the line if we made a mistake. This was when I was making games but it also applies to just about every CRUD app I've written. Tangentially, one thing I often ask other senior technical leaders (especially Director, VP or CTO) is: what is the most costly mistake yo…

> we aren't making air-traffic control systems here

I also find that attitude troubling.

I've worked on software that could loose peoples' cherished data. Now I work on software that could cause flooding if it misbehaves.

Take a bit more pride in your work.

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

#70

Post by mewpmewp2 »

frutiger wrote: post #57
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…

> "Well," said the software engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again." Only the brakes don't work - the engine still does. Why would they need to push the car uphill?

It's preferable the fuel state stays as it is. How do you know it's not the amount of fuel otherwise?
Post reply on HN