Learn More
Resend Email
3
Time you lost faith in your dev future?
Week 152 Group Rant
Agred
6y

My main project in work is making program in C# (right now .NET Standard) that can read scans of invoices that are sent from contractors. I'm working on it for almost two years now (with breaks and only halftime because university). Alone. And for last two months I've been redesigning, refactoring and making whole app "better", using experience and knowledge gained in the last two years.

Obviously my boss wasn't happy with that but I got him to accept it, promising that it'll make it work faster, expansion will be simpler and I'll make core as a separate library that can be used anywhere, not only in the JobRouter ecosystem.

And so I reworked most of the code, made it cleaner, I hope, and a tad quicker. And I was happy with it while testing on a package of invoices. Today I made first integration with customer's JobRouter.

The results aren't any better - in some cases they are much worse. Especially while searching for invoice entries, which can be in any shape or form and on any of document's pages.

I guess, being a Junior, I wasn't really up to the task. I'm sick of working on a "guessing" program that has to work with every invoice template users can imagine. I'm sick of not getting any recognition for what I did good. And I'm sick of constantly being pushed to make it work better when I just don't have any more ideas or my skills are just lacking.

To be honest, I don't know what to do. I'll probably have to work on making it search the data better. But it's not trivial to just look at the code and see errors. Iterating on the code while working with different invoices worked for a bit in older versions, but I reached the point where changes made to make one invoice be read better, made another one worse.

Its like on those GIFs where you squish one bug to make another two appear.

So yeah, I'm currently really doubting my career, skills and intelligence.

rant

wk152

depressed
Favorite
Ranter
Comments
  • 1
    6y
    This is why more experience steps push back against re-factoring. The potential pay off is nice, but does it really offset the cost of regressions? Just barely working as better than broken.
  • 1
    6y
    @toriyuno Yeah, I get your point. I still don't think it was a mistake, as working with this codebase is easier. I just have to think about better algorithms to guess where is each value :)
  • 1
    6y
    When embarking on a refactoring effort for potential performance gains, it's nice to have some evidence up front. Let's say it's simple like swapping out some string comparisons that could culture invariant. You know that it will be faster, doing a quickie POC to compare N strings the old way vs the new way might tell you that your new code will probably be at least 5 ms faster. Cool. Does it matter? Maybe if that 5ms is part of 1million transactions. Maybe not, if it's how much longer it takes a dialog to display. Regardless, you now have info to use as justification for your change ( and to cya later if things don't work out as intended) or a reason to not do that particular refactor and do a different one instead. Every change has a cost, and refactoring is incorrectly viewed as always a good thing. So, next time, see if you can come up with some info up front that gives you a reasonable view of the rewards.
  • 0
    6y
    @monkeyboy Our reward was splitting from JobRouter API and getting ready for other usage of our product. But during the reworking process I've completely turned around how whole process works and that, I think, created a problem where I couldn't use 100% of my old algorithms. Instead I started writing new ones.
  • 1
    6y
    Been there, done that. Unit tests help a good deal. Profile your code to see what's happening. It is easy to break things like that and can be hard to fix. It just takes debugging and some debug logging statements to start fixing it.
  • 1
    6y
    A classic from 19 (!) years ago: https://joelonsoftware.com/2000/04/...
  • 1
    6y
    @toor I guess, in this situation, "unit" test is each invoice I'm processing. I'm then trying to fix mistakes in this document checking out what went wrong. But as I said before, making one invoice better often makes another worse.
    It doesn't help that scans are often in bad quality or skewed. And Tesseract OCR likes to miss some words or read them with mistakes.
  • 1
    6y
    @Agred ah, I see. You are using ocr, that makes things fun. prolly an actual case for some sort of machine learning model.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment