Lukas Murdock
Subscribe for updates and more.

Software Engineering

Planted 02023-12-24

Knowledge areas

Based on SWEBOK

Table of contents

SWEBOK

Released 2013.

SWEBOK V3.0 comprises 15 Knowledge Areas, plus a new Appendix on Standards.

SWEBOK Wiki

Wikipedia: Software Engineering Body of Knowledge

SWEBOK Guide V3 Topics

TOC

  • Chapter 1: Software Requirements
  • Chapter 2: Software Design
  • Chapter 3: Software Construction
  • Chapter 4: Software Testing
  • Chapter 5: Software Maintenance
  • Chapter 6: Software Configuration Management
  • Chapter 7: Software Engineering Management
  • Chapter 8: Software Engineering Process
  • Chapter 9: Software Engineering Models and Methods
  • Chapter 10: Software Quality
  • Chapter 11: Software Engineering Professional Practice
  • Chapter 12: Software Engineering Economics
  • Chapter 13: Computing Foundations
  • Chapter 14: Mathematical Foundations
  • Chapter 15: Engineering Foundations

Chapter 1: Software Requirements

  1. Software Requirements Fundamentals
    • Definition of a Software Requirement
    • Product and Process Requirements
    • Functional and Nonfunctional Requirements
    • Emergent Properties
    • Quantifiable Requirements
    • System Requirements and Software Requirements
  2. Requirements Process
    • Process Models
    • Process Actors
    • Process Support and Management
    • Process Quality and Improvement
  3. Requirements Elicitation
    • Requirements Sources
    • Elicitation Techniques
  4. Requirements Analysis
    • Requirements Classification
    • Conceptual Modeling
    • Architectural Design and Requirements Allocation
    • Requirements Negotiation
    • Formal Analysis
  5. Requirements Specification
    • System Definition Document
    • System Requirements Specification
    • Software Requirements Specification
  6. Requirements Validation
    • Requirements Reviews
    • Prototyping
    • Model Validation
    • Acceptance Tests
  7. Practical Considerations
    • Iterative Nature of the Requirements Process
    • Change Management
    • Requirements Attributes
    • Requirements Tracing
    • Measuring Requirements
  8. Software Requirements Tools

Chapter 2: Software Design

  1. Software Design Fundamentals
    • General Design Concepts
    • Context of Software Design
    • Software Design Process
    • Software Design Principles
  2. Key Issues in Software Design
    • Concurrency
    • Control and Handling of Events
    • Data Persistence
    • Distribution of Components
    • Error and Exception Handling and Fault Tolerance
    • Interaction and Presentation
    • Security
  3. Software Structure and Architecture
    • Architectural Structures and Viewpoints
    • Architectural Styles
    • Design Patterns
    • Architecture Design Decisions
    • Families of Programs and Frameworks
  4. User Interface Design
    • General User Interface Design Principles
    • User Interface Design Issues
    • The Design of User Interaction Modalities
    • The Design of Information Presentation
    • User Interface Design Process
    • Localization and Internationalization
    • Metaphors and Conceptual Models
  5. Software Design Quality Analysis and Evaluation
    • Quality Attributes
    • Quality Analysis and Evaluation Techniques
    • Measures
  6. Software Design Notations
    • Structural Descriptions (Static View)
    • Behavioral Descriptions (Dynamic View)
  7. Software Design Strategies and Methods
    • General Strategies
    • Function-Oriented (Structured) Design
    • Object-Oriented Design
    • Data Structure-Centered Design
    • Component-Based Design (CBD)
    • Other Methods
  8. Software Design Tools

Chapter 3: Software Construction

  1. Software Construction Fundamentals
    • Minimizing Complexity
    • Anticipating Change
    • Constructing for Verification
    • Reuse
    • Standards in Construction
  2. Managing Construction
    • Construction in Life Cycle Models
    • Construction Planning
    • Construction Measurement
  3. Practical Considerations
    • Construction Design
    • Construction Languages
    • Coding
    • Construction Testing
    • Construction for Reuse
    • Construction with Reuse
    • Construction Quality
    • Integration
  4. Construction Technologies
    • API Design and Use
    • Object-Oriented Runtime Issues
    • Parameterization and Generics
    • Assertions, Design by Contract, and Defensive Programming
    • Error Handling, Exception Handling, and Fault Tolerance
    • Executable Models
    • State-Based and Table-Driven Construction Techniques
    • Runtime Configuration and Internationalization
    • Grammar-Based Input Processing
    • Concurrency Primitives
    • Middleware
    • Construction Methods for Distributed Software
    • Constructing Heterogeneous Systems
    • Performance Analysis and Tuning
    • Platform Standards
    • Test-First Programming
  5. Software Construction Tools
    • Development Environments
    • GUI Builders
    • Unit Testing Tools
    • Profiling, Performance Analysis, and Slicing Tools

Chapter 4: Software Testing

  1. Software Testing Fundamentals
    • Testing-Related Terminology
    • Key Issues
    • Relationship of Testing to Other Activities
  2. Test Levels
    • The Target of the Test
    • Objectives of Testing
  3. Test Techniques
    • Based on the Software Engineer’s Intuition and Experience
    • Input Domain-Based Techniques
    • Code-Based Techniques
    • Fault-Based Techniques
    • Usage-Based Techniques
    • Model-Based Testing Techniques
    • Techniques Based on the Nature of the Application
    • Selecting and Combining Techniques
  4. Test-Related Measures
    • Evaluation of the Program Under Test
    • Evaluation of the Tests Performed
  5. Test Process
    • Practical Considerations
    • Test Activities
  6. Software Testing Tools
    • Testing Tool Support
    • Categories of Tools

Chapter 5: Software Maintenance

  1. Software Maintenance Fundamentals
    • Definitions and Terminology
    • Nature of Maintenance
    • Need for Maintenance
    • Majority of Maintenance Costs
    • Evolution of Software
    • Categories of Maintenance
  2. Key Issues in Software Maintenance
    • Technical Issues
    • Management Issues
    • Maintenance Cost Estimation
    • Software Maintenance Measurement
  3. Maintenance Process
    • Maintenance Processes
    • Maintenance Activities
  4. Techniques for Maintenance
    • Program Comprehension
    • Reengineering
    • Reverse Engineering
    • Migration
    • Retirement
  5. Software Maintenance Tools

Chapter 6: Software Configuration Management

  1. Management of the SCM Process
    • Organizational Context for SCM
    • Constraints and Guidance for the SCM Process
    • Planning for SCM
    • SCM Plan
    • Surveillance of Software Configuration Management
  2. Software Configuration Identification
    • Identifying Items to Be Controlled
    • Software Library
  3. Software Configuration Control
    • Requesting, Evaluating, and Approving Software Changes
    • Implementing Software Changes
    • Deviations and Waivers
  4. Software Configuration Status Accounting
    • Software Configuration Status Information
    • Software Configuration Status Reporting
  5. Software Configuration Auditing
    • Software Functional Configuration Audit
    • Software Physical Configuration Audit
    • In-Process Audits of a Software Baseline
  6. Software Release Management and Delivery
    • Software Building
    • Software Release Management
  7. Software Configuration Management Tools

