harisrid Tech News

Hello everyone !!!!

Today, I wanna dive into a technical opinion of mine – reasons why I’m against using LOC [ Lines of Code ] or Number of CLs [ Change Lists] as workplace performance indicators. They’re useful proxies, not exact perfect indicators, of leveling or performance. Let’s go into why.

Reason #1 : Good Engineers Usually Write Code – that Deletes Code? Wait what?

Conventional patterns typically hold true – the more senior and the more experienced a developer is, the more frequent they write and they release new source code.

Not exactly!

Patterns also have their exceptions and anomalies. And I’d also argue that the best engineers write little to no code. Experience teaches me that the best engineers are so good, that their changes tend deletative – they eliminate large chunks of code, configurations, data, and static files. I’ve seen engineers introduce code that entails a couple of extra steps and a dynamic configuration, but in the process, can delete 5000+ LOC or 20+ statically-written out files. These refactor efforts bolster long-running codebase health.

Reason #2 : LOC makes no sense for design work

LOC transitions to become a worse metric for more senior levels which naturally involve less coding. Seniors naturally spend more time in mentorship roles or advisory-esque roles – designing systems and solutioning multi-quarter ambiguous problems. What should the evaluation criteria entail for seniors or staff+ folks who spend six hours weekly in the design phase of stories, with minimal code units? What are good indicators or progress? Does delivering a rough-draft design document or a fully-fleshed out design document count? Or user stories and the minimal code for proof-of-concepts ( some of which can be quickly discarded )?

Reason #3 – Configuration Changes Carry Impact

We can run into scenarios where a few lines of code yields substantial impact; they are less “visible”, BUT, they carry long-running positive benefits. Let’s imagine engineers discover changes such as :

1. Better failure hailing – bolsters retry failure mode handling ( e.g. changing the number of retries for exponential backoff )
2. Deployment changes – Shifting an application’s YAML file from blue-green traffic deployment ( from 0%-100% sudden shift ) towards a canary traffic deployment ( 0%-20%-…-100% shifting ).
3. Auto-scaling policy change – discovers that they can change an auto-scaling policy’s min-#-instances and max-#-instances and saving on long-term cloud compute usage.
4. Expediting build-and-releases – pipelines and environments that aren’t up-to-date with the latest configurations slows down developer velocity. It turns out that the work done to execute R&D and set up the right set of configurations, dependencies, and tests for environments can yield tremendous impacts in feature delivery pace.

Reason #4 – Savings aren’t always in code

Did a developer figure out that we can save on database storage by updating our underlying schemas? Did they figure out how to leverage pre-existing compression algorithms and strategies?

Reason #5 – LOC and User Stories are “gameable”

Turns out smart engineers can easily figure out how to create a series of incredibly small change list and submit their code at a higher frequency, then they would have if they submitted their same units of code, but in slightly larger change lists. An engineer can figure out how to create to many user stories with minimal task sets, versus sufficiently-sized stories with an apropos number of tasks.

So how should I assess developers?

This is a really good question, and in my honest opinion, it’s better deserved to be on a case-by-case, set & setting basis. There’s no “one-size-fits-all” answer – and there probably won’t be one – since no single person has actually figured out the perfect approach. Intuition, instinct, holistic feedback ( from management, peers, and stakeholders), and project visibility play their roles in gauging long-term quality.

There’s a couple of better, but still imperfect measures, such as :

1. Total business revenue saved
2. Total profits generation
3. Number of customers/teams/end users onboarded.
4. Conversions of initial design documents to production-ready features
5. Number of direct reports/mentees getting promoted¹.
6. Number of interviews conducted.²
7. Demonstrates initiatives and takes on the right number of problems at the right level of scope.

1. This metric is more typical for leadership & management. Last I correctly recall, the success of managers is based on the success of their teams. ↩︎
2. Also questionable, since there’s hiring seasons and times when folks conduct fewer or more behavioral, coding, and system design interviews. ↩︎