Software Developer Technical Definition of Abilities

I was recently asked to compile a list of the qualities of the different level of programmers. Using multiple sources around the inter-web, this is what I came up with.

Junior developer

These developers are brand new to the game and most will have less than two years’ experience in total. All things can be solved with code and they will bang straight into the problem without first looking at what is actually needed. They need a lot of supervision and in some cases a breaking in period where you need to knock the "I know it all already" out of them. In many cases the phrase "I don’t know how to do that" is very hard for them to say. Many are not used to working in teams or using source control. The great thing is that we all have been there and we know it’s a growing phase and they will grow out of it. They will need near-constant help. Not only will they not know the business domain, but they may also struggle with the fundamentals of the language or the toolset. They don't know what they don't know, so without guidance, they will make frequent mistakes which, if not kept on top of, will derail the wider team. They are assigned the least complex tasks and should be supervised fairly closely. Generally they know about 10% of what they think they know. Usually they have not been through the whole development cycle and so often make some very naive choices if given the opportunity to choose. Sadly many of them don't actually care what the requirement is, they want to build things their way. They often have poor debugging skills.

Intermediate Developer

Intermediate level is where many programmers fall. Usually developers in this role will have between 2 and 7 year and possibly up to 10 years, although some can stay at this level their whole careers. They will develop code with less supervision and will likely be able to solve most of the routine problems they face but may struggle through some. They will be independently productive and will be able to tackle most tasks on their own, or understand when they need to reach out for help. Many times they will be assigned a task by the dev-lead and they will do it without worrying about the bigger picture. After a while they begin to see issues reoccurring and will begin to learn how to avoid them. They may unfortunately become attached to their code believing only they can really understand it. They are not generally tasked with high level design or highly complicated tasks that require an in-depth level of knowledge. They may be tasked with the design of a piece of the application though, especially as they are in the zone to become a senior developer. They are good at maintenance tasks or tasks where they can focus on just their piece of the puzzle, but are not usually expected to consider the application as a whole unless working with senior developers or being prepped for promotion to senior. They can usually do a decent job of troubleshooting and debugging, but they have to really slog through to get the hard ones. They do not yet have enough experience to see the patterns in the problems that point them to the probable place they are occurring. But they are gaining those skills and rarely need to ask for debugging help. They have probably been through the whole development cycle at least once and seen the results of design problems and are learning how to avoid them in the future. Usually they tend to be more likely to take a requirement at face value and not push it back when it has obvious problems or gaps. They have learned enough to know what they don't know and are starting to gain that knowledge. They are the workhorses of the programming world, they deliver probably 80-90% of the routine code and maybe 10% of the very difficult stuff. When they do start worrying about the bigger picture start them on the course to be a senior developer.

A Senior Developer

Generally have at least ten years of experience and have almost always at this level know they are doing. Usually experts in their chosen technology stack and will know the supporting stacks quite well. They will be honest about gaps in their knowledge because they know it’s better for them to get a person who does know what they are doing in to help. They are the ones that get the hard unsolvable tasks and they manage to fix them with what can be described as magic. They will be gifted at troubleshooting often having a strange sixth sense for fixing issues because they have done much of it before. Often used as a mentor. They will be looking at the big picture and more importantly listening to what the customer needs rather than what the customer wants. Is able to challenge the customer for correct requirements in regular language and in turn tell the development team what they should be doing. When going into a client, they will begin to understand their workflows better than the clients themselves even after a couple of weeks. They will tend to be more switched on to the issues outside of the programming domain such as data privacy and regulatory concerns. They have been on at least one death march and know exactly why some things are to be avoided. Senior developers will generally be choosier about what they work with because they will have being through the mill and also due to scarcity can decide not to work with a particular technology. They will be able to mentor more junior members of the team. They are given the hard tasks (the ones nobody knows how to solve) and often get design responsibilities, however, they may need their proposed designs vetted because they sometimes lack an overall architectural vision. They often work independently because they have a proven track record of delivering the goods. Often they are amazing troubleshooters. They know how to deliver a working product and meet a deadline. They know what corners can be cut and what corners should never be cut. They know at least one and often several languages at the expert level. They have seen a lot of "hot new technologies" hit the workplace and disappear, so they tend to be a bit more conservative about jumping on the bandwagon for the next exciting new development tool (but not completely resistant to change - those would be the older Intermediate developers who never make the leap to Senior). They understand their job is to deliver working software that does what the users want, not to play with fun tools. They are often pickier about where they will work because they can be and because they have seen firsthand how bad some places can be. They seek out the places that have the most interesting tasks to do. Often they know more about their company's products than anyone else even if they have been there only a few months. They know they need more than programming knowledge and are good at getting knowledge about the business domain they support as well. They are often aware of issues that juniors never consider and intermediates often don't think about such as regulatory and legal issues in the business domain they support. They can and will push back a requirement because they know what the problems with it will be and can explain the same to the laymen.