Chapter 7: Software Engineering Management

  1. Initiation and Scope Definition
    • Determination and Negotiation of Requirements
    • Feasibility Analysis
    • Process for the Review and Revision of Requirements
  2. Software Project Planning
    • Process Planning
    • Determine Deliverables
    • Effort, Schedule, and Cost Estimation
    • Resource Allocation
    • Risk Management
    • Quality Management
    • Plan Management
  3. Software Project Enactment
    • Implementation of Plans
    • Software Acquisition and Supplier Contract Management
    • Implementation of Measurement Process
    • Monitor Process
    • Control Process
    • Reporting
  4. Review and Evaluation
    • Determining Satisfaction of Requirements
    • Reviewing and Evaluating Performance
  5. Closure
    • Determining Closure
    • Closure Activities
  6. Software Engineering Measurement
    • Establish and Sustain Measurement Commitment
    • Plan the Measurement Process
    • Perform the Measurement Process
    • Evaluate Measurement
  7. Software Engineering Management Tools

Chapter 8: Software Engineering Process

  1. Software Process Definition
    • Software Process Management
    • Software Process Infrastructure
  2. Software Life Cycles
    • Categories of Software Processes
    • Software Life Cycle Models
    • Software Process Adaptation
    • Practical Considerations
  3. Software Process Assessment and Improvement
    • Software Process Assessment Models
    • Software Process Assessment Methods
    • Software Process Improvement Models
    • Continuous and Staged Software Process Ratings
  4. Software Measurement
    • Software Process and Product Measurement
    • Quality of Measurement Results
    • Software Information Models
    • Software Process Measurement Techniques
  5. Software Engineering Process Tools

Chapter 9: Software Engineering Models and Methods

  1. Modeling
    • Modeling Principles
    • Properties and Expression of Models
    • Syntax, Semantics, and Pragmatics
    • Preconditions, Postconditions, and Invariants
  2. Types of Models
    • Information Modeling
    • Behavioral Modeling
    • Structure Modeling
  3. Analysis of Models
    • Analyzing for Completeness
    • Analyzing for Consistency
    • Analyzing for Correctness
    • Traceability
    • Interaction Analysis
  4. Software Engineering Methods
    • Heuristic Methods
    • Formal Methods
    • Prototyping Methods
    • Agile Methods

Chapter 10: Software Quality

  1. Software Quality Fundamentals
    • Software Engineering Culture and Ethics
    • Value and Costs of Quality
    • Models and Quality Characteristics
    • Software Quality Improvement
    • Software Safety
  2. Software Quality Management Processes
    • Software Quality Assurance
    • Verification & Validation
    • Reviews and Audits
  3. Practical Considerations
    • Software Quality Requirements
    • Defect Characterization
    • Software Quality Management Techniques
    • Software Quality Measurement
  4. Software Quality Tools

Chapter 11: Software Engineering Professional Practice

  1. Professionalism
    • Accreditation, Certification, and Licensing
    • Codes of Ethics and Professional Conduct
    • Nature and Role of Professional Societies
    • Nature and Role of Software Engineering Standards
    • Economic Impact of Software
    • Employment Contracts
    • Legal Issues
    • Documentation
    • Tradeoff Analysis
  2. Group Dynamics and Psychology
    • Dynamics of Working in Teams/Groups
    • Individual Cognition
    • Dealing with Problem Complexity
    • Interacting with Stakeholders
    • Dealing with Uncertainty and Ambiguity
    • Dealing with Multicultural Environments
  3. Communication Skills
    • Reading, Understanding, and Summarizing
    • Writing
    • Team and Group Communication
    • Presentation Skills

Chapter 12: Software Engineering Economics

  1. Software Engineering Economics Fundamentals

1.1. Finance 1.2. Accounting 1.3. Controlling 1.4. Cash Flow 1.5. Decision-Making Process 1.6. Valuation 1.7. Inflation 1.8. Depreciation 1.9. Taxation 1.10. Time-Value of Money 1.11. Efficiency 1.12. Effectiveness 1.13. Productivity

  1. Life Cycle Economics
    • Product
    • Project
    • Program
    • Portfolio
    • Product Life Cycle
    • Project Life Cycle
    • Proposals
    • Investment Decisions
    • Planning Horizon
    • Price and Pricing
    • Cost and Costing
    • Performance Measurement
    • Earned Value Management
    • Termination Decisions
    • Replacement and Retirement Decisions
  2. Risk and Uncertainty
    • Goals, Estimates, and Plans
    • Estimation Techniques
    • Addressing Uncertainty
    • Prioritization
    • Decisions under Risk
    • Decisions under Uncertainty
  3. Economic Analysis Methods
    • For-Profit Decision Analysis
    • Minimum Acceptable Rate of Return
    • Return on Investment
    • Return on Capital Employed
    • Cost-Benefit Analysis
    • Cost-Effectiveness Analysis
    • Break-Even Analysis
    • Business Case
    • Multiple Attribute Evaluation
    • Optimization Analysis
  4. Practical Considerations
    • The “Good Enough” Principle
    • Friction-Free Economy
    • Ecosystems
    • Offshoring and Outsourcing

Chapter 13: Computing Foundations

  1. Problem Solving Techniques
    • Definition of Problem Solving
    • Formulating the Real Problem
    • Analyze the Problem
    • Design a Solution Search Strategy
    • Problem Solving Using Programs
  2. Abstraction
    • Levels of Abstraction
    • Encapsulation
    • Hierarchy
    • Alternate Abstractions
  3. Programming Fundamentals
    • The Programming Process
    • Programming Paradigms
  4. Programming Language Basics
    • Programming Language Overview
    • Syntax and Semantics of Programming Languages
    • Low-Level Programming Languages
    • High-Level Programming Languages
    • Declarative vs. Imperative Programming Languages
  5. Debugging Tools and Techniques
    • Types of Errors
    • Debugging Techniques
    • Debugging Tools
  6. Data Structure and Representation
    • Data Structure Overview
    • Types of Data Structure
    • Operations on Data Structures
  7. Algorithms and Complexity
    • Overview of Algorithms
    • Attributes of Algorithms
    • Algorithmic Analysis
    • Algorithmic Design Strategies
    • Algorithmic Analysis Strategies
  8. Basic Concept of a System
    • Emergent System Properties
    • Systems Engineering
    • Overview of a Computer System
  9. Computer Organization
    • Computer Organization Overview
    • Digital Systems
    • Digital Logic
    • Computer Expression of Data
    • The Central Processing Unit (CPU)
    • Memory System Organization
    • Input and Output (I/O)
  10. Compiler Basics
    • Compiler/Interpreter Overview
    • Interpretation and Compilation
    • The Compilation Process
  11. Operating Systems Basics
    • Operating Systems Overview
    • Tasks of an Operating System
    • Operating System Abstractions
    • Operating Systems Classification
  12. Database Basics and Data Management
    • Entity and Schema
    • Database Management Systems (DBMS)
    • Database Query Language
    • Tasks of DBMS Packages
    • Data Management
    • Data Mining
  13. Network Communication Basics
    • Types of Network
    • Basic Network Components
    • Networking Protocols and Standards
    • The Internet
    • Internet of Things
    • Virtual Private Network (VPN)
  14. Parallel and Distributed Computing
    • Parallel and Distributed Computing Overview
    • Difference between Parallel and Distributed Computing
    • Parallel and Distributed Computing Models
    • Main Issues in Distributed Computing
  15. Basic User Human Factors
    • Input and Output
    • Error Messages
    • Software Robustness
  16. Basic Developer Human Factors
    • Structure
    • Comments
  17. Secure Software Development and Maintenance
    • Software Requirements Security
    • Software Design Security
    • Software Construction Security
    • Software Testing Security
    • Build Security into Software Engineering Process
    • Software Security Guidelines

