on
Italy
- Get link
- Other Apps
I am willing to bet that 98% of us, junior
developers, go through this phase at some point. I am going to use an
imaginary character, Jack, as a way to better explain this.
As a young, enthusiastic, & passionate developer,
Jack strives to be the best at his job. He is curious about everything,
so he is always learning something new, whether it is a new programming
language, paradigm, design pattern, or technology. He now knows seven
programming languages. He knows how to write imperative, functional,
event-driven, and object-oriented programs. Jack not only knows how to
write fabulous factory methods, sexy singletons, delicious decorators,
and prodigious prototypes, he knows when to properly use them (or at
least he thinks he does).
Oh, and by the way, Jack also knows a ton about
different environments, like Node.js, Java, Haxe, ooc, and even the one
that you pushed to your private GitHub repository last night. Trust me,
he knows it. OMG! How could I forget? Jack writes assembly too.
Because of all of this knowledge, Jack
begins to develop, what I would like to call, a foolish sense of
superiority. He now knows a ton more than average Joe, and therefore, he
is better qualified for Joe’s job. And please do yourself a favor,
never call Jack a “junior” developer, or even worse, (uh oh, here it
comes) a “cupcake”; if you do, please do not be surprised when you have a
crazy headache later that night because Jack is sitting in his bedroom
smacking a doll resembling you with a tire iron.
The experienced.
He who would learn to fly one day must first learn to walk and run and climb and dance; one cannot fly into flying.
Those are the amazing words of a great philosopher & poet, Friedrich Wilhelm Nietzsche.
See, there is a difference between having a ton of
knowledge and being experienced. It took me a while to understand that,
but the difference is quite interesting I must say.
Disclaimer: I am still learning and adapting to a lot of this stuff myself. I am in no way saying that these things do not apply to me as well.
Emotions.
The
more experienced developer knows how to break the less experienced in
order to shape them. But…but…but WTH do you mean by that, Jonathan? It
is really time you stop with the brown-nosing! I am already getting
tired of it!
Okay, you really haz to calm down right now and listen.
One thing that sits right next to young,
enthusiastic, and passionate is what I have started to call “the
staple”. You are said to have “the staple”, in my dictionary, if, as a
developer, you are too attached to your technologies and productions. As
the junior developer with these characteristics, you spend an extensive
amount of time perfecting your code, thinking about all of the design
patterns and principles that apply, writing unit tests (often really
useless ones), et cetera. At
some point, you finish and you are super duper confident about your
work, so you go ahead and hand it all over to the “senior” developer,
with a brilliant smile on your face of course. Then, to your surprise,
she tells you that a design pattern that you used was unnecessary, your
system is not horizontally scalable, and there is too much premature
optimization going on. The little guy inside of you begins to cry, but
you are strong, so you refuse to let her see it. You begin to wonder
where dolls and tire irons are sold. She then goes on to explain
herself. She tells you that, in a previous experience, the singleton
pattern that you used, was used for that same purpose, where some basic
dependency injection would have been a better fit, and thus left them
(her previous team) swimming in a pool of refactoring. She then explains
that writing to the server’s disk from your application, an application
that is supposed to be load balanced, automatically disqualifies it as a
good candidate for load balancing, because a file written to server 1's
disk will not be readable on servers 2 and 3. She also tells you that
the premature optimization of making all of your variable names one
character in length will only hurt you in the future as there are tools
for that exact purpose. Hmm…“maybe I do not need that doll after all”,
you say.
That is what I mean by breaking you in order to shape
you. Not only did you receive some expert criticism on your work, you
learned a few new things along the way.
Design and process.
Before being employed by Ai Squared,
I was a freelancer. I had an appreciation for well architected
products, and I had the foolish assumption that the stuff that I was
building were well architected…they were far
from that. So what is good architecture? That is one question that I am
not yet qualified to answer, but, in a few years, I will come back to
tell you. Okay? Deal.
One thing that I can say (so far) though is that
there are two things that junior developers usually ignore that, in my
humble opinion, are a must for engineering well architected products.
These two things are, what I call, “design” and “process”. We all know
what “design” usually means, of course (hopefully), but what do I mean
when I say “design”? Design is, simply, thinking about something that
you want to build before you build it.
As junior developers, as backwards as it may sound,
we have the habit of building before thinking and only thinking as we
build. Being a freelancer, I was provided with tasks and left alone
(well, mostly) to accomplish them. Because of this, I would crank out
[poorly designed] code (minimum: 75 LOC/hour) for straight 15-20
hours…better than a goat (haha, I find it funny that you did not know
that goats code…#smh). All I had to make sure was that the client was
happy and that their requirements were met. As long as the poorly
designed code produced the output requested by the client, all was good
and everyone was happy.
Okay, so what do you mean by “process” then? Process
is a clearly defined route to be taken in order to accomplish a task.
This is where project management, planning, and project management tools
come into play. Again, before being actually in a software team, I knew
about many project management tools, like Trello, Redmine, and Sprint.ly.
In fact, I even used a couple of them, including Trello and Redmine.
However, I had no process, so I treated these powerful project
management tools like to-do lists (complete and incomplete type of
thing). I knew, in theory, what QA was, but I did not really understand
that process either.
I now have the opportunity to learn how to properly create processes.
The overall déjà vu proficient and the overall jamais vu expert.
By Tkgd2007 [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
There
is nothing at work that I enjoy more than hearing my experienced
co-workers describe mistakes that they have made in the past, the
consequences of such mistakes, and what they learned. As a developer
with an aspiration of reaching their level some day, it gives me the
opportunity to skip a few mistakes that I would have otherwise made.
But Jonathan…your title! Okay, okay, allow me to explain.
The well-known expression “déjà vu” is a French expression literally meaning “already seen”. Almost an antonym of this expression is “jamais vu”, literally meaning “never seen”.
Many junior developers (including me of course) know
folks with “Senior” as a prefix or “Architect” as a suffix of their
title whom we feel are less knowledgeable (in terms of
programming-related skills) than us. One interesting characteristic of
many of these folks though is that they have been around for a long
time, worked for many companies (not necessarily), made many mistakes,
learned from their mistakes, et cetera.
However, unlike us, they might not know every language, environment,
and/or technology out there. Instead what they do is they make
themselves experts in a few areas (usually one or two, as far as I have seen),
and instead of learning every language, environment, and/or technology
out there, they pick maybe one or two languages, environments, and/or
technologies, and make themselves true experts in those.
What does it mean to be a true expert in a language, environment, and/or technology? In my dictionary, a true expert in anything,
is simply someone who is an expert, by not only knowing and
understanding their domain at an expert level (inside and out, that is),
but through years of experimentation and making use of such expertise.
In other words, in my humble opinion, any developer with the time and
commitment can become an expert in, say, a language like C# in maybe
about a year (keep reading, keep reading), but to become a true expert like the honorable Jon Skeet, it takes years.
So what do you mean, Jonathan, by “overall déjà vu proficient”. I am referring to the true
experts. Their expertise may lie in only one or two areas, but they
have “already seen” many things in those areas. They can build scalable
systems, have a deep understanding of the ecosystem, know the shortcuts
that lead to disaster, know when to optimize, et cetera. Woah! “scalable systems”…what is that thingy? Well, see, fortunately, at the moment, we (junior developers) fall under the “overall jamais vu expert” category. We may be experts (notice the omission of “true”)
in many different things, know how to build systems, have an
understanding of the ecosystem, and know many shorcuts, but we
(generally) have no idea how to scale the systems that we build, our
understanding of the ecosystem is quite shallow, the shortcuts that we
take are mostly never even properly evaluated, and we spend a lot of
time over-engineering and optimizing prematurely.
Why the rush, folks?
There is no need to rush.
If there is one article that I would never remove from my bookmarks, it has to be “Teach Yourself Programming in Ten Years” by the amazing Peter Norvig.
Comments
Post a Comment