3 ms·

- Ceartian people own certain systems/projects. - Ownership is only the point person of knowlage/direction/insights - Anyone can work on the code "owned" by s

- Ceartian people own certain systems/projects. - 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.

externalreality 7y ago
I do believe in giving people responsibility for an area/concern/system of code. It gives them a sense of responsibility and and encourages them to do good work. It allows some creativity and style. I limits turn-over. I agree with totally however.
scarface74 8y ago
The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment. 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.
- macca321 8y ago
  What's tricky is when that lambda doesn't have a documented contract with the systems it talks to, doesn't have end to end integration tests, has a unique build pipeline, requires manual infrastructure creation and there are 100 others like that. I'm not saying yours is like that, but I've definitely seen that happen.
  - scarface74 8y ago
    Well, many things on your list are spot on but the ones that are shouldn’t be scary. - 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__": Code that calls the handler with dummy data. - 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.
protonimitate 8y ago
> - Ownership is only the point person of knowlage/direction/insights 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).

externalreality 7y ago

I do believe in giving people responsibility for an area/concern/system of code. It gives them a sense of responsibility and and encourages them to do good work. It allows some creativity and style. I limits turn-over. I agree with totally however.

scarface74 8y ago

The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment. 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.

macca321 8y ago
What's tricky is when that lambda doesn't have a documented contract with the systems it talks to, doesn't have end to end integration tests, has a unique build pipeline, requires manual infrastructure creation and there are 100 others like that. I'm not saying yours is like that, but I've definitely seen that happen.
- scarface74 8y ago
  Well, many things on your list are spot on but the ones that are shouldn’t be scary. - 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__": Code that calls the handler with dummy data. - 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.

protonimitate 8y ago

> - Ownership is only the point person of knowlage/direction/insights 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).