Chapter 14: Mathematical Foundations

  1. Set, Relations, Functions
    • Set Operations
    • Properties of Set
    • Relation and Function
  2. Basic Logic
    • Propositional Logic
    • Predicate Logic
  3. Proof Techniques
    • Methods of Proving Theorems
  4. Basics of Counting
  5. Graphs and Trees
    • Graphs
    • Trees
  6. Discrete Probability
  7. Finite State Machines
  8. Grammars
    • Language Recognition
  9. Numerical Precision, Accuracy, and Errors
  10. Number Theory
    • Divisibility
    • Prime Number, GCD
  11. Algebraic Structures
    • Group
    • Rings

Chapter 15: Engineering Foundations

  1. Empirical Methods and Experimental Techniques
    • Designed Experiment
    • Observational Study
    • Retrospective Study
  2. Statistical Analysis
    • Unit of Analysis (Sampling Units), Population, and Sample
    • Concepts of Correlation and Regression
  3. Measurement
    • Levels (Scales) of Measurement
    • Direct and Derived Measures
    • Reliability and Validity
    • Assessing Reliability
  4. Engineering Design
    • Engineering Design in Engineering Education
    • Design as a Problem Solving Activity
    • Steps Involved in Engineering Design
  5. Modeling, Simulation, and Prototyping
    • Modeling
    • Simulation
    • Prototyping
  6. Standards
  7. Root Cause Analysis
    • Techniques for Conducting Root Cause Analysis

BoKs

Kent’s Epic Programming Principles

Epic Programming Principles

  • Core
    • Software is built for people, by people
    • Value in-person connections
    • Be the kind of person people like working with
    • Do good in the world
    • Value your time
    • Don’t solve problems, eliminate them
  • Craft
    • ‘Best practices’ do not exist
    • Do as little as possible
    • Make it work, make it right, make it fast
    • Optimize for sustainable velocity
    • Optimize for the unknown
    • Pragmatism is more important than ‘purity’
    • Keep it consistent
    • Don’t confuse simplicity with familiarity
    • Balance innovation with stability
    • Take ownership
    • Use static testing tools
    • Don’t prioritize temporary problems over long-term problems
    • There is no such thing as the ’right tool for the job’
    • Default to standards
  • Testing and performance
    • Tests should resemble users
    • Make assertions specific
  • Debugging and resilience
    • Least privilege
    • Design to fail fast and early
    • Optimize for the debugging experience
    • Install extinguishers before the fire starts
  • Developer experience
    • Adapt to and adopt productive tools
    • Document your work
    • Offline development matters
    • Deployable commits
    • Small and short lived merge requests
    • Go down to level up
  • Career
    • Solidify knowledge through teaching
    • Magnify your conversation impact
    • Communicate value
    • Know where to make money
    • Focus on unique value proposition
    • Keep learning
    • Prioritize relationships
    • Strive for excellence
    • Be honest
    • Embrace reality
    • Take personal responsibility

Skills matrix

Sema

Sema’s Developer skills matrix

General

  • General
    • Beginner: A Beginner developer is just getting started.
    • Advanced Beginner: Advanced Beginners may not be the workhorse of a project but they can provide more value than they require from a dev team.
    • Intermediate: Intermediate developers can effectively support Advanced Beginner and Beginner developers. They can understand and ask challenging questions about design techniques.
    • Advanced: Advanced developers are capable of looking at the bigger picture for engineering challenges and design key components from scratch. They can mentor not just support more junior devs.
    • Expert: Experts can not only design a solution but also see how it interacts with other software. They’re capable of acting as force multipliers as well as mentors. While they may not be as “hands on keyboard” as other devs they still know how to code at an incredibly high level.
  • Where they are likely to be found
    • Beginner: Self-taught developers who are just getting started. Programming or Computer Science students in their first two years of study.
    • Advanced Beginner: Developers who have been coding for a few months to a few years.
    • Intermediate: Most professional software developers.
    • Advanced: Most Advanced developers fill Tech Lead roles though they can still be found in the frontline of a team.
    • Expert: Experts sometimes have “Architect” in their title and are rare and valuable enough to be spread across multiple teams.

Communication

  • Feedback and Code Reviews
    • Beginner: Have not learned how to handle constructive feedback professionally. Pull Request comments are low value.
    • Advanced Beginner: Accepts constructive feedback calmly but may need multiple iterations to implement the technical solution. Can catch obvious errors in PRs but may be hesitant to challenge or provide actionable suggestions.
    • Intermediate: Accepts constructive feedback well and can implement it quickly in and out of code reviews. Provides quality guidance to Advanced Beginners.
    • Advanced: Accepts constructive feedback with grace and acts on it when appropriate. Provides context-appropriate and actionable feedback to develop ers of all levels. Recognizes their own biases and actively works to correct them. Capable of seeing bugs through reading code in PRs before even pulling down the branch.
    • Expert: Models a supportive and productive feedback culture. Accepts constructive feedback with grace and acts on it when appropriate. Proactively reaches out for more feedback in areas of lower skill or where previous mistakes were made calling out hotspots for reviewers to focus on.
  • Requirements
    • Beginner: Requires very detailed step-by-step overviews of requirements. Can carry very small tasks. Cannot estimate time requirements.
    • Advanced Beginner: Can implement requirements but may be “to the letter” of acceptance criteria and no more. Will be familiar with just a few areas of a single application. Low quality estimation.
    • Intermediate: Implements requirements both to the letter and spirit of acceptance criteria. Asks good questions during requirements grooming. However they may fall into “Bikeshedding” patterns or require very detailed specifications. Mixed estimation accuracy.
    • Advanced: Frequently provides the organization / project with simpler optimized requirement alternatives. Can communicate organization / project needs to developers and design constraints to users. Can break down large requirements by domain or stack verticals. Good estimation accuracy. Effective at “pushing back” on the Business.
    • Expert: Consistently anticipates the organization’s / project’s needs and improves grooming to suit it. Capable of building roadmaps that balance technical efficiency with maximum value. Influences testing strategies to ensure quality. Excellent estimate accuracy. Highly effective at “pushing back” on the Business.
  • Technical Communication
    • Beginner: Low or incorrect knowledge of technical vocabulary. Explains concepts with textbook definitions without practical backing.
    • Advanced Beginner: Can communicate clearly with higher level developers but still struggles to discuss things with non-technical stakeholders. Can help beginners with obvious problems but will defer fairly frequently.
    • Intermediate: Beginning to show the ability to discuss technical topics with non-technical stakeholders. Can fluently discuss topics with correct vocabulary. Developing pattern matching and simplification skills.
    • Advanced: Capable of fluently discussing technical topics with simplified and direct vocabulary. Organizes written communication for consumption by the intended audience. Expert pattern matcher but may over-simplify and miss details.
    • Expert: Able to discuss technology with the broadest range of stakeholders from the form of simplified executive presentations to in-depth debates with solution architects on the details of tool selection. Passively builds knowledge and insight in more junior team members.

