8 ms·

Best Practices Are Not Always the Best

50 points by bloomca 8y ago

mlevental 8y ago
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.
- Retric 8y ago
 Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. Camelcase is the middle ground where it's a good idea but personal preference may show up yet people get just as dogmatic about it. IMO, what trips people up is when wisdom says "don't use Oracle products" it's completely accurate, but not that helpful when you inherit a huge mess.
 - mlevental 8y ago
 >don't parse HTML with a regular expressions Even if I agree with you (I don't know because I've never been in the situation where that was a thing I was considering and weighing against other options) what I'm arguing here is that if someone asks how to do that then you should either tell them along with the admonishment or not say anything at all. But don't go around being a dick by yelling "haha that's the dumbest thing ever and I'm not going to tell you because of best practices"
 - Pamar 8y ago
 While I agree with you in general (i.e. educate people or just stay silent instead of pontificating/be condescending if not rude), what would you say about the canonical answer on StackOverflow, then? https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 https://stackoverflow.com/questions/1732348/regex-match-open...
 - mlevental 8y ago
 meh. the tone isn't so bad but, while at first i thought otherwise, it doesn't really comprehensively explain why it's a bad idea (on first skim i thought most of the content of the answer was an explanation of the difference between a state machine and cfg or something like that). i think a good model for how to answer questions like this is really the same as you'd answer kids' questions as a parent (or maybe anyone's questions?): a flat out no is completely unsatisfactory and lazy. a no with a measured explanation is good.
 Pamar 8y ago
 Again, agreed. But what when something is at the same time pretty much wrong but also something that everyone tries to do because superficially looks like a good idea? The reaction on StackOverflow was because they were getting dozens (hundreds) more or less identical copies of the same question. It was the same with "parse email via regexp" but I understand that more recent versions of the RFC make this doable.
 - coldtea 8y ago
 >Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. I call BS. "Don't have a continuously running service parse arbitrary HTML with regular expressions" would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totally, absolutely, fine. If my HTML file is like: <html> <body> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> </body> </html> I can parse it just fine with regex. And even parsing is the wrong word: I can extract the information I want is a better term. I won't be parsing anything in the AST sense.
 - deleted 8y ago
 [deleted]
 - Retric 8y ago
 That is a trap and why people give that advice so freely. Sure, today you just want to parse these files just the once an never again, ever, really I mean it. Can you determine if it's <html><body>Yes</body></html> Vs <html><body>No</body></html> well sure and even more complex operations also 'work'. However, if you control what's going on then don't use regular expressions it's wasteful overhead. If you don't control it then you can't tell if it will stay like that, which is the trap. Things that don't change the meaning like swapping the order Attributes which does not change the meaning will often force an update to your regular expression. PS: It's also why these are called best practices not physical laws.
 - coldtea 8y ago
 >If you control what's going on then don't use regular expressions it's wasteful overhead. Not really, if you control what's going on it's a very fast option -- use awk, sed, or your scripting language's regex lib, and get the values you need. End of story. Nobody cares if you can micro-optimize it with lower level string parsing that doesn't use a regex engine -- and the regex engine might end up being faster that that anyway. >If you don't control it then you can't tell if it will stay like that, which is the trap. No, but I already covered that in my original comment. One can do it to extract values for a specific, known html file, I said. Besides, (a) a lot of changes can still be caught by regex -- e.g. the order of attributes don't matter if the regex checks for that specific attribute alone (e.g. a href in an a tag). (b) other changes will also fuck any non-regex, parser-based lib. E.g. if the nesting changes or an element is moved to another section. It's not like you don't have to update scripts written with e.g. BeautifulSoup or some HTML parser when the document changes. >It's also why these are called best practices not physical laws. That's up to those who advocate them to understand: and don't hand them out as if they were physical laws "NEVER PARSE HTML WITH REGEX".
 - cgdub 8y ago
 > you really should just say don't do that You should also say WHY not to do that. This lets whoever asked decide whether the reasoning applies to their own unique situation. Perhaps they are doing a one-off scrape of a single file with consistent structure like in the other comment. The asker can also apply the same reasoning to similar situations. They won't come back to ask if they should use regex to parse JSON tomorrow. And if you can't explain why something is "best practice", maybe it shouldn't be "best practice".
 - nix0n 8y ago
 > you really should just say don't do that This is counterproductive unless you also say what to do instead.
