> There are also tons of evangelists, which promote their technology/process/approach of choice, giving endless introductory talks and blogposts, but without answering complicated questions.<p>I find some programmers are very adamant that there's always a right way and a wrong way to do something and you just have to examine the pros and the cons. Well, what about when it's between a legacy codebase that no one on the team has even spent half a day looking at and an idea that someone read on a blog post that they never bothered to try? You can't honestly begin to identify pros and cons in a situation like that. But this is how our industry is now. So you kind of have to take claims of "best practices" with a grain of salt.<p>I don't even really engage in discussions on "best practices" anymore. Not because I'm cynical, but because they just lead nowhere. Write some code that runs, show it to me and we'll talk.
you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal experience (and abilities to make the right decision for themselves) and their circumstances (the project itself) and it's always around something dogmatic/a reflection of fanboyism. most recently on #reactjs I wanted to know if there were a way to have locally scoped styles in react like in Vue - I got only condescension about how react is for "bigboys" and hence eschews the practice. Finally someone said hey maybe try styled-components, which was basically close enough and has 16,000 stars on GitHub (so I doubt it's "worst practices"). software devs are some of the most zealous people I've ever met - everything is an opportunity to bike shed and every question or difference of opinion is an opportunity to quarterback someone else's code base.
We’ve iterated on our process quite a bit for my startup. I agree that sometimes you need a completely new approach, but more often than not what already works for another team will most likely work for us with some small tweaks. What I find works pretty well is to think about the problem, apply our existing knowledge and experiences to the solution, make any obvious edits for our unique, then test it out. From there, we make tweaks if needed to get to what works, or we completely scrap what we know and try something completely new. Process, like product, requires iteration. But process is also built off conventions and modeled off core human behaviors. Chances are the wheel doesn’t need to be completely reinvented. My advice would be to fork what works on the process side, and use all your creative energy to come up with something new on the product side.
Evertime I hear someone defend something as a best practice without any other justification, I mentally switch “best practice” with “cargo culting” and lose no information.<p>Sometimes the best practice in question does have value and can be articulated. But in those cases the articulated reason makes a better argument and you don’t hear the phrase “best practice” quite as often. When it is just cargo culting, the only defense is to repeat “best practice” over and over again.
Two years into my programming career, there's still almost nothing I do that isn't just implementing the best way someone else thought to do it. And I still have a lot more to learn before I would start off on my own. My only problem with best practices is that sometimes there are too many and living up to them all would take all your time. And some of them are just evangelists for niche ideas and it's hard to tell.
"Don't use Goto," "Don't use Regex against HTML." Worse than not following best practices is accepting it without demur. The insight dawned upon when I learned how Chromium's team doesn't use continuous branching. The codebase moves so fast that committing to a single branch is a much better option [1]. I highly doubt Google's engineers made that choice out of sloppiness.<p>Although, I think it's not simple to foresee long-term implications of our decisions. And, best practices do fill that hole. At the same time, programmers should keep an open mind to use a solution if it's a radically simpler choice.<p>[1]: <a href="https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b" rel="nofollow">https://medium.com/@aboodman/in-march-2011-i-drafted-an-arti...</a>
This wikipedia page explains the nuance of best practice: <a href="https://en.wikipedia.org/wiki/Best_practice" rel="nofollow">https://en.wikipedia.org/wiki/Best_practice</a><p>Not following best practices is more likely to result in inefficiency. But the key word here is "practice".<p>Practice dancing a lot and you will be able to dance well, in the form of dancing you practiced. There are other forms of dance and thus other forms of practice. Practice for lindy hop is going to differ from practice for tango, or jazz. And the <i>best</i> practice for lindy will result in the best lindy dancing, as it has been developed over time and has the best outcomes.<p>But if for some reason you need to do lindy hop in, say, a <i>really</i> cramped space, the practice will have to change. Best practice doesn't mean only practice.
One benefit of best practices is standardizing the way things are done. I have worked on project where the original developer had invented a "thin models fat controllers" philosophy for Django (best practices are fat models thin controllers). What a mess that was.....
When they moved us, programmers and related staff, to "cubettes" -- not even full cubes, but rather a corner in a shared three-sided "pen" with low walls. Your neighbor's shoulder three to five feet away from you. Cube meetings crowding into their half of the pen. Conversations shouted willy-nilly across the open floor plan.<p>They called that the "best practice".<p>"Best" is in the eyes of whoever's calling it a "best practice".
Being a tad pedantic and agree with the spirit of the article, but this just seems like a result from the overuse of the phrase 'best practices'.
b2b business is based upon best practices though, you cannot have a startup mentality (hack or disrupt) when its legal consequences would outrisk the possible gain