Core Software Skills

  • Data Structures
    • Beginner: Understands simple control flow and some basic collections. May fit incorrect but familiar data structures to far too many problems.
    • Advanced Beginner: Understands most control flow and collections. Can sometimes tell when an algorithm can be improved but probably won’t know how. Follows established patterns but cannot chart a new course.
    • Intermediate: Can optimize advanced beginner code call out reasons for performance deficiencies and understands the basics of how data access and networking calls can affect performance.
    • Advanced: Strong understanding of data structures and rarely makes degenerative code mistakes. Intimately understands data access and network calls. Knows hot spots where technical debt lives and must be addressed at a solution level.
    • Expert: Can implement high-tier algorithms with maximum performance. Understands how to build rube-goldberg/code golf structures - and uses this knowledge to avoid them at all costs. Strong understanding of popular and valuable design patterns.
  • Style and Semantics
    • Beginner: Methods are typically too large with verbose or otherwise unuseful names. Can imitate patterns or styles but often incorrectly.
    • Advanced Beginner: Will think about how to solve a problem generically before worrying about syntax. Will ask naive but still-useful questions. Will require reinforcement to follow established patterns.
    • Intermediate: Uses inoffensive function and variable names as a rule. Has developed opinions about coding styles and languages and can speak about their background. Highly complex code may still need a heavy hand from Advanced or Expert developers to make it beautiful.
    • Advanced: Has a knack for using agreeable function and variable names that other developers use without complaint. Deviates from style when appropriate but is an advocate for shared approaches. Capable of implementing complex code and explaining it to another developer for validation.
    • Expert: Consistently drives high-level vision for style with high team buy-in. Influences entire codebases while writing a subset of the code. Accepts feedback and follows along when joining a new team with mature practices - even if those practices don’t match the Developer’s own.
  • General
    • Beginner: Can implement greedy solutions to algorithm problems but misses corner cases. No/ low understanding of unit testing. Only familiar with a small number of frameworks some only by name.
    • Advanced Beginner: Can implement basic solutions that may not be optimal and catch simple corner cases. Will build tests if assigned but needs strong patterns to build off of. Strongly familiar with at least one framework.
    • Intermediate: Implements medium complexity functionality after a team discussion and can be trusted with complexity given enough detail from Senior team members. Code is generally complete and can be trusted with both unit and “Dev Testing” tasks.
    • Advanced: May be the first boots on the ground for a new feature creating scaffolds for intermediate developer s to follow. Understands the frameworks in use across the entire stack and has dabbled enough outside of the toolset to know what’s good and what’s not. Has a plan for how to improve whatever the team’s next project is.
    • Expert: Can organize and design critical-path features for the organization / project and its users. Has a wide variety of experience outside of a project’s selected toolset and understands the life-and-hype cycle of new frameworks at a deep level. Has a plan to make sure the entire team’s skills will be used to their maximum potential for the next project even if it doesn’t build their resume quite as much.

Infrastructure

  • Source Control and Application Lifecycle Management
    • Beginner: Can clone a git repository but unfamiliar with branching and little or no knowledge of keeping work tracking organized.
    • Advanced Beginner: Understands branching strategies but generally just for a single team. Can follow strong work tracking practices when provided.
    • Intermediate: Understands branching strategies from a couple of teams and approaches and can provide pros and cons. Understands work tracking and adheres to standards. Able to provide good feedback and opinions for improving team processes.
    • Advanced: Knows the pros and cons of multiple branching strategies but may still try and force an inappropriate one on a certain product. Understands work tracking systems and how to passively communicate with the organization / project through them. An advocate for improved process.
    • Expert: Capable of creating a cohesive branching strategy that serves the need of both the development team and users. Enhances the ALM experience with rich tagging versioning and automated documentation generation. Can provide valuable and cross-team guidance on best practices.
  • Design and Deployment
    • Beginner: Will require significant help to set up a typical project. Little understanding of underlying hardware or the particulars of tool selection.
    • Advanced Beginner: Will encounter issues if the “happy path” of environment setup hits a snag. Will not understand environment progression or the details of how components fit together.
    • Intermediate: Can use well-developed Google-Fu to sort through issues and environmental differences. Understands environment progression for lower environments and has optimized their setup for debugging.
    • Advanced: Has set up instructions for projects and knows common pitfalls. May be familiar with containers. Capable of designing simple DevOps pipelines and fully understands environment progression for product(s) they work on.
    • Expert: Understands almost every aspect of the infrastructure required for a solution and has optimized them for performance and simplicity. Can author rich DevOps pipelines even if their knowledge may not match a dedicated professional.

Sijin Joseph Programmer Competency Matrix

Computer Science

  • Data structures
    • Level 0: Doesn’t know the difference between Array and LinkedList
    • Level 1: Able to explain and use Arrays, LinkedLists, Dictionaries etc in practical programming tasks
    • Level 2: 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.
    • Level 3: Knowledge of advanced data structures like B-trees, binomial and fibonacci heaps, AVL/Red Black trees, Splay Trees, Skip Lists, tries etc.
  • Algorithms
    • Level 0: Unable to find the average of numbers in an array (It’s hard to believe but I’ve interviewed such candidates)
    • Level 1: Basic sorting, searching and data structure traversal and retrieval algorithms
    • Level 2: Tree, Graph, simple greedy and divide and conquer algorithms, is able to understand the relevance of the levels of this matrix.
    • Level 3: 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.
  • Systems programming
    • Level 0: Doesn’t know what a compiler, linker or interpreter is
    • Level 1: 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.
    • Level 2: 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.
    • Level 3: 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…

Software Engineering

  • Source code version control
    • Level 0: Folder backups by date
    • Level 1: VSS and beginning CVS/SVN user
    • Level 2: Proficient in using CVS and SVN features. Knows how to branch and merge, use patches setup repository properties etc.
    • Level 3: Knowledge of distributed VCS systems. Has tried out Bzr/Mercurial/Darcs/Git
  • Build automation
    • Level 0: Only knows how to build from IDE
    • Level 1: Knows how to build the system from the command line
    • Level 2: Can setup a script to build the basic system
    • Level 3: Can setup a script to build the system and also documentation, installers, generate release notes and tag the code in source control
  • Automated testing
    • Level 0: Thinks that all testing is the job of the tester
    • Level 1: Has written automated unit tests and comes up with good unit test cases for the code that is being written
    • Level 2: Has written code in TDD manner
    • Level 3: Understands and is able to setup automated functional, load/performance and UI tests