Senior Lead Developer

Possesses the same attributes as a Senior Developer however in addition they are responsible for the underlying architecture for the software program, as well as for overseeing the work being done by any other software engineers working on the project. A lead programmer will typically also act as a mentor for new or lower-level software developers or programmers, as well as for all the members on the development team. Although the responsibilities are primarily technical, lead programmers also generally serve as an interface between the programmers and management and have supervisorial responsibilities in delegating work and ensuring that software projects come in on time and under budget. Lead programmers also serve as technical advisers to management and provide programming perspective on requirements. Typically a lead programmer will oversee a development team of between two and ten programmers, with three to five often considered the ideal size. Teams larger than ten programmers tend to become unmanageable without additional structure. A lead programmer normally reports to a manager with overall project or section responsibility.

Maven: As a lead developer at Microsoft, I spend far less time in the source code than I have in the past. Let me clarify - I am in the source code quite a bit, just not contributing new code. Instead, I have chosen to focus more on design issues and code reviews when I find the time. However, if I had far fewer than 10 reports that would allow me to be closer to the code and even be a contributing developer, although not at the expense of the people I need to help grow. Different people have differing opinions on exactly what the role of a lead developer is, and truthfully, it really depends on the specific situation. However, most "leads" are also managers, and caring about your people and removing distractions from their everyday work is a high priority. Let me know if you want to discuss leading and managing more, in the context of developers of course.

Additional Descriptive Matrix

Note that the knowledge for each level is cumulative; being at level n implies that you also know everything from the levels lower than n.

