|
|
|
|
|
by davorak
580 days ago
|
|
I do not know what context this happened to you in, but in the context of building something quickly, learning, while not being an expert in an area, best practice are a common crutch. In many work places either they do not have time or at least think they do have time to think things through 100% for themselves from first principles so they depend on best practices instead. That makes sense to me and I would expect better results on average with using best practices than rejection of best practices in the above context. That said I try to work on things where I am not always in the above context, where thinking things through end to end provides a competitive advantage. |
|
There are plenty of them that help us write concurrent code that avoids common deadlock situations without having to resort to writing proofs every time. Someone already did the work and condensed it down into a rule to follow. Even if you don’t understand the underlying proof you can follow the rule and hope that everything will shake out.
What I find we struggle most with is knowing when we actually need to write the proof. Sometimes we bias ourselves towards best practices and intuition when working it out formally would be more prudent.