There are a few concepts/principles in software engineering that are over-emphasised and prioritised without enough actual thinking.
Time to firs...
For further actions, you may consider blocking this person and/or reporting abuse
Anyway, just a few words on the 3 points
To be super clear (if we're all off quoting Wikipedia YAWN)
Where 'emic' means within the social group.
What Chris is saying (I think) is that the social group of developers attribute to the three objects (DRY, time to first byte, and 'clean' commit histories) inherent supernatural powers which they have in and of themselves.
If you are sexually aroused in any way by having a clean commit history, seek help.
Also
This is not really the point I'm trying to make.
If you are fetishising time to first byte then you are prioritising performance. The point is that you should not be prioritising that above everything else in respect to performance.
I wouldn't get too caught up about the definition of "fetish".
Wikipedia
Very good article! I really like your advice on DRY coding. I find myself overthinking when I put too much focus on DRY.
I was about to create some overly complicated DRY solution to two very similar functions today. But thinking about this post again, i decided against it. 🤗
See the other comments, fetish is appropriate (if exaggerated) :)
I'm intrigued by the build-a-framework fetish, which - unlike the others you describe - isn't quite based on any useful principles.
What am I talking about? Let's say that as a .NET developer I need to store some data in some Azure tables. My tendency will be to create abstractions that aren't specific to Azure at all, and then in the implementation I'll use the classes Microsoft provides. The same is true for pretty much anything. Sometimes someone produces a really great library that simplifies the use of another, and if it seems really helpful then I'll use it.
The fetish I see is that developers immediately want to start building pointless, unnecessary "frameworks" to wrap existing classes, and then they want everyone else to use them for the sake of consistency. (This is much worse when it's a developer who can enforce it.) So now if I want to use an Azure table I have to use their weird, buggy wrapper class in a library named CompanyName.Frameworks.Storage.AzureTableStorage. Existing code is littered with dependencies on
IMySpecialAzureTableStorageWrapperClasswhich a) isn't an abstraction because it can't represent anything other than Azure table storage, and b) hides or confuses the methods I need on the underlying classes. The solution? Add to the problem by modifying the wrapper. (I'm sorry, I meant "framework.")It forces developers to learn someone else's bad proprietary code while denying the opportunity to learn the underlying API. In return it adds nothing except bugs and overhead.
It also gives some developers an opportunity to appear productive because they're constantly writing wrappers for stuff that doesn't need to be wrapped, and the fact that it's used everywhere creates the illusion that it serves a purpose.
I agree with this, but if I were going to debate anything it might be that conflating performance and usability with "doesn't work without Javascript". This is a possible consequence for some apps, but on the web, as it has evolved, delivering a fully-functional JS-free web experience seems like a reach.
For many sites, sure, it is silly to glob on all this JS. Probably most even, but many applications are built in a way to use the web as a JavaScript platform. So I think you have to distinguish between these use cases.
The conflation was accidental on my part. The main point I was trying to drive was the over-emphasis on time to first byte can end up with teams ignoring other factors (like number of resources to fetch) and also the proposed solutions to improve time to first byte can also hurt the other performance metrics I mentioned.
Thanks for sharing! Regarding DRY, were you referring to this article by Sandi Metz? sandimetz.com/blog/2016/1/20/the-w...