What does it really mean to be a “junior programmer”

Friday night, I received an email from a friend of mine who had just graduated from college (Rochester Institute of Technology) and works in a very promising startup programming C ++ systems and teaching artificial intelligence. Below is a small fragment of his letter.

Dude, one thing at work bothers me - although my colleagues are mostly nice people, I feel as if my work is completely unappreciated. I work with six engineers (together we make up a team of seven engineers). Of the six, one is Platform Architect (Platform Architect), two are Senior Application Engineers, another one is Software Architect (Software Architect), the other two are responsible for Quality Assurance. To be honest, and I don’t want it to sound arrogant, but with the exception of one Senior Applied Engineer, I realized that I know much more than all these “older” guys. Don't get me wrong ... they have been doing this for many years, working on important systems and all that, but I am more educated than they are. Most often, due to the fact that I am a Junior Systems Engineer, my ideas are simply swept aside and my hard work is absolutely not appreciated ... frankly, it makes me terribly furious. Sometimes I think about returning to freelancing (especially considering that I have already finished college) .

I was 80% sure that I should write this post after reading that email. 15% gave me a reading of this , this and that . The last 5% I received after reading this .
')
I am a junior developer . My current position could have been simply called Software Developer, but I am 18 years old (will be 19 in August), and for this reason I am a junior developer in the software industry. So, what is it really? I have seen too many descriptions of what it is, according to various people, to be a “junior” developer. I also noticed that younger developers (including me, at some point in the past) associate this term with a certain disgrace . Over the past few months I have had the opportunity to work in a team of brilliant engineers who create a cool and useful product. Despite the fact that only about 6 months have passed, as I have been working in a real team that creates software, I am sure that I can give, I think, a suitable definition to a junior developer.

Instead of giving a formal definition, I will present a few examples from which you can extract the meaning of this meaning. Well ... drove.

Disclaimer for my buddy : I still love you, buddy. [:)].

Nerdy

I bet that 98% of us junior developers somehow go through this phase. To better explain this, I use a fictional character - Jack.

Being a young, enthusiastic and passionate developer, Jack strives to be the best in his profession. He is interested in everything, so he constantly learns something new, be it 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. Not only does Jack know how to write amazing factory methods, sexy singletons, pretty decorators and extraordinary prototypes, he knows how to use them properly (or at least he thinks so).

Oh, and by the way, Jack also knows a whole lot about various platforms, such as Node.js, Java, Haxe, ooc, and even the one you added to your private GitHub repository last night. Believe me, he knows it all. OMG! How could I forget? Jack also programs in assembly language.

And thanks to this whole pile of knowledge, Jack is starting to feel, as I call it, a reckless sense of superiority. Now he knows hundreds of times more than the usual Joe, and therefore he is better suited to the position of Joe. And please, do yourself a favor, never call Jack a “junior” developer, or worse (oh, well, that started) “kid”; if you still do it, then do not be surprised that later that evening you will have a wild headache, because Jack, sitting in his bedroom, bludgeons mount on a doll resembling you.

Experienced

“He wouldn’t have to go; one cannot fly into flying ”(Go from easy to hard) - Friedrich Wilhelm Nietzsche

The amazing expression of the great philosopher and poet, Friedrich Wilhelm Nietzsche.

You see, there is a difference between having a lot of knowledge and having experience. It took me some time to realize this, but I must say, this difference is quite interesting.

Disclaimer : I myself am still learning and getting used to it all. I do not in any way assert that all this also does not apply to me.

Emotions

A more experienced developer knows how to break less experienced ones, then to shape them. But ... but ... but what do you mean by that, Jonathan? Finish to dunk up! I'm starting to tire of it!

Well, you really need to calm down and listen.

One thing is closely connected with “young, full of enthusiasm and passion”, and as I began to call it - “specialization” or “hook”. In my understanding, if you are a developer and they tell you that you have a “hook,” it means that you are too attached to your technologies and products. As a junior developer with these characteristics, you spend an enormous amount of time improving your code, while thinking about all these applied design patterns and principles, writing unit tests (often quite useless), etc. At some point you’re finishing up and a super-duper confident about your work goes straight to the “senior” developer, of course with a sparkling smile on his face. Then, to your surprise, she says that the design pattern you used was optional, that your system does not scale horizontally, and that you hurried with optimization. The little dude inside you starts crying, but you hold on courageously and don’t show her that. You start to think about where the dolls and the mount are sold. Then she begins to explain her point of view to you. She tells you that based on previous experience, the single pattern that you used was previously used for the same purpose, while dependency injection would have been better, and, if it had happened, then it (her previous team) would not have to wallow in the swamp refactoring. She then explains to you that writing to the server disk from your application, an application that needs to be balanced when distributing the load, automatically disqualifies him as a candidate for optimizing the load, because the file recorded on the disk of server 1 will be readable on servers 2 and # 3. It also tells you that premature optimization, in which all your variable identifiers become one long character, only hurts you in the future, since there are special tools for these purposes. Um ... you say, "maybe I don’t need this doll at all."

