Just because you don't have to write some novel algorithm doesn't mean you're not solving hard problems.
I'm currently in a very similar situation - a project in which we have a table of records, two of which are special in a certain, business-related way, but need to be presented along with the others, so to get around this we place "ifs" here and there - a lot of them.
It's a generally simple project that has been turned into something overly complicated because somebody lacked the foresight to design the architecture better.
Instead I am jumping from file to file, trying to work out what is going on, what all the seemingly unnecessary code is doing. It can be both tedious and difficult just to get data between the database and a webpage.
I want to rewrite a lot of it, but I understand that working, tested code is actually worth quite a lot, and there may be functionality that i haven't understood yet.
That idea - the distinction between tedious and hard - is going into my mental toolkit. Thank you.