00:00:00
Recently, I unlocked a new achievement
00:00:01
in life, a midlife crisis when I came to
00:00:04
the realization that I've spent most of
00:00:05
my adult life writing code. And most of
00:00:08
that code is total garbage. It's code
00:00:09
that never saw the light of a production
00:00:11
server and was either abandoned,
00:00:13
refactored, or left to rot in the
00:00:15
graveyard of GitHub. As I reflected upon
00:00:17
this further, I realized that many of
00:00:18
the best practices, the hot
00:00:20
game-changing frameworks, and the
00:00:22
perfect folder structures didn't
00:00:23
actually matter to the end user. I
00:00:25
wasted countless hours chasing
00:00:26
programming dragons that made me feel
00:00:28
more productive but ultimately led
00:00:30
nowhere. In today's video, we'll debunk
00:00:33
nine smart ideas that waste your time as
00:00:35
a programmer. And for each myth, we'll
00:00:37
look at how it lures you in, why it's
00:00:39
actually a trap, and most importantly,
00:00:40
how to not do the things that I have
00:00:42
done. Now, one of the main goals of this
00:00:44
channel is to show you the latest tech
00:00:45
you need to use to be relevant. But it's
00:00:47
actually a myth that you need to use the
00:00:49
latest tech to be relevant. In fact, you
00:00:50
might even become more hirable by
00:00:52
focusing on old dinosaur technologies
00:00:54
like WordPress and PHP still runs most
00:00:57
of the web applications out there. Java
00:00:59
runs most of the enterprise world. Most
00:01:01
databases are SQL based and C++ runs
00:01:03
most of the low-level systems. However,
00:01:05
there are shiny new replacements for
00:01:07
tech like this, including Nex.js,
00:01:09
Cotlin, NoSQL, and Rust. And the lure is
00:01:12
a massive feeling of FOMO if you're not
00:01:13
mastering the bleeding edge of these
00:01:15
so-called superior technologies. To be
00:01:17
clear, I'm not discouraging you from
00:01:18
learning these. They're awesome, but
00:01:20
it's important to understand that most
00:01:22
of the real world, where the jobs exist,
00:01:24
are not going to change their dinosaur
00:01:25
tech stacks anytime soon. The critical
00:01:27
banking systems still run on Cobalt, and
00:01:29
Java will still be powering 3 billion
00:01:31
devices long after everybody watching
00:01:33
this is dead. Most CTOs are smart enough
00:01:35
to know that if it ain't broke, don't
00:01:37
fix it. Here's a real life example. A
00:01:39
few years ago, engineers from Twitter
00:01:41
released a hot new database called
00:01:42
Fauna. It was a pretty solid product,
00:01:44
and I even made a video about it. But
00:01:46
the technology was proprietary, VC
00:01:48
funded, and like most startups, the
00:01:50
business failed recently. They have no
00:01:52
choice but to shut down their servers.
00:01:53
And if you were an early adopter, you're
00:01:55
now screwed and would have been much
00:01:56
better off with a boring SQL database.
00:01:59
Adopting tech too early is one thing,
00:02:00
but adhering to programming dogma can
00:02:02
waste even more time. The problem with
00:02:04
programming is that there are many
00:02:05
different ways to solve the same
00:02:07
problem, but some people out there
00:02:08
believe that there's only one true way
00:02:10
to write code. Some common cults out
00:02:12
there include the object-oriented
00:02:13
purists and the functional programming
00:02:15
extremists. I've been a member of both
00:02:17
cults and have learned a lot from them,
00:02:18
but dedicating your entire life to just
00:02:20
one of them is a waste of time. I mostly
00:02:22
code in JavaScript, which is a
00:02:23
multiaradigm language that can satisfy
00:02:25
all of these cults. In 2018, functional
00:02:28
programming was having a renaissance in
00:02:29
web development. But back then, if you
00:02:31
use classes in your code, you were
00:02:32
literally Hitler. And I found myself
00:02:34
bending over backwards to try to do
00:02:36
everything in the most functional way
00:02:37
possible. no mutable state and higher
00:02:39
order functions everywhere. But a few
00:02:41
years later, after the spell wore off, I
00:02:43
eventually realized that classes can be
00:02:45
pretty useful. And my code today often
00:02:46
includes a combination of things I've
00:02:48
learned from both of these cults. But
00:02:50
another time waster to watch out for is
00:02:52
clean code, which comes from a legendary
00:02:54
book written by Uncle Bob Martin, known
00:02:55
as the handbook for agile software
00:02:57
craftsmanship. Most of the advice in
00:02:59
this book is great. Use meaningful
00:03:01
names, write small functions, use
00:03:03
consistent formatting, and so on. But
00:03:04
some of the advice is a little more
00:03:06
nuanced, like the dry principle of don't
00:03:08
repeat yourself, which means you
00:03:10
shouldn't duplicate or write the same
00:03:11
code over and over again. And on the
00:03:13
surface, that seems like a good idea.
00:03:14
But also, when you try too hard to keep
00:03:16
things clean, you might end up with an
00:03:18
endless layer of wrappers, interfaces,
00:03:20
and pointless indirection. It's
00:03:21
paralysis by analysis, and you end up
00:03:24
spending more time refactoring than
00:03:25
building actual features that people
00:03:27
want. I think a better acronym would be
00:03:28
rug, repeat until good. duplicate code
00:03:31
at first and then pull it into a single
00:03:33
abstraction after the repetition becomes
00:03:35
painful. Clean code also recommends
00:03:36
test-driven development and testing can
00:03:38
be extremely valuable, but it's a myth
00:03:40
that 100% test coverage means that your
00:03:43
code is well protected. Your boss, who
00:03:44
has no programming experience, is likely
00:03:46
a big fan of code coverage tooling that
00:03:48
will show how much of your source code
00:03:50
is executed when a test suite is run.
00:03:52
It's interesting, but optimizing for
00:03:54
100% coverage is often a huge waste of
00:03:56
time and can often be misleading because
00:03:58
high coverage does not equal high
00:04:00
quality. Optimizing for coverage
00:04:02
encourages developers to write pointless
00:04:03
tests that just touch lines and not
00:04:05
catch real bugs. And even worse than
00:04:07
wasting time, it provides a full sense
00:04:09
of security. And then on top of that, it
00:04:11
makes your CI builds even slower, which
00:04:13
is going to cost you more money. When it
00:04:14
comes to test coverage, it's quality,
00:04:16
not quantity that matters. But one thing
00:04:18
that truly must matter is performance.
00:04:20
Well, actually, it's a myth that you
00:04:22
should always optimize for performance.
00:04:24
Yet another time waster is benchmarking
00:04:26
and optimizing code that just doesn't
00:04:28
run at the scale to justify those
00:04:29
optimizations. It's far more important
00:04:31
to make sure that your code is correct
00:04:33
and then only optimize for performance
00:04:35
when it becomes painfully obvious that
00:04:36
your code sucks in production. On a
00:04:38
similar note, you also don't need to
00:04:39
optimize your cloud infrastructure like
00:04:41
you're about to scale like Facebook.
00:04:43
Like I used to think that I needed this
00:04:44
complex serverless micros service
00:04:46
architecture with global sharding and
00:04:48
edge caching, but it turns out that one
00:04:50
small VPS is perfectly fine for my five
00:04:52
users. And then finally, that brings us
00:04:54
to the elephant in the room, the myth
00:04:56
that AI is about to replace all
00:04:57
programmers soon. There are some awesome
00:04:59
AI codew writing tools out there, but
00:05:01
it's becoming more and more clear that
00:05:02
many programmers are now wasting a bunch
00:05:04
of time relying too much on AI. For
00:05:06
example, Claude Sonnet 3.7 is really
00:05:09
good at writing code, but it's also
00:05:10
notoriously verbose. You might ask it to
00:05:13
build a simple website and it'll just
00:05:14
randomly engineer some new JavaScript
00:05:16
framework from scratch. And because you
00:05:18
forgot how to write code, you'll just
00:05:19
approve it and move on with your life.
00:05:21
AI programming tools are both the
00:05:23
greatest productivity booster I've ever
00:05:24
seen in my life, but when used
00:05:26
improperly, they can also be the biggest
00:05:27
time waster. The key to success is to
00:05:29
have a solid foundation in problem
00:05:31
solving. And you can start building that
00:05:33
foundation for free today thanks to this
00:05:34
video sponsor, Brilliant. A hard truth
00:05:37
is that code is useless if you don't
00:05:39
understand the math and computer science
00:05:40
behind it. Brilliant helps you learn
00:05:42
these concepts quickly by providing
00:05:44
short, fun, interactive lessons, which
00:05:46
is a method proven to be six times more
00:05:48
effective than watching video lectures.
00:05:50
But most importantly, you'll build
00:05:52
critical thinking skills through problem
00:05:53
solving, not memorizing. Before you try
00:05:55
to jump into Vibe Coding, I'd highly
00:05:57
recommend taking their thinking and code
00:05:59
course to build a timeless problemolving
00:06:01
foundation where you'll learn how to
00:06:03
actually think like a programmer. Try
00:06:05
everything Brilliant has to offer for a
00:06:06
free for 30 days by visiting
00:06:08
brilliant.org/fireship org/fireship or
00:06:10
scan the QR code on screen and get 20%
00:06:12
off an annual premium subscription.
