- Doesn’t know the difference between Array and LinkedList
- Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks
- Knows space and time tradeoffs of the basic data structures, Arrays vs LinkedLists, Able to explain how hashtables can be implemented and can handle collisions, Priority queues and ways to implement them etc.
- Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc
- Unable to find the average of numbers in an array
- Basic sorting, searching and data structure traversal and retrieval algorithms
- Tree, Graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix.
- Able to recognize and code dynamic programming solutions, good knowledge of graph algorithms, good knowledge of numerical computation algorithms, able to identify NP problems etc.
- Doesn’t know what a compiler, linker or interpreter is
- Basic understanding of compilers, linker and interpreters. Understands what assembly code is and how things work at the hardware level. Some knowledge of virtual memory and paging.
- Understands kernel mode vs. user mode, multi-threading, synchronization primitives and how they’re implemented, able to read assembly code. Understands how networks work, understanding of network protocols and socket level programming.
- Understands the entire programming stack, hardware (CPU + Memory + Cache + Interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing…
- 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
- 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
- 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
- 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.
- 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.
- 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
- 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.
- 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
- 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.
- 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
- 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
- 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.
- 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
- 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
- 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
- No knowledge of scripting tools
- Batch files/shell scripts
- Perl/Python/Ruby/VBScript/Powershell
- Has written and published reusable code
- 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.
- 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)
- 1
- 2-3
- 4-5
- 6+
- 1
- 2-5
- 6-9
- 10+
- 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.
- 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.
- 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)
- 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.
- 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
- 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.
- 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
- 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
##############################################################################################################
- I can produce a correct implementation for a simple function, given a well-defined specification of desired behavior and interface, without help from others.
- I can determine a suitable interface and produce a correct implementation, given a loose specification for a simple function, without help from others. I can break down a complex function specification in smaller functions.
- I can estimate the space and time costs of my code during execution. I can empirically compare different implementations of the same function specification using well- defined metrics, including execution time and memory footprint. I express invariants in my code using preconditions, assertions and post-conditions. I use stubs to gain flexibility on implementation order.
- I use typing and interfaces deliberately and productively to structure and plan ahead my coding activity. I can design and implement entire programs myself given well-defined specifications on external input and output. I systematically attempt to generalize functions to increase their reusability.
- I can systematically recognize inconsistent or conflicting requirements in specifications. I can break down a complex program architecture in smaller components that can be implemented separately, including by other people. I can us existing (E)DSLs or metaprogramming patterns to increase my productivity.
- I can reliably recognize when underspecification is intentional or not. I can exploit under-specification to increase my productivity in non-trivial ways. I can devise new (E)DSLs or create new metaprogramming patterns to increase my productivity and that of other programmers.
- I can adapt my code when I receive small changes in its specification without rewriting it entirely, provided I know the change is incremental. I can change my own code given detailed instructions from a more experienced programmer.
- I can determine myself whether a small change in specification is incremental or requires a large refactoring. I can change my own code given loose instructions from a more experienced programmer.
- I can derive a refactoring strategy on my own code, given relatively small changes in specifications. I can change other people's code given precise instructions from a person already familiar with the code.
- I can predict accurately the effort needed to adapt my own code base to a new specification. I can follow an existing refactoring strategy on someone else's code. I can take full responsibility for the integration of someone else's patch onto my own code.
- I can reverse-engineer someone else's code base with help from the original specification, and predict accurately the effort needed to adapt it to a new specification.
- I can reverse-engineer someone else's code base without original specification, and predict accurately the effort needed to adapt it to a new specification.
- I know the entry and termination points in the code I write. I can use the main I/O channels of my language to input and print simple text and numbers.
- I am familiar with recommended mechanisms to accept program options/parameters from the execution environment and signal errors, and use them in the code I write.
- I can delegate functions to an external process at run-time. I know how to productively use streaming and buffering to work on large data sets and use them in my code. I am familiar with the notion of locality and use it to tailor my implementations.
- I am familiar with at least one API for bi- directional communication with other run-time processes. I can write client code for simple Internet protocols. I am familiar with the most common packaging and redistribution requirements of at least one platform and use them in my own projects. I can use predetermined programming patterns to exploit platform parallelism productively in my code.
- I can implement both client and server software for arbitrary protocol specifications. I can quantify accurately the time and space overheads of different communication mechanisms (e.g., syscalls, pipes, sockets). I am familiar with hardware architectures and can predict how sequential programs will behave when changing the underlying hardware. I can estimate the scalability of parallel code fragments on a given platform.
- I am familiar with most software architectures in use with systems I develop for. I can work together with system architects to mutually optimize my own software architecture with the overall system architecture. I am familiar with most design and operational cost/benefit trade-offs in systems that I develop for.
- I can assemble program fragments by renaming variables until the whole becomes coherent and compatible with my goal.
- Given a library of mostly pure functions and detailed API documentation, I can reuse this library productively in my code.
- I can recognize when existing code requires a particular overall architecture for reuse (e.g. an event loop). I can adapt my own code in advance to the requirements of multiple separate libraries that I plan to reuse.
- I can recognize and extract reusable components from a larger code base for my own use, even when the original author did not envision reusability. I can package, document and distribute a software library for others to reuse. I can interface stateless code from different programming languages.
- I can systematically remove constraints from existing code that are not mandated by specification, to maximize its generality. I can read and understand code that uses APIs most common in my domain without help from their documentation. I can interface code from different programming languages with distinct operational semantics.
- I can discover and reliably exploit undocumented/unintended behavior of any code written in a language I understand, including code that I did not write myself.
- I can read the code I wrote and explain what I intend it to mean to someone more experienced than me.
- I can read code from someone of a similar or lower level than me and explain what it means. I can recognize and explain simple mismatches between specification and implementation in my code or code from someone at the same level as me or lower.
- I can show and explain code fragments I write in either imperative or declarative style to someone else who knows a different programming language where the same style is prevalent, so that this person can reproduce the same functionality in their language of choice.
- I can explain my data structures, algorithms and architecture patterns to someone else using the standard terms in my domain, without reference to my code.
- I can gauge the expertise level of my audience and change the way I talk to them accordingly. I can recognize when an explanation is overly or insufficiently detailed for a given audience, and give feedback accordingly.
- I can take part effortlessly in any conversation or discussion about the language(s) I use, and have a good familiarity with idiomatic constructs. I can come up spontaneously with correct and demonstrative code examples for all concepts I need to share with others.
- I can distinguish between a command prompt at a shell and an input prompt for a program run from this shell. I can follow online tutorials without help and reach the prescribed outcome. I can search for the text of common error messages and adapt the experience of other people to my need.
- I can distinguish between features general to a language and features specific to a particular language implementation. I can read the text of error messages and understand what they mean without external help.
- I can read the reference documentation for the language(s) or API I use, and refer to it to clarify my understanding of arbitrary code fragments. I can understand the general concepts in articles or presentations by experts. I can track and determine who is responsible for an arbitrary code fragment in a system I use or develop for.
- I can infer the abstract operating model of an API or library from its interface, without access to documentation, and write small test programs to test if my model is accurate. I can recognize when a reference documentation for a language or API is incomplete or contradictory with a reference implementation.
- I am able to read and understand most expert literature applicable to the languages I use. I am able to recognize when an academic innovation is applicable to my domain and adapt it for use in my projects.
- I can recognize and expose tacit assumptions in expert literature in my domain. I can reliably recognize when the narrative or description of a programming achievement is false or misleading, without testing explicitly.
- I can use a common programming environment and follow common workflows step-by-step to test/run a program.
- I can integrate my source files in a programming environment that automates large portions of my programming workflow. I use version control to track my progress and roll back from unsuccessful changes.
- I express and use dependency tracking in my programming environment to avoid unnecessary (re)processing in my development cycles. I can use different development branches in version control for different programming tasks.
- I use different workflows for different programming assignments, with different trade-offs between initial set-up overhead and long-term maintenance overhead. I can enter the environment of someone else at my level or below and make code contributions there with minimal training.
- I modify my programming environment to tailor it to my personal style, and can quantify how these changes impact my productivity. I can productively use the preferred programming environments of at least 80% of all programmers at my level or below.
- I can reliably recognize and quantify friction between other programmers and their programming environment. I can measurably improve the productivity of my peers by helping them tailor their environment to their personal style.
- I can distinguish between correct and incorrect output in my own programs. I am familiar with the etiquette for asking help from experts in my domain.
- I can reliably distinguish between incorrect output due to incorrect input, from incorrect output due to program error. I can narrow down the location of a program error in a complex program to a single module or function. I can isolate and fix Bohr bugs in my own code.
- I can translate human knowledge or specifications about invariants into assertions or type constraints in my own code. I can inspect the run-time state of a program to check it matches known invariant. I write and use unit tests where applicable.
- I can reduce a program error to the simplest program that demonstrates the same error. I have one or more working strategy to track and fix heisenbugs in code that I can understand. I write and use regression tests for code that I work with directly.
- I can devise systematic strategies to track and fix mandelbugs in code that I can understand. I can recognize a hardware bug in a system driven mostly by software I designed.
- I can track and attribute responsibility accurately for most unexpected/undesired behaviors in systems that I develop for. I can track and isolate hardware bugs in systems where I have access to all software sources.