There are nefarious managers, but most times it's our own failings to communicate that makes us invisible.
It's not a failing to be introverted and not desire attention/spotlight.
> If she made sure to inform what is she fixing, management would appreciate her more.
Most people usually get annoyed when you tell them what you're doing for them.
It is a failing if you care about getting recognition. Self-promotion isn't the only reason for recognition. For instance you might want to promote proactive maintenance instead of reactive repairs.
> Most people usually get annoyed when you tell them what you're doing for them.
That is very different from my personal experience.
"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.
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".
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.
It could also be a matter of the ratio between tech work to be done and tech workers available. In an IT department that has too much pending work, it might be more worthwhile to implement quick crap solutions than to go back and properly fix stuff. You could call this a failure in properly funding such a department, but this is viable to happen in a business where the executives (or whoever controls the funding) don't really understand the difference between crap tech work and good tech work.
In most ops roles, Dave would be fixing someone else's broken-ass system, and anyone else in the rotation would have a similar number of "incidents" against them.
because Dave isn't blamed for the incident reports - either the original reporter is or no blame is assigned. Dave gets all the accolades though.
Human nature at its "finest". I now work at a place where that's no longer an issue for me because "blaming the messenger" isn't a management culture where I am now.
Eventually the entire system self supported...and was retired a year later.
What should be rewarded is the skill necessary to architect software in such a way that it is easy to maintain. I often say to myself, does this decrease the effort needed by the reporting team to create reports? Does it isolate features and make it easy for devs to find the source of issues and fix them? Is it modular enough that users can expect a quick turnaround time for new features?
What I've found is that many developers, even those who believe they should be seniors and above, are unable to think from this perspective, or frequently think it's "impossible" to make software that addresses and solves the issues of all groups. In my experience, it is never impossible, it is all about having the right architecture, which can takes weeks to fully think up and realize, and may still change afterwards, but the design of the software is what I usually choose to reward.
I find this increasingly to be the case.
The fashion now is to do everything with MVPs and sprints.
The big hidden assumption with this style of development is that any problem can be solved using incremental 'local searches'¹ through the design space.
This is definitely not true, especially for co-optimization problems like you describe above².
1: https://en.wikipedia.org/wiki/Hill_climbing
2: "Solving the issues for all groups" appears like a meta co-optimization problem.
after a number of years in (mostly) software i’ve observed less tolerance for that level of analysis. i understand why it can/will impact velocity, and that the cost to change software (and time) is a fraction of that with physical systems...but still...a part of me winces whenever im like “screw it, im merging this sans impact analysis” ;)
has anyone else had a similar experience?
My experience, exactly.
Imagine the following scenario.
Acme Co. has some piece of software that is critical to the operation for their business.
Dave is in charge of the software system. The software crashes often but Dave is always there to save the day.
Dave often has to stay up all night and is seen fixing problems at the final hour. Management takes notice of this and often sends out emails congratulating Dave for his hard work.
One day Dave leaves, and is replaced by Amy. Amy takes over the system and slowly and methodically fixes all the bugs that were causing the outages in the software.¹
Over time the code becomes more reliable, till eventually it runs smoothly.
Now what would management say if you asked which programmer was better. They'd likely say: "Amy is pretty good, but boy that guy Dave was a real rockstar!"
When you reward a behaviour, you will get more of it.
If you want software maintenance, then you need to reward it. But often, perversely we reward its opposite.
I'm working mostly as an ops person these days, and if I do my job well it makes my contribution look invisible. When things are going right, there won't be anything to notice.
1: In other words, code maintenance.