No dogs were harmed in the making of this app

That&#x27;s quite a tale, a parable almost about how software engineering differs from other jobs (I want to say &#x27;real&#x27; jobs but tongue in cheek). I like this one too, it&#x27;s even snappier.<p>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 control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.<p>The car&#x27;s occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?<p>&quot;I know,&quot; said the department manager, &quot;Let&#x27;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.&quot;<p>&quot;No, no,&quot; said the hardware engineer, &quot;That will take far too long, and besides, that method has never worked before. I&#x27;ve got my Swiss Army knife with me, and in no time at all I can strip down the car&#x27;s braking system, isolate the fault, fix it and we can be on our way.&quot;<p>&quot;Well,&quot; said the software engineer, &quot;Before we do anything, I think we should push the car back up the road and see if it happens again.&quot;

I&#x27;ve developed a real distaste for the people whining about how we aren&#x27;t real engineers and we &quot;just&quot; 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.<p>It betrays a profound misunderstanding of the situation. The other engineering disciplines don&#x27;t work like that because they&#x27;re just soooo much more professional than us. They don&#x27;t work like that because it is a better way. They work like that because for them, it is the <i>only</i> way. You do not build a hotel, and then realize the ceilings need to be six inches higher, and tear the whole thing down and start over.<p>If they <i>could</i> work by running ceilingHeight += 6 and hitting &quot;Rebuild&quot;, see the hotel rebuilt and the automated unit tests automatically double-check the usability of everything inside for handicapped people etc., all for a grand total of about $2.82, they absolutely would.<p>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&#x27;s completely expected that that results in highly significant changes to our processes.<p>Do we sometimes fail to bring enough process to a problem? Yup. But if you think that&#x27;s a problem unique to programming, I prescribe to you spending several hours with <a href="https:&#x2F;&#x2F;www.imdb.com&#x2F;title&#x2F;tt4788946&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.imdb.com&#x2F;title&#x2F;tt4788946&#x2F;</a> .

Several times throughout my career I&#x27;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&#x27;t take any error for granted, at the bare minimum I log it. You just never know, your software could still be used 5 years from now and in a totally different environment than you ever imagined.

A physicist friend used to quote Rutherford, all science is either physics or stamp collecting.<p>By which my friend meant, physics has a way of being checked by physical reality in a way that math or computer science don&#x27;t.<p>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 thousands of degrees hot. Errors and miscalculations in that work environment meant that people could die unpleasant deaths very quickly.<p>So when he looked at math PhD students who at most got chalk dust onto their sweater, calling themselves scientists, he disagreed.

I always like to see upstream corrective action after something like this. If there was adequate logging &#x2F; error reporting, this wouldn&#x27;t have taken a week to fix. Whatever library he sent the invalid &quot;image&#x2F;jpg&quot; 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.

This reminds me of a colleague I had that would often say &quot;we aren&#x27;t making air-traffic control systems here&quot;. 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&#x27;ve written.<p>Tangentially, one thing I often ask other senior technical leaders (especially Director, VP or CTO) is: what is the most costly mistake you have made? If you are a junior engineer, make sure you do it sometime. Many&#x2F;most high-level leaders in tech can tell stories in the $100k to $1m range. I&#x27;ve seen people lose millions of dollars on a project and get promoted immediately after. It is important to understand why that can happen and why it can even be a good thing.

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.<p>Not to say I didn&#x27;t get stressed out debugging. I had one demo while developing software for AT&amp;T&#x27;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&#x27;t work. Knowing the software worked, I checked everything I could all the while stressing out. Finally I asked the lab tech to check the line. Somehow our only configured line was disconnected. The problem was a stupid hardware issue.