Programming

  • Problem decomposition
    • Level 0: Only straight line code with copy paste for reuse
    • Level 1: Able to break up problem into multiple functions
    • Level 2: Able to come up with reusable functions/objects that solve the overall problem
    • Level 3: 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
    • Level 0: Not able to think above the level of a single file/class
    • Level 1: Able to break up problem space and design solution as long as it is within the same platform/technology
    • Level 2: Able to design systems that span multiple technologies/platforms.
    • Level 3: 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
    • Level 0: Cannot express thoughts/ideas to peers. Poor spelling and grammar.
    • Level 1: Peers can understand what is being said. Good spelling and grammar.
    • Level 2: Is able to effectively communicate with peers
    • Level 3: Able to understand and communicate thoughts/design/ideas/specs in a unambiguous manner and adjusts communication as per the context
  • Code organization within a file
    • Level 0: No evidence of organization within a file
    • Level 1: Methods are grouped logically or by accessibility
    • Level 2: Code is grouped into regions and well commented with references to other source files
    • Level 3: File has license header, summary, well commented, consistent white space usage. The file should look beautiful.
  • Code organization across files
    • Level 0: No thought given to organizing code across files
    • Level 1: Related files are grouped into a folder
    • Level 2: Each physical file has a unique purpose, for e.g. one class definition, one feature implementation etc.
    • Level 3: Code organization at a physical level closely matches design and looking at file names and folder distribution provides insights into design
  • Source tree organization
    • Level 0: Everything in one folder
    • Level 1: Basic separation of code into logical folders.
    • Level 2: No circular dependencies, binaries, libs, docs, builds, third-party code all organized into appropriate folders
    • Level 3: Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system.
  • Code readability
    • Level 0: Mono-syllable names
    • Level 1: Good names for files, variables classes, methods etc.
    • Level 2: No long functions, comments explaining unusual code, bug fixes, code assumptions
    • Level 3: Code assumptions are verified using asserts, code flows naturally – no deep nesting of conditionals or methods
  • Defensive coding
    • Level 0: Doesn’t understand the concept
    • Level 1: Checks all arguments and asserts critical assumptions in code
    • Level 2: Makes sure to check return values and check for exceptions around code that can fail.
    • Level 3: Has a library to help with defensive coding, writes unit tests that simulate faults
  • Error handling
    • Level 0: Only codes the happy case
    • Level 1: Basic error handling around code that can throw exceptions/generate errors
    • Level 2: Ensures that error/exceptions leave program in good state, resources, connections and memory is all cleaned up properly
    • Level 3: 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
    • Level 0: Mostly uses IDE for text editing
    • Level 1: Knows their way around the interface, able to effectively use the IDE using menus.
    • Level 2: Knows keyboard shortcuts for most used operations.
    • Level 3: Has written custom macros
  • API
    • Level 0: Needs to look up the documentation frequently
    • Level 1: Has the most frequently used APIs in memory
    • Level 2: Vast and In-depth knowledge of the API
    • Level 3: Has written libraries that sit on top of the API to simplify frequently used tasks and to fill in gaps in the API
  • Frameworks
    • Level 0: Has not used any framework outside of the core platform
    • Level 1: Has heard about but not used the popular frameworks available for the platform.
    • Level 2: Has used more than one framework in a professional capacity and is well-versed with the idioms of the frameworks.
    • Level 3: Author of framework
  • Requirements
    • Level 0: Takes the given requirements and codes to spec
    • Level 1: Come up with questions regarding missed cases in the spec
    • Level 2: Understand complete picture and come up with entire areas that need to be speced
    • Level 3: Able to suggest better alternatives and flows to given requirements based on experience
  • Scripting
    • Level 0: No knowledge of scripting tools
    • Level 1: Batch files/shell scripts
    • Level 2: Perl/Python/Ruby/VBScript/Powershell
    • Level 3: Has written and published reusable code
  • Database
    • Level 0: Thinks that Excel is a database
    • Level 1: Knows basic database concepts, normalization, ACID, transactions and can write simple selects
    • Level 2: 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.
    • Level 3: 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

  • Languages with professional experience
    • Level 0: Imperative or Object Oriented
    • Level 1: Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types
    • Level 2: Functional, added bonus if they understand lazy evaluation, currying, continuations
    • Level 3: Concurrent (Erlang, Oz) and Logic (Prolog)
  • Platforms with professional experience
    • Level 0: 1
    • Level 1: 2-3
    • Level 2: 4-5
    • Level 3: 6+
  • Years of professional experience
    • Level 0: 1
    • Level 1: 2-5
    • Level 2: 6-9
    • Level 3: 10+
  • Domain knowledge
    • Level 0: No knowledge of the domain.
    • Level 1: Has worked on at least one product in the domain.
    • Level 2: Has worked on multiple products in the same domain.
    • Level 3: Domain expert. Has designed and implemented several products/solutions in the domain. Well versed with standard terms, protocols used in the domain.

Knowledge

  • Tool knowledge
    • Level 0: Limited to primary IDE (VS.Net, Eclipse etc.)
    • Level 1: Knows about some alternatives to popular and standard tools.
    • Level 2: 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.
    • Level 3: Has actually written tools and scripts, added bonus if they’ve been published.
  • Languages exposed to
    • Level 0: Imperative or Object Oriented
    • Level 1: Imperative, Object-Oriented and declarative (SQL), added bonus if they understand static vs dynamic typing, weak vs strong typing and static inferred types
    • Level 2: Functional, added bonus if they understand lazy evaluation, currying, continuations
    • Level 3: Concurrent (Erlang, Oz) and Logic (Prolog)
  • Codebase knowledge
    • Level 0: Has never looked at the codebase
    • Level 1: Basic knowledge of the code layout and how to build the system
    • Level 2: Good working knowledge of code base, has implemented several bug fixes and maybe some small features.
    • Level 3: 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
    • Level 0: Has not heard of the upcoming technologies
    • Level 1: Has heard of upcoming technologies in the field
    • Level 2: Has downloaded the alpha preview/CTP/beta and read some articles/manuals
    • Level 3: Has played with the previews and has actually built something with it and as a bonus shared that with everyone else
  • Platform internals
    • Level 0: Zero knowledge of platform internals
    • Level 1: Has basic knowledge of how the platform works internally
    • Level 2: Deep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code.
    • Level 3: Has written tools to enhance or provide information on platform internals. For e.g. disassemblers, decompilers, debuggers etc.
  • Books
    • Level 0: Unleashed series, 21 days series, 24 hour series, dummies series…
    • Level 1: Code Complete, Don’t Make me Think, Mastering Regular Expressions
    • Level 2: Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month
    • Level 3: 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
    • Level 0: Has heard of them but never got the time.
    • Level 1: Reads tech/programming/software engineering blogs and listens to podcasts regularly.
    • Level 2: Maintains a link blog with some collection of useful articles and tools that he/she has collected
    • Level 3: Maintains a blog in which personal insights and thoughts on programming are shared

Bradford Fults

Software Engineer Leveling Matrix

