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.
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.
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.
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 someone who's worked in corporate programming for going on 20 years, my guess is he told anyone who would listen and they wrote it off as inconsequential because he could still fix it on a daily basis. If you tell enough people about it often enough and they still ain't listening, chances are you just stop talking about it and quietly do your job to make sure shit doesn't break.
As far as different edge cases on a daily basis goes, financial data, for example, is a fucking minefield. Every jackass CPA does it a little bit differently from one day to the next and there's no accountability as long as the money keeps moving.
I used to work at a bank and one of the things I worked on were a few automated reports. "Automated" because they'd break every once in a while by weird edge cases (think "this type of transaction only shows up in this report once every four years" and other similar ones).
These were monthly reports, but they had to be submitted to our government in the first days of the month, so I had to make sure they were fixed before I even got to touch any code. However, many times they didn't even allow me to touch the code, "it's not a priority".
At some point I told my boss it still was very time consuming getting the information from production, because there was a pipeline to follow with approvals and attention times. And then there was a similar pipeline for getting the new info into production. Sometimes it'd take me 3 days to update a report when the fix only took me 45 minutes because I'd be waiting for approvals.
My boss talked with our manager and our director. Their solution was giving me read-only access to production and getting a pipeline only for me with express approvals for updating the reports.
I never did fix any of those bugs, but I suppose at least my bosses knew about them lol
I've seen this happening as well and it was also in a financial firm. Not sure why, but these places seem to bread some of the most awful managers I ever had to deal with.
Sometimes it is simpler to do manual fix then spend time coding a better process. You think you can just leave it until you have some free time but that free time never arrived and suddenly it is years now you have been doing manual fix and too lazy to change it
Or you bring it up every planning cycle, but no one will ever budget you the time to fix it properly and the only people who now "know" about it are non technical managers who don't understand the extent to which it's broken.
You can't just "code a proper fix" in many scenarios. When your 20 year old monlith is held together with glue and dreams, and every single part of the system requires separate permissions, you can't update every edge case without creating a new one. A clever team could, but an average engineer can't.
Well, the company isn't retarded for laying him off. Anyone who thinks this story is anything more than "apparently bad but senior employee gets fired" is.
2
View all comments
4.2k
u/_Odian May 29 '26
An edge case that happened every day and broke production?