- _asummers 8y ago
 A similar frustration I have is when you ask a specific question and get a "Why would you do it that way? Rearchitect your app this way!". That's not reasonable, outside the smallest of applications, regardless of if the underlying advice is sound.
- jrs95 8y ago
 Sounds like the community might be a reason to use Vue over React ;) In all seriousness this is a problem I've run into before as well. I once reported a bug and the lead developer of the project responded saying he didn't think the bug existed. Setting the hostname in the config to the server's IP address was irreversible even if you change it later -- the site would redirect back to the raw IP and outgoing emails would have the raw IP in them. Many other users were commenting about the issue with no response from the maintainer, and I ended up finding a workaround using one of the "developer options" which was really just a one line ruby config change. Then, the author wrote like a one paragraph response saying that you should never set up the software like that and not to use that workaround because it's a "developer option". This bug went unfixed for about 2 years after that. And this is a relatively common and high profile piece of open source software. The whole thing was just bizarre, especially how positive my experiences with other open source projects (some third party Spring packages and Go Dep in particular) have been.
 - mlevental 8y ago
 >Sounds like the community might be a reason to use Vue over React ;) I've run into these "no I'm not telling you because of best practices" people in every single "community"
 - jrs95 8y ago
 I'm sure -- the only times I haven't are when I haven't even had the opportunity to. I was just joking around.
 - specialist 8y ago
 Grrr. I’ve always designed away the sharp edges. Because I don’t want the 4:00a wake up call from panicky customers. Which is why all my devs also did rotations in tech supp, QA/test, build monkey, etc.
- dkersten 8y ago
 I agree.. if you ask any kind of question on code optimisation on stackoverflow you’ll be bombarded with “profile and see” responses, or “don’t bother, your compiler can do a better job” or “use an existing library”, but... profiling will only tell me what’s best on my current hardware, not in the general case. It doesn’t help me understand typical performance characteristics of common operating systems or hardware. It also doesn’t help me with coming up with new better approaches that I don’t know about (which is why I’m asking the question in the first place, to learn what I don’t know). The compiler can do a decent job, but it’s not magic and it often pretty easy to beat the compiler or at least helping it (eg by following Mike Actons advice - compiler can’t make cache inefficient code cache efficient often). Finally, regarding using libraries, sure, in production code I probably will, but I want to learn! If nobody learns, who will write tomorrow’s libraries?
