- Ownership is only the point person of knowlage/direction/insights
- Anyone can work on the code "owned" by someone else
- Idealy the writer fixes their own bugs and does their own refactoring (for speed and learning reasons) but that should NEVER obstruct delivery of a feature or value add to the company.
The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment.
this is such a key factor to preventing the toxic attitudes that can develop, imo.
At the end of the day, everyone who touches the code base is "responsible" for keeping the machine running.
Any team that favors blaming/shaming for bad code should be avoided at all costs. The mindset should be "what is wrong? How do we fix it? How do we prevent it in the future?" At no point should "who did this?" enter the equation, unless they are harboring some secret fix that no one else knows about (and this just points to other deficiencies in the process).
I have just the opposite problem. No one else wants to add features to code that I wrote because they don’t want to ramp up.
This isn’t difficult to understand code - some of it is less than a 30 line Python AWS Lambda function.
The process is documented in the repo in the readme.
I'm not saying yours is like that, but I've definitely seen that happen.
- end to end integration tests - if they are APIs, they for the most part have a Postman collections in the repo. If they are event based lambdas, they have the standard
if __name__ == "__main__":
- build pipeline and manual resource creation. It’s so easy to export a SAM template from the console it’s criminal to not at least do that. But, yeah we have a CodePipeline to do that.
I have been on the other side though of inheriting a lambda and wondering how the hell did they go through the write->debug->fix cycle? Did they actually load it to AWS first? I spent a day creating a “test harmess”. Not real AAA unit tests, just something I could run locally to debug.