3 ms·
The problem is really simple. I know this may sound contentious, so read carefully. Junior developers, BY DEFINITION, cannot be trusted with important project
by lmilcin 5y ago
The problem is really simple.
I know this may sound contentious, so read carefully.
Junior developers, BY DEFINITION, cannot be trusted with important projects. If you do, you are responsible if something fails, not the developer.
By "important" I mean anything that may significantly impact company. If you would fire for it then it is important.
By "cannot be trusted" I don't mean they can't do it. Maybe they can, maybe they can't. You need to have somebody experienced to make sure there is no technical surprises, that you are getting what you think you are getting and that you will get feedback if something is not happening right.
My personal distinction between senior and junior developers is whether they can be trusted with important projects. A senior person is somebody who is experienced enough, intelligent enough and mature enough to recognize something is not right and come back to you for direction.
I work with a lot of people who get a label of "senior" but are not. This is a problem.
It is interesting, that at one known company people who can be trusted with important projects are called "officers". So basically you have junior developers, senior developers and officers. I guess "senior" is given just to pacify developers who would be called junior with a lot of years of experience but "officer" as a real recognition of maturity.
- ratww 5y agoI had something similar but not quite at the company I worked previously: about 90% of the developers there were senior, and some had only 1 or 2 years of experience. However there were levels and a level 5 Senior was paid about twice as much as a level 1 Senior. In the end it was more about making everyone "happy".
- lmilcin 5y agoI forgot to mention, half my team is currently Vice President and other half is Associate Vice President. People take this because they are deluded this is worth anything and company gives it because it does not cost anything.
- wruza 5y agoHeh, my experience is two decades of for-business custom software development. But no matter how much you brush the 1-month-old half-project and how strong you stress them on not diverging from the script at the presentation, there will be some idiot who will tap randomly to show all critical issues of a not-yet-product to investors, including the ones that you warned them about in capsbold beforehand. You can’t trust something done in a hurry, by a junior, by a senior, or by a chief officer of rockets and things. Of course I would test for gibberish in fields, but only because I have OCD to fix crappy frameworks or glueware before using it for anything. I don’t usually dare to use as-is from-scratch methods for presentations, only parts of already tested projects. Management knows this and feels very relaxed at their shows, which allows for what I described above. Deception is a team work, and if you want to succeed, just follow the damn script. Make it threaded, excessive, whatever, stress your brain matter and foresee the questions, we’ll harden the path. But I “double dare you” to step off it. That’s just not realistic.