4 ms·
This is partly because, in my opinion, some "best practices" are superstitions. Some practice was best because of some issue with 80s era computing, but is now
by astrobe_ 3y ago
This is partly because, in my opinion, some "best practices" are superstitions.
Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation.
Yet it is still passed down as a best practice and followed blindly because that's what they teach in schools. But nobody can tell why it is "good", because it is actually not relevant anymore.
Scientific code has no superstitions (as expected I would say), but not for the best reasons; they didn't learn the still relevant good practices either.
- DragonStrength 3y agoActually, when I’ve followed those guidelines, it’s because the tech lead graduated in the 1980s, almost certainly learned it all on the job, but has always done it that way. Others just do what they’ve done before. School talked about those things, but not in a “this is the right way” sort of thing.
- tchalla 3y agoI wish we communicated the intent of the “best practice” instead of the practice itself.
- quickthrower2 3y agoThere is no best practice. It is good to know the tools. In dojo, do that crazy design pattern shit and do crazy one long function. Do some C#, Java, JS, Go, Typescript, Haskell, Ruby, Rust (not necessarily those but a big variety). I want the next person to understand my code - this is very important. Probably more important than time spent or performance. If spending another 10% refactoring to make it easier to understand, even if just adding good comments, it is well worth it. Make illegal state impossible, if you can (e.g. don't store the calculated value, and if you do then design it so it can't be wrong!). Make it robust. Pretend it'll page you at 2am if it breaks!
- ohlokkru 3y ago[flagged]
- fsloth 3y agoNow don't go blaming capitalism. It's the software engineers tendency to always be on the lookout for the silver bullet that will fix one of the currently broken things so it doesn't hurt so much that drives this endless performance theater. In this environment there is an endless flood of salesmen - some benevolent, some charlatans - trying to sell the next fix. The problem is as pointed out by Alan Kay among others that software engineering as a discipline seems to be a pop culture that always is uncritically on the lookout for the next methodology promoted by it's inventor. Without a hint of criticism or self reflection.
- kolinko 3y agoIt was the same in communist countries, even more so. If anything, we’re having less of this now that we switched to capitalism than before.
- jampekka 3y agoYou'll probably get downvoted for mentioning this, but capitalism is a big factor here. It's not so much about selling books and farming engagement. It's about commodification of labor. The "best practices" tend to cater to the lowest common denominator to get at least something done. This lowers bargaining power of labor, drives down wages and increases capital's share of the pie. This is inevitable in capitalism. Happens to all crafts. This is why we can have cheap crap but not nice things.
- dahart 3y agoWhat makes you say that the current culture and fads in some software companies has anything to do with capitalism?
- jeremyjh 3y agoYou’d have as much credibility if you blame it on fluoridation of water as blame it on capitalism.
- 3y ago
- jayd16 3y agoSuch as what? I don't really know of any such superstitions that are based on nothing. I see a lot of opinion/taste presented as something more, but I really can't think of superstitions.
- thethimble 3y agoOOP madness? XML? Web scale databases? Perhaps not superstition but certainly fundamentalist/hype-based thinking.
- jayd16 3y agoChasing hyped up fads seems like the opposite of superstitions from the 80s, no?
- ndriscoll 3y agoI don't know if I'd call it a superstition exactly, but there's a subset of people who are fine with foo1.plus(foo2) and bar1.plus(bar2) where foo and bar are different types, but for some reason, "foo1 + foo2" and "bar1 + bar2" is "confusing" or somehow evil. It feels a bit like they're superstitious about it. I get a similar vibe from people who have an aversion to static type inference.
- astrobe_ 3y agoI saw an example the other day that escapes annoyingly escapes my mind now, as it has been sort of overwritten by the "why the heck do some people name Makefiles with a capital M!?" pet peeve. But I'd say a bit of everything listed in TFA. For instance global variables are the type of thing which makes a little voice say "if you do that, something bad will eventually happen". The voice of experience sometimes say things like that, though.
- leptons 3y agoToday's "best practice" is tomorrow's worst practice.
- chaxor 3y agoIt is important to have popular and powerful tools that can reduce amount of code for things like caching and building. For example, Snakemake (os-independent make) with data version control based off of torrent (removing complication of having to pay for AWS, etc) for the caching of build steps, etc would be a HUGE win in the field. *No one has done it yet* (some have danced around the idea), but if done well and correctly, it could reduce the amount of code and pain in reproducing work by thousands of lines of code in some projects. It's important for the default of a data version control to be either ipfs or torrent, because it's prohibitive to make everyone set up all these accounts and pay these storage companies to run some package. Ipfs, torrent, or some other centralized solution is the only real solution.