Software Engineering
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
source code version control	Folder backups by date	VSS and beginning CVS/SVN user	Proficient in using CVS and SVN features. Knows how to branch and merge, use patches setup repository properties etc.	Knowledge of distributed VCS systems. Has tried out Bzr/Mercurial/Darcs/Git
build automation	Only knows how to build from IDE	Knows how to build the system from the command line	Can setup a script to build the basic system	Can setup a script to build the system and also documentation, installers, generate release notes and tag the code in source control
automated testing	Thinks that all testing is the job of the tester	Has written automated unit tests and comes up with good unit test cases for the code that is being written	Has written code in TDD manner	Understands and is able to setup automated functional, load/performance and UI tests
Programming
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
problem decomposition	Only straight line code with copy paste for reuse	Able to break up problem into multiple functions	Able to come up with reusable functions/objects that solve the overall problem	Use of appropriate data structures and algorithms and comes up with generic/object-oriented code that encapsulate aspects of the problem that are subject to change.
systems decomposition	Not able to think above the level of a single file/class	Able to break up problem space and design solution as long as it is within the same platform/technology	Able to design systems that span multiple technologies/platforms.	Able to visualize and design complex systems with multiple product lines and integrations with external systems. Also should be able to design operations support systems like monitoring, reporting, fail overs etc.
communication	Cannot express thoughts/ideas to peers. Poor spelling and grammar.	Peers can understand what is being said. Good spelling and grammar.	Is able to effectively communicate with peers	Able to understand and communicate thoughts/design/ideas/specs in a unambiguous manner and adjusts communication as per the context	This is an often under rated but very critical criteria for judging a programmer. With the increase in outsourcing of programming tasks to places where English is not the native tongue this issue has become more prominent. I know of several projects that failed because the programmers could not understand what the intent of the communication was.
code organization within a file	no evidence of organization within a file	Methods are grouped logically or by accessibility	Code is grouped into regions and well commented with references to other source files	File has license header, summary, well commented, consistent white space usage. The file should look beautiful.
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
code organization across files	No thought given to organizing code across files	Related files are grouped into a folder	Each physical file has a unique purpose, for e.g. one class definition, one feature implementation etc.	Code organization at a physical level closely matches design and looking at file names and folder distribution provides insights into design
source tree organization	Everything in one folder	Basic separation of code into logical folders.	No circular dependencies, binaries, libs, docs, builds, third-party code all organized into appropriate folders	Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system.	The difference between this and the previous item is in the scale of organization, source tree organization relates to the entire set of artifacts that define the system.
code readability	Mono-syllable names	Good names for files, variables classes, methods etc.	No long functions, comments explaining unusual code, bug fixes, code assumptions	Code assumptions are verified using asserts, code flows naturally – no deep nesting of conditionals or methods
defensive coding	Doesn’t understand the concept	Checks all arguments and asserts critical assumptions in code	Makes sure to check return values and check for exceptions around code that can fail.	Has his own library to help with defensive coding, writes unit tests that simulate faults
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
error handling	Only codes the happy case	Basic error handling around code that can throw exceptions/generate errors	Ensures that error/exceptions leave program in good state, resources, connections and memory is all cleaned up properly	Codes to detect possible exception before, maintain consistent exception handling strategy in all layers of code, come up with guidelines on exception handling for entire system.
IDE	Mostly uses IDE for text editing	Knows their way around the interface, able to effectively use the IDE using menus.	Knows keyboard shortcuts for most used operations.	Has written custom macros
API	Needs to look up the documentation frequently	Has the most frequently used APIs in memory	Vast and In-depth knowledge of the API	Has written libraries that sit on top of the API to simplify frequently used tasks and to fill in gaps in the API	E.g. of API can be Java library, .net framework or the custom API for the application
frameworks	Has not used any framework outside of the core platform	Has heard about but not used the popular frameworks available for the platform.	Has used more than one framework in a professional capacity and is well-versed with the idioms of the frameworks.	Author of framework
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
requirements	Takes the given requirements and codes to spec	Come up with questions regarding missed cases in the spec	Understand complete picture and come up with entire areas that need to be speced	Able to suggest better alternatives and flows to given requirements based on experience
scripting	No knowledge of scripting tools	Batch files/shell scripts	Perl/Python/Ruby/VBScript/Powershell	Has written and published reusable code
database	Thinks that Excel is a database	Knows basic database concepts, normalization, ACID, transactions and can write simple selects	Able to design good and normalized database schemas keeping in mind the queries that’ll have to be run, proficient in use of views, stored procedures, triggers and user defined types. Knows difference between clustered and non-clustered indexes. Proficient in use of ORM tools.	Can do basic database administration, performance optimization, index optimization, write advanced select queries, able to replace cursor usage with relational sql, understands how data is stored internally, understands how indexes are stored internally, understands how databases can be mirrored, replicated etc. Understands how the two phase commit works.
Experience
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
languages with professional experience	Imperative or Object Oriented	Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types	Functional, added bonus if they understand lazy evaluation, currying, continuations	Concurrent (Erlang, Oz) and Logic (Prolog)
platforms with professional experience	1	2-3	4-5	6+
years of professional experience	1	2-5	6-9	10+
domain knowledge	No knowledge of the domain	Has worked on at least one product in the domain.	Has worked on multiple products in the same domain.	Domain expert. Has designed and implemented several products/solutions in the domain. Well versed with standard terms, protocols used in the domain.
Knowledge
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
tool knowledge	Limited to primary IDE (VS.Net, Eclipse etc.)	Knows about some alternatives to popular and standard tools.	Good knowledge of editors, debuggers, IDEs, open source alternatives etc. etc. For e.g. someone who knows most of the tools from Scott Hanselman’s power tools list. Has used ORM tools.	Has actually written tools and scripts, added bonus if they’ve been published.
languages exposed to	Imperative or Object Oriented	Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types	Functional, added bonus if they understand lazy evaluation, currying, continuations	Concurrent (Erlang, Oz) and Logic (Prolog)
codebase knowledge	Has never looked at the codebase	Basic knowledge of the code layout and how to build the system	Good working knowledge of code base, has implemented several bug fixes and maybe some small features.	Has implemented multiple big features in the codebase and can easily visualize the changes required for most features or bug fixes.
knowledge of upcoming technologies	Has not heard of the upcoming technologies	Has heard of upcoming technologies in the field	Has downloaded the alpha preview/CTP/beta and read some articles/manuals	Has played with the previews and has actually built something with it and as a bonus shared that with everyone else
	2n (Level 0)	n2 (Level 1)	n (Level 2)	log(n) (Level 3)	Comments
platform internals	Zero knowledge of platform internals	Has basic knowledge of how the platform works internally	Deep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code.	Has written tools to enhance or provide information on platform internals. For e.g. disassemblers, decompilers, debuggers etc.
books	Unleashed series, 21 days series, 24 hour series, dummies series…	Code Complete, Don’t Make me Think, Mastering Regular Expressions	Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month	Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer
blogs	Has heard of them but never got the time.	Reads tech/programming/software engineering blogs and listens to podcasts regularly.	Maintains a link blog with some collection of useful articles and tools that he/she has collected	Maintains a blog in which personal insights and thoughts on programming are shared

http://sijinjoseph.com/programmer-competency-matrix/