Fuck you, devs who quote Knuth:

"Premature optimization is the root of all evil"

I agree with the spirit of the quote. I agree that long-winded arguments comparing microsecond differences in performance between looping or matching constructs in a language syntax is almost always nonsense. Slightly slower code can even be preferable if it's significantly clearer, safer and easier to maintain.

But, two fucking points need to be made to you lazy quickfix hipsters trying to sell your undercooked spaghetti code as "al dente", just fucking admit that you had no clue what you were doing.

So here we go:

1. If you write neat correct code in one go, you don't need to spend time to optimize it. Takes time to learn the right patterns, but will save you time during the rest of your career.

2. If you quote Knuth, at least provide the context: "We should forget about small efficiencies, say about 97% of the time [...] Yet we should not pass up our opportunities in that critical 3%"

YES THAT CRITICAL 3% IS WHERE YOU MESSED UP.

I'll forgive you for disgorging your codevomit into this silly PR.

BUT YOU'RE QUOTING KNUTH IN YOUR DEFENSE?

Premature optimization is the root of all evil... 6300 SQL queries to show a little aggregate graph on the dashboard... HE WOULD FUCKING SLAP YOUR KEYBOARD IN HALF IN YOUR FACE.

This! Premature optimization is the mother of all evil.

- Premature optimization is bad and wastes your time
- You need to see the big picture
- Always add extra hours to your estimates
- Test your feature like a QA engineer; look for the edge cases

I swear I work with mentally deranged lunatics.
Dev is/was using TFS's web api to read some config stuff..

Ralph: "Ugh..this is driving me crazy. I've spent all day trying to read this string from TFS and it is not working"
Me: "Um, reading a string from an web api is pretty easy, what's the problem?"
Ralph: "I'm executing the call in a 'using' statement and cannot return the stream."
Me: "Why do you need to return a stream? Return the object you are looking for."
Ralph: "Its not that easy. You can return anything from TFS. All you get back is a stream. Could be XML, JSON, text file, image, anything."
Me: "What are you trying to return?"
Ralph: "XML config. If I use XDoc, the stream works fine, but when I step into each byte from the stream, I the first three bytes have weird characters. I shouldn't have to skip the first three bytes to get the data. I spent maybe 5 hours yesterday digging around the .Net stream readers used in XDoc trying to figure out how it skips the first few bytes."
Me: "Wow...I would have used XDoc and been done and not worried about that other junk."
Ralph: "But I don't know the stream is XML. That's what I need to figure out."
Me: "What is there to figure out? You do know. Its your request. You are requesting a XML config."
Ralph: "No, the request can be anything. What if Sam requests an image? XDoc isn't going to work."
Me: "Is that a use-case? Sam requesting an image?"
Ralph: "Uh..I don't know...he could"
Me: "Sounds like your spending a lot of time doing premature optimization. You know what your accessing TFS for, if it's XML, return XML. If it's an image, return an image. Something new comes along, modify the code to handle it. Eazy peezy."
<boss walks in from a meeting>
Boss: "Whats up guys?"
Ralph: "You know the problem with TFS and not being able to stream the data I had all day yesterday? I finally figured it out. I need to keep this TFS reader simple. I'll start with the XML configs and if we more readers later, we can add them."
Boss: "Oh yea, always start simple and add complexity only when you need it."

Frack...Frack..Frack...you played some victim complaining to anyone who would listen yesterday (which I mostly ignored) about reading data from TFS was this monumental problem no one could solve, then you start complaining to me, I don't fall for the BS, then tell the boss the solution was your idea?

Lunatic or genius? Wally would be proud.

I eat food. And I cook food. Believe it or not, cooking is very similar to coding. Things you do at the very beginning haunt you till the very end. Also, premature optimization is the root of all evil (in both domains).

Premature optimization. 🙊

New course on Udamnme

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - C. A. R. Hoare

Premature optimization

Premature optimization is the root of all evil.

Premature optimization is the root of all evil. 😈

I found weird that some developer never ask why when facing a problem. "What do you mean never ask why?" here some story.

Let's say a developer work with simple app. Laravel as Backend and Postgresql as Database. He face a problem that the app very slow when searching data.

