Maliciously compliant with LOC performance metrics

Level 1: All Pages, No Answers

Imagine your teacher says, “Whoever writes the longest essay will get a prize.” 📚 Now, instead of actually writing a good story or answers, one clever kid just writes random words and letters on a ton of pages. They even draw a silly picture out of letters that takes up many lines. So their essay ends up super long, maybe the longest in the class, but it’s mostly nonsense. When the teacher (who’s like the experienced person checking the work) actually reads it, they realize the student was just trying to look good by making it long, without doing the real work. The teacher and the other kids would probably laugh a little because it’s such an obvious trick, but the teacher definitely wouldn’t give that kid a good grade just for having more pages. In fact, they’d likely be annoyed and say, “This isn’t what I asked for.”

This is exactly what’s happening in the meme, but with computer code. The company thought “more lines of code = better work,” so the developer filled their program with a big art picture made of text (which doesn’t help the program at all) just to make it look longer. The senior engineers are like the teacher, noticing the trick and shaking their heads. The joke is funny because it shows how silly it is to judge work just by quantity instead of quality – whether it’s pages in an essay or lines in a code file.

Level 2: Counting Comments as Code

Let’s break this down in simpler terms. The meme highlights a situation involving line-count metrics and a sneaky way a developer tried to exploit them. Many companies (usually non-technical managers or misguided Management/PMs) sometimes use “lines of code” (LOC) as a measure of a developer’s productivity. That means they might think a programmer who writes 500 lines in a week is doing more work (or doing a better job) than one who wrote 50 lines. It’s an easy number to grab, but it doesn’t tell the whole story. This meme shows a DeveloperHumor twist on that: the developer literally padded their code with a bunch of ASCII art comments to increase the line count without adding any real functionality. ASCII art is when you draw a picture using text characters (like making a smiley face out of punctuation and letters). Here, the picture is embedded in the code file as a giant comment block. Comments in code are text meant for humans to read (like notes or descriptions), and the computer ignores them when running the program. They often appear in green in code editors (as shown in the screenshot).

In the image (a VSCode screenshot of a TypeScript file named app.ts), lines 165 through 197 are all prefixed with //. In TypeScript (and many languages like JavaScript, C, etc.), // starts a single-line comment. Everything after those slashes on that line is not executed as code. So what the developer did was insert a multi-line artwork made of symbols and letters, all commented out. It likely looks like a face or some design when you see it monospaced in the editor. It doesn’t matter what the art is — the key is that it’s completely non-functional. But guess what? Those are still lines in the file. If someone is counting “how many lines of code did Bob write this month?”, these comment lines will count towards that number unless the counting tool is smart enough to ignore comments (and many simple metrics tools are not that smart). This is an example of loc_gaming: gaming (i.e., tricking or exploiting) the lines-of-code metric.

Now, imagine you’re a senior engineer reviewing this code (doing a code review). You open the diff expecting to see useful code changes, and instead you see a huge chunk of green text that’s just an ASCII caricature staring back at you. You’d probably react with confusion or skepticism: “Why on Earth is this here?!” 🤨 It’s immediately clear that those lines don’t do anything for the program. In a code review, that’s a big issue because every line in the codebase has a cost – someone might have to read it, maintain it, or remove it later. So filler like this is considered really bad for CodeQuality and maintainability. This is a prime example of a CodeReviewPainPoint where a reviewer has to call out unnecessary or low-value additions. It might be funny as a joke, but it would almost certainly not be allowed into the production code. A comment with ASCII art might be okay in a fun open-source project README or in a demo, but not in serious application code just to meet a bogus metric. The senior devs know that if you start letting things like this slide, you end up with bloated, hard-to-read code. It doesn’t actually make the software better for users at all.

Let’s also talk about why a developer might do this. If the company culture or a project manager is measuring performance by LOC, developers (especially less experienced ones or those under pressure) might feel the need to write as many lines as possible. This is a known performance_measurement_flaw because it encourages the wrong behavior. A good developer will try to write clean, efficient code, which often means fewer lines – not more. For example, if I can solve a problem in 10 well-written lines instead of 50, that’s usually a positive thing. But a naive metric would make it look like I did “less work” than someone who wrote 50 lines of messy code. In some extreme cases, people have indeed tried to cheat the system. They might copy-paste code, write things in a very roundabout way, or, as shown here, add huge comment blocks or unnecessary text, just to inflate the numbers. It’s a form of “malicious compliance” – doing exactly what the metric asks for, knowing it’s silly.

For a junior developer or anyone new to this concept, here are the key points to understand:

• Line of Code (LOC) Metric: This is counting how many lines are in your program. Some managers wrongly use it to judge developer productivity. It’s like thinking a book is better just because it has more pages.
• ASCII Art in Comments: ASCII art means creating pictures out of standard text characters. Putting ASCII art in comments means those pictures live in the code file but don’t affect how the code runs. It’s decorative (or in this case, done to cheat the numbers).
• Code Review: This is the process where other developers (often senior or peers) look over your code changes. They make sure the code is good quality, works, and doesn’t include anything weird... like a giant commented picture that shouldn’t be there.
• Senior Engineers’ Perspective: Experienced devs care about what the code does, not just how it looks in metrics. They’ve likely seen misguided attempts to measure productivity before. So when they review code and see something that was obviously done just to tick a box (like “wrote X lines this week”), they’ll be skeptical and probably have a talk with you (or with management) about why that’s not okay.