- Rapzid 8y ago
 Oh man this brings back memories. I learned golang for/during a performance coding competition. It was extremely frustrating asking questions about unsafe, pointer casting, and other nuts and bolts in golang-nuts and the irc channel. People were flat out refusing to answer very straight forward questions because "what are you trying to do", "that's not safe", "you shouldn't have to do that". Other fun times; trying to clear the dirty bit on an ntfs file system, and probing into details only "library writers" should have to worry about.
 - Can_Not 8y ago
 There was a discussion earlier in life about how Django didn't support prepared statements. I didn't believe this, as no ORM I've ever used didn't use prepared statements by default. I asked around, trying to verify this claim. I got "what are you trying to do?" I'm trying to find out if Django's ORM uses prepared statements by default. Outside of that one ticket in Google search results (I'm not tuned into that ecosystem, so I can't discern if it's reliable proof or not), it seems like nobody really knows.
- rkangel 8y ago
 Please consider putting in the effort to capitalise the start of sentences properly, and possibly split up your post into multiple paragraphs. Whether you like it or not, I and many others instinctively use grammar, spelling and punctuation as a signal about the mind behind the post. Plus, it makes your post easier to read - posts that aren't just a continuous flow of text with no break are easier to read. My point is - there is an easy way to give your post a greater chance of influencing the thinking more people.
- Can_Not 8y ago
 I might end up writing react code at any random time in my future, I'm currently curious on how one would do the equivalent of "VueJS component computed properties" in React.
- nucleardog 8y ago
 I work on a lot of less-usual stuff. Kiosks, signage display drivers, interactive games running on touch screen walls, etc. I quite frequently run into the problem of the answer to something simply being "that's not best practice", "that's insecure" or even "that's user-hostile". I don't /care/. This is getting installed on a Raspberry Pi and installed inside of a touchscreen coffee table and towed across the country. It doesn't matter that this non-internet-connected device may be vulnerable to other websites accessing its webcam. It doesn't matter that hiding scrollbars and cursors is normally user-hostile. Go ahead and make the point that it's not best practice, insecure, or user-hostile... But don't make that your entire answer.
andygcook 8y ago
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.
- majewsky 8y ago
  I suggest that you work on making your statements more punctual. For example, if I'm not missing anything, all of this could be shortened to: > We apply best practices most of the time to save time, but we usually tweak them for our concrete situation. Be sure to spend most of your energy on your core competence instead of bikeshedding over processes.
- asdsa5325 8y ago
  At least you didn't plug a link this time!
xojp123 8y ago
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'.
- epicide 8y ago
  Exactly. "Best" practices don't always turn out to be the best, after all. "Better" practice might be a better (heh) fit. It's often more useful to look at anti-patterns and avoid those (still with a grain of salt) than it is to go looking for a pre-existing "best" solution to your specific problem.
  - coldcode 8y ago
    Don't get me started on the other best, "Best of Breed". Nothing in software or programming is a binary system, best and dreadful.
Noumenon72 8y ago
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.
DrNuke 8y ago
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
deleted 8y ago
[deleted]
shubhamjain 8y ago
"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. 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. [1]: https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b https://medium.com/@aboodman/in-march-2011-i-drafted-an-arti...
quantumhobbit 8y ago
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. 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.
- vorpalhex 8y ago
  I prefer to think of the term as "sensible default". A "best practice" is usually not the worst default to have, and if you don't have the time or bandwidth to dive into a problem and just want to pick a solution from a hat, you could do a lot worse. The danger comes in that when you want to supplant the best practice with a new practice, you have to genuinely understand the problem in your context, and be able to articulate a full explanation about why the new practice has an advantage. But there is definitely cargo culting around best practices - see using Redux. Core features of your app shouldn't be left to just acceptable defaults, but instead you should grapple with those problems and choose the best possible answer you can at the time.
  - SketchySeaBeast 8y ago
    >The danger comes in that when you want to supplant the best practice with a new practice, you have to genuinely understand the problem in your context, and be able to articulate a full explanation about why the new practice has an advantage. We're experiencing that exact problem - we're introducing for the first time a company wide best practice, which isn't even defined yet and in a constant state of flux, but it's become a shield the strongest evangelists stand behind "why would you want to do that? It's not best practice?" - the "best practice" might not last the month, and it's not clear why that's the "best practice", but it's become a magic seal of approval.
tboyd47 8y ago
> 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. 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. 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.
pasbesoin 8y ago
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. They called that the "best practice". "Best" is in the eyes of whoever's calling it a "best practice".
peterwwillis 8y ago
This wikipedia page explains the nuance of best practice: https://en.wikipedia.org/wiki/Best_practice https://en.wikipedia.org/wiki/Best_practice Not following best practices is more likely to result in inefficiency. But the key word here is "practice". 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 best practice for lindy will result in the best lindy dancing, as it has been developed over time and has the best outcomes. But if for some reason you need to do lindy hop in, say, a really cramped space, the practice will have to change. Best practice doesn't mean only practice.
watertom 8y ago
Best practices = minimally acceptable If everyone is doing it. how can it possible make you the best?
collyw 8y ago
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.....

50 points by bloomca 8y ago

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.

Retric 8y ago
Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. Camelcase is the middle ground where it's a good idea but personal preference may show up yet people get just as dogmatic about it. IMO, what trips people up is when wisdom says "don't use Oracle products" it's completely accurate, but not that helpful when you inherit a huge mess.
- mlevental 8y ago
 >don't parse HTML with a regular expressions Even if I agree with you (I don't know because I've never been in the situation where that was a thing I was considering and weighing against other options) what I'm arguing here is that if someone asks how to do that then you should either tell them along with the admonishment or not say anything at all. But don't go around being a dick by yelling "haha that's the dumbest thing ever and I'm not going to tell you because of best practices"
 - Pamar 8y ago
 While I agree with you in general (i.e. educate people or just stay silent instead of pontificating/be condescending if not rude), what would you say about the canonical answer on StackOverflow, then? https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 https://stackoverflow.com/questions/1732348/regex-match-open...
 - mlevental 8y ago
 meh. the tone isn't so bad but, while at first i thought otherwise, it doesn't really comprehensively explain why it's a bad idea (on first skim i thought most of the content of the answer was an explanation of the difference between a state machine and cfg or something like that). i think a good model for how to answer questions like this is really the same as you'd answer kids' questions as a parent (or maybe anyone's questions?): a flat out no is completely unsatisfactory and lazy. a no with a measured explanation is good.
 - Pamar 8y ago
 Again, agreed. But what when something is at the same time pretty much wrong but also something that everyone tries to do because superficially looks like a good idea? The reaction on StackOverflow was because they were getting dozens (hundreds) more or less identical copies of the same question. It was the same with "parse email via regexp" but I understand that more recent versions of the RFC make this doable.
