The know-it-all.
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.


Pospiech at the Polish language Wikipedia [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], from Wikimedia Commons

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.

By Cat, the Bob [Public domain], via Wikimedia Commons

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?

By Fengalon [Public domain], via Wikimedia Commons

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.

Post a Comment