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 Kode1 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.


  1. Fictional character ^

Toggle hosts file for less distractions (in Haskell)

I decided to edit the /etc/hosts file to block access to some domains that I compulsory visit when working, in order to reduce my distractions. The usual suspects are Twitter, Facebook, Hacker News, and some real-world news sites.

So I edited the file and added the following lines:

# -- WORK --
127.0.0.1     news.ycombinator.com
127.0.0.1     facebook.com
127.0.0.1     twitter.com

Now they’re blocked. But I also wanted the option to quickly comment this section out and back again.

I could do it quickly in Ruby but I thought that it would be a great way to exercise my basic Haskell skills.

It took me quite a while to get it right — my Haskell is rusty. But after it compiled, I only had one little logical bug, which I quickly found out and fixed.

The final code is below. It also backs up hosts file (just in case) and prints the resulting hosts file. Both of these steps could be removed, as they’re not important for its main functionality.

import Data.List

-- Starts toggling the comment after a line that starts with "# --"

processLine switch line
    | length line == 0                          = (switch, line)
    | switch == False && take 4 line == "# --"  = (True, line)
    | switch == True                            = (True, toggleLine line)
    | otherwise                                 = (switch, line)
      where toggleLine l
              | head l == '#' = tail l
              | otherwise     = "#" ++ l

process = snd . mapAccumL processLine False

main = do
  hosts <- readFile "/etc/hosts"
  writeFile "/etc/hosts.backup" hosts
  let newHosts = unlines $ process (lines hosts)
  putStrLn newHosts
  writeFile "/etc/hosts" newHosts

I’m sure this could be done shorter, as everything in Haskell, but I’m just a beginner.

I then compiled the code and put the binary in my user’s bin folder.

Since it edits the /etc/hosts file, it has to be run with sudo. I added a line to sudo permissions (run sudo visudo to edit the file) to allow me to run it without a password:

jacob ALL = NOPASSWD: /Users/jacob/bin/switch_hosts

Then, I added an action to Keyboard Maestro to run sudo /Users/jacob/bin/switch_hosts using a trigger in its system menu. You could do a hotkey trigger or use a TextExpander expansion, or use LaunchBar, or Alfred, or just type it in the Terminal.

It just was this kind of day. I couldn’t do real work, but I could play a little to make my environment better for when I’ll be able to work.

Of course, there are commercial products that can help with distraction-free work environment, like Concentrate, which offers this and more. But I prefer to run less applications, if possible.