I giggled at the end. Just yesterday, we solved an issue that plagued the company for 3 years. For us it was the letter &#x27;A&#x27;.<p>Someone had been doing manual fixes inserting and removing data for the past 3 years. It became part of his job. He added a recurring event in his calendar just to do that regular clean up. Millions of customers depended on this one individual making sure they had the correct data plan on their phone line.<p>You can imagine the chaos when he forgets or goes on PTO.<p>Turns out: if $line-&gt;status == STATUS_ACTIVE<p>one was &#x27;Active&#x27; the other was &#x27;active&#x27;. No dogs were harmed, but incalculable money was lost over the years.

I&#x27;m feeling the anecdote about the wasp nest.<p>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.<p>The thing lasted six months and then started to malfunction badly. The culprit? The interface is running on essentially a big black Android tablet and they installed it on the side of the building that faces East. Mid-spring rolled around and it caught enough sun every day to overheat and fry the touch electronics and part of the screen hardware.<p>As a software engineer, writing the kind of software I do, I <i>never</i> have to worry about thermal load.

&gt; I sent a message to my friend, &quot;Cracked it at last. It was the letter &#x27;E&#x27;.&quot;<p>Funny how the simplest, tiniest bugs are often the hardest to find. Just this morning I burned an hour or two hunting down an off-by-one error. Turns out it was an &quot;index + 1&quot; that I had forgotten to change when I refactored (facepalm).

While the low stakes can be seen as a privilege, I could also argue it can be seen as utterly detrimental.<p>Many of us suffer from mental health issues up to burnout. Why do we burnout if we&#x27;re not dealing with life or death? Something is psychologically wrong with this job.<p>This is, obviously, a multidimensional issue, but one of the probable causes is Alienation. Ultimately, some software developers can, consciously or not, question the meaningfulness of spending 40+ hours a week on stuff that is, to a large extent, pointless - even harmful. Sure, the money is good, but how much cash do you need to buy meaning? How deep in the hedonic threadmill can you go before snapping?<p>I&#x27;m not even sure if these questions apply to myself, it&#x27;s just something that keeps coming up in my own therapy and among friends in the trade.

Loved this story. A bit skeptical that that kind empathetic manager really exists in the field, but maybe.<p>Most telling that no sales&#x2F;marketting&#x2F;product managers showed up to console the guy. Satire just couldn’t plausibly stretch that far. But maybe I’m too jaded. Would love to see the reply that posited a section to this story where the empathetic individual from one of those domains gave solace to the main character.

Wow what incredible timing. I am currently working on an Image Uploader component and the gotchas are hiding around every corner.

The dog’s owner paid for surgery, but wouldn’t pay for an x-ray?

Wait, how was this not caught in testing? It&#x27;s not like this would differ between testing and production.

We had a presentation of our new medical instrument to marketing on Wednesday so there was a big push on Monday to get the display up and running perfectly. There was a dot on the screen. I didn&#x27;t know why there was a dot but I was under pressure to finish everything else. So I semi-ignored it.<p>The the Engineering Manager walked by. &quot;There&#x27;s a dot,&quot; he said, &quot;Get rid of it before Wednesday.&quot;<p>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&#x27;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.<p>&quot;That dot is still there.&quot;<p>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.<p>MOVE B #0,D0<p>Do you see it? Imagine this is the 1990s, with a green screen monitor and a PDP-11.

Besides the debuggers&#x2F;analyzers&#x2F;simulators&#x2F;emulators… we have at our disposal, a more powerful “ancient” mechanism exist: code inspection&#x2F;review&#x2F;desk-check by a fellow programmer.<p>I understand it’s not applicable in all positions&#x2F;companies and heavily depends on the team and project size, but I’ve seen it work too many times.<p>Following this, the next best thing is testing (as others have commented).

