Best practices for a Google scale company, where most best practices come from, is NOT the best practice for everyone else.
Against Best Practices
171–180 of 218 posts
Re: Against Best Practices
#172Best practices for a Google scale company, where most best practices come from, is NOT the best practice for everyone else.
As someone at Google, I hardly believe they deserve to be used at Google. We have like 20% the efficiency we could have if we were more selective about procedure.
Re: Against Best Practices
#173Dan Morena, CTO at Upright.com, made the point that every startup was unique and therefore every startup had to find out what was best for it, while ignoring whatever was considered "best practice." I wrote what he told me here: https://respectfulleadership.substack.com/p/dan-morena-is-a-... My summary of his idea: No army has ever conquered a country. An army conquers this muddy ditch over here, that open wheat fiel…
> No army has ever conquered a country Napoleon and his army would like to have a word with you… I get the analogy but I think it can be made a lot better, which will decrease people who dismiss it because they got lost in where the wording doesn’t make sense. I’m pretty confident most would agree that country A conquered country B if country B was nothing but fire and rubble. It’s pretty common usage actually. Also,…
It's a cute analogy, but like all analogies it breaks after inspection. One might try and salvage it by observing that military "best practice" in the field and Best Practice at HQ need not be, and commonly are not, the same, either for reasons of scope or expediency. Moreover, lower case "practice" tends to win more, more quickly. Eg guerillas tend to win battles quickly against hidebound formal armies.
For a startup, winning "battles, not wars," is what you need, because you have finite resources and have an exit in mind before you burn through them. For a large enterprise, "winning wars not battles" is important because you have big targets on your back (regulators, stock market, litigation).
One might paraphrase the whole shooting match with the ever-pithy statement that premature optimization is the root of all evil.
Re: Against Best Practices
#174Earlier quoted context omitted.
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…
> 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 qualit…
I agree with you, I think you're describing the same sort of person I was thinking of in the second paragraph of this post: https://joshduff.com/2022-02-07-eschatology-of-software.html
Re: Against Best Practices
#175I once put in an e-mail the following "best practice applied for the sake of best practice, is bad practice" to consultant who chalked up an awful decision to "applying best practices"
Re: Against Best Practices
#176That's some weird ligature, on that font...
I don't think that the issue is with "best practices," or any other type of dogma.
I think the main issue, is that companies tend to hire folks that aren't especially skilled at what they do, and rely on excessive structure, to compensate, or that they don't stay around, long enough, to get comfortable with the structure.
This can apply to both newer folks, who don't understand the system well enough to effectively deviate, and ones with a lot of experience, who have allowed themselves to get so hidebound, they are afraid to deviate.
As I have gotten older, wiser, and more battle-scarred (often, from self-inflicted injuries), I have learned that "It Depends™" is the only true mantra for my work.
Usually, best practices/dogma/structure becomes important, when the codebase is being worked on by a team, and when there's the need to coordinate work between teams.
There's some type of work that just can't be done, without structure. I've done that type of work. Other work can be killed by too much structure. I've done that kind of work, as well.
Re: Against Best Practices
#177Earlier quoted context omitted.
What makes you so sure they do? Go to the hardware store and behold how many fasteners there are. Go down the rabbet hole of pipe fittings. Consider the optimal size of lumber, someday. And then get ready for the horrors of electrical connections. Not necessarily in how many there are; the real horror is how many think there is a "one true answer" there. You can find some solace in learning of focusing effects. But,…
That's a great point. In the end, other engineering areas also have lots of "it depends" situations, where often there are multiple correct answers, depending on availability, legislation, safety, physical constraints, etc. Perhaps in software engineering people are just too quick or immature to judge. > rabbet hole Nice pun ;)
I'd love to claim the pun was intended! :)
Re: Against Best Practices
#178The advantage of best practices is that you have something you can follow without having to analyze the situation in depth. The disadvantage of best practices is that you may have to analyze the situation in depth to notice that they maybe aren’t the best choice in the specific situation. The harm that best practices can do are lessened by viewing them as a rule of thumb conditioned on certain premises rather than as…
That’s why I think Best Practice is a bad term. I rather call it something like Best Toolkit or Best Elements.
Maybe the problem is the word Best. Perhaps Standard Practice is better — suggests "the usual way we do things" without presuming it is the best and only way to do things.
Re: Against Best Practices
#179Earlier quoted context omitted.
> Only software engineers pretend best practices exist outside of any useful context. I am not seeing this issue with programmers in general or with my coworkers, with the exception of those who in general have a hard time collaborating with others. So my question was/is if you discount the above exception are people seeing a problem with programmers/coworkers not taking context in to account? I have not noticed a wi…
Aren't these discussions the evidence? The fact that the author wrote a blog post and we are here discussing it. I might be missing the point of your question. This is everywhere around us in the development world. Anytime people compare react to htmx, redis to postgres, TDD vs BDD. I'd like to point out I never called it a problem. I said that was a judgement call for you to make. We all have harmless biases. But ye…
> But yeah, it can be a problem. If I have an engineer derailing my team because of his insistence for svelte, and can't read the room: ie can't take any of the context of the business, stack, domain, team, into his consideration, then yeah, it becomes a problem. Time is money
I would describe this someone who does not know how to collaborate, maybe they don't know the balance they need between give and take, maybe they do not know how to format their ideas so they are understood by the group, maybe there is some fundamental misunderstanding. Since the tool of collaboration is not working for them, they reach for other tools to leverage and achieve their goals, like argument by authority via a convenient best practice.
The best practice/standard was not the issue, lack of context for the best practice was the the issue, the lack of collaboration or ability therein is the issue.
Re: Against Best Practices
#180How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…
> How other engineering industries deal with this phenomena? They don't. CAD, the "programming languages" of most other engineering disciplines, is as much of a Wild West.
I'd say Yes and No, there are standardized ways to analyze common engineering problems, for example beam deflection equations https://en.wikipedia.org/wiki/Deflection_(engineering)
or Heat Exchanger efficiency calculations (https://en.wikipedia.org/wiki/Logarithmic_mean_temperature_d...) etc.
Often the models and equations rely on making assumptions in order to simplify the problem (cue the joke about physicist and the spherical cow). This is one of the reasons thing are designed with tolerances and safety factors.
Software like CAD and particularly Computational Fluid Dynamics (CFD) packages can simulate the problem but at least with CFD you would typically perform other types of verification such as wind tunnel tests etc.