I think "Best Practices" are a good thing, so long as you understand why they are best practices and in what situations. They are bad thing when they are simply dogmatic cargo-cult programming without that understanding.
Moreover, I think they're a good thing as a short hand when thinking about problems. You don't have to think about why this is a best practice for every problem you encounter, because if you did, you'd never get anything done. i.e., Why don't we write all of our code in a single main method? Oh yeah, because it becomes a nightmare to find bugs, update to add new features, reuse algorithms inside it...etc...etc. Instead of going through the rationalization every time, the Best Practices rule of thumb generally works out.
Where it doesn't work out is if you've never done the exercise of why they're best practices in the first place. For every best practice I follow, I have understood the justifications and as a result, have developed an intuitive sense for when my situation is the exception to the rule. Or, if my intuition fails me and it gets questioned, I can re-run the exercise and perhaps change my mind.
1. Never do work on a branch that is being tracked on the origin. Always segregate your work on a local-only branch by doing a 'git checkout -b my-work'
2. Since I prefer not to have merge commits that don't add value to the history, I always get the latest changes, and rebase my-work off the latest. i.e.,
git checkout develop (being tracked on the origin)
git pull (get latest changes)
git co my-work
git rebase develop
git co develop
git merge my-work (no merge commit as it's fast forwarded)
git push
git branch -d my-work
I wholly agree with this, and feel that all project plans should be constructed to mitigate the very high risk of initial estimates.
Too many project processes treat estimates as commitments with no backup plan when they (inevitably) go awry. I think a better approach would be to design your system around the idea that all estimates are suspect until proven otherwise, which of course leads to iterative approaches etc.
However, you can't run a business without any idea when anything will ship. Estimation is still, in my view, a very necessary step, so long as there is significant incentive to get it right rather than get it fast, AND the business is receptive to a little ambiguity through the project life cycle. This is a very difficult balance to strike.
In my experience you can have certainty in project scope or time, but not both.
I disagree. While the comments won't break your code, they can certainly ease the introduction of bugs, and cause cognitive delays when they're wrong or out of date.
Comments need as much care as the code itself, with the DRY principle guiding when they need to be pruned.
>Stop worrying about the procedural code [...] I don’t see a lot of value coming out of the abstractions we create.
I completely agree here. If you're not getting value out of the abstractions, don't introduce them.
However, abstractions in general and OO design does solve many issues that arose from procedural programming. The trick is to recognize the problems, and focus your design around those.
To me, technical debt comes in both the intentional and non-intentional form (and more often than not, the latter). In fact, I'm a firm believer that all software tends toward entropy, so feature additions inherently add to technical debt if conscious care and refactoring is not taken.
Technical debt (to me) is measured in "extra time to add the next feature", however in practice this measurement is impossible, as your control is a theoretical application with the debt removed.
Moreover, I think they're a good thing as a short hand when thinking about problems. You don't have to think about why this is a best practice for every problem you encounter, because if you did, you'd never get anything done. i.e., Why don't we write all of our code in a single main method? Oh yeah, because it becomes a nightmare to find bugs, update to add new features, reuse algorithms inside it...etc...etc. Instead of going through the rationalization every time, the Best Practices rule of thumb generally works out.
Where it doesn't work out is if you've never done the exercise of why they're best practices in the first place. For every best practice I follow, I have understood the justifications and as a result, have developed an intuitive sense for when my situation is the exception to the rule. Or, if my intuition fails me and it gets questioned, I can re-run the exercise and perhaps change my mind.