Seniors and leads are always a burden and evil, but do juniors and middles work? Or just in our company?

Question

Work organization

I am junior. I had to work in a team (same) on different projects. One of the projects became impoverished, could no longer feed the team. And now there is only one developer. Just one developer on a complex architecture project with C++, JavaScript, Node.js and Lua. And he is a junior. And he is me.

All the projects we have worked with are forks, or we are contractors in general. That is, the code is not ours. Accordingly, the main (for me) problem is to study the code. And there is no use here from a senior and a lead. Because they don’t answer your questions on the code quickly, not always, and they are not obliged to answer at all.
And I can study the code myself without a senior and a lead .

The senior and the lead themselves almost never write code. They try not to write. If they write, then supposedlythe most difficult. And then in this most difficult thing, something needs to be improved and the junior has to study it. It's easier then to write it yourself. As a result, a junior (and he is the only junior in the project!) must navigate all parts of the project, and even study them on the go, rushing here and there.
Without a senior and a lead, I also have to know everything, but there is no left dude who writes new code and has to learn it too.

Now about the stress of late deadlines. Stress resistance is probably such a thing that a strong one reduces stress in the team, and a weak one increases it, adding more from oneself. So, the senior and the leader, as soon as they see that I don’t have time, they scold and even fire me (but then they take me back).
Without senior and leadI risk disrupting only a more or less global deadline. And then the customer will send me and I will have to beg the customer to return. Only 1 time! And the senior and the leader during this time would have had time to scold me 5 times.

Now about the quality of the code. A junior with a senior and a lead is afraid all the time, waiting for comments on quality, waiting for delays because of this. At the same time, it cannot justify its own delays by polishing the code. Double standards. They can, but I can't.
Without a senior and a lead, I also focus on delivery on time and on security. I sometimes give up on quality. But I am always calm and sure that if I pass something, then it is forever. And I check the code for bugs accordingly. I do a self-review, and it is much more useful than a review of a senior and a lead who is looking for where to be aesthetic, and not where a bug is.The number of bugs after the departure of the team dropped sharply.

The only thing that got worse is that sometimes solutions began to appear in the code that were frankly not optimal and slowed down. After all, I'm not just a junior, but I also have some problems with algorithms. But I rolled them back and fixed them, and this is not so often. And the brakes are still not bugs.

Sorry for a lot of letters and I have a question, is it like this everywhere or is there a benefit from a senior and a lead?

Answer 1

Just one developer on a complex architecture project with C++, JavaScript, Node.js and Lua. And he is a junior. And he is me.

After all, I'm not just a junior, but I also have some problems with algorithms. But I rolled them back and fixed them, and this is not so often. And the brakes are still not bugs.

Problems in your lack of understanding of the principles of building large projects, their maintenance and support (the entire life cycle of the product). Hence the questions like this.

And the brakes are still not bugs.

This is exactly EXACTLY! and there are bugs, only up to a certain point they are implicit. And this is much worse than obvious!

Answer 2

Of course, it’s always evil, all Googles, Linux, Windows, etc. were made by juniors.
PS Well, what kind of naivety.

Answer 3

Often seniors and leads are responsible for the work of the team as a whole and for the product for which they release. Believe me, often these are already almost managerial positions. Sometimes such people simply have no time to write code. But they are responsible for it

A junior with a senior and a lead is afraid all the time, waiting for comments on quality, waiting for delays because of this

This is a matter of your internal communications. Do you communicate with them at all?

I do a self-review, and it is much more useful than a review of a senior and a lead who is looking for where to be aesthetic, and not where a bug

How can you self-review if you do not have enough experience and write

I sometimes give up on quality

Here is the difference between a junior and a senior. You don't know the importance of this

And the brakes are still not bugs

It's not that a bug is a critical thing. Your brakes and bad code lead to a bottleneck when the code copes with current tasks, but when large data arrives, it will not be able to process them at a sufficient speed

Answer 4

I am junior. I had to work in a team (same) on different projects. One of the projects became impoverished, could no longer feed the team. And now there is only one developer. Just one developer on a complex architecture project with C++, JavaScript, Node.js and Lua. And he is a junior. And he is me.

