Maybe I got unlucky in my career but I've worked with a "Dave" and an "Amy" where the OP's description is spot on.
"Dave" got all the hero credit and "Amy" was deemed as nothing more than someone average at her job.
While peers might now "Amy" is the real hero, non-technical people don't grasp that very well. And unfortunately normally those are the managers and executives.
> While peers might now "Amy" is the real hero, non-technical people don't grasp that very well
This could be also a failing to communicate effectively. Us developers sometimes have a hard time translating:
"the join duplicates records because X table has duplicate values in Y field. We need to add a unique key constraint to it and catch the exception in module Z"
into
"your report has duplicated products because someone captured the serial number twice. I'm going to add the missing validation so this doesn't happen again".
If Dave brought up the system and features, from nothing to something, which is where the difficulty is, then he probably should get more praise.
I think polishing or even refactoring an existing solution that now has well defined and understood required features, corner cases, and quirks will always be vastly easier than the unknowns involved in building something from scratch.
"Dave" got all the hero credit and "Amy" was deemed as nothing more than someone average at her job.
While peers might now "Amy" is the real hero, non-technical people don't grasp that very well. And unfortunately normally those are the managers and executives.