- coldtea 8y ago
 >Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. I call BS. "Don't have a continuously running service parse arbitrary HTML with regular expressions" would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totally, absolutely, fine. If my HTML file is like: <html> <body> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> </body> </html> I can parse it just fine with regex. And even parsing is the wrong word: I can extract the information I want is a better term. I won't be parsing anything in the AST sense.
 - deleted 8y ago
 [deleted]
 - Retric 8y ago
 That is a trap and why people give that advice so freely. Sure, today you just want to parse these files just the once an never again, ever, really I mean it. Can you determine if it's <html><body>Yes</body></html> Vs <html><body>No</body></html> well sure and even more complex operations also 'work'. However, if you control what's going on then don't use regular expressions it's wasteful overhead. If you don't control it then you can't tell if it will stay like that, which is the trap. Things that don't change the meaning like swapping the order Attributes which does not change the meaning will often force an update to your regular expression. PS: It's also why these are called best practices not physical laws.
 - coldtea 8y ago
 >If you control what's going on then don't use regular expressions it's wasteful overhead. Not really, if you control what's going on it's a very fast option -- use awk, sed, or your scripting language's regex lib, and get the values you need. End of story. Nobody cares if you can micro-optimize it with lower level string parsing that doesn't use a regex engine -- and the regex engine might end up being faster that that anyway. >If you don't control it then you can't tell if it will stay like that, which is the trap. No, but I already covered that in my original comment. One can do it to extract values for a specific, known html file, I said. Besides, (a) a lot of changes can still be caught by regex -- e.g. the order of attributes don't matter if the regex checks for that specific attribute alone (e.g. a href in an a tag). (b) other changes will also fuck any non-regex, parser-based lib. E.g. if the nesting changes or an element is moved to another section. It's not like you don't have to update scripts written with e.g. BeautifulSoup or some HTML parser when the document changes. >It's also why these are called best practices not physical laws. That's up to those who advocate them to understand: and don't hand them out as if they were physical laws "NEVER PARSE HTML WITH REGEX".
