In the software industry (as in many other industries), developers are commonly categorized as either Junior-level, intermediate, or Senior-level. The most typical definition for these distinctions is based on the number of years of experience (0-2 years = junior, 2-5 years = intermediate, >5 years = senior, or something along those lines). This post describes an alternative basis for making these distinctions that is based on the type of designs that a developer creates, rather than the number of years they have been creating software professionally.
Since our trade is fairly difficult intellectually, I don’t think that the number of years of experience accurately dictates the effectiveness of a developer, and thus it’s a poor basis for distinction. If you’re not actively trying to improve, additional years of experience probably doesn’t make you much more effective, and my experience working with a fair amount of developers at a number of different companies reflects that.
Here is the basis I’m going to start using for categorizing developers:
Junior: Creates overly-simple designs with lots of duplication. Their apps are easy to understand, but hard to maintain.
Intermediate: Creates overly-complex designs with lots of unnecessary indirection. Typical code smells that indicate an intermediate developer are very long, convoluted class names that don’t convey much meaning, unnecessary abstractions and use of frameworks that aren’t adding any value in the context (but increase complexity). Their apps have a high learning curve to understand the architecture, but then are fairly maintainable (for at least intermediate-level developers) once you’ve successfully grokked all the indirection.
Senior: Creates simple, elegant designs. Their apps are fairly easy to understand (for at least intermediate-level developers), maintain and enhance. They use abstractions where they make sense and frameworks that add value to the particular application.
Am I right/wrong/silly? Leave a comment!