Software Design & Implementation

  • Quality
    • L1
      • Writes consistently good and maintainable code, and needs little syntax/convention feedback.
      • Consumes documentation and only asks teammates when documentation and effort don’t yield results; produces basic documentation.
      • Understands the basics of writing automated unit & functional tests.
      • Consistently authors good test cases and achieves good test coverage with the help of their team.
      • Writes most code without obvious bugs; knows how to avoid common problems.
    • L2
      • Writes consistently great code requiring no syntax/convention feedback.
      • Often adds new and relevant documentation to existing repositories of knowledge.
    • L3
      • Understands the organizational value of great documentation and spends time to maintain, update and extend existing repositories of knowledge.
      • Advises the rest of the team on quality of code, tests & documentation.
      • Identifies & pragmatically applies better code practices or tooling.
    • L4
      • Creates & structures documentation for large code projects concisely & consistently.
      • Advises their team and other teams on best practices for code, test & documentation quality.
    • L5
      • Considers (and proposes, when appropriate) new programming language & platform choices for the organization.
      • Leads efforts to improve documentation & code skills sharing across teams.
      • Makes the organization more effective through smart & pragmatic application of non-cutting-edge but useful code tools & patterns.
  • Architecture
    • L1
      • Some architectural design/approach feedback may be necessary, but understands and applies feedback consistently.
      • Is comfortable with the basics of code interface design; is learning to be more intentional.
      • Understands and can usually recognize technical debt; can pay it down when advised.
      • Has some experience with data formats, performance & locality; is learning quickly.
    • L2
      • Strong architectural design & approach experience; only the most complex designs refined with senior teammates.
      • Good intuition for code interface design; looks for opportunities to learn from other projects & teams.
      • Understands and consistently recognizes technical debt; looks for opportunities to negotiate and pay it down incrementally, sometimes with prompting.
      • Much more comfortable with multiple data formats & their tradeoffs; can anticipate most performance issues and make use of existing patterns to solve them.
    • L3
      • Deep architectural & design pattern experience; consults for teammates on more difficult designs, and sets up new projects to ensure architectural success.
      • Understands and plans with technical debt in mind; negotiates to pay it down incrementally and consistently, advises and prompts other teammates on technical debt.
      • Can solve nearly all performance and data issues within the context of their team by applying experience & knowledge sharing.
    • L4
      • Works with Architecture team regularly to define & refine cross-team architectural approaches with extensive experience & sharing.
      • Understands technical debt as a long-term budgeting and risk management tool; articulates when to incur more and when to pay it down.
      • Guides organizational adoption of new data formats, data stores, and patterns for performance & data locality; consults regularly across teams on similar issues.
      • Sometimes employs prototyping for exploration of designs.
    • L5
      • Succeeds by introducing simpler and time-tested approaches to technical problems to several teams.
      • Fuses organizational strategy with technical architecture, including cross-team design & code sharing.
      • Uses prototyping as a primary tool for rigorous design exploration.
  • Running Systems
    • L1
      • Uses out-of-the-box tools to instrument and monitor systems; works well with the monitoring philosophy espoused by their team.
      • Can do basic code profiling alone and optimize obvious offenders.
      • Understands the basics of failsafe design; can implement with minimal prompting.
      • Has some comfort working with live production systems, but may rely on teammates before taking actions.
    • L2
      • Customizes out-of-the-box tools, may create small custom tools to instrument and monitor systems.
      • Helps tune and change the monitoring philosophy on their team.
      • Can do multi-application and multi-layer profiling alone and optimize almost all offenders.
      • Strong understanding of failsafe design and regularly implements and occasionally mentors others on it.
      • Unqualified comfort working with live production systems, debugging issues and taking careful actions with protections against destruction.
    • L3
      • Creates new tools when necessary (and avoids doing so when not) to instrument and monitor systems; defines, realigns and understands cross-functional and cross-org implications of team’s monitoring philosophy.
      • Acts as a primary mentor on running systems for the rest of their team.
    • L4
      • Can solve any profiling challenge at any layer of the stack, down to bits on disk/in RAM and up to multi-region clusters of data.
      • Seeks out running systems mentorship opportunities across teams.

Team Collaboration & Advice

  • Project & Team Scope
    • L1
      • Is a member of one or two small or medium projects at a time.
      • Works mostly with their own team.
    • L2
      • Usually leads one or two medium or large projects at a time.
      • Recognized for occasional participation in cross-team relationships and projects.
    • L3
      • Acts as an ambassador and proactive connector for their team with other teams.
      • Usually leads at least one major project and sometimes several medium projects on their team.
      • Sometimes leads cross-team projects and plays a significant role in major organizational initiatives.
      • Relied upon to keep complex projects on-track and sustainably implemented.
    • L4
      • Works between and across teams almost as much as with their own.
      • Participates in major projects and initiatives within and between teams, including working groups.
      • Sometimes called in to mitigate large risks or solve tricky problems.
    • L5
      • Significant contributor to Architecture team and leader of working group efforts across the organization.
    • L6
      • Consults on numerous medium & large projects across the organization & actively connects different teams & systems.
      • Leads major strategic technical initiatives across many or all teams.
  • Technical Collaboration
    • L1
      • Communicates accurately about all technical subjects in their work—both speaking/writing and listening/understanding; spends more time learning than explaining.
      • Can disagree and understand disagreement constructively and non-defensively.
      • Fully embraces team solutions and commits to delivery without issue.
    • L2
      • Leads technical explanations when appropriate; knows when to listen and give space to teammates.
      • Approaches disagreement with inquisitiveness, empathy and the goal of a stronger solution; models this behavior for teammates; consistently disarms conflict.
      • Guides team toward a decision, clarifies and gets buy-in, and holds self & teammates accountable for decision.
    • L3
      • Facilitates technical discussions between teammates; has deep familiarity with technical topics under discussion at all levels.
    • L4
      • Proactively seeks out gaps in technical understanding, especially cross-functional, and works with a variety of teammates to fill the gaps.
  • Communication & Empathy
    • L1
      • Communicates concisely, effectively & clearly.
      • May sometimes need minimal coaching on communication skills, but overall a strong speaker and listener.
    • L2
      • Coaching on communication skills is rare and exceptional; very strong speaker and listener.
      • Can usually explain technical subjects to non-technical teammates.
    • L3
      • Can explain deeply technical subjects to non-technical teammates with ease.
    • L5
      • Often takes the lead to communicate technical topics to technical & non-technical directors and business leaders.