- cgdub 8y ago
 > you really should just say don't do that You should also say WHY not to do that. This lets whoever asked decide whether the reasoning applies to their own unique situation. Perhaps they are doing a one-off scrape of a single file with consistent structure like in the other comment. The asker can also apply the same reasoning to similar situations. They won't come back to ask if they should use regex to parse JSON tomorrow. And if you can't explain why something is "best practice", maybe it shouldn't be "best practice".
- nix0n 8y ago
 > you really should just say don't do that This is counterproductive unless you also say what to do instead.
_asummers 8y ago
A similar frustration I have is when you ask a specific question and get a "Why would you do it that way? Rearchitect your app this way!". That's not reasonable, outside the smallest of applications, regardless of if the underlying advice is sound.
jrs95 8y ago
Sounds like the community might be a reason to use Vue over React ;) In all seriousness this is a problem I've run into before as well. I once reported a bug and the lead developer of the project responded saying he didn't think the bug existed. Setting the hostname in the config to the server's IP address was irreversible even if you change it later -- the site would redirect back to the raw IP and outgoing emails would have the raw IP in them. Many other users were commenting about the issue with no response from the maintainer, and I ended up finding a workaround using one of the "developer options" which was really just a one line ruby config change. Then, the author wrote like a one paragraph response saying that you should never set up the software like that and not to use that workaround because it's a "developer option". This bug went unfixed for about 2 years after that. And this is a relatively common and high profile piece of open source software. The whole thing was just bizarre, especially how positive my experiences with other open source projects (some third party Spring packages and Go Dep in particular) have been.
- mlevental 8y ago
  >Sounds like the community might be a reason to use Vue over React ;) I've run into these "no I'm not telling you because of best practices" people in every single "community"
  - jrs95 8y ago
    I'm sure -- the only times I haven't are when I haven't even had the opportunity to. I was just joking around.
- specialist 8y ago
  Grrr. I’ve always designed away the sharp edges. Because I don’t want the 4:00a wake up call from panicky customers. Which is why all my devs also did rotations in tech supp, QA/test, build monkey, etc.
