@_.-AAA-._
#1 Never fall in love with your code #2 Simplicity is the ultimate sophistication #3 Your code should be written for someone else to understand
@tharundevireddy8406
8th myth ‘Brilliant will make you smart’
@johnbode5528
As I usually put it: 1. Paradigms come and go, but legacy code is forever . There's a reason so many companies are running decades-old code; rewriting that code has implications that go way beyond the size of the talent pool. It touches everything from procurement to training to procedures to documentation. You're not just changing the code, you're changing the entire corporate ecosystem that grew up around that code. Not to mention any new system has to work just as well out of the box as code that's been patched and tweaked for decades, and in many cases any changeover would have to be instantaneous. The risks of re-implementing those systems in new(er) languages grossly outweigh any potential benefits. 2. It doesn't matter how fast your code is if it's wrong. It doesn't matter how fast your code is if it can't be patched when requirements change or bugs are found. It doesn't matter how fast your code is if it leaks sensitive information, or provides a vector for malware. It doesn't matter how fast your code is if it dumps core when someone sneezes in the next room. Focus on getting it correct , then focus on making it easy to maintain, then focus on making it secure, then focus on making it robust (or making it fail gracefully ), and after all that you can focus on making it fast.
@funkynerd_com
I'm a PHP developer. I love it when people laugh and/or scoff at me when I say that. I have been one for 20 years now and earn a pretty decent pay leading a very small team of Devs. I will not be fired anytime soon. I own a house, 2 cars, a motorbike and have a wife and a kid, all thanks to PHP. So laugh away, and think of me while you're frustrated trying to learn this week's new JavaScript framework.
@ComradeLuna
Got paid by the state of New York to learn COBOL (basically a bootcamp that you get paid to do) and now I work for them. Old languages are still widely in use. If there's one thing that's worth stressing the most it's that. I regularly work on code that was written in 1987 with the last update in '97 for "Millennium Compliance". People here have been told for the last 2 decades that we'd be done with all the COBOL stuff by 2020, 5 years into the decade and we're nowhere close. Honestly I'd be surprised if it's gone by 2050.
@glurp1er
As a senior programmer, I can assure you that "following the new trend" is the worst thing you can do. I've witnessed too many "revolutionary" frameworks die. You should always reduce your dependencies to a minimum if you want your project to last.
@horndude77
For myth 5 I've always liked the saying: make it work, make it right, make it good, make it fast. It's a good priority ordering.
@Ripotes
My first job, the first time I got a look at the Java back end, it was just a massive list of functions that looked mostly the same so I asked our chief engineer why there was a so much repeated code and he said it's because they all serve separate modules with separate users who could request changes at any time so keeping the services from having any shared dependencies helps make sure changing one will never break another. It was a large company and the whole R&D division pretty much relied on him continuing to work there to the point where he was fully remote back when nobody was allowed to do that so I tend to value any advice I got from him. I think of it like this. Abstraction and Encapsulation are both your friends, but they're not friends with each other. Very often have opposite opinions actually and you will have to pick sides. Abstraction prioritizes the well being of your codebase while Encapsulation prioritizes regression management and the end user.
@dogyX3
1. 0:47 You need to use the latest tech to stay relevant 2. 2:00 Aim for maximum theoretical purity or pattern adherence 3. 2:50 You must adhere to Uncle Bob's clean code rules at all times 4. 3:40 100% Code coverage is something that matters 5. 4:21 You should always optimize your code 6. 4:37 You should always optimize for web scale 7. 4:53 AI is about to replace all programmers
@OneTwoMark
That last point about AI was a breath of fresh air, considering I how I feel after every AI video Fireship usually covers.
@Ryukachoo
3:42 I've been some combination of QA, systems test engineer, automation engineer, and sdet for like 10 years now. Everything here is bang on, every single time a Dev finds a code coverage tool, my manager at the time gets excited about having the shiny 100% and I have to tell them that 100% is oftentimes actually worse than 30% or lower or for the reasons you just described Personally? Shoot for 80%, and only write a test if it's actually good
@trueberryless
3:42 Just read the first two chapters of "Unit Testing Principles, Practices, and Patterns" by Vladimir Khorikov and Myth 4 is 100% covered, pun intended
@roelf8044
.NET developer with 20 years of experience here. I agree wholeheartedly with all the myths you mentioned🎉
@adamemsley2736
Completely agree with repeated code not always being bad. Sometimes I will have 3 medium-sized functions that are almost the same - but I also can see the broader application scope and realise that foreseeable changes later down the line would be hideously difficult if generic functions were to be used to reduce repeated code!
@Little-bird-told-me
Most of coders think that being productive is writing code but in reality being productive is when they ship the finished app
@bobthemagicmoose
The testing thing really drives me bonkers. Most code I see is useless wrappers and abstractions. They then have unit tests to touch every line. These unit tests then mock out everything and turn into snapshot tests of what the function does. They don't test any expectations of the function, just the implementation. So they ensure that it does what is programmed to do (not what it should do). Not only is this tedious and useless, it makes refactoring a huge chore.
@GSBarlev
These are the most milquetoast, lukewarm takes I have heard in years, and people need to hear them, because while they should be obvious, there are still waaay too many developers (especially tech leads) out there who believe these myths.
@LukasSkywalker_
Another one... Tests does help A LOT on larger teams. I worked on a couple of companies that didn't write any tests. The amount of bugs that were mitigated becuase we added tests were fenomenal. Since then, I tend to always write tests on more critical code. I agree that it does not need to be 100% coverage, but don't avoid tests, please.
@Johnlongears
i'm so glad you've deboonked these myths
@Fireship