Timeline for How exactly experience level is determined in Software Industry?
Current License: CC BY-SA 4.0
13 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 20, 2020 at 13:13 | comment | added | bob | @Luaan Spot on. Years are neither required nor necessarily helpful. But on average there seems to be a correlation as long as you also check the other important things besides years in seat. Experience is years of demonstrated performance and growth and reliability and other good qualities (and learning from mistakes and making fewer big ones over time). Someone with many years working who never grows isn't senior, and someone who learns quickly can get there faster. But they have more onus to demonstrate that they have done so. | |
May 20, 2020 at 8:04 | comment | added | Luaan | @bob After all, blunders are probably how most of us have learned the big lessons (like "don't let the customer to pressure you to deploy a feature before you think it's ready"). Of course, that still means years are mostly irrelevant; what matters is how often you do new things, and how well you learn from them. If you learn the big things while playing around with your hobby projects in college, good for you - it has much the same value, without the catastrophic "oopsie" moments. And trying new things can give you better value one hour a day than a simple job eight hours a day. | |
May 20, 2020 at 0:03 | comment | added | gnasher729 | @bob There is obviously a difference between senior and "senior". | |
May 19, 2020 at 21:25 | comment | added | Bernhard Barker | @Flater What you say about handling not necessarily meaning solving is true, but there's certainly a bit of ambiguity in the original statement. Part of seniority is getting help when needed, and knowing when and where to get it (but also needing help less often), so making this distinction clear seem vital. | |
May 19, 2020 at 21:16 | history | edited | gnasher729 | CC BY-SA 4.0 |
edited body
|
May 19, 2020 at 19:03 | comment | added | DJClayworth | The other useful definition of a senior is "capable of supervising a junior". | |
May 19, 2020 at 17:54 | comment | added | bob | On average this tracks with experience level, but there are outliers of course. There are "senior" devs that have never actually progressed past junior, and there are probably "junior" devs that somehow have the experience needed without having to actually put time in chair. But the latter is pretty rare. That said, pretty much every junior dev thinks they're the exception (and I did too :) ). | |
May 19, 2020 at 17:51 | comment | added | bob | Actually I'd say junior="doesn't know what they don't know and liable to make major blunders", mid-level="starting to learn their limitations and to not mess up big-time", and senior="good grasp of their limitations, and knows how to not make big mistakes". There's more to it than that of course, but that's a big part of it. Juniors may be technically awesome, but are pretty big risks which is why they're not usually given a lot of responsibility. Seniors are much lower risk and so are given higher responsibility. That and they hopefully have good soft skills. | |
May 19, 2020 at 14:29 | comment | added | Seth R | @JuhaUntinen, a good senior will be someone aware of their own limitations. It doesn't mean they know how to do everything themselves, it means they will know how to find the person who does and get them involved. Indeed, many things require a team effort. A senior will be the one leading the team. | |
May 19, 2020 at 13:24 | comment | added | Flater | @JuhaUntinen: Handling a problem is not the same as solving a problem. A senior should be capable of handling a problem, i.e. either solve it or coordinate with the people who can solve it. Note that in this answer, mediors are listed to do things if not too difficult, which implies seniors are able to approach (= handle, not solve) problems of any difficulty. The interpretation you've taken "handle any problem" to mean is unattainable for any human being at any point (even Superman can't solve any problem, e.g. kryptonite-related matters). Handling any problem would require omnipotence. | |
May 19, 2020 at 12:18 | comment | added | Rhayene | and don't forget different strong and weak points - just because a senior CAN do it, it doesn't mean a junior or midlevel dev wouldn't do better work on a certain task if it is their particular strong area. | |
May 19, 2020 at 12:02 | comment | added | Juha Untinen | "senior = can handle any problem". That's a bit exaggerated. There are many architectural things that will be done as a team rather than alone. And some things are done as teamwork, to make a good design or to finish it by a deadline. And if you think you know everything about everything, you might get your backside burned :) | |
May 19, 2020 at 10:52 | history | answered | gnasher729 | CC BY-SA 4.0 |