Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
1 - Programmer produces code he believes is bug-free.
2 - Product is tested. 20 bugs are found.
3- Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4 - Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
5 - Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
6 - Users find 137 new bugs.
7 - Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
8 - Entire testing department gets fired.
9 - Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
10 - New CEO is brought in by board of directors. He raises the programming team's salary to redo the program from scratch.
11 - Programmer produces code he believes is bug-free.
12 - fml9 -
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.3 -
- 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 cases2 -
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.
4 -
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).4
-
I think I have a programming disease: Premature refactoring. Sometimes I refactor the refactor that I'm doing.1
-
CEO: Please have the dev ready to update Product on 8/20.
Me: That's premature.
CEO: Okay, let them know they'll be updating the team on 8/20.
Fuck. You.2 -
And now they are threatening us... Brilliant!
- they refuse to sign a legal agreement with us [for our services]
- they only gave us a verbal promise they will pay for our services
- they revoke lots of our accesses
- another company is taking over their product we were hired to look after before. Now they demand us do things for them for free
- a few integrations are malfunctioning with premature EOF [while reading a response]. I had escalated this with the most throughout case analysis I have done in my entire life. Three times over the last 2 years. Explaining every single detail that needs to be done, how, by whom and how to interpret the results. Escalations went to their high level mgmt. And directly had been rerouted to /dev/null...
- now they asked us to fix this whole shit. For free ofc, they have no money to pay us..
- they begged
- when that didn't work - they started threatening to route all their customers' complaints to us and flood us with them
at first I was proud to work on their project. I didn't want to leave it when my manager asked me to. A national level project, making a difference for my own country. But now.....
that's gov, my friends. That's politics and power games.8 -
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.2 -
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 ¯\_(ツ)_/¯2 -
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.1
-
I think the sleep deprived me is finally cracking under the weight of incompetent assholes.
We just launched a major project in some weird cocktail of Agile slapped with MVP and release to the wild in a waterfall, but it was premature, premature in the sense QA hasn't even finished their side of things, but because some fuck with with "manager" in their title decided they have burnt through the budget with incompetence and scrapped an entire element of the project and outsourced just so they could make a shittier version that doesn't even fucking work.
How hard do you want to fail before you will start listening to the people that now have to work around the fucking clock to clean up this horse shit of a mess.
I'm literally arguing over field mapping with multiple 3rd parties, when the fucking requirements state WTF this is suppose to look like. All because they didn't validate or test their own shit.
Why is EVERY FUCKING cock head in this industry a waste of space and cash! Is it really to much to ask for 1 fucking project to fucking go live that actually fucking works where I don't need to work 2 weeks straight (including weekends) after going live just to be sure that what shit does hit the fan isn't going to create a SEV 1 issue...
Sorry, I'm pissed at the incompetence of others I need to deal with on a daily basis. It's not like this field is insanely hard. A little attention to detail and self validation, verification goes a long way. But clearly that's a rarity.
Once this shit is stable and actually works, I'll be pulling out the mop to clean up half this shit just so it actually works.
Oof, I'm getting to old for this bullshit.4 -
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.6
-
Been at it inconsistently for two weeks and a few days now. Hitting approx 30 wpm with dvorak! Starting to slowly integrate it into my daily work. I'm on my way to becoming ambitextrous. 😎8
-
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?3 -
A pm asked about a feature I was developing and I went on to show them what I got so far. Feature-wise almost finished, but it still needed to be polished and thoroughly tested, as such it wasn't merged yet. Weeks later - I couldn't finish it yet for unrelated reasons - there was great confusion about why the feature is not there as it had been billed to the customer already. So I gotta pull some sunshine out of my ass and bring it to the last release branch..1
-
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”.6 -
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.3
-
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.2
-
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 ;) -
that moment when a fellow dev asks you a web dev ( PHP ) for help and you see
... -03 -0fast & funroll fruity loops ...
im not surprised that Gentoo box died ... -
Sometimes people want to be too smart. If you want to consume a handful different restful API, it might make sense to abstract away some common functionality in your client implementation — yet to assume they follow the same convention in how their URI is built is borderline insane.
All I wanted to do was to change one API to a newer version, and now the implementation breaks for at least two other because it was done in an Abstract class and now I have to untangle that mess.
In some cases code duplication wouldn't be that bad. Even if an otherwise unrelated API seemingly share the same contract, still assume it has its own contract. You never know how those API evolve and I proclaim they will evolve towards breaking your assumptions.1 -
gulp started throwing premature close on useref:dist yesterday
said it was on a dependency
spent whole afternoon checking gulp issues and reviewing dependencies
as it turns out, it was nothing even remotely related to the error message
it was a spread operator used to merge objects
why must the Lord test me like that -
"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.
Top Tags
Weekly Rant
View