What it really means to be a "Junior programmer"
Friday night, I received an email from my friend who just graduated from College (Rochester Institute of Technology) and works in a very promising startup, working in a C++ programming systems and learning artificial intelligence. Below a small snippet of his letter.
Dude, one thing at work haunts me – although my colleagues are mostly nice people, I feel as though my work did not appreciate. I work with six engineers (together we make up a team of seven engineers). Of the six, one — Platform Architect (platform Architect), two Senior Engineers, Applied scientists, and one Software Architect (Software Architect), the other two are responsible for the Quality Assurance. To be honest, and I don't want to sound arrogant, but with the exception of one Senior Engineer and Specialist, I realized that I know a lot more than all these "older" guys. Don't get me wrong... they've been doing this for many years, working on important systems and all, but I'm more educated than they are. Most often, due to the fact that I'm a Junior System Engineer, my ideas were swept aside and my hard work is absolutely ignored... frankly, it infuriates me terribly. Sometimes I'm thinking about going back to freelancing (especially considering that I already graduated College).
I was 80% sure I should write this post after reading that email. 15% gave me a reading of this, this and this. The last 5% I got after reading this.
I am a Junior developer. My current position could be called "software Developer", but I'm 18 (will be 19 in August), and for this reason, in the industry I am a Junior developer. So, what is it really? I saw too many descriptions of what it is, in the opinion of various people to be a "Junior" developer. I also noticed that Junior developers (including me, at some point in the past) this term is associated with some shame. In the last few months I have had the opportunity to work in a team of brilliant engineers, which creates a cool and useful product. Despite the fact that it's only been about 6 months since I work in a real team that creates, I am sure that I can give, I think, a good definition of a Junior developer.
Instead of giving a formal definition, I will present a few examples of which you will be able to extract the meaning of this value. Well... drove.
Disclaimer for my buddy: I still love you, buddy. [:)].
Nerdy
I bet 98% of us Junior developers, one way or another pass through this phase. To better explain it, I use a fictional character – Jack.
Being young, full of enthusiasm and passion by the developer, Jack strives to be the best in their profession. Everything is interesting to him, so he is constantly learning something new, whether it is a new programming language, paradigm, design pattern or technology. At the moment, he knows seven programming languages. He knows how to write imperative, functional, event-driven and object-oriented programs. Jack not only knows how to write amazing factory methods, sexy singletons, pretty decorators and extraordinary prototypes, he knows how to use them correctly (or at least he thinks so).
Oh, by the way, Jack also knows a ton about different platforms such as Node.js, Java, Haxe, ooc, and even the one you added to your private GitHub repository last night. Trust me, he knows it all. OMG! How could I forget? Jack also program in assembler.
And thanks to all the bunch of knowledge, Jack begins to feel, as I call it, a reckless sense of superiority. Now he knows hundreds of times more than the average Joe, so it's better suited for the position that Joe. And please, do yourself a favor, never call Jack a "Junior" developer, or worse (Oh, well, rushed) "baby"; if you do, do not be surprised that later that evening you will have a wild headache, because Jack is sitting in his bedroom, bludgeons with a tire iron on the doll resembling you.
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" (Go from simple to complex) — Friedrich Wilhelm Nietzsche,
A wonderful expression of the great philosopher and poet, Friedrich Wilhelm Nietzsche.
You know, there's a difference between having a heap of knowledge and experience. It took me some time to realize it, but I gotta say, this difference is quite interesting.
Disclaimer: I'm still learning and getting used to this. I any way not saying that all this also does not apply to me.
Emotions
A more experienced developer knows how to break the less experienced, then to shape them. But... but... but what do you mean, Jonathan? Finish fawn! I'm starting to get tired of this!
Well, you really need to calm down and listen.
One thing closely related to "young, full of enthusiasm and passion" and as I began to call her "specialization" or "hook". In my understanding, if you're a developer and you say that you have a "hook", it means that you are too attached to their technology and products. As a Junior developer with these characteristics, you spend a huge amount of time improving your code while thinking about all these used the design patterns and principles-write unit tests (often quite useless), etc. At some point you finish and super-duper confident on account of their work go straight to the "senior" developers, of course with a shining smile on her face. Then, to your surprise, she said that the design pattern that you used was unnecessary, that your system is not massturbate horizontally, and that you hurried with optimization. Little guy inside of you starts to cry, but you held up bravely and not show her that. Begin to think about where to sell the doll and the crowbar. Then she begins to explain their point of view. It tells you that based on previous experience, a single pattern that you used, were previously used for the same purpose, while dependency injection would be better, and if it happened, they (her previous team) would not have to wallow in the swamp of refactoring. She then explains to you that write to the disk server with your application, which must be balanced in load distribution automatically disqualifiziert him as a candidate for optimizing the load because the file is written to the disk server number 1, will be readable on servers # 2 and # 3. It also tells you that premature optimization where all of your variable identifiers be one long symbol, will only hurt you in the future, since for these purposes there are special tools. Mm... you say, "maybe I don't need this doll."
That's what I mean, mention to break to then give form. You not only received expert critical feedback on your work, you learned something new in the process.
Useful reading: the programmer's Rule number one — leave emotion at the doorstep
Design and process
Before to go to work in Ai Squared, I was a freelancer. I highly valued products with a great architecture, and I had the false assumption that the things I created was well designed... I was Daleks from the truth. So what is good architecture? Yet I'm not qualified to answer this question, but after a few years I'll come back and answer it. Okay? Hand.
One thing I can say (yet) that there are still two things that Junior developers are ignoring, and that, in my humble opinion, is necessary to create products with excellent architecture. These two things, as I call them, "design" and "process". We all, of course (I hope), know that usually means "design", but what I mean when I say its "design"? The design is just think of something you want to do before you start doing it.
We, as the younger developers tend to build without thinking, and thinking once built. In the everyday life of a freelancer, I was given the job and left alone (usually), so I made them. For this reason, I stamped [bad quality] code (at least 75 lines of code per hour) for 15-20 hours. All I had to take care is only that the client was satisfied and its demands were taken into account. While poor quality code doing something like client, everything was fine and everybody was happy.
Okay, but then what do you mean by "process"? The process is clearly defined route in which to go, to do the job. This is where you will find useful project management, and planning. And again, before getting into the real team in software development, I knew about the various tools of project management such as Trello, Redmine and Sprint.ly. I even some of them were, including Trello and Redmine. However, the process I still was not, so I used the powerful tools of project management as a to do list (smash all the tasks on the implemented and unimplemented). Theoretically, I knew what the Quality Assurance, but still do not understand the process.
Now I have the opportunity to learn how to create the process correctly.
In General, déjà vu is a specialist and overall jamais vu expert.
At work nothing gives me greater pleasure than to listen to the stories of my experienced colleagues about errors committed by them in the past, the consequences of such mistakes, and about lessons they have learnt. And since I am a developer who wishes to someday reach their level, I have the opportunity to avoid some of the mistakes I would commit.
But Jonathan... title of your post! Okay, okay, let me explain.
The famous expression "déjà vu" is a French expression, literally meaning "already seen." Almost the opposite of this expression is "jamais vu," literally meaning "never seen".
Many Junior developers (including me) know people with the prefix "Senior" or end of "the Architect" in the names of their positions, whom they consider less educated (with respect to programming skills) than themselves. However, one interesting feature is inherent in many of these people is that they have been in business for a long time worked in different companies (not necessarily), made a lot of mistakes, learn from them, etc. in spite of this, they, unlike us, may not know every language, platform and/or technology. Instead, they improve their skills in several areas (I know, usually one or two). And instead of studying each language, platform and/or technology they choose one or two languages, platforms and/or technologies and become true experts in these areas.
What it means to be true expert in relation to any language, platform and/or technology? For me true expert at any, it's just someone who not only knows or understands its own area on the expert level (how it works inside and outside), but with many years of experience in this field. In other words, in my humble opinion, every developer, to make efforts, after year can become an expert in, say, C# (constantly reading), but to become true expert, such as dear Jon Skeet, you need to spend years.
So what do you mean, Jonathan, by saying, "in General, déjà vu specialist". I'm talking about true experts. Their expertise may only apply to one or two areas, but they "already have seen" a lot of things in these areas. They can create a scalable system, they have a deep understanding of the ecosystem, they know the shortcuts that lead to disaster, know when to apply optimization, etc. Wow! "a scalable system" ... what is that thing? You see, happiness, at the moment, we (Junior developers) fall under the category of "in General, jamais vu expert". We can be experts (mind you, not enough "true") to various things, you can know how to create a system that can have the concept of the ecosystem can know a lot of shortcuts, but we (essentially) have no idea how to scale the systems that we create, our understanding of ecosystems is very superficial, the shortcuts that we choose in fact do not need, and we spend a lot of time on premature optimization.
People, what's the rush?
In haste there is no need.
One article I will never get from their bookmarks, "Teach yourself programming in 10 years", written amazing Peter Norvega.
If you haven't read it yet, pour yourself a glass Natural 100% Apple Juice Mott's (because it will do you good and so that's what I do now... [;p]), turn off the TV, Burst on the Head of His Brother (OK... I never said that), click on the link located above and carefully read everything.
Wait, I'm confused... you didn't say why to be "in General, jamais vu expert" developer is luck. In the end, my friend, this is the time of our lives when we can and are we allowed to make mistakes, learn from them and gain experience. Look at it as an advantage (of course in a good way), which will only make us better.
Well... that's it. The end.
The translation is done in the framework of the summer school start-UPS Tolstoy Summer Camp and MetaBeta.
Comments
Post a Comment