Thursday, February 3, 2022

Mature vs Immature Developers



As a manager, I frequently consider impact, results, peer feedback, artifacts, and other direct, objective information about developers when analyzing their performance.  There is a dimension of seniority that is not easily summarized by these objective measures -- maturity.  I usually summarize observable, behavioral differences by saying things like "the senior developer comes into code you wrote, cleans it up, adds documentation, and fixes your bugs for you; the junior developer files bugs without reading your code and asks you to add capabilities or features that violate the purpose of your design."  But what are the abstract elements and signs of maturity?

My friend recently blogged about an article he came across and generalized that non-developers also display these abstract signs of maturity or immaturity.  I could not agree more.


2 comments:

Anonymous said...

And how much it corelate with productivity? ;)
How much using tools and methodologies can mitigate it?
And other such questions,
if only you'd be interested to answer em as an expert.

Mitchell Wyle said...

Performance, productivity, and the tools / systems that protect a team from catastrophes are very interesting topics and would require a much longer analysis & post. Thank you "Anonymous" for the suggestion. Here is a quick comment as a partial answer to your question: Just as Key Results don't always align to their intended Objective (OKRs), so also do individuals' Key Performance Indicators (KPIs), e.g. "productivity" align to a team's overall performance, e.g. velocity, or customer delight over time. Some people on a team are "force multipliers," making everyone else much better while contributing nominally, while others are workhorse loners, pounding out artifacts and work product that is not always aligned. One Human Performance approach in which I personally am certified is this model that does answer some facets of your question.