It’s Simpler than You Think

Writing bad code is simpler than you think. Yada-yadas will make you believe that it takes special skills to craft junk code, that only a “chosen few” among us are capable of doing it. They may trick you into thinking that it takes a lot of apathy, the ability to hand wave, the special gut feeling to make bad assumptions, and a keen, sharp focus on the short term (or smaller picture). Sounds like a lot, doesn’t it?

Well, to tell you the truth, it’s not that hard. For those of you who strive to write poor code, with a special focus on screwing up on big data jobs, I have compiled a set of action items that will help you in embarking on this journey.

A word of warning is in order. As you read through the 16 points, you may get demotivated. You may think you’ll never be one of them. To fight such dark thoughts, you may want to think about the developers you had written off as good; haven’t you seen them doing one of these? If they can do it, so can you!

0. Don’t Unit Test

1. Don’t Waste Time Thinking About Names

2. Documentation is Useless

3. Either Comment Nowhere, or Comment Everywhere

4. If You Think it Will Work, it Will Work

5. Early Optimization is Evil so Write Stupid Code

6. Head start: Start Coding Before You Know What’s to be Done

7. Specifications less than 100 pages are useless

8. The First Test should be on a Billion Lines, in Distributed Mode

9. Your Work is Good Enough to Live on master branch at All Times

A. No One Can Review Your Code Once It’s Written, Ideally Not Even You

B. If the following hugeData.flatMap().reduceByKey().groupByKey().map(_.toString) throws a OOM, Spark must be a fad.

C. Big O Matters for People In School taking Algorithms Courses

D. If the Job Finished, the Data has to be Right

E. If the Job Crashes on a 100 Cores, All You Need is 200 Cores

F. Don’t Waste Time Looking at the Data

thatsIt. now_go_rock!

---

Edit: Hacker News Discussion