In order to solve that problem he implement cache using redis but he found problem that it fast occasionally. In order to solve that problem he implement elasticsearch because he think elasticsearch very good for search but he found another problem that sometimes data on postgresql out of sync with data on elasticsearch. In order to solve that problem he implement cronjobs to fix out of sync data but he found another problem that cronjobs cannot fix out of sync data in real time. and so on...

Do you see the problem? He never ask why the app slow. Which part search the data? Backend or Database (Search in the Backend mostly slower than Database because Backend have to get all data on database first). Has the query been optimized? (limit offset, indexing). How about the internet connection? etc.

For me it's important to ask why when facing a problem and try to solve the problem as simple as possible.

PR comment: You don't need this useCallback and this useMemo, it's premature optimization, this component will not have a lot of rerenders anyway.

*remove it and merge it*

Few weeks later...
Slack message: why the app is so slow???

*opens a PR putting back all "premature" optimizations*

PR comment: Hum... I don't think that's it, but let's try it.

*merge it*

*slowness is gone*

Slack message: wow! How did you figured out so quickly???

Me: I was lucky, I guess ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Overthinking and premature optimization. God damn them both! My mind completely freezes trying to come up with the best approach without actually trying or typing anything, only thinking.

PreMature optimization is the root of all evil

I know by heart that "premature optimization is the root of all evil" but not when I'm coding, no! I premature optimize the shit out of my code until I get crippled down and then I undo everything and make a working version no matter how terrible it is.

Team lead: guys, we need to brainstorm on feature X. We can have this service do blah blah..., have a cache at blah blah...

Me: I think it's too complicated. We can simplify the design by doing blah blah... and measure the performance as we go, let's not do premature optimization.

Team lead: no, we definitely need this. We'll pitch this to the CTO later

*Later when we meet the CTO*
Team lead: Hi Mr CTO, about feature X, we're gonna do this blah blah... what do you think?

CTO: *basically repeats what I said*

Team lead: Thank you for the insights, really helpful. We will do as you suggest.

WHAT THE FUCK?

My biggest dev sin is premature optimization. I'll try to produce the best possible code without the need for it to be there. I will waste my time thinking of wierd edge cases that can be handled with a simple if-else, but why not tweak the algo to handle them internally.

To be honest with you, I’ve never had a bad experience with PHP.

Yes, it’s “dirty” compared to something like Haskell, but it’s not a bad thing. Dirty things usually bring simplicity and allow implementing the intended case super quickly, at the cost of breaking apart at scale. There are no bad tools, there are wrong tools for the job.

Premature optimization is the root of all evil. The more I launch new projects for me/other companies, the more I come to the realization that the vast majority of the projects out there will never see scale. They will be proven non-viable/impractical and deemed obsolete way before they outgrow the $20 VPS they were hosted on.

Sometimes (all the time, really) launching quickly like there is no tomorrow is the most viable business strategy. If (yes, “if”, not “when”) your project outgrows PHP and gets to the point when PHPs abstraction model is the bottleneck, you’ll have the money to rewrite the project in any language out there, trust me.

As someone said on biking subreddit to a person that asked how to buy the newest super-aero helmet, “if the aerodynamics of the old helmet is what holds you back, someone will be sending you the new one for free”.

Lead developer likes premature optimization. Always forces me to remove a if here and there because "bad for the performance".

Now her optimization caused a base component to fail, ppl will have to spend the night debugging.

Best of all, it's my last day ;)

My biggest flaw when working in IT: I will refuse to prioritize time- consuming work with minimal added value (cf premature optimization, 0.001% edge cases) when I have a backlog of work that will add much more, obvious value and I will not budge to manager or architect power-plays and tendencies to micromanage my responsibilities, even if it may eventually end up getting me in trouble.

While a precaching service worker can grossly improve the performance of a SPA, it definitely doesn't improve the speed of development when introduced between the dev's browser and the app to be debugged.

dammit fuck this premature optimization on choosing which orm library is the best

"Premature optimization is the root of all evil" - he quoted Donal Kunth words. Though it's not the worst advice. From then, coding became simple on achieving the task.

Premature optimization doesn’t mean no optimization.