For Recruiters
A surefire method for proving that your engineers are just code monkeys to you.

Lines of code: The best metric to prove you're a clueless exec

A few weeks ago, we published an article advocating the merits of lines of code as a productivity metric for software development after Elon Musk reportedly asked Twitter engineers to present him with their recent work. The response from software developers themselves was... less than stellar. With “a load of garbage” and “offensively stupid” being the tip of the iceberg. 

Although we understand that lines of code are sometimes used by some engineers at JPMorgan as a metric to measure productivity, the measure certainly isn't universally favoured in financial services. One senior trading floor engineer says it's more about the "problems that are solved," and the "work that's delivered in reasonable time."  Another senior engineer, now at JPM, says lines of code haven't been used to measure developers' productivity "since the 1980s." Right. 🥴

The problem, says Bryan Finster, a distinguished engineer working in the defense industry, is that there simply is “no viable individual productivity measure” on an individual basis. 

Finster says lines of code are a particularly egregious example as it suggests companies view their engineers as “typers, rather than engineers,” focusing solely on quantity of output with no thought towards its context. They see as “replaceable cogs” because “code is code is code,” no matter who types it. 

Finster notes that “people will always work to and optimize the thing they are measured by,” and in the case of lines of code, this can actively harm productivity.  

Traditionally, “senior engineers are leading the direction rather than pounding out code” and so will have comparatively lower numbers to less experienced recruits. If LOC were to be used, those senior engineers would dedicate less time to giving direction to a project or helping greener developers improve and instead just type without an implicit goal. 

In fact, churning out lines of code can indicate a lack of productivity. Finster suggests that if there's one high performer in a group of low performers, it suggests they “don’t interact well with the team and can cause internal friction.” Finster says “leadership and involvement with people rather than making decisions is more important” than just writing more code for an engineer in that situation. 

This doesn't mean LOC are entirely redundant. Another JPMorgan VP says he looks at Jira tickets closed, lines of code and code commits per engineer, but that they're not used to track people. - They're only really used to identify serious underperformers. 

The metrics that are truly effective are less determinative. Finster advises asking questions like “are we delivering what the end user needs in the most efficient way?”  One banking engineer says the best measures are subjective and take into consideration the technical difficulty of a project. However, this exposes engineers to managers' biases. 

Really, there's no perfect way of measuring developers' productivity. But if you have suggestions we'd like to know in the comments box below. 

Click here to create a profile on eFinancialCareers. Comment ANONYMOUSLY on articles and make yourself visible to recruiters hiring for top jobs in technology and finance. 

Have a confidential story, tip, or comment you’d like to share? Contact: in the first instance. 

Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)

Photo credit: eFinancialCareers/Dall-e


AUTHORAlex McMurray
  • Ma
    24 November 2022

    Are story points not a better measure of productivity than tickets closed and lines of code? Do we NEED to track people's productivity at all?

  • co
    24 November 2022

    Number of lines could be used to determine if someone did some work, but not the quality or effectiveness. A better metric would be merge / pull requests to master, where a review has taken place. I am amazed just how many orgs (still) do not do this.

  • ph
    24 November 2022

    My brother used to get a kick out of writing entire programs in one line of coder under APL. He and I, albeit in different languages, normally wrote well documented code, generally fully structured, using libraries and other shared code. Of course, if LOC determined, say, our pay, we could write truly krappy code with far more lines than needed to do the job properly. Though both of us are too stubborn to stay at any place that stupid.

  • Sq
    23 November 2022

    Many great contributions delete accidental complexity leaving the solution vastly simplified and easier to maintain. LOC difference is often negative in such cases. Does it mean that it translates to negative productivity?

Apply for jobs

Find thousands of jobs in financial services and technology by signing up to eFinancialCareers today.

Boost your career

Find thousands of job opportunities by signing up to eFinancialCareers today.
Latest Jobs
State Street Corporation
Bank Loans Transformation, AVP
State Street Corporation
Dublin, Ireland
State Street Corporation
Transfer Agency Fund Events Officer
State Street Corporation
Kilkenny, Ireland
State Street Corporation
Transfer Agency, Senior Associate
State Street Corporation
Dublin, Ireland
State Street Corporation
Business Strategy - Organisation and Governance-Officer
State Street Corporation
Kilkenny, Ireland