3 ms·
The OP is missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that sudden
by soheil 9y ago
The OP is missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly and that's what some companies try to do, there are other type of companies that solve more mundane problems (hr software, customer relation management software, email tool) that have been solved over and over again. To bundle all companies into one category when it comes to training junior devs is a mistake, junior devs could be trained at companies working on easier problems much more cost effectively and efficiently.
- chrisper 9y agoI'd disagree with you in this part: >Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly If you have let's say 5 senior devs and 1 junior. Then the problem still can get solved quickly while the junior will learn a lot. Obviously, hiring 1 senior and 5 juniors would be a mistake.
- soheil 9y ago>If you have let's say 5 senior devs and 1 junior. Then the problem still can get solved quickly while the junior will learn a lot. Obviously, hiring 1 senior and 5 juniors would be a mistake. Perhaps that is true, what I was saying is a matter of degrees not absolutes. Let me rephrase for you: to the extend that a company is working on hard problems they should minimize the ratio of junior to senior devs.