today we are going to explore the growth
stages of a program a couple of weeks
ago I made a video that turned out to be
one of the most controversial ones I
made soup for the video was called
straight line code over functions where
I stress that you should prefer simple
inline code over function extraction
that video got a lot of responses like
this one thanks for the rest of the
videos but I have to respectfully
disagree with this one testability
composability and reusability are
completely lost when you don’t decompose
into smaller units I plead with you to
take this video down before my
co-workers see it and continue writing
huge monolithic functions that do 50
different things M Costello this is a
fantastic comment you are right that
some people should not watch that video
because they might get the wrong idea
and that depends on where they are in
their growth as programmers and that is
what I would like us to explore today
today’s video is a complete and utter
ripoff of a poor answer by a fantastic
former colleague of mine blixt I have
linked the answer in the episode
description blixt talks about three
phases in the life of a drone the novice
hacker the philosopher abstractor and
the wise hacker blixt describes the
novice hacker like this what is code
it sure is ugly and I don’t quite
understand why it works but here it is
and that is me and everyone when they
are starting out as programmers you are
copy pasting things all over the
Internet and you don’t quite understand
all of it but it works and you’re
getting shit done as you grow older as a
programmer you grow more and more into
the second phase the philosophy
abstractor blixt describes the
philosophy abstractor
like this well this code it works for
now but if I move this part into a
factory and create an interface with
these methods it will also support all
of these future edge cases that I can
think of as a professional programmer
most of your time almost all of your
time is spent understanding other
people’s code and I have done this a lot
I have recently had the interesting
experience of taking over code written
by somebody who isn’t a programmer by
trade I’ve never done that before and it
was very eye-opening to me the person in
question knows some programming and has
written a complete piece of software but
he’s not a programmer by trade he’s
actually a doctor I expected his code to
be messy and that I would have to spend
a lot of time to make sense of it but in
fact it was quite the opposite
understanding his code base was actually
much easier than most of the code bases
that I encounter at work hmm and his
code is messy there’s a duplication
galore and there’s spelling errors all
over the place but that doesn’t matter
because his code is straightforward
his code consistently takes the simplest
possible route to solve a problem and
that makes it really easy to understand
and follow even though it is the very
opposite of irrigant in contrast I’ve
many times taking over software by
developers who have a lot of knowledge
about software design patterns and how
to do optimization and then have they
made use of that their code does not
have spelling errors their code does not
have duplication no their code has an
abstract base class you simply need to
implement this abstract base class and
pass it an object that implements this
specific interface and
then you have something that just works
with logarithmic time complexity it is
magnificent gaze upon my creation and in
a way it is incredibly impressively put
together but when it comes down to it
cook like that is very often very
difficult to understand to figure out
with the program dance you have to move
to this other file and remember that
this other thing that is being called
here is being injected over here the
programmer that wrote this fill it with
the best of intentions trying to
abstract problems away from you but in
the end it just made things harder and
that brings us to lists third stage of
programmer growth so this the novice
hacker the philosopher abstractor and
wise and blix describes the wise hacker
like this move fast break things revise
and fix and get shit done the wise
hacker knows the same patterns and
optimization techniques that the
philosophy abstractor does the
difference is that the wise hacker knows
that you should almost never use them
the key word there is almost there will
be parts of your code where you should
optimize or generalize or modularize
their hell out of it and when that
happens the wise hacker knows how to do
it and how to do it well but again the
wise hacker only does it when absolutely
necessary and that is because the wise
hacker knows that modularization and
generalization and optimization have
costs these things are not like world
peace or kittens they are not
universally good they are not free you
need to get a lot of value out of them
or they will not be worth it when you
are modularizing or optimizing more
generalising you are making a trade-off
the wise hacker does modular
the white sucker does generalize the
wise hacker does optimize but like
spider-man teaches us with great power
comes great responsibility and you
should only use your powers when
necessary the wise hacker writes stupid
simple and straightforward code whenever
possible you have watched an episode of
fun fun function a weekly show where we
try to become more excited and confident
about programming by exploring old
wisdom wild ideas and having fun bye Joe
do not miss out on the next episode
follow me on twitter at MP Jaime 1 till next Monday stay curious