Code with Engineering Playbook
microsoft.github.io
Code with Engineering Playbook
1–10 of 23 posts
Re: Code with Engineering Playbook
#2As much as one could "nitpick" about ommisions or unnecessary points, for large companies these things are obvious yet necessary.
I also liked the writing style guides that Microsoft and Google put out in recent years:
Re: Code with Engineering Playbook
#3As much as one could "nitpick" about ommisions or unnecessary points, for large companies these things are obvious yet necessary. I also liked the writing style guides that Microsoft and Google put out in recent years: - https://docs.microsoft.com/en-us/teamblog/style-guide - https://developers.google.com/style/highlights
Thanks for that! Definitely giving it a read as I want to make my writing quality more consistent.
Re: Code with Engineering Playbook
#4Good stuff! Always good to see how the big players do it!
Re: Code with Engineering Playbook
#5As much as one could "nitpick" about ommisions or unnecessary points, for large companies these things are obvious yet necessary. I also liked the writing style guides that Microsoft and Google put out in recent years: - https://docs.microsoft.com/en-us/teamblog/style-guide - https://developers.google.com/style/highlights
Too bad Google is going woke https://developers.google.com/style/inclusive-documentation#...
Re: Code with Engineering Playbook
#6This was written by the organization I used to work for in Microsoft. It was developed over the last 6 years by the Commercial Software Engineering organization through hundreds of real, production ready, engineering engagements with Microsoft customers and partners.
There’s nothing groundbreaking for seasoned engineers but it serves as a very robust set of reminders, especially the secondary and tertiary elements that often fall off when projects get stressed to move faster/cheaper/more featured.
Also important that this isn’t Microsoft’s home grown process - rather an amalgamation of working with hundreds of companies - some tech companies, many not - with wide ranges of software engineering maturity. It’s also written and maintained by the engineers directly and with a singular purpose. No marketing, no fluff, no technology or vendor implementations.
Re: Code with Engineering Playbook
#7Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redeploying”. Going to try and implement that in my own projects.
I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.
Re: Code with Engineering Playbook
#8Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redeploying”. Going to try and implement that in my own projects. I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.
>I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.
Hi, stupid junior here. Can you elaborate a bit or give me some reading material? I'm currently struggling to get good practices with tests and understanding associated metrics. Thank you!
Re: Code with Engineering Playbook
#9Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redeploying”. Going to try and implement that in my own projects. I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.
I know this is meant more for backend applications than software meant to run on end user hardware, but...
>able to change logging level without code changes
The folks at Suckless would like a word. ;-)
Personally, I think having to recompile software just to change settings is a royal pain in the butt.
Re: Code with Engineering Playbook
#10Lots of good stuff in there. One that caught my eye is “able to change logging level without code changes”. I would take that one step further to “without redeploying”. Going to try and implement that in my own projects. I disagree strongly with “90%+ unit test coverage” though. Diminishing returns are very real there.
Agreed on the 90% unit test coverage. I'm all for high test coverage, but I care more about having solid assertions. Too often I see test that are expecting an error, but not the error it's getting.
Major business rules need tests too, but they are much harder to write - so we get high unit test coverage and not hard conversations about test quality.