In Software Engineering The Numbers Do Mean Direction With Clarity

 

I came across a post where a person from community said, he is making 40 PRs a day.  Further, he said, the long standing architects there could not keep up with that pace.  It sounds impressive to one listening it.

Wait!  This put me into a thought.

I'm writing 100+ test cases and executing the 100+ test cases reading line by line.  How should I consider and interpret this?  How do my reporting manager look at this and interpret my contribution and value add?  Do I get the big hike and promotion in each cycle?

Why I say this?

• Making 40 PRs in a day is as good as writing 100+ test cases and executing it -- when the number is expected and rated.

In a day, what can one push in 40 PRs?  Is this in a same repository or to the different projects repositories?  I have no idea.  But, as a engineer, I have a concern when I see that number -- 40 PRs or 100+ test cases by a person.  What are the review guidelines?  Who is reviewing it?  What is evaluated in the review before the merge is approved?

Engineering Manager, Numbers And Direction With Clarity

While one is on a intended direction with clarity the numbers make a better story.  If not, can it still make a story what is expected?

As an engineer, I see the numbers in everything and whatever I do.  The numbers help to represent, describe and communicate.

When the focus is on the numbers, it does not mean one is having the clarity.  

For example, I'm executing 50 test cases and 100+ in an automation run.  Does the organization, business and my peer programmers get anything from this number?  Will it be counted in as my value addition and contribution?

If we engineers are evaluated on numbers, I have seen the engineers running with the spreadsheet, number of PRs, test cases, product stories, the tickets marked as 'done', instances created and orchestrated.  Isn't it?  Do you see this at your work?

Engineering and Numbers

I learn, when we engineer a solution the goal is to have the clarity on what we are going to do, why and how.

Having the clarity means removing the ambiguities and being aware of it.  This is a major part of the solving in an engineering.

When the clarity is established with no confusions it sets a direction.  This direction is important with a clarity; it tells where we are heading, why and how.

Implementation is one part of the big engineering.

Do numbers remove the direction and clarity?  If one is obsessed with numbers and biased to it, it can derail the efforts.

When we are biased and acknowledge one's voice and thought in an engineering, we are not solving.  We are setting an example of Factory Pattern which the software engineering is not all about.

Engineering Manager, Numbers, Clarity and Direction

I as an Engineering Manager, my primary goal will be to set the direction to team with clarity.  If I do no set a direction and why we want to accomplish it, the team and delivery will be in chaos.

If anyone in my team is behind the numbers for showing PRs, test cases and stories, I will assist them to build the clarity and see it.

I will help them in knowing what the management sees and how to show one's delivery as an impact in conversion and numbers.  

Why this impact conversion matter -- I will talk about it and help to visualize it.  I did not get this from my engineering managers.  It has costed me and the team though delivery went on time sprint on sprint and KPIs looked as set and expected.

A person making 40 PRs and 100+ test cases in a day, is a smoke which indicates something is not right!

To end here, here is the sum up

• The number of PRs in a day and test cases written and executed by a person looks impressive, but it is not a impact and conversion.
• Remove the ambiguities, establish the clarity, set the direction and evaluate it consistently.
• Software Engineering is not all about the numbers, PRs, stories, tests, instances, pipelines and orchestration.
• Engineering Manager is critical role in the Software Engineering -- this is a role which sets the direction to the development teams with clarity by resolving the ambiguities to deliver with the velocity.
• The management wanting the numbers and asking for it can mislead the effective and skilled Engineering Manager.
• This two not the same -- 'the numbers' and 'the conversion and impact'; these two are numbers with different stories.
• 40 PRs and 100+ tests by a person in a day does not mean she or he has clarity and direction.

In today's timeline of AI and LLM, it is the number of tokens.  Someone saying I used less number of token is a value add?

Then, what is clarity with direction in the Software Engineering?  What it is to your reporting manager?  What it is to the business and management who decides on your employment, hike, promotion, benefits and growth?

Ask your Engineering Manager.  It is not too late.