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: alex.mcmurray@efinancialcareers.com 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

 

author-card-avatar
AUTHORAlex McMurray
Cancel
  • Ri
    Rikette
    29 November 2022

    We faced this exact same problem at another bank, where they wanted to use an off-the-shelf product to measure productivity. An in-depth analysis proved that the people who had written that tool had no understanding of a developer's job, and were simply abusing CFOs.


    So we came up with our own tool, where the business would put a currency-less value in front of each user story, and the development team would gather that value once the user story was delivered in prod. We also monitored spending (using head count, not $). This gave each team a measure of how their productivity varied over time. You could observe the impact of a new joiner, of a leaver, of a refactoring. It was very useful...


    Since the measure was currency-less, you could not compare productivity across teams, which was a positive side effect since, although it's a legitimate ask, it's one that makes no sense since they're solving different problems.


    Then top management decided that every body should be using the off-the-shelf tool. I guess what they wanted to measure was the productivity across teams, regions...



  • Ma
    Matt
    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
    code1
    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
    photobug56
    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
    SquaremileDev
    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?

Show more

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.
Recommended Jobs
Capstone Investment Advisors (UK) LLP
2023 Investment Graduate Rotation Program
Capstone Investment Advisors (UK) LLP
London, United Kingdom
Pearse Partners
Hedge Fund Equity L/S Analyst
Pearse Partners
London, United Kingdom
Oxford Knight
Data Analyst - London- Quant Trading
Oxford Knight
London, United Kingdom
Selby Jennings
Quantitative Trader - HFT
Selby Jennings
London, United Kingdom