Ownership & Accountability

  • Productivity, Time & Task Management
    • L1
      • Accomplishes tasks within an acceptable time frame.
      • Can estimate work tasks with help from teammates & manager.
      • Understands & acts in accordance with given priority of work tasks.
      • Consistently delivers work tasks based on prior commitments and task definition to fulfill the specification of work.
    • L2
      • Maintains a strongly consistent personal velocity of work tasks.
      • Estimates work tasks accurately in most cases, with minimal oversight.
      • Understands, negotiates & applies work priorities correctly.
      • Knows when to conclude conversations, meetings, and pre-work tasks in order to complete work on time.
      • Accomplishes nearly all work tasks in a timely manner; and raises an alarm early when tasks are off schedule.
      • Thoroughly vets work requirements and helps refine them to fulfill the intent of the requirements.
    • L3
      • Leverages own abilities and practices to mentor and improve the productivity of the entire team.
    • L4
      • Successfully manages cross-team commitments and work completion.
      • Improves productivity of teammates across multiple teams.
  • Project Accountability
    • L1
      • Avoids surprising stakeholders whenever project expectations change; communicates changes early and often.
      • Consistently communicates with project stakeholders about expectations.
    • L2
      • Proactively finds gaps in project plans and works with stakeholders to specify them.
      • Effectively communicates project status and expectation changes without prompting.
      • May occasionally help teammates overcome obstacles and complete project work.
    • L3
      • Consistently helps teammates overcome obstacles and complete project work.
    • L4
      • Enables and improves cross-team collaboration by helping individual teammates and working with stakeholders.
    • L5
      • Works with organizational leaders to improve project accountability across many or all teams.
  • Production Support
    • L1
      • Participates in team on-call or escalation procedures and can resolve basic issues.
      • Communicates effectively to team about production issues.
      • Escalates issues appropriately.
      • Takes good notes about production issues.
      • Participates in follow-up retrospectives and completes assigned work as requested.
    • L2
      • Can comfortably and effectively resolve issues outside of their immediate scope of experience.
      • Proactively identifies risks for production issues and works with stakeholders to resolve.
    • L3
      • Leads definition & refinement of team on-call or escalation procedures.
      • Can resolve nearly all issues escalated within their team.
      • Communicates about production issues effectively with public & leadership.
      • Acts as primary owner of production issues and thoroughly oversees them to completion.
      • Leads RCAs, definition & assignment of follow-up work.
  • Autonomy & Self-Starting
    • L1
      • Dives into new projects & technologies with curiosity and a drive to understand.
      • Maintains a healthy amount of urgency and consistency in their work.
      • Makes effective use of existing documentation, examples and other resources to gain a solid understanding before relying on teammates.
      • Knows how to ask good questions of their teammates and does so after trying options on their own.
      • Has awareness of rabbit holes and doesn’t burn too much time on their own before consulting teammates.
    • L2
      • Gains adequate understanding of projects that lack good documentation or usage examples through systematic learning, triage and discussions.
      • Contributes knowledge back to projects to enable self-starting of other teammates.
      • Very rarely falls down rabbit holes.
    • L3
      • Achieves expert-level knowledge of new systems & technologies through rigorous learning, curious testing and prior experience.
      • Takes primary responsibility for improving projects to enable self-starting by other teammates.
      • Avoids rabbit holes through self-discipline, awareness and resourcefulness.

Brand & Relationships

  • Product & Business Team Relationships
    • L1
      • Understands how product & business teams adjacent to theirs operate.
      • Builds & maintains a friendly relationship and open channel of communication with product team counterparts.
    • L2
      • Works proactively with product counterparts to build strong relationships within and across teams.
      • Knows and understands business stakeholders’ motivations as it affects their team.
    • L3
      • Takes primary responsibility for relationships with product & business stakeholders within and across teams to better plan for and position their own team.
      • Thinks about inter-team relationships strategically and work constantly to improve them.
    • L4
      • Establishes strong relationships with product and business stakeholders across the organization to facilitate their own cross-team scope.
  • Engineering Team Relationships
    • L1
      • Understands team & organizational engineering strategy and how they apply to their role & team.
      • Works to represent self & team positively within the organization.
      • May seek out relationships with engineering leaders for mentorship or broader context.
    • L2
      • Informs team engineering strategy by working with their manager.
      • Actively participates in execution and some planning of organizational engineering strategy.
      • Seeks out relationships with engineering leaders to build understanding of organizational strategy.
    • L3
      • Decides & collaborates on team engineering strategy with manager & teammates.
      • Sometimes involves self in organizational engineering strategy.
      • Seeks to build strong relationships with engineering leaders across the organization.
    • L4
      • Effective relationship builder throughout the engineering organization.
      • Often involved in strategic organizational plans.
    • L5
      • Very effective relationship builder among most or all engineering leaders, regardless of function or relative team relationship.
      • Proactively involved in and often leads strategic organizational decisions and plans.
    • L6
      • Unquestionably strong relationships with all engineering leaders in the organization.
      • Represents role model strategic engineering values and expertise.
      • Creates & effectively manages many organizational strategy plans.
  • External Representation
    • L1
      • Always represents self, team & company positively to external audiences.
      • Thinks about how external communication affects the brand and plans accordingly, sometimes with help from teammates or leaders.
      • Not generally expected, but certainly encouraged to represent company & team externally (e.g. blog posts, meetup group talks, conference speaking).
    • L2
      • Might be more proactive in seeking out external representation opportunities.
      • Contributes some external blog posts.
    • L3
      • Contributes & solicits blog post opportunities from teammates.
    • L4
      • Consistently represents self, team & company through excellent blog posts.
      • Sometimes represents self, team & company with external speaking engagements.
    • L5
      • Consistently represents self, team & company with external speaking engagements.
      • May participate in industry working groups on behalf of company.
    • L6
      • Acts as primary contact for any relevant industry working groups to represent company.
      • Known among some industry groups for reputation at company.
    • L7
      • Well-known among industry groups for reputation at company.
      • Regularly cited & invited as an expert within industry conferences for expertise relevant to company.

Innovation

  • Contributing to Product Enhancements
    • L1
      • Understands drivers behind product roadmap items as it affects their team.
    • L2
      • Sometimes participates in roadmap feedback with product team.
      • Looks for opportunities to simplify product & technical design.
    • L3
      • Regularly participates in the creation of the team roadmap & ensuing feedback.
      • Builds a reputation for simplifying product & technical design through proactive conversations.
    • L4
      • Often helps refine roadmaps across teams based on technical strategy & constraints.
      • Helps to define & create new product abilities by changing technical strategy or constraints.
    • L5
      • Proactively seeks to create or redefine roadmaps with product & business counterparts.
    • L6
      • Widely respected for important contributions to product roadmaps across the organization.
  • Driving Efficiency of Systems & Practices
    • L1
      • Takes responsibility for customer-impacting performance of systems on which they work.
      • Sometimes thinks about team practices; may suggest improvements to team or manager.
    • L2
      • Seeks to understand and vet performance characteristics of new and old systems; shares methods & knowledge.
      • Regularly observes team practices & processes and suggests improvements to team or manager.
    • L3
      • Consistently pursues improvements to performance, starting with the impact to customers.
      • Thinks critically about team practices & processes and regularly discusses improvements with leads & manager.
      • Observes organizational practices & processes and sometimes collaborates across teams to improve them.
    • L4
      • Applies cross-team experience to provide consistent and replicable performance improvements for customers.
      • Regularly discusses, tweaks and seeks feedback on organizational practices & processes.
    • L5
      • Takes ownership & responsibility for organizational practices & processes and their continuous improvement.
  • Collaborating on Patents
    • L1
      • Understands company patent strategy and may surface patent opportunities to team & manager.
      • Collaborates on patent applications if asked.
      • Understands outside patent clearance guidelines before writing new software.
    • L2
      • Often thinks about and surfaces patent opportunities to team & manager.
    • L3
      • Regularly surfaces patent opportunities & risks to manager & Patents team.
    • L4
      • Surfaces cross-team patent opportunities & risks to Patents team.
      • Ensures participation from team members in idea disclosure and review processes.
      • Works with Patents team to find ways to accomplish goals with minimized risk with respect to outside patents.
      • Works with Patents team to ensure company protectable subject matter is identified during collaborations with third parties.

