TL;DR Programming

TL;DR, an abbreviation for “Too long; didn’t read”, is Internet slang used in reply to a lengthy online message. It is also used at the beginning of a summary of such a message. — Wikipedia.

TL;DR

This essay explores TL;DR in programming context. It tries to find out if the trend of TL;DR behaviour spreads to software development as well, and what are the dangers of that. It’s about Bob. It’s not about you. Good programmer don’t TL;DR. Good programmers read.

Enter Bob

Robert Kode¹ is a long-time programmer. Bob loves to code. He was programming since his early teens and is fluent in six languages. He speaks only English but can read and write the other five. These five are not used for speech.

Over the years Bob developed good know-how in many areas of software development and has an intuitive understanding of many concepts. He can crunch code fast and his code is fast.

It just so happens that Bob is a TL;DR programmer.

Too Long; Didn’t Read

TL;DR comes from the increasingly short attention span of today’s Internet generation. Do programmers also fall victim to the short attention span which leads to TL;DR?

Bob believes that programming is about writing. Writing code. Writing code comments. Writing commit messages.

Bob was assigned to write a new module for an application. He skimmed the requirements for the module. He skipped half the paragraphs in the email that described some focus points. He didn’t get back to them when he churned out lines of code.

Eventually, Bob’s module implemented half the cases it was supposed to support. In some cases, it did what it wasn’t meant to do. QA filed a ton of bugs and Bob found himself in Tester Driven Development mode.

Now he cannot afford to skip reading the bug reports.

Too Lazy; Didn’t Research

How much research had to be done before writing the first line of code for Apollo Project?

Bob’s got years of programming experience, as I said, so he relies on his intuition. Oftentimes more than he should.

This time our Mr. Kode got the kind of task that he liked. He was supposed to implement a peculiar data processing algorithm for, well, the data.

Bob had prior experience writing some algorithms and was excited about the new challenge. He conceived the general approach of the algorithm as he was reading the requirements. He might have overlooked some of the intricacies of the requirements (see above) so it didn’t help either.

Bob went right ahead to writing it. After half a day it kind of worked. There were some edge cases that required attention. It was also slow. It also didn’t scale well for high amounts of data. Another day went on trying to optimize it. Then another day. Then it started giving the wrong results. And crashing on the edge cases.

Robert didn’t invest the time to think through his idea before developing. It’s not easy, so he trusted his intuition instead.

Bob also didn’t run a relevant search on Google. If he had, he might have stumbled upon a paper, or a blog post, or an answer on Stack Overflow, any of which might have helped him select and implement the right approach. Research is hard. Bob didn’t research. Bob was a bit too lazy.

They say good programmers are lazy. But they say it for a different reason.

Q&!A

Q: Does TL;DR programming lead to the culture of Stack Overflow questions of “please give me code to do X”?

Q: Do we see more bugs today because of TL;DR attitude? Including critical bugs like Boeing 787 bug which could bring the plane down in one case? Or more security omissions?

Q: How many programmers just try things out until they work, sometimes without understanding the theoretical basis of why and how? Or choose a simpler, inadequate solution?

Q: Could this also apply to other aspects of the software business, like product and project management, software architecture and market research?

Q: Are you a little like our Bob? A: I am

👉 Discuss on Hacker News.