Principles that guide my way of working as a developer
Preamble
That’s it — this is the first post. A challenge I never really took seriously… and yet, it was only a matter of time!
At this stage, I plan to write about experience feedback from my day‑to‑day life as a .NET developer, as well as real‑estate renovation. One doesn’t seem to have much to do with the other… or does it?
What better way to start this blog than with the principles that guide me?
Prerequisite
An open mind!
Context
I have mostly worked with small, heterogeneous teams (up to 5 developers), meaning people whose experience ranged from what we might call fresh out of school to senior with 10+ years.
Of course, that does not mean much in itself — experience and quality of work are not necessarily correlated. And anyway, what is quality work?
Vision
We must strengthen the trust of stakeholders and demonstrate that business concerns are at the heart of what we do.
Therefore, we should provide a set of good practices to keep in mind throughout our development work.
Principles
- every piece of work SHOULD be reviewed by at least one developer other than the author
- you MUST cover your code with tests, but without over‑focusing on them
- the main branch in Git MUST be protected and MUST NOT be deleted
- the build and unit‑test pipeline MUST run on opened pull requests
- the build, unit‑test, and integration‑test pipelines (if any) MUST run on every commit to main
- in teams using code reviews, nobody SHOULD push directly to main without a Pull/Merge Request (exceptions may exist if everyone agrees)
- you SHOULD apply the SOLID principles
- everyone MUST try to keep things KISS
- the You Ain’t Gonna Need It principle SHOULD be kept in mind, but not applied too strictly
- the Don’t Repeat Yourself principle SHOULD be followed, but not applied too strictly
- you SHOULD try to adopt Clean Architecture (Hexagonal or Onion)
- you MUST use business/functional terminology as much as possible
- you SHOULD take interest in DDD concepts
- you SHOULD focus your code on business rules rather than technical choices
- you SHOULD try to drive your code with test cases when provided
- you SHOULD apply the famous Boy Scout rule: leave the code cleaner than you found it
Conclusion
I consider this to be something like a “principle zero” that I try to keep in mind at all times. It can — and should — evolve over time and through experience.
The last rule is truly my favorite, so here it is one more time:
you SHOULD apply the famous Boy Scout rule: you SHOULD leave the code cleaner than you found it.