&gt; As software developers, it’s easy to overlook the privileges we enjoy. We have the unique ability to delve deep into intricate processes, monitor real-time activities, log what’s happening, and even pause time with a debugger. This remarkable capability is not only cheap but fast, bordering on thoughtless.<p>&gt; While many other professions struggle to understand and resolve their issues, we have the advantage of being able to experiment multiple times a day with just a few clicks.<p>So much strained positivity, as if the author was tasked to find something to be thankful for. Look, software engineering is a great job if you enjoy the work. But even in this parable, the problem is the author&#x27;s week of distress and flailing. It has nothing to do with the work and everything to do with the author.<p>All the others he turns towards, no matter their discipline, their tools for investigation, or the constraints they faced in a dilemma, relate stories where they have a mature understanding of how their industry works and how they navigate its system. They encounter problems in the course of their work and they resolve them in the course of their work. Maybe it takes a little while to proceed with diagnosis. Maybe it takes a long while to integrate improvements into a later product. Maybe they need to forgo some procedure that they prefer to use.<p>By the authors account, the embedded engineer, the hardware engineer, the CEO and veterinarian all face greater challenges when solving problems in their work, yet they all speak of their road through those challenges with a confidence that the author lacks. They try to soothe the author and empathize, but none of their stories hint at a week of panicked flailing.<p>So if they handle their work so much more confidently, is it true that their dilemmas are worse and that the author is lucky to be a software engineer?<p>If the author listened to their own invented characters, the realization to come to is not that the author is lucky to work in a field with purported &quot;privileges&quot; and that everyone else has it worse (gross!), but that <i>everyone</i> faces dilemmas in their work and that the real skill is in staying cool and confidently relying on the processes of their discipline. And this has everything to do with the person doing the work and nothing to do with the discipline. The realization is that challenges arise in all professions and that you can proceed through them without distress and flailing if you allow yourself patience and confidence.<p>It&#x27;s funny because they wrote this as a parable, but they missed the real lesson in the very piece they wrote. Four people reassure them that &quot;We&#x27;ve been there! We all go through this!&quot; and their takeaway is &quot;I need to remember that I&#x27;m lucky and that everybody else has it even worse.&quot;

A very nice post, well written and with a positive outlook on our position.<p>And while there are many developers that write software that directly impact in one way or another the lives of other human beings, generally speaking we need to recognize we are in a fairly privileged position, as the author states.

And this is why I have a few KLOC file that has every known media type as a named variable. It takes up less space than a single JPEG image, but it makes it so I never screw up media type spelling.<p>Because I, too, have been there.

&gt; I sent a message to my friend, &quot;Cracked it at last. It was the letter &#x27;E&#x27;.&quot;<p>Enum types have saved me so many &quot;typo&quot;-related errors. Even in this case, it&#x27;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.

this kind of thing is what I realised in my first 2 years of my work life. and whenever we have a family gathering, those relatives are usually bragging how hard their jobs and life are. but not me, I brag how easy my job is. clock in at 930, get the hell out at 1830, then no thoughts given about job after the hours.

I miss working on low-risk stuff like that. I now work in healthcare, and a missing letter can mean that someone dies.

&gt; By Thursday, I began to worry about my own job security. I had been spinning on a feature I said I would ship 3 days ago.<p>Off-topic: is it really like that in the US? (I&#x27;m assuming he&#x27;s from the US). Like, if you get stuck for a few days, you start to worry about being fired or reprimanded?

I read this on break and needed to hear these words of encouragement and hope.<p>Thank you for sharing your misadventure with us.

I always dogfood my own software, but now I guess I also need to corn cob dog my software, too.

A good Friday story.

Thank you for this. Its lovely to be reminded that a lot of us share some the same ups and downs whatever we&#x27;re doing.

I now feel very validated for using TypeScript to statically validate mime types.

Feedback: I opened your page, eager to read, saw the &quot;subscribe to my substack&quot; email popup and just left.<p>Not salty, just broke my interest. So now I will go about my day without reading your article. p.s. I&#x27;m sure it&#x27;s very good though<p>Consider saving that popup until I&#x27;ve read some of the article

Perhaps the jpg -&gt; jpeg tidbit will save my ass someday. Thanks

Reminder that vets have it extra hard.<p>And a reminder to myself to do good.

wait... but why did it work in the development environment?

The article is nonsense from the first sentence.<p>Software development has all of diagnoses, audits and proofreading.<p>It&#x27;s an all-encompassing discipline.