I think it is best to strongly reject the idea "best practices will always benefit you".
Most best practices that I have been told about were low local maxima at best, and very harmful at worst.
If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.
It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).
> It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).
If everyone follows that then every decision will be bikeshedded to death. I think part of the point of the concept of "best practices" is that some ideas should be at least somewhat entrenched, followed by default, and not overturned without good reason.
Ideally your records of best practices would include a rationale and scope for when they should be reexamined. But trying to reason everything out from first principles doesn't work great either.
Well calling something a bikeshed is implicitly claiming that it's not so important. Often the specific choice is not very important, but making a choice rather than not making one is important. And while an effective organisation would not allow important decisionmaking to get derailed, many organisations are ineffective.
> Most best practices that I have been told about were low local maxima at best, and very harmful at worst.
This matches my experience, though sometimes they indeed will be helpful, at least after some consideration.
> If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.
In certain environments this will get you labeled someone who doesn't want to create quality software, because obviously best practices will lead to good code and not wanting to follow those practices or questioning them means that you don't have enough experience or something. Ergo, you should just apply SOLID and DRY everywhere, even if it becomes more or less a cargo cult. Not that I agree with the idea, but that way of thinking is prevalent.
(not that I agree with that, people just have that mindset sometimes)
I definitely sympathize with the thrust of the article. I think the reality is somewhere in the middle: best practices are useful short-cuts and people aren't always idiots for suggesting them. I've worked with folks who insist on Postel's law despite security research in recent years that suggest parsers should be strict to prevent langsec attacks, for example. In those cases I would refute leniency...
Although I also do work in fintech and well... card payment systems are messy. The legal framework covers liability for when actors send bad data but your system still has to parse/process/accept those messages. So you need some leniency.
It does drive me up the wall sometimes when people will hand-wave away details and cite maxims or best-practices... but those are usually situations where the details matter a great deal: security, safety, liveness, etc. People generally have the best intentions in these scenarios and I don't fault them for having different experience/knowledge/wisdom that lead them to different conclusions than I do. They're not idiots for suggesting best practices... it's just a nuisance.
That's what I mean about the rejection being too strong. It should be considered that best practices are often useful and helpful. We don't have to re-develop our intuitions from first principles on every project. It would be tedious to do so. But a healthy dose of skepticism should be used... especially when it comes to Postel's Law which has some decent research to suggest avoiding it.
I don't think anyone has ever thought that best practices will always benefit you. Nothing always works every single time in every single case.
This whole thing is really silly and obvious.
Of course you shouldn't blindly follow advice without thinking. But not following advice just because it might not always be right is also a bad idea.
My advice: In general, you should follow good advice from experienced people. If enough experts say this is the best way to do something, you should probably do that, most of the time.
But that advice will never trend on HN because it isn't clickbait or extreme, and requires using your noggin.
> I don't think anyone has ever thought that best practices will always benefit you.
Whenever a "best practice" or "convention" has been presented to me, that is how it has been framed. (...it is best practice, therefore, it will definitely benefit you to follow it)
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.
100%… a best practice in other traditional engineering practices help us work within the state of the art. They’re the accumulated wisdom and experience of engineers that came before us.
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.
It depends on the office culture. The last time I worked in an office, I used a red/green busy signal like this, and people would generally respect it.
It really does depend on office culture. Some people might be more reasonable if you communicate directly. I don't think it would go down well everywhere if you state "Hey! No talking to me if Mr. Smurf is on the table!"... Mr Smurf might have an unfortunate accident sooner rather than later.
If you work a job where having one of these incidents once a year or more is "normal" then the dev team needs to devote most of its time to fixing that, or you need to change employers.
What I mean to imply is that it is an issue that is naturally fixed by improved development, and that fixing does require development skill, but the organization can hamstring their developers to prevent them fixing the issue even if they could.
an incident only once a year is an absurd bar. I'm no fan of on call but ensuring that level of incident avoidance would force the company to move at glacial speeds, which is even worse over the long term than getting paged.
I think my sweet spot is somewhere between once a week and once a month, spread across the whole team.
an incident that requires immediate developer intervention, rather than waiting until tomorrow? It seems like you would have to go out of your way to create a system so fragile that this happened once a month
I worked at a telco that served a few tens of thousands of customers in a huge remote region.
There are so many systems held together with baling wire it was rare to go a day without a significant outage, usually multiple. Everyone who was remotely knowledgeable about tech was basically a firefighter.
I don't think this takes into account the reality of huge megacorps with tons of development teams situated globally who are constantly changing the codebase.
Incidents happen as code changes. Even once you fix it, the changing nature of the code can introduce more issues
I've never worked at a megacorp, but if megacorp employees believe that it is more acceptable for them to cause issues for customers than a 3-dev company, that really seems like a skill issue for the megacorp.
If it is unacceptable to cause that downtime, you write code that makes the downtime much less likely
I expect the scale here is not apples to apples. A three person team is often on a small product and downtime is often a catastrophe like truly broken for customers. Meanwhile a megacorp is often many many large products and downtime usually means a piece of one of them is degraded.
My random guess is that the "downtime" is fairly proportional to the scale difference with megas probably taking the edge.
I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.
Understanding the domain is mission critical for projects. As the lead/architect/PO/... You need to balance what stakeholder say and what the really need. You can not get that, if you do not know the domain.
I'll echo what other people are saying, that you should just not connect the smart tv to your wifi, but I am nervous about smart TVs that ship with cell chips to connect to the manufacturer's servers when people don't hook the device up to wifi.
I'm not sure how to determine which models do or don't ship with cell chips.
That's not a thing. Do you seriously believe OEMs would ship a 4G/5G modem and bundle an unlimited data plan with low margin consumer electronics, just to earn a few dollars per year from ads?
And man, oh man, wouldn’t we all just love a device with a free cell modem and a data plan ripe for the hacking?
IOW, if it has been done, hackaday, et al., would have already shown us how to bypass the weak obfuscation and get free data. Or at least an article on “my new Samsung TV has a cell modem that they don’t advertise. ‘da fuq?”
You can fiddle with the interface and tweak some layout parameters in the sidebar somewhat.
By the time I got it to something I liked, it severely violated the spirit of the experiment, lol (was too big and sparse, with lots of padding between items – the opposite of what it was trying to show): https://share.cleanshot.com/0xD9bPcWD1CL5wDvlVhB
And I still don't know how these numbers are used. I wouldn't be able to keep track of even 3-4 numbers at once, much less the dozens here.
I read about half the article before giving up, but is there any information what Israeli officials actually did to shape US discourse? Besides having meetings.
"It included 80 programs already under way for advocacy efforts “to be done in the ‘Concert’ way”, he said.
The “Concert” remark referred to a sprawling relaunch of a controversial Israeli government program initially known as Kela Shlomo, designed to carry out what Israel called “mass consciousness activities” targeted largely at the US and Europe. Concert, now known as Voices of Israel, previously worked with groups spearheading a campaign to pass so-called “anti-BDS” state laws that penalize Americans for engaging in boycotts or other non-violent protests of Israel.
Its latest incarnation is part of a hardline and sometimes covert operation by the Israeli government to strike back at student protests, human rights organizations and other voices of dissent."
To me, the article is littered with detailed concrete examples of how Israel has sought to suppress and manipulate US public opinion and prevent or dampen normal democratic discussion, protest and actions. The above quote is in the opening few paragraphs.
> worked with groups spearheading a campaign to pass so-called “anti-BDS” state laws
What kind of groups did they work with? What kind of work did they do with them? For all I know they're funneling money to non-profits owned by family members of government officials.
Nothing special, and an exceeding amount is above board. Everyone is playing the same game, using mostly the same tactics. Get wealthy people on board, use that to get policy makers on board while buying up advertising to target and sway people one way or the other.
All foreign powers will try to do the same thing, through the legal channels, and the not so legal channels. The current order enforced on the back of the US dollar is simply too powerful to not do that. Americans are broadly naive about this, so it's relatively easy to "shock" them into caring about it.
Most best practices that I have been told about were low local maxima at best, and very harmful at worst.
If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.
It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).