dkersten 8y ago
I agree.. if you ask any kind of question on code optimisation on stackoverflow you’ll be bombarded with “profile and see” responses, or “don’t bother, your compiler can do a better job” or “use an existing library”, but... profiling will only tell me what’s best on my current hardware, not in the general case. It doesn’t help me understand typical performance characteristics of common operating systems or hardware. It also doesn’t help me with coming up with new better approaches that I don’t know about (which is why I’m asking the question in the first place, to learn what I don’t know). The compiler can do a decent job, but it’s not magic and it often pretty easy to beat the compiler or at least helping it (eg by following Mike Actons advice - compiler can’t make cache inefficient code cache efficient often). Finally, regarding using libraries, sure, in production code I probably will, but I want to learn! If nobody learns, who will write tomorrow’s libraries?
Rapzid 8y ago
Oh man this brings back memories. I learned golang for/during a performance coding competition. It was extremely frustrating asking questions about unsafe, pointer casting, and other nuts and bolts in golang-nuts and the irc channel. People were flat out refusing to answer very straight forward questions because "what are you trying to do", "that's not safe", "you shouldn't have to do that". Other fun times; trying to clear the dirty bit on an ntfs file system, and probing into details only "library writers" should have to worry about.
- Can_Not 8y ago
  There was a discussion earlier in life about how Django didn't support prepared statements. I didn't believe this, as no ORM I've ever used didn't use prepared statements by default. I asked around, trying to verify this claim. I got "what are you trying to do?" I'm trying to find out if Django's ORM uses prepared statements by default. Outside of that one ticket in Google search results (I'm not tuned into that ecosystem, so I can't discern if it's reliable proof or not), it seems like nobody really knows.
rkangel 8y ago
Please consider putting in the effort to capitalise the start of sentences properly, and possibly split up your post into multiple paragraphs. Whether you like it or not, I and many others instinctively use grammar, spelling and punctuation as a signal about the mind behind the post. Plus, it makes your post easier to read - posts that aren't just a continuous flow of text with no break are easier to read. My point is - there is an easy way to give your post a greater chance of influencing the thinking more people.
Can_Not 8y ago
I might end up writing react code at any random time in my future, I'm currently curious on how one would do the equivalent of "VueJS component computed properties" in React.
nucleardog 8y ago
I work on a lot of less-usual stuff. Kiosks, signage display drivers, interactive games running on touch screen walls, etc. I quite frequently run into the problem of the answer to something simply being "that's not best practice", "that's insecure" or even "that's user-hostile". I don't /care/. This is getting installed on a Raspberry Pi and installed inside of a touchscreen coffee table and towed across the country. It doesn't matter that this non-internet-connected device may be vulnerable to other websites accessing its webcam. It doesn't matter that hiding scrollbars and cursors is normally user-hostile. Go ahead and make the point that it's not best practice, insecure, or user-hostile... But don't make that your entire answer.

andygcook 8y ago

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.

majewsky 8y ago
I suggest that you work on making your statements more punctual. For example, if I'm not missing anything, all of this could be shortened to: > We apply best practices most of the time to save time, but we usually tweak them for our concrete situation. Be sure to spend most of your energy on your core competence instead of bikeshedding over processes.
asdsa5325 8y ago
At least you didn't plug a link this time!

xojp123 8y ago

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'.

epicide 8y ago
Exactly. "Best" practices don't always turn out to be the best, after all. "Better" practice might be a better (heh) fit. It's often more useful to look at anti-patterns and avoid those (still with a grain of salt) than it is to go looking for a pre-existing "best" solution to your specific problem.
- coldcode 8y ago
  Don't get me started on the other best, "Best of Breed". Nothing in software or programming is a binary system, best and dreadful.

Noumenon72 8y ago

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.

DrNuke 8y ago

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

deleted 8y ago

[deleted]

shubhamjain 8y ago

"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. 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. [1]: https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b https://medium.com/@aboodman/in-march-2011-i-drafted-an-arti...

quantumhobbit 8y ago

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. 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.

vorpalhex 8y ago
I prefer to think of the term as "sensible default". A "best practice" is usually not the worst default to have, and if you don't have the time or bandwidth to dive into a problem and just want to pick a solution from a hat, you could do a lot worse. The danger comes in that when you want to supplant the best practice with a new practice, you have to genuinely understand the problem in your context, and be able to articulate a full explanation about why the new practice has an advantage. But there is definitely cargo culting around best practices - see using Redux. Core features of your app shouldn't be left to just acceptable defaults, but instead you should grapple with those problems and choose the best possible answer you can at the time.
- SketchySeaBeast 8y ago
  >The danger comes in that when you want to supplant the best practice with a new practice, you have to genuinely understand the problem in your context, and be able to articulate a full explanation about why the new practice has an advantage. We're experiencing that exact problem - we're introducing for the first time a company wide best practice, which isn't even defined yet and in a constant state of flux, but it's become a shield the strongest evangelists stand behind "why would you want to do that? It's not best practice?" - the "best practice" might not last the month, and it's not clear why that's the "best practice", but it's become a magic seal of approval.

tboyd47 8y ago

> 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. 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. 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.

pasbesoin 8y ago

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. They called that the "best practice". "Best" is in the eyes of whoever's calling it a "best practice".

peterwwillis 8y ago

This wikipedia page explains the nuance of best practice: https://en.wikipedia.org/wiki/Best_practice https://en.wikipedia.org/wiki/Best_practice Not following best practices is more likely to result in inefficiency. But the key word here is "practice". 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 best practice for lindy will result in the best lindy dancing, as it has been developed over time and has the best outcomes. But if for some reason you need to do lindy hop in, say, a really cramped space, the practice will have to change. Best practice doesn't mean only practice.

watertom 8y ago

Best practices = minimally acceptable If everyone is doing it. how can it possible make you the best?

collyw 8y ago

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.....