101–110 of 202 posts
Earlier quoted context omitted.
Or perhaps that nobody had the common sense to call a tow truck , so that they can get down the mountain without relying on a field repair to a safety-critical system.
NIH syndrome
The the Engineering Manager walked by. "There's a dot," he said, "Get rid of it before Wednesday."
With all the other things going right with the project, why this dot--a single pixel--was so important drove us all crazy. I ran through the assembly code that handled all this over and over again and couldn't see anything wrong. Never a reported error by the assembler. Neither could the project manager. Stayed at work all night to wrap it all up and, on Wednesday morning, everything was done and working perfectly just as the Engineering Manager walked into the room at 8am.
"That dot is still there."
Like the author of the article, I questioned whether I should be in this line of work. I continued rewriting, assembling, and testing every variation of the code I could. At 3:00PM on Friday, I found the issue.
MOVE B #0,D0
Do you see it? Imagine this is the 1990s, with a green screen monitor and a PDP-11.
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.…
> Shed your inferiority complex. We are not squalling babies drooling on our blocks while Real Men (with all the pejorative connotations modern political sensibilities see in that term fully intended) are building bridges and dams. *We engineer with better tools than they could dream of having, and it's completely expected that that results in highly significant changes to our processes.*
Why is the term engineer so important to you ? Just do your job, do it right, and ignore criticism.
Earlier quoted context omitted.
Why not hire hardware engineers to write software then?
Because software development isnt an engineering task. Engineers are good at building bridges, and artists are good at making paintings. That doesnt mean it is a good idea to have the engineers paint paintings.
Art is for everyone. Painting is a special form of art. Math makes for beautiful art, so download LibreCAD and free your mind.
(Speaking as an ex. IT guy, ex. CNC machinist who is attending art school at the age of 40 as a form of rehab.)
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.…
> Shed your inferiority complex. We are not squalling babies drooling on our blocks while Real Men (with all the pejorative connotations modern political sensibilities see in that term fully intended) are building bridges and dams. *We engineer with better tools than they could dream of having, and it's completely expected that that results in highly significant changes to our processes.* I just want to add, that thi…
They are, frankly, welcome to it, right up until they try to ruin my job by adding negative-value processes because of their complex.
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.
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…
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, they're useless to the developer or support engineer who might be trying to help them.
Earlier quoted context omitted.
> "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?
So, using previous records, they should estimate fuel usage during the decent. Then they should walk to the nearest fuel station, purchase fuel, and walk back. During that time, they can calculate the amount of fuel that will evaporate while they have the gas cap off and the amount of fuel that will stick to the walls of the piping between the gas cap and the fuel tank. This way when they return to the car, they can put in almost exactly the amount of fuel that was consumed during their harrowing stop.
This presumes the fuel station has the same mixture as they have in their tank. Otherwise all bets are off and they should simply give up.
Wait, how was this not caught in testing? It's not like this would differ between testing and production.
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?
The dog’s owner paid for surgery, but wouldn’t pay for an x-ray?