Perhaps you are only listed as a junior, but in fact you are already a mid.
Perhaps nobody needs this project, and it is purely supported somehow, because if the project was critical, there would be money and people for it.

All the projects we have worked with are forks, or we are contractors in general. That is, the code is not ours. Accordingly, the main (for me) problem is to study the code. And there is no use here from a senior and a lead. Because they don’t answer your questions on the code quickly, not always, and they are not obliged to answer at all.
And I can study the code myself without a senior and a lead.

So are you alone or do you have seniors and leads?
A lead must have a team, he cannot have just one June. Perhaps after all there are several of you and you do not have a project, but a specific one component?

The senior and the lead themselves almost never write code. They try not to write. If they write, then supposedly the most difficult. And then in this most difficult thing, something needs to be improved and the junior has to study it. It's easier then to write it yourself. As a result, a junior (and he is the only junior in the project!) must navigate all parts of the project, and even study them on the go, rushing here and there.
Without a senior and a lead, I also have to know everything, but there is no left dude who writes new code and has to learn it too.

If you could write everything that the senior and the lead wrote yourself without consultation, then change jobs and immediately look for the position of a senior.

Now about the stress of late deadlines. Stress resistance is probably such a thing that the strong in this reduces stress in the team, and the weak increases it, adding more from himself. So, the senior and the leader, as soon as they see that I don’t have time, they scold and even fire me (but then they take me back).

If that's the case, change jobs.

Without a senior and a lead, I only risk disrupting a more or less global deadline. And then the customer will send me and I will have to beg the customer to return. Only 1 time! And the senior and the leader during this time would have had time to scold me 5 times.

Senior and lead are local guys. If the customer sends, he will simply hire another team and no pleas will return. And the money comes from the customer, and not from the senior, lead or junior. Therefore, if the customer is satisfied, this is the most important thing. Everything else (code quality, product performance, availability of juniors / leads / seniors) - do not care. The main thing is to convince the customer that everything is fine, and that he continues to give money.

Now about the quality of the code. A junior with a senior and a lead is afraid all the time, waiting for comments on quality, waiting for delays because of this. At the same time, it cannot justify its own delays by polishing the code. Double standards. They can, but I can't.

It is worth reading about technology debt. The absence of bugs is good. But if the product continues to be developed and changed, someone will have to pick and upgrade your code. If it is not written according to standards, it will be much more difficult, longer and therefore more expensive to change it.
Many, many bicycles lead to such a legacy that it is cheaper to rewrite everything from scratch than to edit it. Perhaps they demand not to grind, but to work according to standards, but they cannot explain this.
Or maybe they're just nitpicking. Nobody knows but you.

Without a senior and a lead, I also focus on delivery on time and on security. I sometimes give up on quality. But I am always calm and sure that if I pass something, then it is forever. And I check the code for bugs accordingly. I do a self-review, and it is much more useful than a review of a senior and a lead who is looking for where to be aesthetic, and not where a bug is. The number of bugs after the departure of the team dropped sharply.

If forever, then why in principle are you still writing code? Shouldn't it have been written long ago forever?
Bugs can be technical and logical. If you know the customer's business well, that's one thing.
The number of bugs after the departure of the team may fall because the development has fallen. There are much fewer bugs if no one writes anything, it's L - Logic.

The only thing that got worse is that sometimes solutions began to appear in the code that were frankly not optimal and slowed down. After all, I'm not just a junior, but I also have some problems with algorithms. But I rolled them back and fixed them, and this is not so often. And the brakes are still not bugs.

There are product requirements. Requirements can specify metrics for performance tests. If the program slows down more than it is specified in the development requirements, this is a bug.
And in general, read about the basics of testing in order to clearly understand what a bug is (roughly speaking, a bug is a discrepancy between the documentation or TK, and not compilation errors)

Sorry for a lot of letters and I have a question, is it like this everywhere or is there a benefit from a senior and a lead?

Everything you wrote looks very strange.
I don’t recall situations where if a junior is fired, then he is then asked to return. This is generally nonsense. Apparently you have some kind of unique case, and perhaps it makes sense either to distrust your words, or, taking them at face value, to advise you to simply change jobs.

Answer 5

Be brave and learn...

Answer 6

What is your question? Learn and change your place, slavery is only in Yandex