— Platoooon! Dress right! As you were! Dress right! Atten-hut! Open your notebooks, take notes!
Oddly enough, the question “how do I become a senior?” comes up on the internet much more often than “how do I become a junior?” From this you might get the impression that no one is interested in the question of how to become a junior. Apparently, either everyone knows how to become one, or they don’t even ask themselves that question, and any beginning programmer immediately considers himself a junior by default. Thus, for example, your grandmother is also a junior. Absurd? Yes. That means we need to formulate some criteria that a junior has to meet in order to be called a junior. I’ll say right away that I don’t like the term “junior,” because it is a word from the vocabulary of metasatanists. And I don’t like metasatanists or metasatanism itself (which I’ll write about separately), so here and below the term “junior” will be replaced with “teenager.”
So, let’s introduce a new term.
Juniority — the set of properties inherent in teenagers.
I’d like to unpack this definition through a series of examples.
Juniority is thinking through and proposing at least two possible solutions to a given problem.
Any programmer runs into difficult tasks that can’t be solved on the first try. An experienced programmer is expected to solve them on his own. It’s not worth expecting the same from a teenager, because there isn’t enough experience. Nevertheless, lack of experience is not a reason to put off solving the task. For every problem or task, a competent teenager should come up with (generate, google, overhear, peek at, copy) at least two possible solutions in order to discuss them with a mentor. Better yet, three options, or even five. This approach stimulates the teenager’s brain to solve its own problems independently.
Juniority is reading all the books and remembering which task is solved in which book. Referring to books while working. Keeping books close at hand.
Everything is very simple here. A beginning programmer has to understand and speak the language in which engineers conduct their dialogue. When the mentor says, “Introduce explaining variable,” something should click in the teenager’s head: “Right, Fowler had something like that in his book on refactoring.” After that, the book needs to be opened, the chapter found and read, and the required refactoring carried out. To start with, the teenager should read these books:
- Erich Gamma, R. Helm, R. Johnson, J. Vlissides. “Design Patterns: Elements of Reusable Object-Oriented Software.”
- Martin Fowler. “Refactoring: Improving the Design of Existing Code.”
- Eric Evans. “Domain-Driven Design (DDD): Tackling Complexity in the Heart of Software.”
- Jef Raskin. “The Humane Interface.”
Juniority is maintaining project documentation and meeting minutes.
With project documentation, everything is clear. You just need to take it and write it right in the code using special comments. With minutes, things are a little more complicated. Most of a teenager’s meetings are one-on-one with his mentor. The biggest mistake is failing to write down some important thought from the mentor. So after any meeting, you need to sit down and take notes on everything.
Juniority is writing tests.
A teenager should know how to test both his own programs and other people’s. You should start by writing test scenarios in natural language. At the next step, develop unit tests; at the next step, acceptance tests.
Juniority is doing code reviews for colleagues, and also studying their reviews.
Usually, in any company, your colleagues’ contributions are always in plain sight — Git looks the same for everyone. A teenager should look through his colleagues’ code, leave comments, and also see what comments they leave for other programmers. You can learn from your own mistakes, and from other people’s too.
Juniority is maintaining Jira. Reporting regularly and committing.
Activity in Jira, email reports, commits to the repository — all of this is the teenager’s “pulse,” by which mentors determine whether he is alive or dead. Nobody needs a “dead” employee who is afraid to ask for help in time in order to solve current problems and move on.
The list of properties can be continued further. The idea itself is very simple: if you can meet these requirements for a prolonged period of time, you’re a junior; if you can’t, then you’re some random asshole and a grandmother.
Let’s write down a few derived terms:
Level up your juniority — consistently and regularly practice the advice given above.
Spew teenage bullshit — ignore the advice given above or by your mentor.
You will ask: but what about seniors? Seniors do not exist. A programmer either solves the task set before him or he doesn’t. The logic here is binary.