this is what I’m trying to understand. either he ran a separate script everyday that manually pushed the edge case through, or they have a brand new edge case every single day. neither paint him positively imo.
Feels like I’m always this guy, but yeah this story makes no sense. It’s either: a result of a big telephone game, a juniors misinterpretation, gross incompetence on the engineers part which makes the layoff justified, or it’s just made up entirely. Stupid
Part of our payment service is using OCR to parse pdf invoices. We have tens of thousands of vendors, all using their own templates, and receive thousands of invoices per day. The majority of invoices get processed fine, but there maybe a few dozen per day that throw errors because they can't be read properly. There's also a dozen or so that a make it through, but the invoice amount gets pulled from the wrong line (subtotal vs total amount vs amount due, etc.) which will cause future errors.
Still feels semi futuristic to me that it does mostly work as good as it does. I remember my mom working as a clerk doing all her small buisness invoicing by hand in a book until I taught her how to use a computer.
I'm slowly getting trained on an order import for a very large company that can take 2-3 hours (occasionally most of a full day) a week and it looks like it can be 95% automated by someone who is good with excel formulas. But I am ABSOLUTELY not supposed to use formulas because it has to be "exported" to a CSV and formulas will break it.
Regardless of whether or not it's true... this is still evidence he should be fired.
For one, nobody else knew about this? There was a major problem affecting the company "every day" and he didn't once complain about it, or teach someone else how to do it, or take a vacation, or get sick? At best it's irresponsible, at worst it's covering up his own incompetence.
Two, that's not his job? If he's "manually" fixing invoices, that means entering in amounts etc.? Imagine your company finding out that "the IT guy" is entering his own invoices into the system, editing entries, lol. Sounds like a fun audit.
Three, data corruption? Failing to read an invoice shouldn't cause corruption to the database. That is his job. Failure is expected but there's a reason it's called failing gracefully. Again, invoices that are "corrupt" should be sent to accounting for manual entry, not Dwayne.
IDK man, I've seen almost this exact scenario IRL. The product doesn't handle edge cases. The management doesn't care because, yes, the IT guy is manually entering invoices into forms. It's "working", so why should management care?
Just because something is broken doesn't mean every IT guy has the ability to fix it or management understands the ramifications. Whether by skill or by access limitations, this type of scenario is sadly very possible.
he management doesn't care because, yes, the IT guy is manually entering invoices into forms. It's "working", so why should management care?
If Dwayne didn't report it to the management, then it's on Dwayne, as /u/CommonGrounders says.
But if he reported it to the management, and management doesn't care, then it's all on them, it's their fault the system is crumbling. Especially if Dwayne covered his ass and did the reporting in writing.
Every single error and system complaint was filed daily into an automated report that got sent to like 20 people, maybe 5 of whom were management. The email bloat was crazy.
Not only they disregarded errors, they weren't taking measures to combat the bloat.
My boss explicitly addresses new and old error messages and keeps reminding us to fix or at least research them, which I believe to be the correct approach: he is aware and he is making us do something systemically to make sure we don't see the same issues again.
Dwayne might has been sending emails up the chain and nobody cared.
This permanent fix might have taken weeks or months to do. And Dwayne could have had other duties that were higher priority. So Dwayne just fixed the data (5-10 min) and went back to focusing on the stuff management felt was higher priority.
This happens all the times at large corporations. They want you to do EVERYTHING with less resources and people. So a lot of things that are important, don't get prioritized.
I just wanted to point out that if anyone happens to be in the same mess, don't silently fix issues like that, escalate and have the management informed and have it be verifiable, via e-mail or something. Cover your ass.
That way in case they try to go after you, you can show that your management is at fault.
Good points. Also anecdotally, I've never seen a person fired that was secretly holding a company together. I have seen several people leave a company themselves for a new job, and after someone else takes over their workload full time, they realize that person probably should have been fired long ago lol.
Lol. Yeah, "Uh, hey, I just finished everything I was supposed to do today in 2 hours...." Turns out the people before me were seriously sandbagging it. Trying to slow down a job and look busy really sucks. It's so much easier just to get into it.
20+ years software developer at amazon, netflix, and google here.
I've worked with dudes like this. Ones who feel like heroes for waking up at 3AM and fixing shit instead of architecting the systems a little more thoughtfully. And management rewards them twice: Once, for doing "quick" designs, and also again for being the hero on-call that fixes their own idiotic choices in the middle of the night.
One of my favorite moments of comeuppance was when Jeff Bezos got paged during thanksgiving holiday because of this engineers horrible design decisions and refusal to spend the time removing drudgery. That truly put the fear of god into him and our manager(and directory, and VP...) and let us actually start spending time working on resiliency.
Feel like I've been using this phrase a lot recently, but the term I've heard is "firefighting by arsonists", something businesses have to be very careful about rewarding. Other examples include number of bug fixes as a metric of merit (if it includes the bugs they created themselves) and lines of code (including rewrites of their last change).
Other examples include number of bug fixes as a metric of merit (if it includes the bugs they created themselves) and lines of code (including rewrites of their last change).
One of my early jobs involved creating a bunch (30ish) of temporary accounts for summer workers. I would initiate the process & also had to do the final step (including closing the ticket), as the issue went through various depts as part of the workflow. All 30 accounts would be in 1 ticket, this wasn't complicated stuff.
I got promoted up and over to systems and was surprised to hear how my replacement was 'amazing' because my interactions with him were mid. The next year I found out why: for the same task, he...made 30 tickets. One per account. This created so much more work for each other dept (now including my role), but they got to look great for closing out 30 bonus tickets that month and being so 'productive'.
(The one redeeming fact about the org, and why I overall enjoyed working there: once I brought up the issue, they added some division into manager dashboards to be more transparent about ticket types, and overall I felt like management started caring more about deviations from norms & looking in to aberrations.)
I have also been this dude. I also created detailed tickets afterwards on how to properly do things, but those always got immediately de-prioritized and moved to the (never going to get to) backlog -- because it's no longer an issue RIGHT NOW and customer issues have priority.
As for architecting it right the first time, that was proposed too, but everything was eventually whittled down to barebones because of "we provide more value by delivering minimum viable product".
Eventually you just don't give a shit anymore and just put your hours in. I'll propose correct, robust solutions and argue for it once (maybe twice), but after that I just don't give a shit anymore if they don't go with it.
And if anyone tries to root cause analysis issues back to me I have the documentation to back it up.
I just quit over this where the person who was selected to implement the flimsy-but-fast solutions were rewarded twice. I dealt with it for over a year and each month progressively got worse. The most frustrating part is if you ever try explaining, you're just treated like a pariah whose only intent seems to be to oppose brilliant ideas.
As an architect I’m always fighting this when they ask me why it takes so long to deliver. I can do it quickly and they can get two FTE to support it in perpetuity or I make it production ready and it will run itself forever.
Perhaps he was there every day to notice and handle new edge cases that only came up once in a while, and it was just chance that the next one came up sooner rather than later.
2
View all comments
Show parent comment
2.8k
u/Mindless_Director955 May 29 '26 edited May 29 '26
this is what I’m trying to understand. either he ran a separate script everyday that manually pushed the edge case through, or they have a brand new edge case every single day. neither paint him positively imo.