Jeremy Shipman

The Software Developer’s Maturity Graph

by Jeremy Shipman

My Hypothesis: If it is clear what a developer’s progression path to proficiency is, they will be able to achieve proficiency faster.

For me, this applies to growing personally as a developer, thinking about the growth of current staff, and defining what to look for when hiring new staff.

The “path” metaphor implies that someone is following a line toward a destination. Perhaps “tree” is a better metaphor, implying there is root/foundational knowledge to build on. The tree metaphor might fall down as concepts need to merge, suggesting a “directed graph”.

Development vs programming

Developer and programmer might be used interchangeably in some settings, but I’m preferring the term “developer”, assuming developers are for businesses, rather than programmers being purely for software.

Therefore, business knowledge needs to be an aspect of a developer’s maturity.

Framing some questions

For a developer like me, the question of growth could be framed in various ways:

  • Knowledge: What don’t I know?
    • How do I self-assess how good I am?
    • What should I focus on learning next?
  • Career progression: What are the various titles of a developers as they progress?
    • Novice/Intern, Junior/Associate, Intermediate, Senior, Principal/Chief, Head/Lead
      • How do competencies and skills vary between these titles?
      • How does this look different within different organisations?
        • Are these labels relative to the organisation? Or applicable across the industry?
  • Skills and competencies
    • What weight should be given to particular skill sets?
    • What is cultural / attitude vs actual developer-specific competency? Should that play into it?
  • What competencies apply to your chosen domain of work / your role at your organisation?
  • What competencies are more valuable than others?
  • What levels of experience matter in which areas?

A mental model of software development maturity

I’ve tried to create a mental model of software development areas that can be made known, time spent on, and depth of understanding grown in.

Obviously nobody can progress through ranks of software development, without having areas of expertise. Increased depth in more areas will set a developer up for pay rises, and or title changes.

Programming

  • Reading and comprehending code quickly.
  • Using a debugger, and other code tools.
  • Can self-sufficiently get from idea to production-ready code.
    • Can plan, write, run, build, deploy, and debug code self-sufficiently.
  • Multiple programming languages, their features, patterns, paradigms, and platforms.
    • Reading and writing, designing, maintaining/supporting.
  • Code organisation at multiple levels of granularity. Shows care for their craft.
  • Knows how to ensure quality with appropriate testing.
  • Knowledge of, and ability to apply existing patterns appropriately, rather than copy pasting and anti-patterns.
  • Able to look ahead to how things should be, and know or be able to find how to get there.
  • Frameworks and libraries. Can make a good choice, and use effectively.
  • Managing error cases appropriately.
  • Can refactor with confidence.
  • Performance - able to identify poor performance, and improve it.
  • Security - able to find, understand, and fix issues.

Tooling

  • Terminal / shell / command line scripting. Linux fu 🥋.
  • Version control - probably with Git
  • Code builds - can set up, optimise.
  • Integrated Development Environment (IDE) - can get the most out of it with shortcuts and features.
  • Automate away common problems. Linting & other checkers, consistent builds, CI / CD tooling….
  • Infrastructure setup, monitoring, and maintenance.

Problem solving, and communication

  • See problems from different perspectives.
  • Explain clearly why decisions have been made.
  • Have strong sense of the risks that come with decisions.
  • Can articulate any compromises made, and their trade-offs.
  • Explain short and long term implications of decisions.
  • Communicate clear reasoning behind decisions.

  • Ready to challenge and be challenged on ideas and assumptions.

  • Understand, and champion the software delivery methodology/framework in use.
  • Level of domain knowledge, including understanding of users.
    • The purpose of the software

Growth

  • Has undertaken and retained a decent amount of learning, whether formal or self-guided.
  • Draws knowledge from the top known developers, rather than just peers.
  • Learning by doing.

Knowledge in topical areas can be helpful:

  • Science, Technology, Engineering, Mathematics
  • Computer Science
    • Algorithms, and relevant understanding of performance/trade-offs
    • Artificial intelligence
    • Cryptography
    • Operating systems
    • Cloud platforms
    • Data Science
    • Embedded systems
    • Video Games
  • Application Development
    • Web, Desktop, and Mobile Apps
  • Electrical engineering

Teamwork

  • Knows how to negotiate concurrent work on the same codebase areas.
  • Generally performing work to help the customer or team, as opposed to self-centered reasons.
  • Good at shared problem solving.
  • Proactively sharing knowledge with the team for their benefit.

Professional Attitude

  • See the business reasoning for work, and negotiate that into a technical.
  • Is competent and active in helping others with issues / learning.
  • Championing technical improvement to the business.
  • Actively self-improving
  • Considerate, respectful
  • Working with integrity
  • Growth mindset

Specific to web development

Being my area of expertise

Experience

I’m suspicious about hearing “years of experience” as a measure of someone’s progress. It’s really about depth of understanding over those years, but yes, time is a real constraint to maturity, and some things simply take time.

The depth of understanding of, and likely time spent with:

  • The qualities of physical dependencies, such as: CPU, Memory, Disk, Networks, Inputs/Outputs.
  • Ability to work on software with people.
    • Self-sufficient, team-work, open-source contribution.
    • Work frameworks and tools
    • Leadership

Conclusion

The above is basically a brain dump to kick off to clarify my own understanding of what people can know. It doesn’t feel complete at this stage.

There’s still the question of what people need to know for their own workplace, or where they want to go in their careers. No journey will be the same. Some people may be more senior in some areas, but not others. Some areas are more important than others, and importance may change over time too.

This is why it seems more like a graph than a path. A bit like how our brains work.

Resources

© 2020 Jeremy Shipman.