Vision

  • Technical Strategy Mapping
    • L1
      • Articulates a coherent future vision for a component or components that they own within a larger system.
    • L2
      • Articulates a coherent future vision for whole systems and several components for which they have responsibility.
    • L3
      • Articulates a coherent future vision for many systems tended by their team.
      • Often assists teammates with building and articulating visions for their responsibility areas.
    • L4
      • Articulates a coherent future vision for systems that span teams, or many systems across teams.
      • Helps define the model of what good & appropriate technical visions comprise.
    • L6
      • Takes primary responsibility for building & articulating organization-level technical visions.
      • Owns the definition & communication of models describing good technical visions.

Integrity & Ethics

  • Fiscal Responsibility
    • L1
      • Spends carefully and only when it’s in service of team & company goals.
      • Ensures timely & accurate accounting of all business expenses.
      • Understands relevant financial drivers behind projects or business initiatives.
    • L2
      • Seeks out and understands overall cost impact of components for which they have responsibility.
    • L3
      • Proactively takes responsibility for cost management of team-owned systems & resources.
      • Looks for opportunities to increase cost efficiency of team-owned systems & resources.
  • Privacy & Security
    • L1
      • Understands basic security & privacy principles; always applies them to daily work.
      • Understands the importance & gravity of handling user data and does so responsibly without exception.
      • Immediately reports privacy or security concerns to manager or Privacy/Security teams.
    • L3
      • Works proactively with Privacy & Security teams to help refine technical strategy based on those constraints.
  • Honesty & Accuracy
    • L1
      • Understands and always tries to give consistent and honest work estimates.
      • Usually understands the limitations of their own knowledge and retains humility about their experiences.
    • L2
      • Almost always understands the limitations of their own knowledge and retains humility about their experiences.
    • L3
      • Always understands the limitations of their own knowledge and retains humility about their experiences.
      • Encourages humility in others through coaching.

Leadership

  • Mentorship & Guidance
    • L1
      • Knows when to seek out mentorship to grow their own experience.
    • L2
      • Sometimes mentors teammates one-on-one with or without prompting.
      • Always treats mentored teammates with respect and kindness, regardless of their experience.
    • L3
      • Proactively mentors teammates one-on-one without prompting.
      • Seeks out opportunities to train other teammates with their knowledge & skills to create team redundancy and backfill ability.
    • L4
      • Often mentors teammates across teams based on experience & expertise.
      • Takes full responsibility for their own succession on their team, including planning, coaching, mentorship & training.
    • L5
      • Serves as a role model for mentorship within the engineering organization.
      • Proactively seeks out mentoring relationships.
      • Helps improve mentors.
  • Broadcasting & Knowledge Sharing
    • L1
      • Feels comfortable explaining technical subjects to their own team.
      • May broadcast to broader engineering groups through Tech Talks or the company technical blog.
    • L2
      • Feels comfortable explaining technical subjects and receiving feedback across teams, whether formally (Tech Talks) or informally.
      • Contributes to the company technical blog on a regular basis.
      • May seek out speaking opportunities at local user groups or conferences.
    • L3
      • Likely seeks out speaking opportunities at local user groups or conferences.
    • L5
      • Habitually seeks out opportunities to share pragmatic experience and expert knowledge with teammates and external engineers via Tech Talks, local user groups and conference speaking engagements.
    • L6
      • May speak externally on cross-functional topics to more diverse non-technical audiences.
  • Influence & Alignment
    • L1
      • Can persuade some direct teammates based on the merits of a technical approach.
      • Makes well-informed technical decisions with all or nearly all of the information required.
    • L2
      • Balanced with good listening, can persuade their entire team of particular tactical approaches to problems.
    • L3
      • Regularly achieves strong alignment with their own team.
      • Sometimes persuades other team leads of a new approach based on sound tactical or strategic reasoning.
    • L4
      • Regularly influences multiple teams to align around a cross-team goal.
      • Can deal with some information ambiguity in decision making, but may make most decisions based on solid evidence.
    • L5
      • Consistently works at a strategic level, influencing technical & non-technical decisions to achieve cross-team alignment on major near-term goals.
    • L6
      • Successfully shapes organizational strategy with long-term considerations from technical architecture.
      • Can persuade teammates at a tactical level with a lot of information, or the entire organization with limited information and sound, relevant experience.
    • L7
      • Strongest technical influencers in the organization, with widely held respect and very forward-thinking plans.

What mistakes do you commonly see novices make in software design?

I had an informal expertise extraction conversation yesterday, with a senior software engineer I respect. The preliminary takeaway for software design expertise is that experts attempt to predict the direction of change for their software requirements, and design accordingly.

They do this intuitively. By feel. So the expert novice difference here is that experts get it right more than they get it wrong. And one measure this engineer gave me is: if their commits on a new feature are all green, not yellow, it means they predicted correctly.

(The implication being that the initial structure was the right one, and the changes in the requirements fit into the design, without too much restructuring.) My god. This explains a LOT of what I’ve seen.

Of course, the main caveat here (again, from the engineer), is that below a certain level of skill, novices don’t realise that the initial structure they chose was wrong, and would keep patching the mistaken design. That is, the green-yellow heuristic is just a heuristic.

“Look, everything is a tradeoff, right? And if you design your code this way, it becomes harder to change that way. (Illustrates) So the question is, can you make the right tradeoffs? The senior engineer is aware of the tradeoffs. The novice engineers can’t even see them.”

“The junior engineer just thinks about the low level implementation details. They don’t even realise that the hard bit is when you uncover new information and the design or requirements change. The senior is always thinking about where the change is mostly likely to come from.”

You know, this explains a whole bunch of behaviours I’ve seen. (Speculating here, this is not part of the extraction):

  • I’ve noticed senior coders tend to spike by doing throwaway prototypes.
  • They also tend to start on a brand new feature by writing everything in one file.

I used to think they spiked prototypes to quickly generate information about the feature. But now I wonder if they’re also looking for ‘direction of change’.

And writing everything in one file, with hard coded variables and very little structure makes sense if you have high uncertainty about a new feature: the best structure to use when you don’t know where the change is going to come from is to have no initial structure at all.

(And of course keeping everything in one file makes the cognitive overhead really low, which means the inevitable restructuring — once the engineer knows where change is coming from/what tradeoffs to pick — is easier to do).

— Cedric Chin

choosing wrong or inappropriate abstractions, not encapsulating design decisions, and designing for data dependencies over functional dependencies.

Books

  • 1979 Edward Yourdon, Larry L. Constantine: Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
  • 2008 Donella H. Meadows: Thinking in Systems
  • 2021 Mark Richards, Benjamin Lange, Neal Ford: Fundamentals of Software Architecture: An Engineering Approach
  • 2023 Kent Beck: Tidy First?

Resource References

Article References