The meme is ManagementHumor because it pokes fun at the idea that management sometimes values the wrong things. It’s also DeveloperHumor because developers share these stories to commiserate. Many of us have early career memories of a boss or client asking for something silly like “include more comments” or “make it longer” because they didn’t know better. And we learn quickly that more lines do not equal more productivity. In fact, there’s pride in writing concise, clear code – like when a junior dev first discovers how to replace 20 lines of clunky code with 5 elegant lines, that’s a victory! So this meme is a lighthearted lesson: developer productivity is not a number you can measure by simple metrics like LOC. If you try, engineers will either (a) get frustrated, or (b) do absurd things like this ASCII art stunt to point out how silly it is. And the senior engineers will be the ones facepalming and explaining to management why focusing on code quality and actual features is more important than any raw line count.

Level 3: Green Comments, Red Flags

In the top panel of this meme, management proudly declares a classic blunder: “use line count to measure performance.” This is the kind of metric that makes every seasoned engineer facepalm. Why? Because experienced devs know that lines of code (LOC) are a terrible proxy for real productivity or CodeQuality. In the bottom panel (a Visual Studio Code screenshot of a TypeScript file), a senior engineer is reviewing code and sees something immediately fishy: lines 165-197 are a giant green blob of commented-out ASCII art. Those green comment lines might form a cool picture (some kind of face, likely a cheeky grin), but they set off red flags in a code review. It’s a blatant case of LOC gaming – the developer has padded the source with dozens of useless lines just to boost the count. This triggers knowing groans and dark chuckles among veteran developers.

From a senior’s perspective, this is a classic example of Goodhart’s Law in software: “When a measure becomes a target, it ceases to be a good measure.” The company chose raw line count as a performance metric, so the developer cleverly (if cynically) gamed the system by adding lines that do nothing. The result? The lines-of-code metric goes up, giving some manager a warm fuzzy feeling that productivity increased, even though the code’s actual functionality hasn’t improved at all. In fact, code filled with ASCII art comments or other fluff is harder to maintain, not easier. Senior engineers see this and immediately recognize it as ManagementHumor meets CodeReviewPainPoints: it’s funny in a dark way, because it highlights how out-of-touch metrics can incentivize the wrong behavior.

Let’s unpack the humor technically. This code is a TypeScript (.ts) file open in VSCode. We see the status bar reading “TypeScript 4.3.5” and line “Ln 197, Col 84” – so the file is at least 197 lines long. But lines 165 through 197 are entirely taken up by a commented block that forms an ASCII-art face. In the minimap on the right, you can literally see the outline of the face drawn in green. It’s large and detailed, composed of characters like !, /, G, 0, and C arranged just so. All these lines start with //, marking them as comments which the TypeScript compiler will ignore completely. They have zero effect on the program’s behavior. However, if some naive metric tool or clueless PM is counting “number of lines in the file” or “lines added this week,” these 33 extra lines of art will inflate those stats. It’s a tongue-in-cheek form of loc_gaming: padding the stats with artful nonsense.

In a real code review (an assessment of code changes before they’re merged), a senior engineer’s reaction would be equal parts skepticism and amusement. On one hand, it’s hilarious as DeveloperHumor – the dev took management’s instruction so literally that they inserted a Mona Lisa made of code! On the other hand, it’s a bit infuriating for anyone who cares about CodeQuality. A senior reviewer would likely leave a comment like: “Umm… care to explain why half your diff is an ASCII portrait? 🧐” They know that true DeveloperProductivity isn’t measured in raw LOC. This meme captures that shared, bittersweet laugh: everyone with experience has seen metrics-driven absurdity like this. Maybe not ASCII art specifically, but definitely codebases bloated with useless code or over-commenting just to satisfy some KPI. The performance_measurement_flaws are obvious – more code doesn’t mean better code. As the saying goes, measuring programming progress by lines of code is like measuring aircraft building progress by weight. If you reward a developer for sheer bulk, you’ll get bulk – whether it’s good or not.

So the humor here is really a critique of management and a nod to battle-scarred devs. The company in the meme thinks counting lines is a great idea, but the senior engineers reviewing code aren’t so easily fooled. They’ve seen this movie before. They know a chunk of green comments in a diff is a red flag that someone is writing code to satisfy a metric rather than solve a problem. It’s a form of malicious compliance: the developer did exactly what was asked (write more lines) in the most absurd, literal way. The end result? The line count goes up, but the actual CodeQuality and feature progress stay the same (or even get worse, since now the codebase has a big chunk of nonsense in it). This meme delivers a sardonic lesson: if you set dumb metrics, don’t be surprised when you get dumb results. And any senior reviewer worth their salt is going to call it out with a raised eyebrow, just like we see here.

# Hypothetical outcome of the ASCII art commit:
$ git diff --stat
 app.ts | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

Above: The commit stats show “33 insertions” — looks like a super productive day, right? 😏 But as the code review reveals, those 33 lines are all fluff. The senior engineers aren’t impressed by numbers on a dashboard; they care about what the code actually does. In code review culture, quality trumps quantity, and this meme nails that truth with a dash of ManagementHumor and a knowing grin from the dev who drew that ASCII face.