This is what I mean when I talk about breaking, to give shape. You not only received expert critical feedback on your work, you learned something new in the process.

Useful reading: The number one programmer's rule is to leave emotions behind the threshold

Design and process

Before joining Ai Squared , I was a freelancer. I highly appreciated products with excellent architecture, and I had a false assumption that the things I created were well designed ... I was far from the truth. So what is good architecture? So far, I am still not qualified to answer this question, but in a few years I will return and answer it. Good? Deal.

One thing I can say (for now) is that there are still two things that younger developers ignore, 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 (hopefully), know what “design” usually means, but what do I mean when I say my “design”? Designing is just thinking about something you want to do before you start doing it.

We, like younger developers, have a habit of building without thinking, and thinking after it has been built. On weekdays, a freelancer, they gave me assignments and left me alone (as a rule) so that I could complete them. For this reason, I stamped the [poor quality] code (at least 75 lines of code per hour) for 15–20 consecutive hours. All I had to take care of was that the client was satisfied and his requirements were taken into account. While the poor quality code did what the client wanted, everything was fine and everyone was happy.

Well, but what then do you mean by “process”? A process is a clearly defined route that you need to go to complete a task. This is where project management, its tools and planning come in handy. And again, before getting into the real software development team, I knew about various project management tools, such as Trello , Redmine and Sprint.ly . I even used some of them, including Trello and Redmine. However, I still didn’t have a process, so I used these powerful project management tools as a to-do list (split all tasks into completed and unfulfilled). Theoretically, I knew what Quality Assurance is, but I still did not understand the process itself.

Now I have the opportunity to learn how to create a process correctly.

In general, déjà vu specialist and in general, jamais vu expert.

At work, nothing gives me more pleasure than listening to the stories of my experienced colleagues about the mistakes they made in the past, the consequences of such mistakes, and the lessons they learned from all this. And, since I am a developer who wants to reach their level someday, I have the opportunity to avoid some of the mistakes that I would certainly have made.

But Jonathan ... the name of your post! Good, good, let me explain.
The famous expression “ déjà vu ” is a French expression that literally means “already seen.” Almost an antonym to this expression is “ jamais vu ”, literally meaning “never seen.”

Many younger developers (of course, including me) know people with the prefix "Senior" or the end of "Architect" in the titles of their positions, which they consider to be less educated (in relation to programming skills) than they are. However, one entertaining feature of many of these people is that they have been in business for a long time, worked in different companies (not necessarily), made many mistakes, learned from them, etc. Despite this, they, unlike us, may not know every language, platform and / or technology. Instead, they improve their skills in several areas ( as far as I know , usually one or two). And instead of learning every language, platform, and / or technology, they choose one or two languages, platforms, and / or technologies and become true experts in these areas.

What does it mean to be a true expert in relation to any language, platform and / or technology? For me, a true expert in anything , it's just someone who not only knows or understands his field at the expert level (how everything is arranged inside and out), but also has many years of experience in this field. In other words, in my humble opinion, every developer, having made an effort, after about a year can become an expert, say, in C # (while constantly reading), but to become a true expert, such as the respected John Skeat , you need to spend years

So what do you mean, Jonathan, saying "by and large, déjà vu specialist". I am talking about true experts. Their competence can extend only to one or two areas, but they have “already seen” a lot of things in these areas. They can create scalable systems, they have a deep understanding of the ecosystem, they know the shortcuts that lead to disaster, they know when to apply optimization, etc. Wow “Scalable systems” ... what is this? You see, fortunately , at the moment, we (junior developers) fall under the category “by and large, jamais vu expert”. We can be experts (notice that there are not enough “ true ”) in various things, we can know how to create systems, we can have an understanding of the ecosystem, we can know a lot of shortcuts, but we (in fact) have no idea how to scale the systems we we create, our understanding of ecosystems is very superficial, the shortcuts that we choose are essentially not needed, and we spend a lot of time on premature optimization.

People, why rush?

In a hurry there is no need.

One article I will never remove from my bookmarks, “ Teach yourself to program for 10 years, ” written by Peter Norvig .

If you haven’t read it yet, then pour yourself a glass of 100% Mott's Natural Apple Juice (because it will be useful for you, and since this is what I myself am drinking now [[; p]), turn off the TV, trespass on Your Brother’s Head (ok ... I never said that), follow the link above and read everything carefully.

Wait, I'm puzzled ... you never said why being a “ jamais vu expert” by all means a developer is luck. In the end, my friend, this is the time of our life when we can and we are allowed to make mistakes, learn from them and get experience. Look at it as an advantage (of course in a good way), which will only make us better.

Good ... that's all. The end.

The translation was made as part of the Tolstoy Summer Camp and MetaBeta summer start-up school.