6 ms·

Sorry, I figured with all the critiques here someone might have an alternative reference.

by YCode 9y ago

rsj_hn 9y ago
It's fine to have company wide coding standards. You don't need to call them "Best Practices", "Our practices" is enough. You can iterate and find out which of these are OK through experience and feedback. Some of the rules here are very specific and just wont work well in the general case (e.g. directory organization, which should probably be decided at a lower level than a company wide policy). Others are too vague to be usefully actionable (security stuff). Having developers instead of legal read Licenses and decide which projects are OK to include in your source seems dangerous.
- YCode 9y ago
  Sure, that's why I asked what other sources are more legitimate/tested. This way I can develop standards for my team, which as of now really doesn't have any.
  - rsj_hn 9y ago
    All the big companies have style guides, but protocols are harder to transplant because it's not reasonable for smaller companies to follow the same practices as big companies. I wouldn't adopt more process overhead without a specific reason. E.g. if you are having quality issues where R&D is shipping stuff before it's ready, then institute a more formal process of sign-off for a release so R&D needs approval from QA. If you are having problems making builds repeatable, then start standardizing the environments with golden images, put everything in version control, etc. If you have issues with licenses for third party code, a 3PP (Third party program) process with sign off from legal/other teams (security would be nice). For each set of problems, there are processes designed to address those. You will also encounter less resistance when the process is a solution to a problem rather than adherence to a best practice. I also wouldn't try to adopt processes just to satisfy a general desire for more process, because there are costs to adopting process overhead, especially the cost of becoming a bit dumber, as an organization, each time you adopt a process to formalize what was previously a judgement call by some decision maker.

Sorry, I figured with all the critiques here someone might have an alternative reference.

by YCode 9y ago

Sorry, I figured with all the critiques here someone might have an alternative reference.

It's fine to have company wide coding standards. You don't need to call them "Best Practices", "Our practices" is enough. You can iterate and find out which of these are OK through experience and feedback. Some of the rules here are very specific and just wont work well in the general case (e.g. directory organization, which should probably be decided at a lower level than a company wide policy). Others are too vague to be usefully actionable (security stuff). Having developers instead of legal read Licenses and decide which projects are OK to include in your source seems dangerous.

YCode 9y ago
Sure, that's why I asked what other sources are more legitimate/tested. This way I can develop standards for my team, which as of now really doesn't have any.
- rsj_hn 9y ago
  All the big companies have style guides, but protocols are harder to transplant because it's not reasonable for smaller companies to follow the same practices as big companies. I wouldn't adopt more process overhead without a specific reason. E.g. if you are having quality issues where R&D is shipping stuff before it's ready, then institute a more formal process of sign-off for a release so R&D needs approval from QA. If you are having problems making builds repeatable, then start standardizing the environments with golden images, put everything in version control, etc. If you have issues with licenses for third party code, a 3PP (Third party program) process with sign off from legal/other teams (security would be nice). For each set of problems, there are processes designed to address those. You will also encounter less resistance when the process is a solution to a problem rather than adherence to a best practice. I also wouldn't try to adopt processes just to satisfy a general desire for more process, because there are costs to adopting process overhead, especially the cost of becoming a bit dumber, as an organization, each time you adopt a process to formalize what was previously a judgement call by some decision maker.