Having worked in various environments with differing levels of success. I've come to a few conclusions that I've forged into my 'personal development principles'. They will read like commandments with the difference being that all things are negotiable here. This is in some ways my own take on the Joel Score Test. There's probably plenty of things to argue about and I welcome the feedback.
This is what I aspire to do
So without further delay, here are my guiding principles in no particular order:
1. Thou shall write to abstractions:
Write to a contract, it's not much extra code. It'll be a prerequisite to writing tests.
Creating an interface is simple and easy. It just needs to be implemented by a concrete class.
Abstract classes are just half-implemented classes that need to be finished by a concrete class.
2. Thou shall write tests that matter:
I was a late adopter to tests. And now that I have I couldn't imagine deploying any mission-critical code without have test coverage. However choose what you test carefully to fully get an ROI on your time. Tests also ensure you play nicely with code you didn't write.
You can also ask other developers to write a test to 'prove' their work to expedite the review process.
3. Thou shall not write monolithic repositories:
100+ projects in a .NET solution? Not if I have any say over it. If you have many teams, you should have many code repositories and gated so that commits are only done by the team responsible or via pull requests (outsiders).
Use individual repos as mid-level components to assemble the final product. Each repo should be versioned and tagged in source control.
4. Thou shall know how to effectively use source control:
One of the single best ways to gain productivity is to use source control effectively. Committing, branching and managing code is almost an art form. Conversely, if a team member is struggling with source control, you need to teach them how to fish in order to avoid a future headache.'
Seriously, source control chops on a team can make\break the whole operation.
5. Thou shall use CI\CD:
"Sorry guys, I broke the build" isn't as bad as checking out code only to find out that it is broken. CI\CD helps avoid "works on my machine" syndrome. You'll never know if your code will truly work on somebody else's machine if something is not continually building the latest code.
"Hey Kevin, can we see that new featured demo'd?" is painless if you're continually delivering your code to an environment often. You'll also be able to have real QA folks test things without being a developer themselves.